Actualizar el servidor de GitHub Enterprise

Acerca de las actualizaciones a GitHub Enterprise Server

GitHub Enterprise Server mejora constantemente y agrega correcciones de errores y funcionalidades nuevas mediante el lanzamiento de características y revisiones. Eres el responsable de las actualizaciones de la instancia. Para obtener más información, vea «Acerca de las mejoras a los nuevos lanzamientos».

Para actualizar una instancia, debe planificar y comunicar la actualización, elegir el paquete adecuado, hacer una copia de seguridad de los datos y, a continuación, realizar la actualización.

Prerrequisitos

Para actualizar correctamente los datostu instancia de GitHub Enterprise Server, el disco de datos de la instancia debe ser al menos un 15 % libre. GitHub recomienda asegurarse de que haya más almacenamiento libre en el disco. En algunos casos poco frecuentes, para los clientes con grandes volúmenes de datos, este umbral puede diferir.

Preparar para una actualización

Para prepararse para una actualización, planifique la ruta de actualización, opcionalmente actualice los ejecutores GitHub Actions y programe una ventana de mantenimiento.

1. Determina una estrategia de actualización y elige una versión a la que actualizar. Para más información, vea "Requisitos de actualización" y consulte Asistente para actualización para encontrar la ruta de actualización de la versión actual.

2. Cree una copia de seguridad nueva del nodo primario de instancia con GitHub Enterprise Server Backup Utilities. Para más información, consulte README de la documentación del proyecto de GitHub Enterprise Server Backup Utilities.

   Nota: La versión de GitHub Enterprise Server Backup Utilities debe ser la misma que la detu instancia de GitHub Enterprise Server o, como máximo, dos versiones posteriores. Para obtener más información, vea «Configurar copias de seguridad en tu aparato».

3. Si tu instancia de GitHub Enterprise Server usa ejecutores autohospedados efímeros para GitHub Actions y has deshabilitado las actualizaciones automáticas, actualiza los ejecutores a la versión de la aplicación de ejecutor que la instancia actualizada ejecutará.

4. Si estás actualizando con un paquete de actualización, programa una ventana de mantenimiento para los usuarios finales del GitHub Enterprise Server. Si estás usando un hotpatch, no se necesita el modo mantenimiento.

   Nota: La ventana de mantenimiento depende del tipo de actualización que realice. Las actualizaciones que utilizan un hotpatch por lo general no necesitan una ventana de mantenimiento. A veces se necesita reiniciar; puedes hacerlo más tarde. Siguiendo el esquema de control de versiones de MAJOR.FEATURE.PATCH, los lanzamientos de patch que utilizan un paquete de actualización normalmente necesitan menos de cinco minutos de tiempo de inactividad. Los lanzamientos de funciones que incluyen migraciones de datos toman más tiempo dependiendo del desempeño del almacenamiento y de la cantidad de datos que se migran. Para obtener más información, vea «Habilitar y programar el modo de mantenimiento».

Tomar una instantánea

Una instantánea almacena el estado de una máquina virtual (VM) en un momento en el tiempo. GitHub recomienda encarecidamente tomar una instantánea antes de actualizar la máquina virtual para que si falla una actualización, pueda revertir la VM nuevamente a la instantánea. GitHub solo recomienda tomar una instantánea de máquina virtual cuando la máquina virtual de la instancia está apagada o cuando la instancia está en modo de mantenimiento y todos los trabajos en segundo plano han finalizado.

Si no estás actualizando a un nuevo lanzamiento de característica, debes tomar una instantánea de VM. Si estás actualizando a un nuevo lanzamiento de patch, puedes adjuntar el disco de datos existente.

Hay dos tipos de instantáneas:

• Las instantáneas de VM guardan el estado completo de la VM, incluidos los datos del usuario y de configuración. Este método de instantáneas requiere una gran cantidad de espacio de disco e insume mucho tiempo.

