Migración del almacenamiento externo de Acciones de GitHub

Acerca de la migración del GitHub Actions almacenamiento externo

Puede migrar GitHub Actions el almacenamiento externo a un nuevo bucket, cuenta o región del mismo proveedor al consolidar cuentas en la nube, cumplir requisitos de residencia de datos o reorganizar la tenencia del almacenamiento.

La migración funciona porque GitHub Actions identifica los objetos almacenados por su clave (ruta de acceso) dentro de un cubo o contenedor, no por el nombre del cubo o la cuenta. Siempre que conserve el diseño de la clave interna y actualice la configuración para que apunte a la nueva ubicación, los registros de flujo de trabajo y los artefactos existentes permanecen accesibles sin interrupción.

Considerations

Antes de empezar, revise las restricciones siguientes. Cada uno determina el enfoque de migración, y varios pueden provocar la pérdida de datos si se ignoran.

Solo el mismo proveedor. Este procedimiento admite migraciones dentro del mismo tipo de proveedor de almacenamiento, por ejemplo, Amazon S3 a Amazon S3, Azure Blob a Azure Blob, Google Cloud Storage a Google Cloud Storage o MinIO a MinIO. Las migraciones entre proveedores no se tratan aquí. Para una migración entre proveedores, póngase en contacto con Soporte técnico para GitHub Enterprise.
No cambie el método de autenticación durante la migración. Si actualmente usa la autenticación basada en credenciales, la configuración de destino también debe usar la autenticación basada en credenciales. Lo mismo se aplica a OpenID Connect. Cambiar el método de autenticación durante un cambio de configuración de almacenamiento puede provocar la pérdida de datos. Para obtener más información, vea Actualización de las credenciales para el almacenamiento de Acciones de GitHub. Para cambiar el método de autenticación, complete primero la migración de almacenamiento y, a continuación, planee un cambio independiente.
La estructura de la clave dentro del bucket o contenedor debe conservarse. Las claves de objeto (rutas de acceso) dentro del cubo o contenedor de origen deben permanecer idénticas en el destino. El nombre del cubo de destino, la cuenta de almacenamiento, la región y otros parámetros de conexión pueden cambiar. Se actualizan en la Consola de administración durante el cambio. La mayoría de las herramientas nativas de copia del proveedor conservan automáticamente la estructura de claves al copiar un cubo o contenedor completo, pero compruebe antes del cambio que el destino coincide con el origen.
GitHub Packages tiene restricciones adicionales. Si también utiliza GitHub Packages, consulte la sección de GitHub Packagesconsideraciones que aparece a continuación antes de empezar.

Prerequisites

Tiene acceso de administrador de sitio a tu instancia de GitHub Enterprise Server.
Ha aprovisionado el almacenamiento de destino en el mismo proveedor que el almacenamiento de origen, en la cuenta, región o tenant deseados.
El destino está vacío.
El destino concede tu instancia de GitHub Enterprise Server los mismos permisos que el origen. Para obtener los permisos necesarios, consulte el artículo de configuración correspondiente:
Tiene credenciales administrativas tanto para el almacenamiento de origen como para el de destino, suficientes para leer todos los objetos de origen y escribir en el almacenamiento de destino.
Tiene una copia de seguridad reciente de tu instancia de GitHub Enterprise Server. Para obtener más información, vea Configuración de copias de seguridad en la instancia con utilidades de copia de seguridad.
Ha ensayado la migración en un entorno de ensayo. Consulte la sección siguiente.

Ensayo de la migración en un entorno de ensayo

Antes de realizar la migración en el entorno de producción, ensaye todo el procedimiento en una instancia de preproducción. Cree una instancia de preproducción GitHub Enterprise Server a partir de una copia de seguridad reciente de producción, configúrela para que apunte a un destino temporal que replique el destino de producción previsto y ejecute todos los pasos de este artículo de principio a fin. Para obtener más información, vea Configurar una instancia de preparación y Utilizar un ambiente de montaje.

Un ensayo de puesta en escena permite validar que:

Los permisos del lado proveedor, el acceso a la red y las directivas en el destino son correctos.
La herramienta de copia que ha elegido completa correctamente el proceso con volúmenes de datos representativos.
El recuento de objetos esperado y el tamaño total coinciden entre el origen y el destino.
Los registros y artefactos de las ejecuciones de flujos de trabajo existentes se pueden recuperar desde la interfaz de usuario tras el cambio.

