{"meta":{"title":"Миграция данных на GitHub Enterprise Server","intro":"После создания архива миграции вы можете импортировать данные в целевой GitHub Enterprise Server экземпляр. Вы сможете просмотреть изменения для потенциальных конфликтов, прежде чем окончательно применить изменения к целевому экземпляру.","product":"Миграции","breadcrumbs":[{"href":"/ru/enterprise-server@3.21/migrations","title":"Миграции"},{"href":"/ru/enterprise-server@3.21/migrations/using-ghe-migrator","title":"ghe-migrator"},{"href":"/ru/enterprise-server@3.21/migrations/using-ghe-migrator/migrating-data-to-github-enterprise-server","title":"Перенос данных"}],"documentType":"article"},"body":"# Миграция данных на GitHub Enterprise Server\n\nПосле создания архива миграции вы можете импортировать данные в целевой GitHub Enterprise Server экземпляр. Вы сможете просмотреть изменения для потенциальных конфликтов, прежде чем окончательно применить изменения к целевому экземпляру.\n\n## Подготовка перенесенных данных\n\n1. Используя команду [`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp) , скопируйте архив миграции, сгенерированный из исходного экземпляра или организации, на целевую GitHub Enterprise Server цель:\n\n   ```shell\n   scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/\n   ```\n\n2. SSH в целевом GitHub Enterprise Server экземпляре. Дополнительные сведения см. в разделе [Доступ к административной оболочке (SSH)](/ru/enterprise-server@3.21/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).\n\n   ```shell\n   ssh -p 122 admin@HOSTNAME\n   ```\n\n3. Убедитесь, что архив миграции имеет достаточные разрешения на чтение.\n\n   ```shell\n   chmod 644 /home/admin/MIGRATION-GUID.tar.gz\n   ```\n\n4. Используйте команду `ghe-migrator prepare`, чтобы подготовить архив для импорта в целевой экземпляр и создать новый уникальный идентификатор миграции, который будет использоваться в последующих шагах:\n\n   ```shell\n   ghe-migrator prepare /home/admin/MIGRATION-GUID.tar.gz\n   ```\n\n   * Чтобы начать новую попытку импорта, запустите `ghe-migrator prepare` еще раз и получите новый уникальный идентификатор миграции.\n   * Чтобы указать, где следует выполнить подготовку файлов миграции, добавьте команду с `--staging-path=/full/staging/path`. По умолчанию — `/data/user/tmp`.\n\n## Создание списка конфликтов миграции\n\n1. Используя команду `ghe-migrator conflicts` с уникальным идентификатором миграции, создайте файл *conflicts.csv*:\n\n   ```shell\n   ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv\n   ```\n\n   * Если не сообщается о конфликтах, можно безопасно импортировать данные.\n\n2. При наличии конфликтов с помощью команды [`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp) скопируйте *conflicts.csv* на локальный компьютер:\n\n   ```shell\n   scp -P 122 admin@HOSTNAME:conflicts.csv ~/Desktop\n   ```\n\n3. [Продолжайте устранять конфликты миграции или настраивать пользовательские](#resolving-migration-conflicts-or-setting-up-custom-mappings) сопоставления.\n\n## Просмотр конфликтов миграции\n\n1. Откройте [conflicts.csv](https://en.wikipedia.org/wiki/Comma-separated_values#Application_support) с помощью текстового редактора или *программного обеспечения для работы с электронными таблицами, совместимого с форматом CSV*.\n2. Руководствуясь приведенными ниже примерами и справочными таблицами, просмотрите файл *conflicts.csv*, чтобы убедиться, что при импорте будут выполнены соответствующие действия.\n\nФайл *conflicts.csv* содержит *карту миграции* конфликтов и рекомендуемые действия. Карта миграции содержит сведения о том, какие данные переносятся из источника и как данные будут применены к целевому объекту.\n\n| `model_name`   | `source_url`                                           | `target_url`                                           | `recommended_action` |\n| -------------- | ------------------------------------------------------ | ------------------------------------------------------ | -------------------- |\n| `user`         | `https://example-gh.source/octocat`                    | `https://example-gh.target/octocat`                    | `map`                |\n| `organization` | `https://example-gh.source/octo-org`                   | `https://example-gh.target/octo-org`                   | `map`                |\n| `repository`   | `https://example-gh.source/octo-org/widgets`           | `https://example-gh.target/octo-org/widgets`           | `rename`             |\n| `team`         | `https://example-gh.source/orgs/octo-org/teams/admins` | `https://example-gh.target/orgs/octo-org/teams/admins` | `merge`              |\n\nКаждая строка в *conflicts.csv* предоставляет следующие сведения:\n\n| Имя                  | Описание                                                                       |\n| -------------------- | ------------------------------------------------------------------------------ |\n| `model_name`         | Тип изменяемых данных.                                                         |\n| `source_url`         | Исходный URL-адрес данных.                                                     |\n| `target_url`         | Ожидаемый целевой URL-адрес данных.                                            |\n| `recommended_action` | Предпочтительное действие, которое выполнит `ghe-migrator` при импорте данных. |\n\n### Возможные сопоставления для каждого типа записи\n\nСуществует несколько различных действий сопоставления, которые `ghe-migrator` может выполнить при передаче данных:\n\n| `action`        | Описание                                                                                                                                                                                                                                                                           | Применимые модели                      |\n| --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- |\n| `import`        | (по умолчанию) Данные из источника импортируются в целевой объект.                                                                                                                                                                                                                 | Все типы записей                       |\n| `map`           | Вместо создания новой модели на основе исходных данных используется существующая запись в целевом объекте. Полезно для импорта репозитория в существующую организацию или сопоставления удостоверений пользователей в целевом объекте с удостоверениями пользователей в источнике. | Пользователи, организации              |\n| `rename`        | Данные из источника переименовываются, а затем копируются в целевой объект.                                                                                                                                                                                                        | Пользователи, организации, репозитории |\n| `map_or_rename` | Если целевой объект существует, данные сопоставляются с ним. В противном случае импортированная модель переименовывается.                                                                                                                                                          | Пользователи                           |\n| `merge`         | Данные из источника совмещаются с существующими данными в целевом объекте.                                                                                                                                                                                                         | Teams                                  |\n\n**Мы настоятельно рекомендуем просмотреть файл *conflicts.csv* и использовать `ghe-migrator audit`, чтобы убедиться, что выполняются нужные действия.** Если все выглядит хорошо, можно продолжить.\n\n## Устранение конфликтов миграции или настройка пользовательских сопоставлений\n\nЕсли вы считаете, что `ghe-migrator` выполнит неправильное изменение, можно внести исправления, изменив данные в *conflicts.csv*. Вы можете внести изменения в любую из строк в *conflicts.csv*.\n\nНапример, предположим, что `octocat` пользователь из источника сопоставляется с `octocat` целевым объектом.\n\n| `model_name` | `source_url`                        | `target_url`                        | `recommended_action` |\n| ------------ | ----------------------------------- | ----------------------------------- | -------------------- |\n| `user`       | `https://example-gh.source/octocat` | `https://example-gh.target/octocat` | `map`                |\n\nВы можете сопоставить пользователя с другим пользователем в целевом объекте. Предположим, вы знаете, что `octocat` на самом деле должен быть `monalisa` в целевом объекте. Столбец можно изменить `target_url` в *conflicts.csv* , чтобы ссылаться `monalisa`на .\n\n| `model_name` | `source_url`                        | `target_url`                         | `recommended_action` |\n| ------------ | ----------------------------------- | ------------------------------------ | -------------------- |\n| `user`       | `https://example-gh.source/octocat` | `https://example-gh.target/monalisa` | `map`                |\n\nВ качестве другого примера, если вы хотите переименовать репозиторий в целевой экземпляр, измените его `octo-org/widgets` на `octo-org/amazing-widgets` и на `target_url``octo-org/amazing-widgets`.`recommend_action``rename`\n\n| `model_name` | `source_url`                                 | `target_url`                                         | `recommended_action` |\n| ------------ | -------------------------------------------- | ---------------------------------------------------- | -------------------- |\n| `repository` | `https://example-gh.source/octo-org/widgets` | `https://example-gh.target/octo-org/amazing-widgets` | `rename`             |\n\n### Добавление пользовательских сопоставлений\n\nРаспространенный сценарий во время миграции заключается в том, что у имена перенесенных пользователей в целевом объекте будут отличаться от тех, что назначены им в источнике.\n\nИмея список имен пользователей в источнике и список имен пользователей в целевом объекте, вы можете создать CSV-файл с пользовательскими сопоставлениями, а затем применить его, чтобы имена пользователей и их данные были правильно сопоставлены после миграции.\n\nВы можете быстро создать CSV-файл пользователей, которые переносятся. Он необходим для применения пользовательских сопоставлений с помощью команды `ghe-migrator audit`:\n\n```shell\nghe-migrator audit -m user -g MIGRATION-GUID > users.csv\n```\n\nТеперь вы можете изменить этот CSV-файл и ввести новый URL-адрес для каждого пользователя, которого вы хотите сопоставить или переименовать, а затем обновить четвертый столбец, чтобы выполнить `map` или `rename`.\n\nНапример, чтобы переименовать пользователя `octocat` в `monalisa` в целевом объекте `https://example-gh.target` создайте строку со следующим содержимым:\n\n| `model_name` | `source_url`                        | `target_url`                         | `state`  |\n| ------------ | ----------------------------------- | ------------------------------------ | -------- |\n| `user`       | `https://example-gh.source/octocat` | `https://example-gh.target/monalisa` | `rename` |\n\nОдин и тот же процесс можно использовать для создания сопоставлений для каждой записи, поддерживающей пользовательские сопоставления. Дополнительные сведения см. в [таблице возможных сопоставлений записей](#possible-mappings-for-each-record-type).\n\n### Применение измененных данных миграции\n\n1. После внесения изменений используйте команду [`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp) для применения измененного файла *conflicts.csv* (или любого другого файла *.csv* сопоставлений в правильном формате) к целевому экземпляру:\n\n   ```shell\n   scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/\n   ```\n\n2. Повторно сопоставите данные миграции с помощью команды `ghe-migrator map`, передав путь к измененным файлу *.csv* и уникальному идентификатору миграции:\n\n   ```shell\n   ghe-migrator map -i conflicts.csv -g MIGRATION-GUID\n   ```\n\n3. Если команда `ghe-migrator map -i conflicts.csv -g MIGRATION-GUID` сообщит, что конфликты по-прежнему существуют, снова выполните процесс разрешения конфликтов миграции.\n\n## Применение импортированных данных на GitHub Enterprise Server\n\n1. SSH в целевом GitHub Enterprise Server экземпляре. Дополнительные сведения см. в разделе [Доступ к административной оболочке (SSH)](/ru/enterprise-server@3.21/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).\n\n   ```shell\n   ssh -p 122 admin@HOSTNAME\n   ```\n\n2. С помощью команды `ghe-migrator import` запустите процесс импорта. Что вам понадобится:\n\n   * GUID миграции. Для получения дополнительной информации см. [раздел «Подготовка мигрированных данных для импорта в GitHub Enterprise Server](#preparing-the-migrated-data).\n   * Ты personal access token для аутентификации. Используемый вами файл personal access token предназначен только для аутентификации как администратора сайта и не требует специального объёма или разрешений. Дополнительные сведения см. в разделе [Управление личными маркерами доступа](/ru/enterprise-server@3.21/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).\n\n   ```shell\n   $ ghe-migrator import /home/admin/MIGRATION-GUID.tar.gz -g MIGRATION-GUID -u USERNAME -p TOKEN\n\n   > Starting GitHub::Migrator\n   > Import 100% complete /\n   ```\n\n   * Чтобы указать, где следует выполнить подготовку файлов миграции, добавьте команду с `--staging-path=/full/staging/path`. По умолчанию — `/data/user/tmp`.\n\n## Проверка данных миграции\n\nПо умолчанию `ghe-migrator audit` возвращает каждую запись. Кроме того, это позволяет фильтровать записи по следующим критериям:\n\n* Типы записей.\n* Состояние записей.\n\nТипы записей соответствуют тем, которые находятся в [перенесенных данных](/ru/enterprise-server@3.21/migrations/using-ghe-migrator/about-ghe-migrator#migrated-data).\n\n## Фильтры типов записей\n\n| Тип записи                                                    | Имя фильтра                   |\n| ------------------------------------------------------------- | ----------------------------- |\n| Пользователи                                                  | `user`                        |\n| Организации                                                   | `organization`                |\n| Репозитории                                                   | `repository`                  |\n| Teams                                                         | `team`                        |\n| Milestones                                                    | `milestone`                   |\n| Проблемы                                                      | `issue`                       |\n| Комментарии к проблеме                                        | `issue_comment`               |\n| Запросы на включение внесенных изменений                      | `pull_request`                |\n| Проверки запросов на включение изменений                      | `pull_request_review`         |\n| Комментарии к фиксации                                        | `commit_comment`              |\n| Комментарии к проверке запроса на вытягивание                 | `pull_request_review_comment` |\n| Выпуски                                                       | `release`                     |\n| Действия, выполняемые для запросов на вытягивание или проблем | `issue_event`                 |\n| Защищенные ветви                                              | `protected_branch`            |\n\n## Фильтры состояния записи\n\n| Состояние записи | Описание                          |\n| ---------------- | --------------------------------- |\n| `export`         | Запись будет экспортирована.      |\n| `import`         | Запись будет импортирована.       |\n| `map`            | Запись будет сопоставлена.        |\n| `rename`         | Запись будет сопоставлена.        |\n| `merge`          | Запись будет объединена.          |\n| `exported`       | Запись экспортирована успешно.    |\n| `imported`       | Запись импортирована успешно.     |\n| `mapped`         | Запись сопоставлена успешно.      |\n| `renamed`        | Запись переименована успешно.     |\n| `merged`         | Запись объединена успешно.        |\n| `failed_export`  | Не удалось экспортировать запись. |\n| `failed_import`  | Не удалось импортировать запись.  |\n| `failed_map`     | Не удалось сопоставить запись.    |\n| `failed_rename`  | Не удалось переименовать запись.  |\n| `failed_merge`   | Не удалось объединить запись.     |\n\n## Фильтрация записей аудита\n\nС помощью команды `ghe-migrator audit` можно отфильтровать данные по типу записи с помощью флага `-m`. Аналогичным образом можно отфильтровать состояние импорта с помощью флага `-s`. Эта команда выглядит следующим образом:\n\n```shell\nghe-migrator audit -m RECORD_TYPE -s STATE -g MIGRATION-GUID\n```\n\nНапример, чтобы просмотреть каждую успешно импортированную организацию и команду, необходимо ввести следующее:\n\n```shell\n$ ghe-migrator audit -m organization,team -s mapped,renamed -g MIGRATION-GUID\n> model_name,source_url,target_url,state\n> organization,https://gh.source/octo-org/,https://ghe.target/octo-org/,renamed\n```\n\n**Настоятельно рекомендуется проводить аудит каждой операции импорта, завершившейся сбоем.** Для этого введите:\n\n```shell\n$ ghe-migrator audit -s failed_import,failed_map,failed_rename,failed_merge -g MIGRATION-GUID\n> model_name,source_url,target_url,state\n> user,https://gh.source/octocat,https://gh.target/octocat,failed\n> repository,https://gh.source/octo-org/octo-project,https://ghe.target/octo-org/octo-project,failed\n```\n\nЕсли у вас есть опасения по поводу неудачного импорта, вы можете связаться с нами, посетив [Поддержка GitHub Enterprise](https://support.github.com).\n\n## Завершение импорта на GitHub Enterprise Server\n\nПосле применения миграции к целевому экземпляру и проверки миграции следует разблокировать репозитории и удалить их из источника. Перед удалением исходных данных рекомендуется подождать около двух недель, чтобы убедиться, что все работает должным образом.\n\n## Разблокировка репозиториев на целевом экземпляре\n\n1. SSH в ваш экземпляр GitHub Enterprise Server. Если экземпляр состоит из нескольких узлов, например, если настроен высокий уровень доступности или георепликация, передача осуществляется по SSH в основной узел. При использовании кластера можно использовать для передачи по SSH в любой узел. Замените HOSTNAME именем узла для экземпляра, именем узла или IP-адресом узла. Дополнительные сведения см. в разделе [Доступ к административной оболочке (SSH)](/ru/enterprise-server@3.21/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).\n\n   ```shell copy\n   ssh -p 122 admin@HOSTNAME\n   ```\n2. Разблокируйте все импортированные репозитории с помощью команды `ghe-migrator unlock`. Вам потребуется GUID миграции:\n\n```shell\n$ ghe-migrator unlock -g MIGRATION-GUID\n> Unlocked octo-org/octo-project\n```\n\n> \\[!WARNING]\n> Если в вашем репозитории есть GitHub Actions рабочие процессы, использующие триггер `schedule` , рабочие процессы не будут запускаться автоматически после импорта. Чтобы снова запустить запланированные рабочие процессы, отправьте фиксацию в репозиторий. Дополнительные сведения см. в разделе [События, инициирующие рабочие процессы](/ru/enterprise-server@3.21/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).\n\n## Разблокировка репозиториев в источнике\n\nПосле завершения миграции необходимо разблокировать репозитории в источнике.\n\n### Разблокировка репозиториев из организации на GitHub.com\n\nЧтобы разблокировать репозитории организации GitHub.com , вы отправляете `DELETE` запрос на [конечную точку разблокировки миграции](/ru/rest/migrations#unlock-an-organization-repository). Что вам понадобится:\n\n* Маркер доступа для проверки подлинности\n* Уникальный `id` миграции\n* Имя репозитория для разблокировки\n\n```shell\ncurl -H \"Authorization: Bearer GITHUB_ACCESS_TOKEN\" -X DELETE \\\n  -H \"Accept: application/vnd.github.wyandotte-preview+json\" \\\n  https://api.github.com/orgs/ORG-NAME/migrations/ID/repos/REPO_NAME/lock\n```\n\n### Удаление репозиториев из организации на GitHub.com\n\nПосле разблокировки репозиториев организации следует удалить все репозитории, которые GitHub.com вы ранее мигрировали через [эндпоинт удаления репозитория](/ru/enterprise-server@3.21/rest/repos/repos#delete-a-repository). Вам потребуется маркер доступа для проверки подлинности\n\n```shell\ncurl -H \"Authorization: Bearer GITHUB_ACCESS_TOKEN\" -X DELETE \\\n  https://api.github.com/repos/ORG-NAME/REPO_NAME\n```\n\n### Разблокировка репозиториев из экземпляра GitHub Enterprise Server\n\n1. SSH в ваш экземпляр GitHub Enterprise Server. Если экземпляр состоит из нескольких узлов, например, если настроен высокий уровень доступности или георепликация, передача осуществляется по SSH в основной узел. При использовании кластера можно использовать для передачи по SSH в любой узел. Замените HOSTNAME именем узла для экземпляра, именем узла или IP-адресом узла. Дополнительные сведения см. в разделе [Доступ к административной оболочке (SSH)](/ru/enterprise-server@3.21/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).\n\n   ```shell copy\n   ssh -p 122 admin@HOSTNAME\n   ```\n2. Разблокируйте все импортированные репозитории с помощью команды `ghe-migrator unlock`. Вам потребуется GUID миграции:\n\n```shell\n$ ghe-migrator unlock -g MIGRATION-GUID\n> Unlocked octo-org/octo-project\n```"}