• Las instantáneas de disco de datos solo guardan los datos de usuario.

  Notas:

  • Algunas plataformas no permiten que tomes una instantánea solo de tu disco de datos. Para estas plataformas, necesitarás tomar una instantánea de tu VM completa.
  • Si tu hipervisor no admite instantáneas de VM completas, debes tomar una instantánea de tu disco raíz y de tu disco de datos en rápida sucesión.

Plataforma	Snapshot (método)	Documentación
Amazon AWS	Disco	Creación de instantáneas de Amazon EBS en la documentación de AWS
Azure	máquina virtual	Realización de copias de seguridad de una máquina virtual de Azure desde la configuración de esta con Azure Backup en Microsoft Learn
Hyper-V	máquina virtual	Habilitación o deshabilitación de puntos de control en Hyper-V en Microsoft Learn
Google Compute Engine	Disco	Creación y administración de instantáneas de disco en la documentación de Google Cloud
VMware	máquina virtual	Instantáneas de una máquina virtual en VMware Docs

Elección de un paquete de actualización

Puede actualizar una instancia de GitHub Enterprise Server a una nueva versión de revisión o a una nueva versión de características. Para actualizar a una versión de revisión, puede usar una revisión frecuente o un paquete de actualización. Para actualizar a una versión de características, debe usar un paquete de actualización.

Una instancia de GitHub Enterprise Server consta de uno o varios nodos. El proceso de actualización que debe seguir depende del número de nodos que tiene la instancia. Para obtener más información, vea «Acerca de GitHub Enterprise Server».

• Actualizar con un hotpatch
  • Actualización de una instancia independiente mediante una revisión activa
  • Actualización de una instancia con varios nodos mediante una revisión activa
• Actualizar con un paquete de actualización
  • Actualización de una instancia independiente mediante un paquete de actualización
  • Actualización de una instancia con varios nodos mediante un paquete de actualización

Actualizar con un hotpatch

Puedes actualizar GitHub Enterprise Server a la versión de revisión más reciente mediante una revisión en caliente.

Puedes utilizar los hotpatches para subir de categoría a un nuevo lanzamiento parchado, pero no a un lanzamiento de características. Por ejemplo, puedes subir de nivel de 2.10.1 a 2.10.5 porque están en la misma serie de características, pero no de 2.10.9 a 2.11.0, porque están en una serie de características diferente.

Por lo general, las revisiones en caliente no requieren un reinicio. Si una revisión en caliente requiere un reinicio, las notas de la versión de GitHub Enterprise Server indicarán este requisito.

Las revisiones en caliente requieren una ejecución de configuración, lo que puede provocar un breve período de errores o falta de respuesta en algunos servicios de tu instancia de GitHub Enterprise Server o en todos ellos. No es necesario habilitar el modo de mantenimiento durante la instalación de una revisión en caliente, pero si lo hace, se garantiza que los usuarios vean una página de mantenimiento en lugar de errores o tiempos de espera. Para obtener más información, vea «Habilitar y programar el modo de mantenimiento».

Si utilizas la Consola de administración, puedes instalar un hotpatch de inmediato o programarlo para que se instale posteriormente. Puede usar el shell administrativo para instalar una revisión en caliente con la utilidad ghe-upgrade. Para obtener más información, vea «Requisitos de actualización».

• Actualización de una instancia independiente mediante una revisión en caliente
• Actualización de una instancia con varios nodos mediante una revisión en caliente

Actualización de una instancia independiente mediante una revisión en caliente

Si va a actualizar una instancia con un nodo utilizando una revisión en caliente y el destino es una versión de revisión, puede actualizar utilizando Consola de administración. Para actualizar a una versión de características, debes usar el shell administrativo.

• Instalar un hotpatch utilizando la Consola de administración
• Instalar un hotpatch utilizando un shell administrativo

Instalar un hotpatch utilizando la Consola de administración

