Esta versión de GitHub Enterprise se discontinuará el 2022-02-16. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener un mejor desempeño, más seguridad y nuevas características, actualiza a la última versión de GitHub Enterprise. Para obtener ayuda con la actualización, contacta al soporte de GitHub Enterprise.

Upgrading GitHub Enterprise Server

Upgrade GitHub Enterprise Server to get the latest features and security updates.

Note: Features such as GitHub Actions, Registro del paquete de GitHub, GitHub para móviles and GitHub Advanced Security are available on GitHub Enterprise Server 3.0 or higher. We highly recommend upgrading to 3.0 or later releases to take advantage of critical security updates, bug fixes and feature enhancements.

Preparing to upgrade

  1. Determine an upgrade strategy and choose a version to upgrade to. For more information, see "Upgrade requirements" and refer to the Upgrade assistant to find the upgrade path from your current release version.

  2. Create a fresh backup of your primary instance with the Utilidades de respaldo del servidor de GitHub Enterprise. For more information, see the Utilidades de respaldo del servidor de GitHub Enterprise README.md file.

  3. If you are upgrading using an upgrade package, schedule a maintenance window for GitHub Enterprise Server end users. If you are using a hotpatch, maintenance mode is not required.

    Note: The maintenance window depends on the type of upgrade you perform. Upgrades using a hotpatch usually don't require a maintenance window. Sometimes a reboot is required, which you can perform at a later time. Following the versioning scheme of MAJOR.FEATURE.PATCH, patch releases using an upgrade package typically require less than five minutes of downtime. Feature releases that include data migrations take longer depending on storage performance and the amount of data that's migrated. For more information, see "Enabling and scheduling maintenance mode."

Acerca de los requisitos mínimos para GitHub Enterprise Server 3.0 y superior

Antes de actualizar a GitHub Enterprise Server 3.0 o superior, revisa los recursos de hardware que has aprovisionado para tu instancia. GitHub Enterprise Server 3.0 presenta características nuevas tales como GitHub Actions y el Registro del paquete de GitHub, y requiere más recursos que la versión 2.22 y anteriores. Para obtener más información, consulta la sección de notas de lanzamiento para GitHub Enterprise Server 3.0.

Los requisitos que incrementan para GitHub Enterprise Server 3.0 y posterior se muestran en negritas en la siguiente tabla.

Licencias de usuariovCPUMemoriaAlmacenamiento conectadoAlmacenamiento raíz
Prueba, Demo o 10 usuarios no frecuentes4
Aumentando desde 2
32 GB
Aumentando desde 16 GB
150 GB
Aumentando desde 100 GB
200 GB
10-30008
Aumentando desde 4
48 GB
Aumentando desde 32 GB
300 GB
Aumentando desde 250 GB
200 GB
3000-500012
Aumentando desde 8
64 GB500 GB200 GB
5000-800016
Aumentando desde 12
96 GB750 GB200 GB
8000-10000+20
Aumentando desde 16
160 GB
Aumentando desde 128 GB
1000 GB200 GB

Para obtener más información acerca de los requisitos de hardware para las GitHub Actions, consulta la sección "Comenzar con las GitHub Actions para GitHub Enterprise Server".

Para obtener más información sobre el ajuste de recursos para una instancia existente, consulta las secciones "Incrementar la capacidad de almacenamiento" e "Incrementar los recursos de memoria o de CPU".

Taking a snapshot

A snapshot is a checkpoint of a virtual machine (VM) at a point in time. We highly recommend taking a snapshot before upgrading your virtual machine so that if an upgrade fails, you can revert your VM back to the snapshot. If you're upgrading to a new feature release, you must take a VM snapshot. If you're upgrading to a patch release, you can attach the existing data disk.

There are two types of snapshots:

  • VM snapshots save your entire VM state, including user data and configuration data. This snapshot method requires a large amount of disk space and is time consuming.

  • Data disk snapshots only save your user data.

    Notes:

    • Some platforms don't allow you to take a snapshot of just your data disk. For these platforms, you'll need to take a snapshot of the entire VM.
    • If your hypervisor does not support full VM snapshots, you should take a snapshot of the root disk and data disk in quick succession.
PlatformSnapshot methodSnapshot documentation URL
Amazon AWSDiskhttps://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
AzureVMhttps://docs.microsoft.com/azure/backup/backup-azure-vms-first-look-arm
Hyper-VVMhttps://docs.microsoft.com/windows-server/virtualization/hyper-v/manage/enable-or-disable-checkpoints-in-hyper-v
Google Compute EngineDiskhttps://cloud.google.com/compute/docs/disks/create-snapshots
VMwareVMhttps://pubs.vmware.com/vsphere-50/topic/com.vmware.wssdk.pg.doc_50/PG_Ch11_VM_Manage.13.3.html
XenServerVMhttps://docs.citrix.com/en-us/xencenter/current-release/vms-snapshots.html

