Skip to main content

Перенос данных на GitHub Enterprise Server

После создания архива миграции можно импортировать данные в целевой экземпляр GitHub Enterprise Server. Вы сможете просмотреть изменения для потенциальных конфликтов, прежде чем окончательно применить изменения к целевому экземпляру.

Подготовка перенесенных данных

  1. С помощью команды scp скопируйте архив миграции, созданный из исходного экземпляра или организации, в целевой объект GitHub Enterprise Server:

    scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/
    
  2. SSH в целевом экземпляре GitHub Enterprise Server. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

    ssh -p 122 admin@HOSTNAME
    
  3. Используйте команду ghe-migrator prepare, чтобы подготовить архив для импорта в целевой экземпляр и создать новый уникальный идентификатор миграции, который будет использоваться в последующих шагах:

    ghe-migrator prepare /home/admin/MIGRATION-GUID.tar.gz
    
    • Чтобы начать новую попытку импорта, запустите ghe-migrator prepare еще раз и получите новый уникальный идентификатор миграции.
    • Чтобы указать, где следует выполнить подготовку файлов миграции, добавьте команду с --staging-path=/full/staging/path. По умолчанию — /data/user/tmp.

Создание списка конфликтов миграции

  1. Используя команду ghe-migrator conflicts с уникальным идентификатором миграции, создайте файл conflicts.csv:

    ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv
    
    • Если не сообщается о конфликтах, можно безопасно импортировать данные.
  2. При наличии конфликтов с помощью команды scp скопируйте conflicts.csv на локальный компьютер:

    scp -P 122 admin@HOSTNAME:conflicts.csv ~/Desktop
    
  3. Перейдите к разделу Устранение конфликтов миграции или настройка пользовательских сопоставлений.

Просмотр конфликтов миграции

  1. Откройте conflicts.csv с помощью текстового редактора или программного обеспечения для работы с электронными таблицами, совместимого с форматом CSV.
  2. Руководствуясь приведенными ниже примерами и справочными таблицами, просмотрите файл conflicts.csv, чтобы убедиться, что при импорте будут выполнены соответствующие действия.

Файл conflicts.csv содержит карту миграции конфликтов и рекомендуемые действия. Карта миграции содержит сведения о том, какие данные переносятся из источника и как данные будут применены к целевому объекту.

model_namesource_urltarget_urlrecommended_action
userhttps://example-gh.source/octocathttps://example-gh.target/octocatmap
organizationhttps://example-gh.source/octo-orghttps://example-gh.target/octo-orgmap
repositoryhttps://example-gh.source/octo-org/widgetshttps://example-gh.target/octo-org/widgetsrename
teamhttps://example-gh.source/orgs/octo-org/teams/adminshttps://example-gh.target/orgs/octo-org/teams/adminsmerge
projecthttps://example-gh.source/octo-org/widgets/projects/1https://example-gh.target/octo-org/projects/1merge

Каждая строка в conflicts.csv предоставляет следующие сведения:

ИмяОписание
model_nameТип изменяемых данных.
source_urlИсходный URL-адрес данных.
target_urlОжидаемый целевой URL-адрес данных.
recommended_actionПредпочтительное действие, которое выполнит ghe-migrator при импорте данных.

Возможные сопоставления для каждого типа записи

Существует несколько различных действий сопоставления, которые ghe-migrator может выполнить при передаче данных:

actionDescriptionПрименимые модели
import(по умолчанию) Данные из источника импортируются в целевой объект.Все типы записей
mapВместо создания новой модели на основе исходных данных используется существующая запись в целевом объекте. Полезно для импорта репозитория в существующую организацию или сопоставления удостоверений пользователей в целевом объекте с удостоверениями пользователей в источнике.Пользователи, организации, проекты
renameДанные из источника переименовываются, а затем копируются в целевой объект.Пользователи, организации, репозитории, проекты
map_or_renameЕсли целевой объект существует, данные сопоставляются с ним. В противном случае импортированная модель переименовывается.Пользователи
mergeДанные из источника совмещаются с существующими данными в целевом объекте.Teams, проекты

Мы настоятельно рекомендуем просмотреть файл conflicts.csv и использовать ghe-migrator audit, чтобы убедиться, что выполняются нужные действия. Если все выглядит хорошо, можно продолжить.

Устранение конфликтов миграции или настройка пользовательских сопоставлений

Если вы считаете, что ghe-migrator выполнит неправильное изменение, можно внести исправления, изменив данные в conflicts.csv. Вы можете внести изменения в любую из строк в conflicts.csv.