Puedes utilziar la Consola de administración para hacer una mejora con un hotpatch si habilitas las actualizaciones automáticas. Entonces se te presentará la última versión disponible de GitHub Enterprise Server a la cual puedes mejorar.

Si el objetivo de actualización que se te presentó es un lanzamiento de una característica en vez de un lanzamiento de parche, no podrás utilizar la Consola de administración para instalar un hotpatch. En vez de eso, deberás instalar el hotpatch utilizando el shell administrativo. Para más información, vea "Instalación de una revisión en caliente mediante el shell administrativo".

1. Habilitar las actualizaciones automáticas. Para obtener más información, vea «Habilitar comprobaciones de actualización automáticas».

2. Desde una cuenta administrativa de GitHub Enterprise Server, en la esquina superior derecha de cualquier página, haga clic en .

3. Si todavía no está en la página "Administrador del sitio", en la esquina superior izquierda, haga clic en Administrador del sitio. 1. En la barra lateral " Administrador del sitio", haz clic en Consola de administración . 1. En la barra de navegación superior, haga clic en Actualizaciones

   

4. Cuando se ha descargado una nueva revisión en caliente, seleccione el menú desplegable del Paquete de instalación.

   • Para instalar inmediatamente, haga clic en Ahora.
   • Para instalarlo más tarde, selecciona una fecha posterior.

5. Haga clic en Instalar.

Instalar un hotpatch utilizando un shell administrativo

1. SSH en tu instancia de GitHub Enterprise Server Si la instancia consta de varios nodos, por ejemplo, si la alta disponibilidad o la replicación geográfica están configuradas, utiliza SSH en el nodo principal. Si usas un clúster, puedes utilizar SSH en cualquier nodo. Para más información sobre el acceso SSH, consulta "Acceder al shell administrativo (SSH)".

   $ ssh -p 122 admin@HOSTNAME

2. Vaya a la página de versiones de GitHub Enterprise Server. Junto a la versión a la que va a actualizar, haga clic en Download y después en la pestaña Upgrading. Copie la URL para obtener el paquete de actualización (archivo .hpkg).

3. Descargue el paquete de actualización a tu instancia de GitHub Enterprise Server mediante curl :

   admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL

4. Ejecute el comando ghe-upgrade con el nombre del archivo de paquete:

   admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.hpkg
   *** verifying upgrade package signature...

5. Si al menos un servicio o componente del sistema requiere un reinicio, el script de actualización de hotpatch se lo notifica. Por ejemplo, las actualizaciones del kernel, MySQL o Elasticsearch pueden requerir un reinicio.

Actualización de una instancia con varios nodos mediante una revisión en caliente

Si va a instalar una revisión en caliente, no es necesario entrar en modo de mantenimiento ni detener la replicación.

• Actualización del nodo principal mediante una revisión en caliente
• Actualización de nodos adicionales mediante una revisión en caliente

Actualización del nodo principal mediante una revisión en caliente

Para obtener instrucciones para actualizar el nodo principal, consulte "Instalación de una revisión de acceso rápido mediante el shell administrativo".

Actualización de nodos adicionales mediante una revisión en caliente

Para actualizar una instancia que consta de varios nodos, como una configuración de alta disponibilidad o replicación geográfica, debe repetir el procedimiento siguiente en cada nodo de réplica, de uno en uno.

1. Para actualizar el nodo, siga las instrucciones de "Instalación de una revisión en caliente mediante el shell administrativo".

2. Conéctese al nodo de réplica a través de SSH como el usuario admin en el puerto 122:

   $ ssh -p 122 admin@REPLICA_HOST

   1. Verifica la mejora ejecutando:

   $ ghe-version

   1. Repita los pasos anteriores para cada nodo adicional.

Actualizar con un paquete de actualización

