Перенос репозиториев из Enterprise Server в Enterprise Cloud

Если вы решили использовать API, вам потребуется написать собственные скрипты или использовать HTTP-клиент, такой как бессонница. Дополнительные сведения о начале работы с api в [AUTOTITLE и Начало работы с REST API](/graphql/guides/forming-calls-with-graphql).

Чтобы перенести репозитории из Enterprise Server на Enterprise Cloud с помощью API, выполните следующие действия:

1. Создание personal access token для исходной и целевой организации
2. ownerId Получение целевой организации на Enterprise Cloud
3. Настройка источника миграции с помощью API GraphQL , чтобы определить, откуда выполняется миграция
4. Для каждого репозитория, который требуется перенести, повторите эти действия.
   • Использование REST API в экземпляр Enterprise Server для создания архивов миграции для репозитория
   • Отправка архивов миграции в расположение, к которым можно получить доступ с помощью
   • Запустите миграцию с помощью API GraphQL для назначения миграции, передавая URL-адреса архива
   • Проверьте состояние миграции с помощью API GraphQL
   • Проверка миграции и проверка журнала ошибок

Чтобы просмотреть инструкции по использованию CLI, используйте переключатель инструментов в верхней части страницы.

1. Создайте и запишите personal access token (classic), которая будет проходить проверку подлинности для целевой организации на Enterprise Cloud, убедившись, что маркер соответствует всем требованиям. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами .
2. Создайте и запишите personal access token, которая будет проходить проверку подлинности для исходной организации, убедившись, что этот маркер также соответствует всем одинаковым требованиям.

В качестве владелец организации в Enterprise Cloudиспользуйте GetOrgInfo запрос для возврата ownerIdидентификатора организации, которая также называется идентификатором организации, для которой требуется принадлежать перенесенные репозитории. Вам потребуется ownerId определить назначение миграции.

query(
  $login: String!
){
  organization (login: $login)
  {
    login
    id
    name
    databaseId
  }
}

{
  "data": {
    "organization": {
      "login": "Octo",
      "id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
      "name": "Octo-org",
      "databaseId": 5610
    }
  }
}

В этом примере MDEyOk9yZ2FuaXphdGlvbjU2MTA= — это идентификатор организации или ownerIdидентификатор организации, который мы будем использовать на следующем шаге.

Так как многие экземпляры Enterprise Server сидят за брандмауэрами, для Enterprise Server версий 3.8 или более поздних версий мы используем хранилище BLOB-объектов в качестве промежуточного расположения для хранения данных, к которым могут получить доступ .

Сначала необходимо настроить хранилище BLOB-объектов с помощью поддерживаемого поставщика облачных служб, а затем настроить параметры в Консоль управления экземпляр Enterprise Server.

CLI поддерживает следующие поставщики хранилища BLOB-объектов:

• Amazon Web Services (AWS) S3
• хранилище BLOB-объектов Azure

В AWS настройте контейнер S3. Дополнительные сведения см. в разделе "Создание контейнера " в документации ПО AWS.

Вам также потребуется ключ доступа AWS и секретный ключ со следующими разрешениями:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucketMultipartUploads",
                "s3:AbortMultipartUpload",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::-migration-bucket",
                "arn:aws:s3:::-migration-bucket/*"
            ]
        }
    ]
}

В Azure создайте учетную запись хранения и запишите строка подключения. Дополнительные сведения см. в разделе "Управление ключами доступа к учетной записи хранения" в Документация Майкрософт.

После настройки контейнера хранилища AWS S3 или учетной записи хранения Хранилище BLOB-объектов Azure настройте хранилище BLOB-объектов в Консоль управления экземпляр Enterprise Server. Дополнительные сведения о Консоль управлениясм. в статье администрирование экземпляра из консоли управления.

1. В учетной записи администратора Enterprise Server, в правом верхнем углу любой страницы щелкните .

2. Если вы еще не на странице "Администратор сайта" в левом верхнем углу щелкните "Администратор сайта". 1. На боковой панели " "Администратор сайта" щелкните Консоль управления.

3. Войдите в Консоль управления.