Upgrading with a hotpatch

Puedes mejorar GitHub Enterprise Server al último lanzamiento parchado utilizando un hotpatch, lo cual no requerirá una ventana de mantenimiento y, habitualmente, no requiere un reinicio. 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 mejorar de 2.10.1 a 2.10.5 porque pertenecen a 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. Using the Consola de administración, you can install a hotpatch immediately or schedule it for later installation. You can use the administrative shell to install a hotpatch with the ghe-upgrade utility. For more information, see "Upgrade requirements."

Notes:

  • If tu instancia de GitHub Enterprise Server is running a release candidate build, you can't upgrade with a hotpatch.

  • Installing a hotpatch using the Consola de administración is not available in clustered environments. To install a hotpatch in a clustered environment, see "Upgrading a cluster."

Upgrading a single appliance with a hotpatch

Installing a hotpatch using the Consola de administración

  1. Enable automatic updates. For more information, see "Enabling automatic updates."
  2. Desde una cuenta administrativa en GitHub Enterprise Server, da clic en la esquina superior derecha de cualquier página. Ícono de cohete para acceder a las configuraciones de administrador del sitio
  3. En la barra lateral izquierda, haz clic en Consola de administración. pestaña Consola de administración en la barra lateral izquierda
  4. En la parte superior de Consola de administración, da clic en Actualizaciones. Actualiza el elemento del menú
  5. When a new hotpatch has been downloaded, use the Install package drop-down menu:
    • To install immediately, select Now:
    • To install later, select a later date. Hotpatch installation date dropdown
  6. Click Install. Hotpatch install button

Installing a hotpatch using the administrative shell

Nota: Si habilitaste las verificaciones de actualizaciones automáticas, no necesitas descargar el paquete de actualizaciones y puedes usar el archivo que se descargó automáticamente. Para obtener más información, consulta "Enabling automatic update checks" (Habilitar verificaciones de actualizaciones automáticas).

  1. SSH en tu instancia de GitHub Enterprise Server. Para obtener más información, consulta "Acceder al shell administrativo (SSH)."
    $ ssh -p 122 admin@HOSTNAME
  2. Visita la GitHub Enterprise Server Página de lanzamientos. Junto a la versión a la que vas a actualizar, haz clic en Download (Descargar), luego haz clic en la pestaña Upgrading (Actualización). Copy the URL for the upgrade hotpackage (.hpkg file).
  3. Descarga el paquete de actualizaciones a tu instancia de GitHub Enterprise Server con curl:
    admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
  4. Run the ghe-upgrade command using the package file name:
    admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.hpkg
    *** verifying upgrade package signature...
  5. If a reboot is required for updates for kernel, MySQL, Elasticsearch or other programs, the hotpatch upgrade script notifies you.

Upgrading an appliance that has replica instances using a hotpatch

Note: If you are installing a hotpatch, you do not need to enter maintenance mode or stop replication.

Appliances configured for high-availability and geo-replication use replica instances in addition to primary instances. To upgrade these appliances, you'll need to upgrade both the primary instance and all replica instances, one at a time.

Upgrading the primary instance

  1. Upgrade the primary instance by following the instructions in "Installing a hotpatch using the administrative shell."

Upgrading a replica instance

Note: If you're running multiple replica instances as part of geo-replication, repeat this procedure for each replica instance, one at a time.

  1. Upgrade the replica instance by following the instructions in "Installing a hotpatch using the administrative shell." If you are using multiple replicas for Geo-replication, you must repeat this procedure to upgrade each replica one at a time.

  2. Conéctate a la instancia 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

Upgrading with an upgrade package

While you can use a hotpatch to upgrade to the latest patch release within a feature series, you must use an upgrade package to upgrade to a newer feature release. For example to upgrade from 2.11.10 to 2.12.4 you must use an upgrade package since these are in different feature series. For more information, see "Upgrade requirements."

Upgrading a single appliance with an upgrade package