Например, предположим, что octocat пользователь из источника сопоставляется с octocat целевым объектом.

model_namesource_urltarget_urlrecommended_action
userhttps://example-gh.source/octocathttps://example-gh.target/octocatmap

Вы можете сопоставить пользователя с другим пользователем в целевом объекте. Предположим, вы знаете, что octocat на самом деле должен быть monalisa в целевом объекте. Столбец можно изменить target_url в conflicts.csv , чтобы ссылаться monalisaна .

model_namesource_urltarget_urlrecommended_action
userhttps://example-gh.source/octocathttps://example-gh.target/monalisamap

В качестве другого примера, если вы хотите переименовать репозиторий в целевой экземпляр, измените его target_url на octo-org/amazing-widgets и на recommend_action rename.octo-org/widgets octo-org/amazing-widgets

model_namesource_urltarget_urlrecommended_action
repositoryhttps://example-gh.source/octo-org/widgetshttps://example-gh.target/octo-org/amazing-widgetsrename

Добавление пользовательских сопоставлений

Распространенный сценарий во время миграции заключается в том, что у имена перенесенных пользователей в целевом объекте будут отличаться от тех, что назначены им в источнике.

Имея список имен пользователей в источнике и список имен пользователей в целевом объекте, вы можете создать CSV-файл с пользовательскими сопоставлениями, а затем применить его, чтобы имена пользователей и их данные были правильно сопоставлены после миграции.

Вы можете быстро создать CSV-файл пользователей, которые переносятся. Он необходим для применения пользовательских сопоставлений с помощью команды ghe-migrator audit:

ghe-migrator audit -m user -g MIGRATION-GUID > users.csv

Теперь вы можете изменить этот CSV-файл и ввести новый URL-адрес для каждого пользователя, которого вы хотите сопоставить или переименовать, а затем обновить четвертый столбец, чтобы выполнить map или rename.

Например, чтобы переименовать пользователя octocat в monalisa в целевом объекте https://example-gh.target создайте строку со следующим содержимым:

model_namesource_urltarget_urlstate
userhttps://example-gh.source/octocathttps://example-gh.target/monalisarename

Один и тот же процесс можно использовать для создания сопоставлений для каждой записи, поддерживающей пользовательские сопоставления. Дополнительные сведения см. в таблице возможных сопоставлений записей.

Применение измененных данных миграции

  1. После внесения изменений используйте команду scp для применения измененного файла conflicts.csv (или любого другого файла .csv сопоставлений в правильном формате) к целевому экземпляру:

    scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/
    
  2. Повторно сопоставите данные миграции с помощью команды ghe-migrator map, передав путь к измененным файлу .csv и уникальному идентификатору миграции:

    ghe-migrator map -i conflicts.csv  -g MIGRATION-GUID
    
  3. Если команда ghe-migrator map -i conflicts.csv -g MIGRATION-GUID сообщит, что конфликты по-прежнему существуют, снова выполните процесс разрешения конфликтов миграции.

Применение импортированных данных к GitHub Enterprise Server

  1. SSH в целевом экземпляре GitHub Enterprise Server. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

    ssh -p 122 admin@HOSTNAME
    
  2. С помощью команды ghe-migrator import запустите процесс импорта. Что вам понадобится:

    $ ghe-migrator import /home/admin/MIGRATION-GUID.tar.gz -g MIGRATION-GUID -u USERNAME -p TOKEN
    
    > Starting GitHub::Migrator
    > Import 100% complete /
    
    • Чтобы указать, где следует выполнить подготовку файлов миграции, добавьте команду с --staging-path=/full/staging/path. По умолчанию — /data/user/tmp.

Проверка данных миграции

По умолчанию ghe-migrator audit возвращает каждую запись. Кроме того, это позволяет фильтровать записи по следующим критериям:

  • Типы записей.
  • Состояние записей.

Типы записей соответствуют тем, которые находятся в перенесенных данных.

Фильтры типов записей

Тип записиИмя фильтра
Пользователиuser
Организацииorganization
Репозиторииrepository
Teamsteam
Milestonesmilestone
Проекты (классическая модель)project
Проблемыissue
Комментарии к проблемеissue_comment
Запросы на включение внесенных измененийpull_request
Проверки запросов на включение измененийpull_request_review
Комментарии к фиксацииcommit_comment
Комментарии к проверке запроса на вытягиваниеpull_request_review_comment
Выпускиrelease
Действия, выполняемые для запросов на вытягивание или проблемissue_event
Защищенные ветвиprotected_branch

Фильтры состояния записи

