Mise à niveau d’un cluster

À 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 patchs à chaud ne nécessitent généralement pas de redémarrage. Si un patch à chaud nécessite un redémarrage, les notes de publication de GitHub Enterprise Server indiquent la configuration requise.

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. Pour plus d’informations, 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.

Sauvegardez vos données avec GitHub Enterprise Server Backup Utilities.
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

Examinez la configuration réseau du cluster pour la version vers laquelle vous effectuez la mise à niveau, puis mettez à jour votre configuration, si nécessaire.
Sauvegardez vos données avec GitHub Enterprise Server Backup Utilities.
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.
Dans la page de téléchargement de GitHub Enterprise Server , copiez l’URL du fichier .pkg de mise à niveau dans le Presse-papiers.

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

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

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.

À 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>"

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

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

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é.
Connectez-vous à l’interpréteur de commandes d’administration du nœud MySQL principal et exécutez la commande ghe-cluster-config-apply.
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.
Quittez le mode maintenance de l’interpréteur de commandes d’administration d’un nœud en exécutant ghe-cluster-maintenance -u.