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.
-
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.
-
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».
-
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á.
-
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
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».
Notas:
-
Si tu instancia de GitHub Enterprise Server ejecuta una compilación de versión candidata para lanzamiento, no la puedes actualizar con una revisión en caliente.
-
Instalar de un hotpatch utilizando Consola de administración no está disponible para clústeres. Para instalar un hotpatch para un clúster, consulte "Actualizar una agrupació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".
-
Habilitar las actualizaciones automáticas. Para obtener más información, vea «Habilitar comprobaciones de actualización automáticas».
-
Desde una cuenta administrativa de GitHub Enterprise Server, en la esquina superior derecha de cualquier página, haga clic en .
-
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
-
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.
-
Haga clic en Instalar.
Instalar un hotpatch utilizando un shell administrativo
Nota: Si ha habilitado las comprobaciones de actualizaciones automáticas, no es necesario descargar el paquete de actualizaciones y puede usar el archivo que se ha descargado automáticamente. Para obtener más información, vea «Habilitar comprobaciones de actualización automáticas».
-
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
-
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).
-
Descargue el paquete de actualización a tu instancia de GitHub Enterprise Server mediante
curl
:admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
-
Ejecute el comando
ghe-upgrade
con el nombre del archivo de paquete:admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.hpkg *** verifying upgrade package signature...
-
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.
-
Para actualizar el nodo, siga las instrucciones de "Instalación de una revisión en caliente mediante el shell administrativo".
-
Conéctese al nodo de réplica a través de SSH como el usuario
admin
en el puerto 122:
1. Verifica la mejora ejecutando:$ ssh -p 122 admin@REPLICA_HOST
1. Repita los pasos anteriores para cada nodo adicional.$ ghe-version
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
Nota: Si ha habilitado las comprobaciones de actualizaciones automáticas, no es necesario descargar el paquete de actualizaciones y puede usar el archivo que se ha descargado automáticamente. Para obtener más información, vea «Habilitar comprobaciones de actualización automáticas».
-
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
-
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).
-
Descargue el paquete de actualización a tu instancia de GitHub Enterprise Server mediante
curl
:admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
-
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".
-
Ejecute el comando
ghe-upgrade
con el nombre del archivo de paquete:admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg *** verifying upgrade package signature...
-
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]
-
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
-
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».
-
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
Advertencia: Cuando se detiene la replicación, si se produce un error en la instancia primaria, se perderá cualquier trabajo que se realice antes de que la réplica esté actualizada y vuelva a comenzar la replicación.
- 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».
- 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
- Para detener la replicación en todos los nodos, ejecute
ghe-repl-stop
en cada nodo. - 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.
-
Actualiza el nodo principal con las instrucciones de "Actualización de una instancia independiente mediante un paquete de actualización".
-
Conéctese al nodo de réplica a través de SSH como el usuario
admin
en el puerto 122:
1. Verifica la mejora ejecutando:$ ssh -p 122 admin@REPLICA_HOST
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`.$ ghe-version
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».
- Repita los pasos anteriores para cada nodo adicional.
- 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".