Acerca de las migraciones de repositorios con GitHub Enterprise Importer
Puedes ejecutar la migración con la GitHub CLI o la API.
La GitHub CLI simplifica el proceso de migración y se recomienda para la mayoría de los clientes. Los clientes avanzados con necesidades de personalización intensivas pueden usar la API para crear sus propias integraciones con GitHub Enterprise Importer.
Si decides usar la API, tendrás que escribir scripts propios, o bien usar un cliente HTTP como Insomnia. Puede obtener más información sobre cómo empezar a trabajar con las API de GitHub en "Introducción a la API REST" y "Formar llamados con GraphQl".
Para migrar los repositorios desde GitHub Enterprise Server a GitHub Enterprise Cloud con las API, haz lo siguiente:
- Crea una instancia de personal access token para la organización de origen y de destino
- Captura el valor
ownerId
de la organización de destino en GitHub Enterprise Cloud - Configure un origen de migración mediante GraphQL API de GitHub para identificar desde dónde se va a realizar la migración.
- Para cada repositorio que quieras migrar, repite estos pasos.
- Usa la API REST en tu instancia de GitHub Enterprise Server a fin de generar archivos de migración para el repositorio
- Cargue los archivos de migración en una ubicación accesible para GitHub
- Inicia la migración con la API GraphQL de tu destino de migración y pasa las URL de los archivos.
- Comprueba el estado de la migración mediante GraphQL API
- Valida la migración y comprueba el registro de errores
A fin de ver instrucciones para usar la API, utiliza el conmutador de herramientas en la parte superior de la página.
Para ver instrucciones de uso de la GitHub CLI, usa el conmutador de herramientas en la parte superior de la página.
Requisitos previos
- Se recomienda encarecidamente realizar una ejecución de prueba de la migración y completar la migración de producción poco después. Para más información sobre las ejecuciones de prueba, consulta "Introducción a una migración entre productos de GitHub".
- Asegúrate de comprender los datos que se migrarán y las limitaciones de compatibilidad conocidas del importador. Para obtener más información, consulte "Acerca de las migraciones entre productos de GitHub".
- Aunque no es necesario, se recomienda detener el trabajo durante la migración de producción. Importer no admite migraciones diferenciales, por lo que los cambios que se produzcan durante la migración no se migrarán. Si decides no detener el trabajo durante la migración de producción, tendrás que migrar manualmente estos cambios.
- Tanto en la organización de origen como en la destino, debes ser propietario de la organización o tener el rol de migración. Para obtener más información, vea «Administración del acceso para una migración entre productos de GitHub».
- Si usas GitHub Enterprise Server 3.8 o superior para configurar un almacenamiento de blobs para los archivos exportados, debes tener acceso a Consola de administración.
Paso 1. Creación de personal access token
- Crea y registra una instancia de personal access token (classic) que se autenticará para la organización de destino en GitHub Enterprise Cloud, y asegúrate de que el token cumple todos los requisitos. Para obtener más información, vea «Administración del acceso para una migración entre productos de GitHub».
- Crea y registra una instancia de personal access token que se autenticará para la organización de origen, y asegúrate de que este token también cumple todos los mismos requisitos.
Paso 2: Obtención de ownerId
la organización de destino
Como propietario de la organización en GitHub Enterprise Cloud, usa la consulta GetOrgInfo
para devolver ownerId
, también denomino id. de organización, para la organización que quieras que posea los repositorios migrados. Necesitarás el valor ownerId
para identificar el destino de la migración.
Consulta GetOrgInfo
query(
$login: String!
){
organization (login: $login)
{
login
id
name
databaseId
}
}
Variable de consulta | Descripción |
---|---|
login | El nombre de la organización. |
Respuesta GetOrgInfo
{
"data": {
"organization": {
"login": "Octo",
"id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
"name": "Octo-org",
"databaseId": 5610
}
}
}
En este ejemplo, MDEyOk9yZ2FuaXphdGlvbjU2MTA=
es el id. de la organización o ownerId
, que se usará en el paso siguiente.
Paso 3: Configuración del almacenamiento de blobs
Como muchas instancias de GitHub Enterprise Server se encuentran detrás de firewalls, para las versiones de GitHub Enterprise Server 3.8 o superiores, se usa el almacenamiento de blobs como una ubicación intermedia para almacenar los datos a los que GitHub puede acceder.
Primero debes configurar el almacenamiento de blobs con un proveedor de nube compatible y, después, configurar los valores en la Consola de administración de tu instancia de GitHub Enterprise Server.
Note
Solo tienes que configurar el almacenamiento de blobs si usas las versiones 3.8 o posteriores de GitHub Enterprise Server. Si usa las versiones 3.7 o posteriores de GitHub Enterprise Server, vaya al "Paso 4: Configuración de un origen de migración en GitHub Enterprise Cloud".
El almacenamiento en blobs es necesario para migrar repositorios con metadatos o código fuente de Git de gran tamaño. Si usas las versiones 3.7 o anteriores de GitHub Enterprise Server, no podrás realizar migraciones en las que las exportaciones de metadatos o código fuente de Git superen los 2 GB. Para realizar estas migraciones, actualiza a las versiones 3.8 o posteriores de GitHub Enterprise Server.
Configuración del almacenamiento de blobs con un proveedor de nube compatible
La GitHub CLI admite los siguientes proveedores de almacenamiento de blobs:
- Amazon Web Services (AWS) S3
- Azure Blob Storage
Configuración de un cubo de almacenamiento de AWS S3
En AWS, configura un cubo S3. Para más información, consulta Creación de un cubo en la documentación de AWS.
También necesitará una clave de acceso de AWS y una clave secreta con los siguientes permisos:
{
"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:::github-migration-bucket",
"arn:aws:s3:::github-migration-bucket/*"
]
}
]
}
Note
GitHub Enterprise Importer no elimina el archivo de AWS una vez que finaliza la migración. Para reducir los costos de almacenamiento, se recomienda configurar la eliminación automática del archivo después de un período de tiempo. Para más información, consulta Establecimiento de la configuración del ciclo de vida en un cubo en la documentación de AWS.
Configuración de una cuenta de Azure Blob Storage
En Azure, crea una cuenta de almacenamiento y anota la cadena de conexión. Para más información, consulta Administración de las claves de acceso de la cuenta de almacenamiento en Microsoft Docs.
Note
GitHub Enterprise Importer no elimina el archivo de Azure Blob Storage una vez que finaliza la migración. Para reducir los costos de almacenamiento, se recomienda configurar la eliminación automática del archivo después de un período de tiempo. Para más información, consulta Optimización de los costes mediante la administración automática del ciclo de vida de los datos en Microsoft Docs.
Configuración del almacenamiento de blobs en la Consola de administración de tu instancia de GitHub Enterprise Server
Después de configurar un depósito de almacenamiento de AWS S3 o una cuenta de almacenamiento de Azure Blob Storage, configura el almacenamiento de blobs en la Consola de administración de tu instancia de GitHub Enterprise Server. Para más información sobre la Consola de administración, consulta "Administración de la instancia desde la consola de administración".
-
Desde una cuenta administrativa de GitHub Enterprise Server, en la esquina superior derecha de cualquier página, haz clic en .
-
Si todavía no estás en la página "Administrador del sitio", en la esquina superior izquierda, haz clic en Administrador del sitio. 1. En la barra lateral " Administrador del sitio", haz clic en Consola de administración .
-
Inicia sesión en la Consola de administración.
-
En la barra de navegación superior, haz clic en Configuración.
-
En Migraciones, haz clic en Habilitar migraciones de GitHub .
-
Opcionalmente, para importar los valores de almacenamiento que has configurado para GitHub Actions, selecciona Copiar configuración de almacenamiento desde Acciones. Para más información, consulta "Habilitación de Acciones de GitHub con Azure Blob Storage" y "Habilitación de Acciones de GitHub con el almacenamiento de Amazon S3".
Note
Después de copiar la configuración de almacenamiento, es posible que tengas que actualizar la configuración de la cuenta de almacenamiento de nube para trabajar con GitHub Enterprise Importer. En concreto, debe asegurarse de que las direcciones IP de GitHub están agregadas a la lista de permitidas. Para obtener más información, vea «Administración del acceso para una migración entre productos de GitHub».
-
Si no importas la configuración de almacenamiento de GitHub Actions, selecciona Azure Blob Storage o Amazon S3, y rellene los detalles necesarios.
Note
Si usas Amazon S3, debes establecer "AWS Service URL" en el punto de conexión estándar de la región de AWS donde se encuentra el cubo. Por ejemplo, si el cubo se encuentra en la región
eu-west-1
, la "URL del servicio de AWS" seríahttps://s3.eu-west-1.amazonaws.com
. Los datos GitHub Enterprise Server de la red de instancia deben permitir el acceso a este host. No se admiten puntos de conexión de puerta de enlace, comobucket.vpce-0e25b8cdd720f900e-argc85vg.s3.eu-west-1.vpce.amazonaws.com
. Para obtener más información sobre los puntos de conexión de puerta de enlace, consulta Puntos de conexión de puerta de enlace para Amazon S3 en la documentación de AWS. -
Haz clic en Probar configuración de almacenamiento.
-
Haga clic en Save settings (Guardar configuración).
Permiso para el acceso a la red
Si has configurado reglas de firewall en la cuenta de almacenamiento, asegúrate de que has permitido el acceso a los intervalos IP para el destino de la migración. Consulte "Administración del acceso para una migración entre productos de GitHub".
Paso 4: Configuración de un origen de migración en GitHub Enterprise Cloud
Puedes configurar un origen de migración mediante la consulta createMigrationSource
. Tendrás que proporcionar el valor ownerId
, o id. de organización, recopilado de la consulta GetOrgInfo
.
El origen de migración es la organización en GitHub Enterprise Server.
Mutación createMigrationSource
mutation createMigrationSource($name: String!, $url: String!, $ownerId: ID!) {
createMigrationSource(input: {name: $name, url: $url, ownerId: $ownerId, type: GITHUB_ARCHIVE}) {
migrationSource {
id
name
url
type
}
}
}
Note
Asegúrate de usar GITHUB_ARCHIVE
para type
.
Variable de consulta | Descripción |
---|---|
name | Nombre para el origen de la migración. Este nombre es para referencia propia, por lo que puedes usar cualquier cadena. |
ownerId | El id. de la organización en GitHub Enterprise Cloud. |
url | Dirección URL de tu instancia de GitHub Enterprise Server. Esta dirección URL no necesita ser accesible desde GitHub Enterprise Cloud. |
Respuesta createMigrationSource
{
"data": {
"createMigrationSource": {
"migrationSource": {
"id": "MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ",
"name": "GHES Source",
"url": "https://my-ghes-hostname.com",
"type": "GITHUB_ARCHIVE"
}
}
}
}
En este ejemplo, MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ
es el identificador de origen de la migración, que se usará en un paso posterior.
Paso 5: Generación de archivos de migración en tu instancia de GitHub Enterprise Server
Utilice la API de REST para iniciar dos "migraciones" en GitHub Enterprise Server: una para generar un archivo del origen de Git del repositorio, y otra para generar un archivo de los metadatos del repositorio (por ejemplo, las incidencias y las solicitudes de incorporación de cambios).
Para generar el archivo de origen de Git, realiza una solicitud POST
a https://HOSTNAME/api/v3/orgs/ORGANIZATION/migrations
, y reemplaza HOSTNAME
por el nombre de host de tu instancia de GitHub Enterprise Server y ORGANIZATION
por el inicio de sesión de la organización.
En el cuerpo, especifica el único repositorio que quieras migrar. La solicitud será similar a esta:
POST /api/v3/orgs/acme-corp/migrations HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Content-Type: application/json
Host: github.acmecorp.net
{
"repositories": ["repository_to_migrate"],
"exclude_metadata": true
}
Para generar el archivo de metadatos, envía una solicitud similar a la misma dirección URL con el siguiente cuerpo:
{
"repositories": ["repository_to_migrate"],
"exclude_git_data": true,
"exclude_releases": false,
"exclude_owner_projects": true
}
Cada una de estas dos llamadas API devolverá una respuesta JSON, incluido el identificador de la migración que ha iniciado.
HTTP/1.1 201 Created
{
"id": 123,
// ...
}
Para obtener más información, consulte "Iniciar una migración de la organización".
La generación de los archivos puede tardar un tiempo, en función de la cantidad de datos. Puede comprobar periódicamente el estado de las dos migraciones con la API "Obtener un estado de migración de la organización" hasta que el valor state
de la migración cambie a exported
.
GET /api/v3/orgs/acme-corp/migrations/123 HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Host: github.acmecorp.net
HTTP/1.1 200 OK
Content-Type: application/json
{
"id": 123,
"state": "exported",
// ...
}
Para obtener más información, consulte "Obtener un estado de migración de la organización".
Note
Si la migración se mueve al estado failed
en lugar de al estado exported
, intenta iniciarla de nuevo. Si se produce un error en la migración repetidamente, se recomienda generar los archivos mediante ghe-migrator
en lugar de la API.
Siga los pasos descritos en "Exportación de datos de migración desde la empresa", y agregue solo un repositorio a la migración. Al final del proceso, tendrá un único archivo de migración con el origen y los metadatos de Git, y puede pasar al paso 6 de este artículo.
Después de que el valor state
de una migración se mueva a exported
, puede capturar la dirección URL de la migración mediante la API "Descargar un archivo de migración de la organización".
GET /api/v3/orgs/acme-corp/migrations/123/archive HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Host: github.acmecorp.net
HTTP/1.1 302 Found
Location: https://media.github.acmecorp.net/migrations/123/archive/cca2ebe9-7403-4ffa-9b6a-4c9e16c94410?token=AAAAABEWE7JP4H2HACKEGMTDOYRC6
La API devolverá una respuesta 302 Found
con un encabezado Location
que redirige a la dirección URL donde se encuentra el archivo descargable. Descarga los dos archivos: uno para el origen de Git y otro para los metadatos.
Para obtener más información, consulte "Descargar un archivo de migración de la organización".
Después de que se hayan completado las dos migraciones y haya descargado los archivos, puede pasar al paso siguiente.
Paso 6: Carga de los archivos de migración
Para importar los datos en GitHub Enterprise Cloud, tiene que pasar los dos archivos para cada repositorio (origen de Git y metadatos) desde la máquina a GitHub mediante GraphQL API.
Si usa GitHub Enterprise Server 3,7 o una versión anterior, primero debe generar direcciones URL para los archivos a los que accederá GitHub. La mayoría de los clientes eligen cargar los archivos en el servicio de almacenamiento de blobs de un proveedor de nube, como Amazon S3 o Azure Blob Storage, y luego generar una dirección URL de corta duración para cada uno.
Si usas GitHub Enterprise Server 3.8 o una versión superior, la instancia carga los archivos y genera las direcciones URL automáticamente. El encabezado Location
del paso anterior devolverá la dirección URL de corta duración.
Es posible que tengas que permitir intervalos IP deGitHub. Para obtener más información, vea «Administración del acceso para una migración entre productos de GitHub».
Paso 7: Inicio de la migración del repositorio
Al iniciar una migración, un único repositorio y sus datos adjuntos se migran a un repositorio nuevo de GitHub que identifiques.
Si quieres mover varios repositorios a la vez desde la misma organización de origen, puedes poner en cola varias migraciones. Puedes ejecutar hasta cinco migraciones de repositorio a la vez.
Mutación startRepositoryMigration
mutation startRepositoryMigration (
$sourceId: ID!,
$ownerId: ID!,
$repositoryName: String!,
$continueOnError: Boolean!,
$accessToken: String!,
$githubPat: String!,
$gitArchiveUrl: String!,
$metadataArchiveUrl: String!,
$sourceRepositoryUrl: URI!,
$targetRepoVisibility: String!
){
startRepositoryMigration( input: {
sourceId: $sourceId,
ownerId: $ownerId,
repositoryName: $repositoryName,
continueOnError: $continueOnError,
accessToken: $accessToken,
githubPat: $githubPat,
targetRepoVisibility: $targetRepoVisibility
gitArchiveUrl: $gitArchiveUrl,
metadataArchiveUrl: $metadataArchiveUrl,
sourceRepositoryUrl: $sourceRepositoryUrl,
}) {
repositoryMigration {
id
migrationSource {
id
name
type
}
sourceUrl
}
}
}
Variable de consulta | Descripción |
---|---|
sourceId | El origen de migración id devuelto por la mutación createMigrationSource . |
ownerId | El id. de la organización en GitHub Enterprise Cloud. |
repositoryName | Un nombre de repositorio único personalizado que actualmente no se use en ninguno de los repositorios propiedad de la organización en GitHub Enterprise Cloud. Se creará una incidencia de registro de errores en este repositorio cuando se complete la migración o se haya detenido. |
continueOnError | Valor de migración que permite que continúe al encontrar errores que no hacen que se produzca un error en la migración. Debe ser true o false . Se recomienda encarecidamente establecer continueOnError en true para que la migración continúe a menos que Importer no pueda mover el origen de Git o Importer haya perdido la conexión y no se pueda volver a conectar para completar la migración. |
githubPat | El valor personal access token de la organización de destino en GitHub Enterprise Cloud. |
accessToken | El valor personal access token para el origen. |
targetRepoVisibility | La visibilidad del nuevo repositorio. Debe ser private , public o internal . Si no se establece, el repositorio se migra como privado. |
gitArchiveUrl | Una dirección URL accesible por GitHub Enterprise Cloud para el archivo de origen de Git. |
metadataArchiveUrl | Una dirección URL accesible por GitHub Enterprise Cloud para el archivo de metadatos. |
sourceRepositoryUrl | Dirección URL del repositorio en la instancia de GitHub Enterprise Server. Esto es obligatorio, pero GitHub Enterprise Cloud no se comunicará directamente con la instancia de GitHub Enterprise Server. |
Para obtener los requisitos de personal access token, consulte "Administración del acceso para una migración entre productos de GitHub".
En el paso siguiente, usarás el id. de migración devuelto por la mutación startRepositoryMigration
para comprobar el estado de la migración.
Paso 8: Comprobación del estado de la migración
Para detectar errores de migración y asegurarse de que la migración funciona, puedes comprobar el estado de la migración mediante la consulta getMigration
. También puedes comprobar el estado de varias migraciones con getMigrations
.
La consulta getMigration
devolverá con un estado para que sepas si la migración es queued
, in progress
, failed
o completed
. Si se ha producido un error en la migración, en Importer se proporcionará un motivo para el error.
Consulta getMigration
query (
$id: ID!
){
node( id: $id ) {
... on Migration {
id
sourceUrl
migrationSource {
name
}
state
failureReason
}
}
}
Variable de consulta | Descripción |
---|---|
id | El valor id de la migración que ha devuelto la mutación startRepositoryMigration . |
Paso 9: Validación de la migración y comprobación del registro de errores
Para finalizar la migración, se recomienda comprobar la incidencia "Registro de migración". Esta incidencia se crea en GitHub en el repositorio de destino.
Por último, se recomienda revisar los repositorios migrados para obtener una comprobación de solidez.
Paso 1: Instalación de la GEI extension of the GitHub CLI
Si se trata de la primera migración, tendrás que instalar la GEI extension of the GitHub CLI. Para más información sobre la GitHub CLI, consulta "Acerca del CLI de GitHub".
Como alternativa, puede descargar un binario independiente desde la página de versiones del repositorio github/gh-gei
. Puede ejecutar el archivo binario directamente, sin el prefijo gh
.
-
Instala la GitHub CLI. A fin de obtener instrucciones de instalación para GitHub CLI, vea el repositorio de GitHub CLI.
Note
Necesitas la versión 2.4.0 o posterior de GitHub CLI. Puedes comprobar la versión instalada con el comando
gh --version
. -
Instalación de la GEI extension.
Shell gh extension install github/gh-gei
gh extension install github/gh-gei
Cada vez que necesites ayuda con la GEI extension, puedes usar la marca --help
con un comando. Por ejemplo, gh gei --help
enumerará todos los comandos disponibles y gh gei migrate-repo --help
todas las opciones disponibles para el comando migrate-repo
.
Paso 2: Actualización de la GEI extension of the GitHub CLI
La GEI extension se actualiza semanalmente. Para asegurarte de que usas la versión más reciente, actualiza la extensión.
gh extension upgrade github/gh-gei
Paso 3: Establecimiento de variables de entorno
Para poder usar la GEI extension para la migración a GitHub Enterprise Cloud, debes crear instancias de personal access token que puedan acceder a las organizaciones de origen y destino y, después, establecer las instancias de personal access token como variables de entorno.
-
Crea y registra una instancia de personal access token (classic) que se autenticará para la organización de destino en GitHub Enterprise Cloud, y asegúrate de que el token cumple todos los requisitos. Para obtener más información, vea «Administración del acceso para una migración entre productos de GitHub».
-
Crea y registra una instancia de personal access token que se autenticará para la organización de origen, y asegúrate de que este token también cumple todos los mismos requisitos.
-
Establece variables de entorno para personal access token, y reemplaza TOKEN en los comandos siguientes por los valores personal access token que has registrado antes. Usa
GH_PAT
para la organización de destino yGH_SOURCE_PAT
para la de origen.-
Si usas Terminal, utiliza el comando
export
.Shell export GH_PAT="TOKEN" export GH_SOURCE_PAT="TOKEN"
export GH_PAT="TOKEN" export GH_SOURCE_PAT="TOKEN"
-
Si usas PowerShell, utiliza el comando
$env
.Shell $env:GH_PAT="TOKEN" $env:GH_SOURCE_PAT="TOKEN"
$env:GH_PAT="TOKEN" $env:GH_SOURCE_PAT="TOKEN"
-
-
Si vas a migrar a Nube de GitHub Enterprise con residencia de datos, para mayor comodidad, establece una variable de entorno para la dirección URL de la API base para tu empresa. Por ejemplo:
Shell export TARGET_API_URL="https://api.octocorp.ghe.com"
export TARGET_API_URL="https://api.octocorp.ghe.com"
Usarás esta variable con la opción
--target-api-url
en los comandos que ejecutes con la GitHub CLI.
Paso 4: Configuración del almacenamiento de blobs
Como muchas instancias de GitHub Enterprise Server se encuentran detrás de firewalls, se usa el almacenamiento de blobs como una ubicación intermedia para almacenar los datos a los que GitHub puede acceder.
En primer lugar, tendrás que configurar el almacenamiento de blobs con un proveedor de nube compatible. Después, debes configurar las credenciales para el proveedor de almacenamiento en Consola de administración o la GitHub CLI.
Configuración del almacenamiento de blobs con un proveedor de nube compatible
La GitHub CLI admite los siguientes proveedores de almacenamiento de blobs:
- Amazon Web Services (AWS) S3
- Azure Blob Storage
Configuración de un cubo de almacenamiento de AWS S3
En AWS, configura un cubo S3. Para más información, consulta Creación de un cubo en la documentación de AWS.
También necesitará una clave de acceso de AWS y una clave secreta con los siguientes permisos:
{
"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:::github-migration-bucket",
"arn:aws:s3:::github-migration-bucket/*"
]
}
]
}
Note
GitHub Enterprise Importer no elimina el archivo de AWS una vez que finaliza la migración. Para reducir los costos de almacenamiento, se recomienda configurar la eliminación automática del archivo después de un período de tiempo. Para más información, consulta Establecimiento de la configuración del ciclo de vida en un cubo en la documentación de AWS.
Configuración de una cuenta de almacenamiento de Azure Blob Storage
En Azure, crea una cuenta de almacenamiento y anota la cadena de conexión. Para más información, consulta Administración de las claves de acceso de la cuenta de almacenamiento en Microsoft Docs.
Note
GitHub Enterprise Importer no elimina el archivo de Azure Blob Storage una vez que finaliza la migración. Para reducir los costos de almacenamiento, se recomienda configurar la eliminación automática del archivo después de un período de tiempo. Para más información, consulta Optimización de los costes mediante la administración automática del ciclo de vida de los datos en Microsoft Docs.
Configuración de las credenciales de almacenamiento de blobs
Después de configurar el almacenamiento de blobs con un proveedor de nube compatible, debes configurar las credenciales para el proveedor de almacenamiento en GitHub:
- Si usas GitHub Enterprise Server 3.8 o superior, configura las credenciales en la Consola de administración.
- Si usas GitHub Enterprise Server 3.7 o una versión inferior, configura las credenciales en la GitHub CLI.
Configuración del almacenamiento de blobs en la Consola de administración de tu instancia de GitHub Enterprise Server
Note
Solo tienes que configurar el almacenamiento de blobs en Consola de administración si usas GitHub Enterprise Server 3.8 o una versión superior. Si usa la versión 3.7 o inferior, en su lugar configura las credenciales en la GitHub CLI.
Después de configurar un depósito de almacenamiento de AWS S3 o una cuenta de almacenamiento de Azure Blob Storage, configura el almacenamiento de blobs en la Consola de administración de tu instancia de GitHub Enterprise Server. Para más información sobre la Consola de administración, consulta "Administración de la instancia desde la consola de administración".
-
Desde una cuenta administrativa de GitHub Enterprise Server, en la esquina superior derecha de cualquier página, haz clic en .
-
Si todavía no estás en la página "Administrador del sitio", en la esquina superior izquierda, haz clic en Administrador del sitio. 1. En la barra lateral " Administrador del sitio", haz clic en Consola de administración .
-
Inicia sesión en la Consola de administración.
-
En la barra de navegación superior, haz clic en Configuración.
-
En Migraciones, haz clic en Habilitar migraciones de GitHub .
-
Opcionalmente, para importar los valores de almacenamiento que has configurado para GitHub Actions, selecciona Copiar configuración de almacenamiento desde Acciones. Para más información, consulta "Habilitación de Acciones de GitHub con Azure Blob Storage" y "Habilitación de Acciones de GitHub con el almacenamiento de Amazon S3".
Note
Después de copiar la configuración de almacenamiento, es posible que tengas que actualizar la configuración de la cuenta de almacenamiento de nube para trabajar con GitHub Enterprise Importer. En concreto, debe asegurarse de que las direcciones IP de GitHub están agregadas a la lista de permitidas. Para obtener más información, vea «Administración del acceso para una migración entre productos de GitHub».
-
Si no importas la configuración de almacenamiento de GitHub Actions, selecciona Azure Blob Storage o Amazon S3, y rellene los detalles necesarios.
Note
Si usas Amazon S3, debes establecer "AWS Service URL" en el punto de conexión estándar de la región de AWS donde se encuentra el cubo. Por ejemplo, si el cubo se encuentra en la región
eu-west-1
, la "URL del servicio de AWS" seríahttps://s3.eu-west-1.amazonaws.com
. Los datos GitHub Enterprise Server de la red de instancia deben permitir el acceso a este host. No se admiten puntos de conexión de puerta de enlace, comobucket.vpce-0e25b8cdd720f900e-argc85vg.s3.eu-west-1.vpce.amazonaws.com
. Para obtener más información sobre los puntos de conexión de puerta de enlace, consulta Puntos de conexión de puerta de enlace para Amazon S3 en la documentación de AWS. -
Haz clic en Probar configuración de almacenamiento.
-
Haga clic en Save settings (Guardar configuración).
Configuración de las credenciales de almacenamiento de blobs en la GitHub CLI
Note
Solo tienes que configurar las credenciales de almacenamiento de blobs en GitHub CLI si usas GitHub Enterprise Server 3.7 o una versión inferior. Si usas la versión 3.8 o superior, en su lugar configura el almacenamiento de blobs en la Consola de administración.
Si configuras las credenciales de almacenamiento de blobs en la GitHub CLI, no podrás realizar migraciones en las que el origen de Git o las exportaciones de metadatos superen los 2 GB. Para realizar estas migraciones, actualiza a la versión 3.8 o superior de GitHub Enterprise Server.
Configuración de las credenciales de AWS S3 en la GitHub CLI
Cuando estés listo para ejecutar la migración, deberás proporcionar tus credenciales de AWS a GitHub CLI: región, clave de acceso, clave secreta y token de sesión (si es necesario). Puedes pasarlas como argumentos o establecer variables de entorno denominadas AWS_REGION
, AWS_ACCESS_KEY_ID
, AWS_SECRET_ACCESS_KEY
y AWS_SESSION_TOKEN
.
También deberás pasar el nombre del cubo S3 con el argumento --aws-bucket-name
.
Configuración de las credenciales de la cuenta de Azure Blob Storage en la GitHub CLI
Cuando estés listo para ejecutar la migración, puedes pasar la cadena de conexión a la GitHub CLI como argumento, o bien pasarla mediante una variable de entorno denominada AZURE_STORAGE_CONNECTION_STRING
.
Permiso para el acceso a la red
Si has configurado reglas de firewall en la cuenta de almacenamiento, asegúrate de que has permitido el acceso a los intervalos IP para el destino de la migración. Consulte "Administración del acceso para una migración entre productos de GitHub".
Paso 5: Generación de un script de migración
Si quieres migrar varios repositorios a GitHub Enterprise Cloud a la vez, usa la GitHub CLI para generar un script de migración. El script resultante contendrá una lista de comandos de migración, uno por cada repositorio.
Note
La generación de un script da como resultado un script de PowerShell. Si usas Terminal, tendrás que generar el script con la extensión de archivo .ps1
e instalar PowerShell para Mac o Linux para ejecutarlo.
Si quieres migrar un único repositorio, pasa al paso siguiente.
Generación de un script de migración
Debes seguir este paso desde un equipo que pueda acceder a la API para tu instancia de GitHub Enterprise Server. Si puedes acceder a la instancia desde el explorador, significa que el equipo tiene el acceso correcto.
Para generar un script de migración, ejecuta el comando gh gei generate-script
.
Para GitHub Enterprise Server 3.8 o versiones posteriores, o si usas la versión 3.7 o una anterior con Azure Blob Storage, usa las marcas siguientes:
gh gei generate-script --github-source-org SOURCE \ --github-target-org DESTINATION \ --output FILENAME \ --ghes-api-url GHES-API-URL
gh gei generate-script --github-source-org SOURCE \
--github-target-org DESTINATION \
--output FILENAME \
--ghes-api-url GHES-API-URL
Si usas GitHub Enterprise Server 3.7 o versiones anteriores con AWS S3, usa las marcas siguientes:
gh gei generate-script --github-source-org SOURCE \ --github-target-org DESTINATION \ --output FILENAME \ --ghes-api-url GHES-API-URL \ --aws-bucket-name AWS-BUCKET-NAME
gh gei generate-script --github-source-org SOURCE \
--github-target-org DESTINATION \
--output FILENAME \
--ghes-api-url GHES-API-URL \
--aws-bucket-name AWS-BUCKET-NAME
Marcadores de posición
Reemplaza los marcadores de posición del comando anterior por los valores siguientes.
Marcador de posición | Value |
---|---|
SOURCE | Nombre de la organización de origen |
DESTINATION | Nombre de la organización de destino |
FILENAME | Nombre de archivo para el script de migración resultante Si usas Terminal, utiliza una extensión de archivo .ps1 , ya que el script generado necesita que se ejecute PowerShell. Puedes instalar PowerShell para Mac o Linux. |
GHES-API-URL | Dirección URL de la API de tu instancia de GitHub Enterprise Server, como https://myghes.com/api/v3 |
AWS-BUCKET-NAME | Nombre del depósito de AWS S3 |
Argumentos adicionales
Argumento | Descripción |
---|---|
--target-api-url TARGET-API-URL | Si vas a migrar a GHE.com, agrega --target-api-url TARGET-API-URL , donde TARGET-API-URL es la dirección URL de la API base para el subdominio de la empresa. Por ejemplo: https://api.octocorp.ghe.com . |
--no-ssl-verify | Si tu instancia de GitHub Enterprise Server usa un certificado SSL autofirmado o no válido, usa la marca --no-ssl-verify . Con esta marca, la GitHub CLI omitirá la comprobación del certificado SSL al extraer datos solo de la instancia. Todas las demás llamadas comprobarán SSL. |
--download-migration-logs | Descarga el registro de migración para cada repositorio migrado. Para más información sobre los registros de migración, consulta "Acceso a los registros de migración para GitHub Enterprise Importer". |
Revisión del script de migración
Después de generar el script, revisa el archivo y, opcionalmente, edita el script.
- Si hay repositorios que no quieras migrar, elimina o convierte en comentario las líneas correspondientes.
- Si quieres que los repositorios tengan otro nombre en la organización de destino, actualiza el valor de la marca
--target-repo
correspondiente. - Si desea cambiar la visibilidad del nuevo repositorio, actualice el valor de la marca
--target-repo-visibility
correspondiente. De manera predeterminada, el script establece la misma visibilidad que el repositorio de origen.
Si el repositorio tiene más de 10 GB de datos de versiones, las versiones no se pueden migrar. Usa la marca --skip-releases
para migrar el repositorio sin versiones.
Si descargó GEI como un binario independiente en lugar de como una extensión para los GitHub CLI, deberá actualizar el script generado para ejecutar el binario en lugar de gh gei
.
Paso 6: Migración de repositorios
Puedes migrar varios repositorios con un script de migración, o bien un único repositorio con el comando gh gei migrate-repo
.
Al migrar repositorios, la GEI extension of the GitHub CLI realiza los pasos siguientes:
- Se conecta a tu instancia de GitHub Enterprise Server y genera dos archivos de migración por repositorio, uno para el origen de Git y otro para los metadatos
- Carga los archivos de migración en el proveedor de almacenamiento de blobs que prefieras
- Inicia la migración en GitHub Enterprise Cloud, con las direcciones URL de los archivos almacenados con el proveedor de almacenamiento de blobs
- Elimina el archivo de migración de la máquina local
Migración de varios repositorios
Si vas a migrar desde GitHub Enterprise Server 3.7 o una versión anterior, antes de ejecutar el script, debes establecer variables de entorno adicionales para autenticarte en el proveedor de almacenamiento de blobs.
-
Para Azure Blob Storage, establece
AZURE_STORAGE_CONNECTION_STRING
en la cadena de conexión de la cuenta de almacenamiento de Azure.Solo se admiten cadenas de conexión que usan claves de acceso de cuenta de almacenamiento. No se admiten las cadenas de conexión que usan firmas de acceso compartido (SAS). Para más información sobre las claves de acceso de cuentas de almacenamiento, consulta Administración de claves de acceso de cuentas de almacenamiento en la documentación de Azure.
-
Pra AWS S3, establece las siguientes variables de entorno.
AWS_ACCESS_KEY_ID
: el id. de clave de acceso del cuboAWS_SECRET_ACCESS_KEY
: la clave secreta del cuboAWS_REGION
: la región de AWS en la que se ubica el cuboAWS_SESSION_TOKEN
: el token de la sesión, si usas credenciales temporales de AWS (consulta Uso de credenciales temporales con recursos de AWS en la documentación de AWS)
Para migrar varios repositorios, ejecuta el script que has generado antes. Reemplaza FILENAME en los comandos siguientes por el nombre de archivo que has proporcionado al generar el script.
-
Si usas Terminal, utiliza
./
.Shell ./FILENAME
./FILENAME
-
Si usas PowerShell, utiliza
.\
.Shell .\FILENAME
.\FILENAME
Migración de un único repositorio
Debes seguir este paso desde un equipo que pueda acceder a la API para tu instancia de GitHub Enterprise Server. Si puedes acceder a la instancia desde el explorador, significa que el equipo tiene el acceso correcto.
Para migrar un único repositorio, usa el comando gh gei migrate-repo
.
Si usas GitHub Enterprise Server 3.8 o versiones posteriores, usa las marcas siguientes:
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME --ghes-api-url GHES-API-URL
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME --ghes-api-url GHES-API-URL
Si vas a migrar desde GitHub Enterprise Server 3.7 o una versión anterior y utilizas Azure Blob Storage como proveedor de almacenamiento de blobs, usa las marcas siguientes para realizar la autenticación:
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \ --ghes-api-url GHES-API-URL --azure-storage-connection-string "AZURE_STORAGE_CONNECTION_STRING"
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \
--ghes-api-url GHES-API-URL --azure-storage-connection-string "AZURE_STORAGE_CONNECTION_STRING"
Si vas a migrar desde GitHub Enterprise Server 3.7 o una versión anterior y utilizan Amazon S3 como proveedor de almacenamiento de blobs, usa las marcas siguientes para realizar la autenticación:
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \ --ghes-api-url GHES-API-URL --aws-bucket-name "AWS-BUCKET-NAME"
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \
--ghes-api-url GHES-API-URL --aws-bucket-name "AWS-BUCKET-NAME"
Marcadores de posición
Reemplaza los marcadores de posición del comando anterior por los valores siguientes.
Marcador de posición | Value |
---|---|
SOURCE | Nombre de la organización de origen |
CURRENT-NAME | Nombre del repositorio que quieres migrar |
DESTINATION | Nombre de la organización de destino |
NEW-NAME | Nombre que quieres que tenga el repositorio migrado |
GHES-API-URL | Dirección URL de la API de tu instancia de GitHub Enterprise Server, como https://myghes.com/api/v3 |
AZURE_STORAGE_CONNECTION_STRING | Cadena de conexión de la cuenta de almacenamiento de Azure. Asegúrate de entrecomillar la cadena de conexión, que contiene caracteres que probablemente interpretará el shell. |
AWS-BUCKET-NAME | Nombre del depósito de AWS S3 |
Argumentos adicionales
Argumento | Descripción |
---|---|
--target-api-url TARGET-API-URL | Si vas a migrar a GHE.com, agrega --target-api-url TARGET-API-URL , donde TARGET-API-URL es la dirección URL de la API base para el subdominio de la empresa. Por ejemplo: https://api.octocorp.ghe.com . |
--no-ssl-verify | Si tu instancia de GitHub Enterprise Server usa un certificado SSL autofirmado o no válido, usa la marca --no-ssl-verify . Con esta marca, la GitHub CLI omitirá la comprobación del certificado SSL al extraer datos solo de la instancia. Todas las demás llamadas comprobarán SSL. |
--skip-releases | Si el repositorio tiene más de 10 GB de datos de versiones, las versiones no se pueden migrar. Usa la marca --skip-releases para migrar el repositorio sin versiones. |
--target-repo-visibility TARGET-VISIBILITY | Los repositorios se migran con visibilidad privada de manera predeterminada. Para establecer la visibilidad, puede agregar la marca --target-repo-visibility ; para ello, debe especificar private , public o internal . Si va a migrar a una empresa con usuarios administrados, los repositorios públicos no están disponibles. |
Cancelación de la migración
Si deseas cancelar una migración, usa el comando abort-migration
, reemplazando MIGRATION-ID por el identificador devuelto de migrate-repo
.
gh gei abort-migration --migration-id MIGRATION-ID
gh gei abort-migration --migration-id MIGRATION-ID
Paso 7: Validación de la migración y comprobación del registro de errores
Una vez que se complete la migración, se recomienda revisar el registro de migración. Para obtener más información, vea «Acceso a los registros de migración para GitHub Enterprise Importer».
Se recomienda revisar los repositorios migrados para obtener una comprobación de solidez.
Una vez que finalice la migración, se recomienda eliminar los archivos del contenedor de almacenamiento. Si tienes previsto completar migraciones adicionales, elimina el archivo colocado en el contenedor de almacenamiento por ADO2GH extension. Si ha terminado la migración, puede eliminar todo el contenedor.