Skip to main content

Enterprise Server 3.15 actualmente está disponible como versión candidata para lanzamiento.

Actualizar con un paquete de actualización

Aprenda a usar un paquete de actualización para actualizar GitHub Enterprise Server a una versión de actualización de características más reciente.

Usando el shell administrativo, puede instalar un paquete de actualización con la utilidad ghe-upgrade.

Si está ejecutando actualizaciones de versiones de características back-to-back, debe asegurarse de que los trabajos en segundo plano se completen antes de continuar con la siguiente actualización a una versión de características. GitHub recomienda esperar 24 horas entre actualizaciones para permitir que las tareas de actualización en segundo plano se completen antes de actualizar una segunda vez. Consulta "Información general del proceso de actualización" y "Requisitos 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.

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

Note

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».

  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. Reemplace HOSTNAME por el nombre de host de la instancia, o el nombre de host o la dirección IP de un nodo. Para obtener más información, vea «Acceder al shell administrativo (SSH)».

    Shell
    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. Consulte "Habilitar y programar el modo de mantenimiento".

    Note

    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 con un paquete de actualización”.

  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. Opcionalmente, durante una actualización a una versión de características, puedes supervisar el estado de las migraciones de base de datos mediante la utilidad ghe-migrations. Consulte "Utilidades de la ea de comandos".

  8. 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 comprobar el estado de los trabajos en segundo plano, usa la utilidad ghe-check-background-upgrade-jobs. Si estás ejecutando actualizaciones de back-to-back, debes asegurarte de que los trabajos en segundo plano se completen antes de continuar con la siguiente actualización a una versión de características. Consulte "Utilidades de la ea de comandos".

Para supervisar el progreso de la ejecución de configuración, 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
  1. Opcionalmente, para validar la actualización, configura una lista de excepciones IP para permitir el acceso a una lista especificada de direcciones IP. Consulte "Habilitar y programar el modo de mantenimiento".

  2. Para las actualizaciones de un solo nodo, realice las tareas posteriores a la actualización, incluyendo la inhabilitación del modo mantenimiento para que los usuarios puedan usar tu instancia de GitHub Enterprise Server.

    Note

    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. 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

Warning

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.

  1. En el nodo principal, habilita el modo mantenimiento y espera a que se completen todos los procesos activos. Consulte "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. Como alternativa, si hay varias réplicas, ejecute ghe-repl-stop-all en el nodo principal, lo que detendrá la replicación en una sola ejecución.

  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

  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
    
  3. Verifica la mejora ejecutando:

    ghe-version
    
  4. En la instancia de réplica, para iniciar la replicación, ejecute ghe-repl-start. Como alternativa, si hay varias réplicas, ejecute ghe-repl-start-all en el nodo principal, lo que iniciará las replicaciones en una sola ejecución. 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 esté iniciando todavía. Espere aproximadamente un minuto antes de volver a ejecutar ghe-repl-status.

    Notas:

    • 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 se habilita GitHub Actions en tu instancia de GitHub Enterprise Server, es posible que veas un mensaje similar al siguiente. Este mensaje se espera cuando la replicación está en pausa debido a que se ha establecido el modo de mantenimiento en el dispositivo principal. Una vez que el modo de mantenimiento deja de estar activado, este mensaje debe resolverse.

      CRITICAL: mssql replication is down, didn't find Token_Configuration!
      

    Si ghe-repl-status no devolvió OK y la explicación no aparece en la nota anterior, póngase en contacto con Soporte técnico para GitHub Enterprise. Para obtener más información, vea «Contactar al Soporte de GitHub».

  5. Repita los pasos anteriores para cada nodo adicional.

  6. 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.