Mise à niveau d’un cluster

Pour mettre à niveau un cluster GitHub Enterprise Server vers la dernière version, utilisez l’interpréteur de commandes d’administration (SSH).

Qui peut utiliser cette fonctionnalité ?

GitHub détermine l’éligibilité au clustering et doit activer la configuration de la licence de votre instance. Le clustering nécessite une planification minutieuse et une surcharge administrative supplémentaire. Pour plus d’informations, consultez « À propos du clustering ».

Dans cet article

À propos des mises à niveau vers un cluster GitHub Enterprise Server

GitHub Enterprise Server s’améliore constamment grâce aux mises en production de fonctionnalités et de patchs. Celles-ci incluent en effet de nouvelles fonctionnalités et des correctifs de bogues. Vous êtes responsable des mises à niveau vers votre instance. Pour plus d’informations, consultez « À propos des mises à niveau vers de nouvelles mises en production ».

Pour mettre à niveau une instance, vous devez planifier et communiquer la mise à niveau, choisir le package approprié, sauvegarder vos données et effectuer la mise à niveau.

Mise à niveau avec un patch à chaud

Vous pouvez mettre à niveau GitHub Enterprise Server vers la dernière version corrective en utilisant un patch à chaud.

Vous pouvez utiliser la mise à niveau à chaud pour effectuer une mise à niveau vers une version de correctif plus récente, mais pas une mise en production de fonctionnalité. Par exemple, vous pouvez effectuer une mise à niveau de 2.10.1 vers 2.10.5, parce qu’ils sont dans la même série de fonctionnalités, mais pas de 2.10.9 vers 2.11.0 parce qu’ils sont dans des séries de fonctionnalités différentes.

Les mises à jour correctives à chaud ne nécessitent pas toujours de redémarrage. Lorsque vous installez le correctif à chaud, un message s’affiche dans le terminal si l’un des packages a besoin d’un redémarrage pour terminer la mise à jour. Vous pouvez planifier ce redémarrage à un moment commode, mais nous vous recommandons de redémarrer dès que possible, en particulier s’il existe des correctifs de sécurité.

Les patchs à chaud nécessitent une exécution de configuration, qui peut provoquer une brève période d’erreurs ou d’absence de réponse pour tout ou partie des services sur votre instance GitHub Enterprise Server. Vous n’êtes pas obligé d’activer le mode maintenance pendant l’installation d’un patch à chaud, mais cela garantit que les utilisateurs voient une page de maintenance au lieu de messages d’erreur ou d’expiration de délai. Consultez « Activation et planification du mode de maintenance ». Le script d’installation de patch à chaud installe le patch à chaud sur chaque nœud du cluster et redémarre les services dans le bon ordre pour éviter un temps d’arrêt.

  1. Sauvegardez vos données avec GitHub Enterprise Server Backup Utilities.

  2. Dans l’interpréteur de commandes d’administration d’un nœud quelconque, utilisez la commande ghe-cluster-hotpatch pour installer le dernier patch à chaud. Vous pouvez indiquer l’URL d’un patch à chaud ou télécharger manuellement ce dernier et spécifier un nom de fichier local.

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

Mise à niveau avec un package de mise à niveau

Utilisez un package de mise à niveau pour mettre à niveau un cluster GitHub Enterprise Server vers la dernière mise en production de fonctionnalité. Par exemple, vous pouvez effectuer une mise à niveau de 2.11 vers 2.13.

Préparation à une mise à niveau

  1. Examinez Configuration réseau de cluster pour la version vers laquelle vous effectuez la mise à niveau, puis mettez à jour votre configuration, si nécessaire.

  2. Sauvegardez vos données avec GitHub Enterprise Server Backup Utilities.

  3. Planifiez une fenêtre de maintenance pour les utilisateurs finaux de votre cluster GitHub Enterprise Server, car il ne pourra pas être utilisé normalement pendant la mise à niveau. Le mode maintenance bloque l’accès des utilisateurs et empêche les modifications de données pendant la mise à niveau du cluster.

  4. Dans la page de téléchargement de GitHub Enterprise Server , copiez l’URL du fichier .pkg de mise à niveau dans le Presse-papiers.

  5. Dans l’interpréteur de commandes d’administration d’un nœud quelconque, utilisez la commande ghe-cluster-each avec curl pour télécharger le package de mise en production sur chaque nœud en une seule étape. Utilisez l’URL que vous avez copiée à l’étape précédente comme argument.

    $ 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. Identifiez le nœud MySQL principal, qui est défini par mysql-master = <hostname> dans cluster.conf. Ce nœud sera mis à niveau en dernier.

Mise à niveau des nœuds du cluster

  1. Activez le mode maintenance en fonction de votre fenêtre planifiée en vous connectant à l’interpréteur de commandes d’administration d’un nœud du cluster et en exécutant ghe-cluster-maintenance -s.

  2. Si vous effectuez une mise à niveau de la version 3.11 ou 3.12 vers la version 3.13 ou ultérieure, Elasticsearch sera mis à niveau dans le cadre de la mise à niveau vers votre cluster. Pour plus d’informations, consultez « Préparation de la mise à niveau d’Elasticsearch dans GitHub Enterprise Server 3.13 ».

    Avant la mise à niveau, vous devez exécuter un script pour préparer votre cluster à une mise à niveau vers la version 3.13 ou 3.14.

    1. Vérifiez que vous exécutez la version corrective requise pour votre version actuelle : 3.11.9 ou version ultérieure pour la version 3.11 ou 3.12.3 ou ultérieure pour la version 3.12.
    2. Sur n’importe quel nœud elasticsearch-server, exécutez /usr/local/share/enterprise/ghe-es-auditlog-cluster-rebalance.

  3. À l’exception du nœud MySQL principal, connectez-vous à l’interpréteur de commandes d’administration de chaque nœud GitHub Enterprise Server. Exécutez la commande ghe-upgrade en indiquant le nom de fichier du package que vous avez téléchargé à l’étape 4 de Préparation à la mise à niveau :

    $ 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. Le processus de mise à niveau redémarre le nœud une fois qu’il est arrivé à son terme. Vérifiez que vous pouvez effectuer un test ping sur chaque nœud qui a redémarré.

  5. Connectez-vous à l’interpréteur de commandes d’administration du nœud MySQL principal. Exécutez la commande ghe-upgrade en indiquant le nom de fichier du package que vous avez téléchargé à l’étape 4 de Préparation à la mise à niveau :

    $ 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. Le processus de mise à niveau redémarre le nœud MySQL principal une fois qu’il est arrivé à son terme. Vérifiez que vous pouvez effectuer un test ping sur chaque nœud qui a redémarré

    Important

    Avant de passer à l’étape suivante, vous devez attendre la fin de la configuration après la mise à niveau. Pour surveiller la progression de l’exécution de la configuration, lisez la sortie dans /data/user/common/ghe-config.log. Par exemple, vous pouvez suivre le journal en exécutant la commande suivante :

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

  7. Connectez-vous à l’interpréteur de commandes d’administration du nœud MySQL principal et exécutez la commande ghe-cluster-config-apply.

  8. Une fois que la commande ghe-cluster-config-apply a abouti, vérifiez que les services sont dans un état sain en exécutant ghe-cluster-status.

  9. Quittez le mode maintenance de l’interpréteur de commandes d’administration d’un nœud en exécutant ghe-cluster-maintenance -u.