Al mismo tiempo que puedes utilizar un hotpatch para actualizar al lanzamiento de patch más reciente dentro de una serie de características, debes utilizar un paquete de actualización para actualizar a un lanzamiento de característica más nuevo. Por ejemplo, para actualizar de 2.11.10 a 2.12.4 debe usar un paquete de actualización, ya que se encuentran en diferentes series de características. Para obtener más información, vea «Requisitos de actualización».

• Actualización de una instancia independiente mediante un paquete de actualización
• Actualización de una instancia con varios nodos mediante un paquete de actualización

Actualización de una instancia independiente mediante un paquete de actualización

1. SSH en tu instancia de GitHub Enterprise Server Si la instancia consta de varios nodos, por ejemplo, si la alta disponibilidad o la replicación geográfica están configuradas, utiliza SSH en el nodo principal. Si usas un clúster, puedes utilizar SSH en cualquier nodo. Para más información sobre el acceso SSH, consulta "Acceder al shell administrativo (SSH)".

   $ ssh -p 122 admin@HOSTNAME

2. Vaya a la página de versiones de GitHub Enterprise Server. Junto a la versión a la que va a actualizar, haga clic en Download y después en la pestaña Upgrading. Seleccione la plataforma adecuada y copia la URL para obtener el paquete de actualización (archivo .pkg).

3. Descargue el paquete de actualización a tu instancia de GitHub Enterprise Server mediante curl :

   admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL

4. Habilita el modo mantenimiento y espera que se completen todos los procesos activos en la instancia del GitHub Enterprise Server. Para obtener más información, vea «Habilitar y programar el modo de mantenimiento».

   Nota: Al actualizar el nodo principal en una configuración de alta disponibilidad, la instancia ya debería estar en modo de mantenimiento si sigue las instrucciones de "Actualización del nodo principal".

5. Ejecute el comando ghe-upgrade con el nombre del archivo de paquete:

   admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg
   *** verifying upgrade package signature...

6. Confirma que te gustaría continuar con la actualización y reinicia después de que se verifique la firma del paquete. El nuevo sistema de archivos raíz escribe en la segunda partición y la instancia de forma automática se reinicia en modo mantenimiento:

   *** applying update...
   This package will upgrade your installation to version VERSION-NUMBER
   Current root partition: /dev/xvda1 [VERSION-NUMBER]
   Target root partition:  /dev/xvda2
   Proceed with installation? [y/N]

7. Una vez reiniciada la instancia, la actualización continuará en segundo plano. No se puede anular el modo de mantenimiento hasta que se complete el proceso. Para supervisar el progreso, lee la salida en /data/user/common/ghe-config.log. Por ejemplo, puedes seguir el registro ejecutando el siguiente comando:

   tail -f /data/user/common/ghe-config.log

8. Opcionalmente, para validar la actualización, configura una lista de excepciones IP para permitir el acceso a una lista especificada de direcciones IP. Para obtener más información, vea «Habilitar y programar el modo de mantenimiento».

9. Para las actualizaciones de un solo nodo, deshabilita el modo mantenimiento para que los usuarios puedan usar tu instancia de GitHub Enterprise Server.

   Nota: Después de actualizar una instancia en una configuración de alta disponibilidad, debe mantenerse en modo de mantenimiento hasta que haya actualizado todos los nodos de réplica y la replicación sea actual. Para obtener más información, consulte "Actualización de nodos adicionales con un paquete de actualización".

Actualización de una instancia con varios nodos mediante un paquete de actualización

Para actualizar una instancia que consta de varios nodos mediante un paquete de actualización, debe actualizar el nodo principal y, a continuación, actualizar los nodos adicionales.

• Actualización del nodo principal con un paquete de actualización
• Actualización de nodos adicionales con un paquete de actualización

Actualización del nodo principal con un paquete de actualización

1. En el nodo principal, habilita el modo mantenimiento y espera a que se completen todos los procesos activos. Para obtener más información, vea «Habilitar y programar el modo de mantenimiento».
2. Conéctese al nodo de réplica a través de SSH como el usuario admin en el puerto 122:

   $ ssh -p 122 admin@REPLICA_HOST