Состояние записиDescription
exportЗапись будет экспортирована.
importЗапись будет импортирована.
mapЗапись будет сопоставлена.
renameЗапись будет сопоставлена.
mergeЗапись будет объединена.
exportedЗапись экспортирована успешно.
importedЗапись импортирована успешно.
mappedЗапись сопоставлена успешно.
renamedЗапись переименована успешно.
mergedЗапись объединена успешно.
failed_exportНе удалось экспортировать запись.
failed_importНе удалось импортировать запись.
failed_mapНе удалось сопоставить запись.
failed_renameНе удалось переименовать запись.
failed_mergeНе удалось объединить запись.

Фильтрация записей аудита

С помощью команды ghe-migrator audit можно отфильтровать данные по типу записи с помощью флага -m. Аналогичным образом можно отфильтровать состояние импорта с помощью флага -s. Эта команда выглядит следующим образом:

ghe-migrator audit -m RECORD_TYPE -s STATE -g MIGRATION-GUID

Например, чтобы просмотреть каждую успешно импортированную организацию и команду, необходимо ввести следующее:

$ ghe-migrator audit -m organization,team -s mapped,renamed -g MIGRATION-GUID
> model_name,source_url,target_url,state
> organization,https://gh.source/octo-org/,https://ghe.target/octo-org/,renamed

Настоятельно рекомендуется проводить аудит каждой операции импорта, завершившейся сбоем. Для этого введите:

$ ghe-migrator audit -s failed_import,failed_map,failed_rename,failed_merge -g MIGRATION-GUID
> model_name,source_url,target_url,state
> user,https://gh.source/octocat,https://gh.target/octocat,failed
> repository,https://gh.source/octo-org/octo-project,https://ghe.target/octo-org/octo-project,failed

Если у вас возникли проблемы с неудачными импортами, обратитесь к нам, перейдя по адресу Поддержка GitHub Enterprise.

Завершение импорта в GitHub Enterprise Server

После применения миграции к целевому экземпляру и проверки миграции следует разблокировать репозитории и удалить их из источника. Перед удалением исходных данных рекомендуется подождать около двух недель, чтобы убедиться, что все работает должным образом.

Разблокировка репозиториев на целевом экземпляре

  1. SSH в GitHub.com. Если экземпляр состоит из нескольких узлов, например, если настроен высокий уровень доступности или георепликация, передача осуществляется по SSH в основной узел. При использовании кластера можно использовать для передачи по SSH в любой узел. Замените HOSTNAME именем узла для экземпляра, именем узла или IP-адресом узла. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

    Shell
    ssh -p 122 admin@HOSTNAME
    
  2. Разблокируйте все импортированные репозитории с помощью команды ghe-migrator unlock. Вам потребуется GUID миграции:

$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project

Warning

Если репозиторий содержит рабочие процессы GitHub Actions с помощью триггера schedule , рабочие процессы не будут выполняться автоматически после импорта. Чтобы снова запустить запланированные рабочие процессы, отправьте фиксацию в репозиторий. Дополнительные сведения см. в разделе События, инициирующие рабочие процессы.

Разблокировка репозиториев в источнике

После завершения миграции необходимо разблокировать репозитории в источнике.

Разблокировка репозиториев из организации в GitHub.com

Чтобы разблокировать репозитории в организации GitHub.com, отправьте запрос DELETE в конечную точку разблокировки миграции. Что вам понадобится:

  • Маркер доступа для проверки подлинности
  • Уникальный id миграции
  • Имя репозитория для разблокировки
curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
  -H "Accept: application/vnd.github.wyandotte-preview+json" \
  https://api.github.com/orgs/ORG-NAME/migrations/ID/repos/REPO_NAME/lock

Удаление репозиториев из организации в GitHub.com

После разблокировки репозиториев организации GitHub.com следует удалить каждый репозиторий, перенесенный ранее с помощью конечной точки удаления репозитория. Вам потребуется маркер доступа для проверки подлинности

curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
  https://api.github.com/repos/ORG-NAME/REPO_NAME

Разблокировка репозиториев из экземпляра GitHub Enterprise Server

  1. SSH в GitHub.com. Если экземпляр состоит из нескольких узлов, например, если настроен высокий уровень доступности или георепликация, передача осуществляется по SSH в основной узел. При использовании кластера можно использовать для передачи по SSH в любой узел. Замените HOSTNAME именем узла для экземпляра, именем узла или IP-адресом узла. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

    Shell
    ssh -p 122 admin@HOSTNAME
    
  2. Разблокируйте все импортированные репозитории с помощью команды ghe-migrator unlock. Вам потребуется GUID миграции:

$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project