Actualizar una agrupación

Para actualizar un clúster de GitHub Enterprise Server a la versión más reciente, usa el shell administrativo (SSH).

¿Quién puede utilizar esta característica?

GitHub determina la idoneidad para la agrupación en clústeres y debe habilitar la configuración de la licencia de la instancia. La agrupación en clústeres conlleva una planeación cuidadosa y una sobrecarga administrativa adicional. Para obtener más información, vea «Acerca de las agrupaciones».

En este artículo

Acerca de las actualizaciones al clúster 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.

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.

Las revisiones en caliente no siempre requieren un reinicio. Al instalar la revisión en caliente, verá un mensaje en el terminal si alguno de los paquetes necesita reiniciarse para completar la actualización. Puede programar este reinicio en un momento que le convenga, pero se recomienda reiniciar tan pronto como sea práctico, especialmente si hay alguna corrección de seguridad.

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. Consulte "Habilitar y programar el modo de mantenimiento".El script de instalación de hotpatch instala el hotpatch en cada nodo de la agrupación y reinicia los servicios en su secuencia adecuada para evitar el tiempo de inactividad.

  1. Copia de seguridad de los datos con GitHub Enterprise Server Backup Utilities.

  2. Desde el shell administrativo de cualquier nodo, use el comando ghe-cluster-hotpatch para instalar la última revisión en caliente. Puedes proporcionar una URL para un hotpatch, o descargar manualmente el hotpatch y especificar un nombre de archivo local.

    ghe-cluster-hotpatch https://HOTPATCH-URL/FILENAME.hpkg

Actualizar con un paquete de actualización

Usa un paquete de actualización para actualizar una agrupación de GitHub Enterprise Server a la última característica de lanzamiento. Por ejemplo, puede actualizar de 2.11 a 2.13.

Preparar para una actualización

  1. Revisa Configuración de la red de agrupaciones para la versión a la que vayas a actualizar y actualiza la configuración según sea necesario.

  2. Copia de seguridad de los datos con GitHub Enterprise Server Backup Utilities.

  3. Planifica una ventana de mantenimiento para los usuarios finales de tu agrupación de GitHub Enterprise Server, dado que no estará disponible para usar normalmente durante la actualización. El modo de mantenimiento bloquea el acceso de los usuarios e impide que se realicen cambios en los datos mientras la actualización de la agrupación está en curso.

  4. En la página de descargas de GitHub Enterprise Server, copie la dirección URL del archivo .pkg de actualización en el Portapapeles.

  5. Desde el shell administrativo de cualquier nodo, use el comando ghe-cluster-each combinado con curl a fin de descargar el paquete de versión para cada nodo en un solo paso. Usa la URL que copiaste en el paso anterior como argumento.

    $ ghe-cluster-each -- "cd /home/admin && curl -L -O https://PACKAGE-URL.pkg"
> ghe-app-node-1:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-app-node-1:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  24.2M      0  0:00:20  0:00:20 --:--:-- 27.4M
> ghe-data-node-2:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-data-node-2:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  21.3M      0  0:00:23  0:00:23 --:--:-- 25.8M
> ghe-data-node-1:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-data-node-1:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  19.7M      0  0:00:25  0:00:25 --:--:-- 25.6M
> ghe-app-node-2:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-app-node-2:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  19.8M      0  0:00:25  0:00:25 --:--:-- 17.6M
> ghe-data-node-3:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-data-node-3:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  19.7M      0  0:00:25  0:00:25 --:--:-- 25.5M

  6. Identifique el nodo MySQL principal, que se define como mysql-master = <hostname> en cluster.conf. Este será el último nodo que se actualizará.

Actualizar los nodos de la agrupación

  1. Para habilitar el modo de mantenimiento en función de la ventana de programación, conéctese al shell administrativo de cualquier nodo de clúster y ejecute ghe-cluster-maintenance -s.

  2. Si vas a actualizar de la versión 3.11 o 3.12 a la versión 3.13 o posterior, Elasticsearch se actualizará como parte de la actualización al clúster. Para más información, consulta Preparación de la actualización de Elasticsearch en GitHub Enterprise Server 3.13.

    Antes de actualizar, deberás ejecutar un script a fin de preparar el clúster para una actualización a la versión 3.13 o 3.14.

    1. Asegúrate de ejecutar la versión de revisión necesaria para la versión actual: 3.11.9 o posterior para la versión 3.11, o 3.12.3 o posterior para la versión 3.12.
    2. En cualquier nodo de elasticsearch-server, ejecuta /usr/local/share/enterprise/ghe-es-auditlog-cluster-rebalance.

  3. Con la excepción del nodo MySQL primario, conéctese al shell administrativo de cada uno de los nodos de GitHub Enterprise Server. Ejecuta el comando ghe-upgrade y proporciona el nombre del archivo de paquete que has descargado en el paso 4 de Preparación para la actualización:

    $ ghe-upgrade PACKAGE-FILENAME.pkg
> *** verifying upgrade package signature...
>  497MB 0:00:04 [ 117MB/s] [==========================================>] 100%
> gpg: Signature made Fri 19 Feb 2016 02:33:50 PM UTC using RSA key ID 0D65D57A
> gpg: checking the trustdb
> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
> gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
> gpg: Good signature from "GitHub Enterprise (Upgrade Package Key) > <enterprise@github.com>"

  4. El proceso de actualización reiniciará el nodo MySQL principal una vez que esté completo. Compruebe que puede usar ping en cada nodo después de reiniciarlo.

  5. Conecta con el shell administrativo del nodo MySQL principal. Ejecuta el comando ghe-upgrade y proporciona el nombre del archivo de paquete que has descargado en el paso 4 de Preparación para la actualización:

    $ ghe-upgrade PACKAGE-FILENAME.pkg
> *** verifying upgrade package signature...
>  497MB 0:00:04 [ 117MB/s] [==========================================>] 100%
> gpg: Signature made Fri 19 Feb 2016 02:33:50 PM UTC using RSA key ID 0D65D57A
> gpg: checking the trustdb
> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
> gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
> gpg: Good signature from "GitHub Enterprise (Upgrade Package Key) > <enterprise@github.com>"

  6. El proceso de actualización reiniciará el nodo MySQL principal una vez que esté completo. Comprueba que puedes usar ping en cada nodo después de reiniciarlo

    Important

    Antes de continuar con el paso siguiente, debes esperar a que se complete la configuración posterior a la actualización. 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

  7. Conéctese al shell administrativo del nodo MySQL principal y ejecute el comando ghe-cluster-config-apply.

  8. Cuando termines ghe-cluster-config-apply, ejecuta ghe-cluster-status para comprobar que los servicios están en un estado correcto.

  9. Ejecute ghe-cluster-maintenance -u para salir del modo de mantenimiento del shell administrativo de cualquier nodo.