Advertencia

La instancia de almacenamiento provisional debe usar un almacenamiento diferente de la instancia de producción. Si no cambia la configuración de almacenamiento, la instancia de almacenamiento provisional puede escribir en el almacenamiento de producción y provocar la pérdida de datos. Para obtener más información, vea Utilizar un ambiente de montaje.

Realización de la migración

Siga estos pasos en orden. GitHub Actions puede continuar atendiendo el tráfico hasta que habilite el modo de mantenimiento.

Realice la copia de datos inicial. Copie todos los objetos del origen al destino mediante una herramienta nativa del proveedor. Los nuevos objetos escritos en el origen durante la copia se capturarán mediante la sincronización diferencial final después de la migración.

Use los comandos de ejemplo como punto de partida. Consulte la documentación original para obtener el conjunto completo de opciones, incluidas las credenciales, el cifrado y la optimización del rendimiento.

Para Amazon S3, use aws s3 sync desde la interfaz de la línea de comandos de AWS. Ejecute primero una ejecución seca para validar la operación y, a continuación, realice la copia.
```
aws s3 sync s3://SOURCE-BUCKET s3://DESTINATION-BUCKET --dryrun
aws s3 sync s3://SOURCE-BUCKET s3://DESTINATION-BUCKET
```
Para Azure Blob Storage, utilice azcopy copy con una firma de acceso compartido en el origen.
```
azcopy copy 'https://SOURCE-STORAGE-ACCOUNT-NAME.blob.core.windows.net/CONTAINER?SAS-TOKEN' 'https://DESTINATION-STORAGE-ACCOUNT-NAME.blob.core.windows.net/CONTAINER' --recursive
```
Para Google Cloud Storage, utilice gcloud storage rsync de la interfaz de línea de comandos de Google Cloud.
```
gcloud storage rsync --recursive gs://SOURCE-BUCKET gs://DESTINATION-BUCKET
```
Para MinIO, utilice mc mirror del cliente de MinIO.
```
mc mirror SOURCE-ALIAS/SOURCE-BUCKET DESTINATION-ALIAS/DESTINATION-BUCKET
```
Una vez completada la copia, compruebe el recuento de objetos y el tamaño total en el destino mediante las herramientas de descripción estándar del proveedor. Investigue cualquier discrepancia antes de continuar.
Habilite el modo de mantenimiento. Para evitar que se escriban nuevos objetos en el origen durante la migración, habilite el modo de mantenimiento en tu instancia de GitHub Enterprise Server. Esto deja brevemente la instancia fuera de línea para los usuarios finales. Para obtener más información, vea Habilitar y programar el modo de mantenimiento.
Realice la sincronización diferencial final. Con el modo de mantenimiento habilitado, vuelva a ejecutar el mismo comando de copia desde el paso de copia inicial. Esto captura los objetos que se escribieron en el origen después de iniciar la copia inicial.

Por ejemplo, para Amazon S3:
```
aws s3 sync s3://SOURCE-BUCKET s3://DESTINATION-BUCKET
```
Actualice la configuración de almacenamiento. Actualice tu instancia de GitHub Enterprise Server para que apunte a la nueva ubicación de almacenamiento. Mantenga el mismo método de autenticación que antes.
1. Inicie sesión en Consola de administración. Para obtener más información, vea Acceso a la Consola de administración.
2. En la barra lateral "Configuración", haga clic en Acciones.
3. En "Artefactos y almacenamiento de registros", actualice los campos que identifican la ubicación de almacenamiento, por ejemplo, el nombre del bucket, el nombre de la cuenta, la región, el ARN del rol o la cadena de conexión. No cambie el método de autenticación.
4. Haga clic en Probar configuración de almacenamiento para validar la nueva configuración.
  
  Advertencia
  
  Si se produce un error en la prueba, no guarde la configuración. Investigue el error y vuelva a probar antes de continuar. Guardar una configuración de almacenamiento no válida puede provocar una interrupción.