4. В верхней панели навигации** щелкните **"Параметры".

5. В разделе "Миграции" нажмите кнопку "Включить" Миграции.

6. При необходимости для импорта параметров хранилища, настроенных для Actions, выберите "Копировать параметры хранилища" из действий. Дополнительные сведения см. в статье "Включение действий с хранилищем BLOB-объектов Azure" и включение Actions с помощью хранилища Amazon S3.

   Примечание.

   После копирования параметров хранилища может потребоваться обновить конфигурацию облачной учетной записи хранения, чтобы работать с Enterprise Importer. В частности, необходимо убедиться, что разрешены IP-адреса . Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами .

7. Если параметры хранилища не импортируются из Actions, выберите Хранилище BLOB-объектов Azure или Amazon S3 и заполните необходимые сведения.

   Примечание.

   Если вы используете Amazon S3, необходимо задать URL-адрес службы AWS для стандартной конечной точки региона AWS, в котором находится контейнер. Например, если контейнер находится в регионе eu-west-1 , будет указан https://s3.eu-west-1.amazonaws.comURL-адрес службы AWS. Сеть экземпляра Enterprise Server должна разрешить доступ к этому узлу. Конечные точки шлюза не поддерживаются, например bucket.vpce-0e25b8cdd720f900e-argc85vg.s3.eu-west-1.vpce.amazonaws.com. Дополнительные сведения о конечных точках шлюза см. в разделе "Конечные точки шлюза" для Amazon S3 в документации AWS.

8. Щелкните " Тестировать параметры хранилища".

9. Нажмите кнопку Сохранить параметры.

Если вы настроили правила брандмауэра в учетной записи хранения, убедитесь, что у вас есть доступ к диапазонам IP-адресов для назначения миграции. См . раздел AUTOTITLE.

Вы можете настроить источник миграции с помощью createMigrationSource запроса. Вам потребуется указать ownerIdидентификатор организации, собранный GetOrgInfo из запроса.

Источник миграции — это ваша организация на Enterprise Server.

mutation createMigrationSource($name: String!, $url: String!, $ownerId: ID!) {
  createMigrationSource(input: {name: $name, url: $url, ownerId: $ownerId, type: _ARCHIVE}) {
    migrationSource {
      id
      name
      url
      type
    }
  }
}

{
  "data": {
    "createMigrationSource": {
      "migrationSource": {
        "id": "MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ",
        "name": "GHES Source",
        "url": "https://my-ghes-hostname.com",
        "type": "_ARCHIVE"
      }
    }
  }
}

В этом примере MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ — это идентификатор источника миграции, который мы будем использовать на следующем шаге.

Rest API будет использоваться для запуска двух "миграций" в Enterprise Server: один для создания архива источника Git репозитория и одного для создания архива метаданных репозитория (например, проблем и запросов на вытягивание).

Чтобы создать исходный архив Git, выполните POST запрос https://HOSTNAME/api/v3/orgs/ORGANIZATION/migrations, заменив HOSTNAME имя узла экземпляр Enterprise Server, а также ORGANIZATION имя входа вашей организации.

В тексте укажите один репозиторий, который требуется перенести. Запрос будет выглядеть примерно так:

POST /api/v3/orgs/acme-corp/migrations HTTP/1.1
Accept: application/vnd.+json
Authorization: Bearer <TOKEN>
Content-Type: application/json
Host: .acmecorp.net

{
  "repositories": ["repository_to_migrate"],
  "exclude_metadata": true
}

Чтобы создать архив метаданных, отправьте аналогичный запрос на тот же URL-адрес со следующим текстом:

{
  "repositories": ["repository_to_migrate"],
  "exclude_git_data": true,
  "exclude_releases": false,
  "exclude_owner_projects": true
}

Каждый из этих двух вызовов API возвращает ответ JSON, включая идентификатор запущенной миграции.

HTTP/1.1 201 Created

{
  "id": 123,
  // ...
}

Дополнительные сведения см. в разделе "Запуск миграции организации".

Создание архивов может занять некоторое время в зависимости от объема данных. Вы можете регулярно проверять состояние двух миграций с помощью API "Получить состояние миграции организации" до тех пор, пока state миграция не изменится exported.