Nota: Si habilitaste las verificaciones de actualizaciones automáticas, no necesitas descargar el paquete de actualizaciones y puedes usar el archivo que se descargó automáticamente. Para obtener más información, consulta "Enabling automatic update checks" (Habilitar verificaciones de actualizaciones automáticas).

  1. SSH en tu instancia de GitHub Enterprise Server. Para obtener más información, consulta "Acceder al shell administrativo (SSH)."

    $ ssh -p 122 admin@HOSTNAME
  2. Visita la GitHub Enterprise Server Página de lanzamientos. Junto a la versión a la que vas a actualizar, haz clic en Download (Descargar), luego haz clic en la pestaña Upgrading (Actualización). Select the appropriate platform and copy the URL for the upgrade package (.pkg file).

  3. Descarga el paquete de actualizaciones a tu instancia de GitHub Enterprise Server con curl:

    admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
  4. Enable maintenance mode and wait for all active processes to complete on the GitHub Enterprise Server instance. For more information, see "Enabling and scheduling maintenance mode."

    Note: When upgrading the primary appliance in a High Availability configuration, the appliance should already be in maintenance mode if you are following the instructions in "Upgrading the primary instance."

  5. Run the ghe-upgrade command using the package file name:

    admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg
    *** verifying upgrade package signature...
  6. Confirm that you'd like to continue with the upgrade and restart after the package signature verifies. The new root filesystem writes to the secondary partition and the instance automatically restarts in maintenance mode:

    *** 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. For single appliance upgrades, disable maintenance mode so users can use tu instancia de GitHub Enterprise Server.

    Note: When upgrading appliances in a High Availability configuration you should remain in maintenance mode until you have upgraded all of the replicas and replication is current. For more information, see "Upgrading a replica instance."

Upgrading an appliance that has replica instances using an upgrade package

Appliances configured for high-availability and geo-replication use replica instances in addition to primary instances. To upgrade these appliances, you'll need to upgrade both the primary instance and all replica instances, one at a time.

Upgrading the primary instance

Warning: When replication is stopped, if the primary fails, any work that is done before the replica is upgraded and the replication begins again will be lost.

  1. On the primary instance, enable maintenance mode and wait for all active processes to complete. For more information, see "Enabling maintenance mode."
  2. Conéctate a la instancia réplica a través de SSH como el usuario "admin" en el puerto 122:
    $ ssh -p 122 admin@replica-host
  3. On the replica instance, or on all replica instances if you're running multiple replica instances as part of geo-replication, run ghe-repl-stop to stop replication.
  4. Upgrade the primary instance by following the instructions in "Upgrading a single appliance with an upgrade package."

Upgrading a replica instance

Note: If you're running multiple replica instances as part of geo-replication, repeat this procedure for each replica instance, one at a time.

  1. Upgrade the replica instance by following the instructions in "Upgrading a single appliance with an upgrade package." If you are using multiple replicas for Geo-replication, you must repeat this procedure to upgrade each replica one at a time.

  2. Conéctate a la instancia 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 réplica, para comenzar la replicación, ejecuta ghe-repl-start.

  5. En la instancia replicada, para garantizar que se estén ejecutando correctamente los servicios de replicación, ejecuta ghe-repl-status. Este comando devolverá un OK para todos los servicios cuando exista una replicación exitosa en progreso y la réplica se haya mejorado. If the command returns Replication is not running, the replication may still be starting. Wait about one minute before running ghe-repl-status again.

    Note: While the resync is in progress ghe-repl-status may return expected messages indicating that replication is behind. For example: CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists

    If ghe-repl-status did not return OK, contact Soporte para GitHub Enterprise. For more information, see "Receiving help from Soporte de GitHub."

  6. When you have completed upgrading the last replica, and the resync is complete, disable maintenance mode so users can use tu instancia de GitHub Enterprise Server.

Restoring from a failed upgrade

If an upgrade fails or is interrupted, you should revert your instance back to its previous state. The process for completing this depends on the type of upgrade.

Rolling back a patch release

To roll back a patch release, use the ghe-upgrade command with the --allow-patch-rollback switch. Cuando bajes de categoría una mejora que ya hayas hecho, deberás utilizar un archivo de paquete de mejora con la extensión .pkg. No hay compatibilidad con los archivos de paquete de hotpatch con la extensión .hpkg.

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.

For more information, see "Command-line utilities."

Rolling back a feature release

To roll back from a feature release, restore from a VM snapshot to ensure that root and data partitions are in a consistent state. For more information, see "Taking a snapshot."

Further reading

¿Te ayudó este documento?

Política de privacidad

¡Ayúdanos a hacer geniales estos documentos!

Todos los documentos de GitHub son de código abierto. ¿Notas algo que esté mal o que no sea claro? Emite una solicitud de cambios.

Haz una contribución

O, aprende cómo contribuir.