3. Para detener la replicación en todos los nodos, ejecute ghe-repl-stop en cada nodo.
4. Para actualizar el nodo principal, sigue las instrucciones de "Actualización de una instancia independiente mediante un paquete de actualización".

Actualización de nodos adicionales con un paquete de actualización

Para actualizar una instancia que consta de varios nodos, como una configuración de alta disponibilidad o replicación geográfica, debe repetir el procedimiento siguiente en cada nodo de réplica, de uno en uno.

1. Actualiza el nodo principal con las instrucciones de "Actualización de una instancia independiente mediante un paquete de actualización".

2. Conéctese al nodo de réplica a través de SSH como el usuario admin en el puerto 122:

   $ ssh -p 122 admin@REPLICA_HOST

   1. Verifica la mejora ejecutando:

   $ ghe-version

   1. En la instancia de réplica, para iniciar la replicación, ejecute `ghe-repl-start`. 1. En el nodo de réplica, para garantizar que los servicios de replicación se ejecuten correctamente, ejecute `ghe-repl-status`. Este comando devolverá `OK` para todos los servicios cuando hay una replicación correcta en curso y la réplica se haya actualizado. Si el comando devuelve `Replication is not running`, es posible que la replicación se siga iniciando. Espere aproximadamente un minuto antes de volver a ejecutar `ghe-repl-status`.

   Nota: Aunque la resincronización esté en curso, ghe-repl-status podría indicar que la replicación va por detrás. Por ejemplo, podría aparecer el siguiente mensaje de error.

   CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists
   

• Si has actualizado cada nodo a GitHub Enterprise Server 3.6.0 o una versión posterior y has iniciado la replicación, pero sigue apareciendo git replication is behind the primary al cabo de 45 minutos, ponte en contacto con Soporte técnico para GitHub Enterprise. Para obtener más información, vea «Contactar al Soporte de GitHub».

• En caso contrario, si ghe-repl-status no devolvió OK, ponte en contacto con Soporte técnico para GitHub Enterprise. Para obtener más información, vea «Contactar al Soporte de GitHub».

1. Repita los pasos anteriores para cada nodo adicional.
2. Cuando haya actualizado el último nodo de réplica y la resincronización esté completa, deshabilite el modo mantenimiento para que los usuarios puedan usar tu instancia de GitHub Enterprise Server.

Restaurar desde una actualización fallida

Si una actualización falla o se interrumpe, deberías revertir tu instancia a su estado anterior. El proceso para completar esto depende del tipo de actualización.

Revertir un lanzamiento de patch

Para revertir una versión de revisión, use el comando ghe-upgrade con el modificador --allow-patch-rollback. Antes de la reversión, la replicación se debe detener temporalmente mediante la ejecución de ghe-repl-stop en todos los nodos de réplica. Al revertir una actualización, tendrá que usar un archivo de paquete de actualización con la extensión .pkg. Los archivos de paquete de revisión en caliente con la extensión .hpkg no se admiten.

ghe-upgrade --allow-patch-rollback EARLIER-RELEASE-UPGRADE-PACKAGE.pkg

Se requiere que reinicies después de ejecutar el comando. Bajar de categoría una mejora previa no afecta la partición de datos, ya que las migraciones no se ejecutan en lanzamientos parchados.

Después de completar la reversión, reinicie la replicación mediante la ejecución de ghe-repl-start en todos los nodos.

Para obtener más información, vea «Utilidades de la ea de comandos».

Revertir un lanzamiento de característica

Para revertir un lanzamiento de característica, restaura desde una instantánea de VM para garantizar que las particiones raíz y de datos estén en un estado consistente. Para más información, vea "Realización de una instantánea".

Información adicional

• "Acerca de las mejoras a los nuevos lanzamientos"