GET /api/v3/orgs/acme-corp/migrations/123 HTTP/1.1
Accept: application/vnd.+json
Authorization: Bearer <TOKEN>
Host: .acmecorp.net

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "state": "exported",
  // ...
}

Дополнительные сведения см. в разделе "Получение состояния миграции организации".

state После перехода exportedна миграцию можно получить URL-адрес миграции с помощью API загрузки архива миграции организации.

GET /api/v3/orgs/acme-corp/migrations/123/archive HTTP/1.1
Accept: application/vnd.+json
Authorization: Bearer <TOKEN>
Host: .acmecorp.net

HTTP/1.1 302 Found
Location: https://media..acmecorp.net/migrations/123/archive/cca2ebe9-7403-4ffa-9b6a-4c9e16c94410?token=AAAAABEWE7JP4H2HACKEGMTDOYRC6

API вернет 302 Found ответ с заголовком Location , перенаправляющимся на URL-адрес, в котором находится скачиваемый архив. Скачайте два файла: один для источника Git и один для метаданных.

Дополнительные сведения см. в разделе "Скачивание архива миграции организации".

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

Чтобы импортировать данные в Enterprise Cloud, необходимо передать оба архива для каждого репозитория (источник Git и метаданные) с компьютера в , используя наш API GraphQL.

Если вы используете Enterprise Server 3.7 или более поздней версии, необходимо сначала создать URL-адреса для архивов, доступных . Большинство клиентов предпочитают отправлять архивы в службу хранилища BLOB-объектов поставщика облачных служб, например Amazon S3 или Хранилище BLOB-объектов Azure, а затем создать короткий URL-адрес для каждого.

Если вы используете Enterprise Server 3.8 или более поздней версии, экземпляр отправляет архивы и создает URL-адреса для вас. Заголовок Location на предыдущем шаге возвращает короткий URL-адрес.

Возможно, вам потребуется разрешить список данных . Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами .

При запуске миграции один репозиторий и его сопутствующие данные переносятся в новый репозиторий , который вы определяете.

Если вы хотите одновременно переместить несколько репозиториев из одной исходной организации, можно ставить в очередь несколько миграций. Одновременно можно выполнять до 5 миграций репозитория.

mutation startRepositoryMigration (
  $sourceId: ID!,
  $ownerId: ID!,
  $repositoryName: String!,
  $continueOnError: Boolean!,
  $accessToken: String!,
  $Pat: String!,
  $gitArchiveUrl: String!,
  $metadataArchiveUrl: String!,
  $sourceRepositoryUrl: URI!,
  $targetRepoVisibility: String!
){
  startRepositoryMigration( input: {
    sourceId: $sourceId,
    ownerId: $ownerId,
    repositoryName: $repositoryName,
    continueOnError: $continueOnError,
    accessToken: $accessToken,
    Pat: $Pat,
    targetRepoVisibility: $targetRepoVisibility
    gitArchiveUrl: $gitArchiveUrl,
    metadataArchiveUrl: $metadataArchiveUrl,
    sourceRepositoryUrl: $sourceRepositoryUrl,
  }) {
    repositoryMigration {
      id
      migrationSource {
        id
        name
        type
      }
      sourceUrl
    }
  }
}

Требования к personal access token см. в разделе Управление доступом к миграции между продуктами .

На следующем шаге вы будете использовать идентификатор миграции, возвращенный из startRepositoryMigration изменения, чтобы проверить состояние миграции.

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

Запрос getMigration возвращается с состоянием, чтобы сообщить, является queuedли миграция , in progress``failedили completed. Если миграция завершилась сбоем, Importer предоставит причину сбоя.

query (
  $id: ID!
){
  node( id: $id ) {
    ... on Migration {
      id
      sourceUrl
      migrationSource {
        name
      }
      state
      failureReason
    }
  }
}

Чтобы завершить миграцию, рекомендуется проверить проблему журнала миграции. Эта проблема создается на в целевом репозитории.

Наконец, рекомендуется просмотреть перенесенные репозитории для проверки звука.