5. Haga clic en Guardar configuración y espere a que los servicios se reinicien completamente.
Como alternativa, puede actualizar la configuración desde la línea de comandos mediante ghe-actions-precheck para la autenticación basada en credenciales. Para obtener más información, vea Utilidades de la línea de comandos.
Valide la migración. Después del cambio de configuración, confirme que GitHub Actions puede leer desde la nueva ubicación de almacenamiento.
1. Deshabilita el modo de mantenimiento. Para obtener más información, vea Habilitar y programar el modo de mantenimiento.
2. En la interfaz de usuario web para tu instancia de GitHub Enterprise Server, abra una ejecución de flujo de trabajo reciente que se completó antes de la migración. Confirme que:
  - Se cargan los registros de ejecución del flujo de trabajo.
  - Los artefactos de compilación se descargan correctamente.
3. Desencadene una nueva ejecución de flujo de trabajo y confirme que:
  - La ejecución se completa correctamente.
  - Los registros y los artefactos generados por la ejecución son visibles.
Si se produce un error en alguna de estas comprobaciones de validación, conserve el almacenamiento de origen y consulte la sección Revertir a continuación.
Desmantelar el almacenamiento de origen. Solo continúe una vez que la validación se haya completado correctamente y haya permitido tiempo suficiente para estar seguro de que la nueva ubicación de almacenamiento es correcta. Como norma, conserve el almacenamiento de origen en un estado de solo lectura durante al menos un ciclo de copia de seguridad completo antes de eliminarlo.

Cuando esté listo para quitar el almacenamiento de origen, siga el procedimiento estándar del proveedor para eliminar un cubo o contenedor.

Reversión

Si la validación falla o surgen problemas después del cambio, vuelve atrás haciendo que tu instancia de GitHub Enterprise Server apunte de nuevo a la ubicación de almacenamiento de origen. El almacenamiento de origen es su copia fiable de referencia. No copie datos del destino al origen como parte de la reversión, ya que los datos escritos en el destino durante un cambio fallido pueden ser parciales o incoherentes, y volver a escribirlos en el origen podría corromper su única copia válida.

Advertencia

Revertir la operación descartará todos los datos que se hayan escrito o eliminado después del cambio. Si se produce un error en la validación, revierte inmediatamente en lugar de intentar la solución de problemas extendida. Cuanto más tiempo espere, más datos están en riesgo.

Si se produce un error en la validación o se producen problemas:

Habilite el modo de mantenimiento inmediatamente.
Consola de administraciónEn , restaure los valores de configuración de almacenamiento originales y haga clic en Probar configuración de almacenamiento y, a continuación, en Guardar configuración.
Deshabilite el modo de mantenimiento y vuelva a ejecutar los pasos de validación con el almacenamiento original.

Después de una reversión satisfactoria, investigue el fallo y planifique un nuevo intento de migración.

Consideraciones de GitHub Packages

Puede aplicar el mismo enfoque de migración al GitHub Packages almacenamiento externo, con las siguientes diferencias importantes. Lea esta sección completa antes de migrar el almacenamiento en una instancia habilitada GitHub Packages .

OpenID Connect no está disponible para GitHub Packages. GitHub Packages solo admite la autenticación basada en credenciales para el almacenamiento externo. La restricción authentication-method de este artículo todavía se aplica: mantenga el método de autenticación sin cambios durante la migración.
GitHub Packages es más sensible a los errores de coincidencia de tiempo. Cuando los paquetes se publican durante la ventana de migración, el sistema crea nuevos objetos de almacenamiento y registros de base de datos. Para evitar la incoherencia, mantenga el modo de mantenimiento habilitado continuamente desde el inicio de la sincronización diferencial final mediante la validación correcta de la nueva configuración.
Actualice ambas configuraciones juntas si el mismo proveedor atiende ambos productos. Si ha configurado GitHub Actions y GitHub Packages para usar el mismo tipo de proveedor y va a migrar ambos, planee la transición como una sola ventana de mantenimiento y actualice ambas configuraciones antes de deshabilitar el modo de mantenimiento.
Para las migraciones entre proveedores de GitHub Packages almacenamiento, póngase en contacto con Soporte técnico para GitHub Enterprise. Los movimientos entre proveedores no se tratan aquí.

Para obtener más información sobre cómo configurar el GitHub Packages almacenamiento, consulte Introducción a los paquetes de GitHub para su empresa.