Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.

Mise à niveau de GitHub Enterprise Server

Mettez à niveau GitHub Enterprise Server pour bénéficier des dernières fonctionnalités et mises à jour de sécurité.

Préparation à une mise à niveau

  1. Établissez une stratégie de mise à niveau et choisissez la version cible de la mise à niveau. Pour plus d’informations, consultez « Conditions à remplir pour la mise à niveau » et Assistant Mise à niveau pour connaître le chemin de mise à niveau à partir de votre version actuelle.

  2. Créez une nouvelle sauvegarde de votre instance principale avec GitHub Enterprise Server Backup Utilities. Pour plus d’informations, consultez le fichier README.md dans la documentation du projet GitHub Enterprise Server Backup Utilities.

    Remarque : Votre version de GitHub Enterprise Server Backup Utilities doit être identique à, ou au plus deux versions ultérieures à, votre instance GitHub Enterprise Server. Pour plus d’informations, consultez « Mise à niveau de GitHub Enterprise Server Backup Utilities ».

  3. Si votre instance GitHub Enterprise Server utilise des exécuteurs auto-hébergés éphémères pour GitHub Actions et que vous avez désactivé les mises à jour automatiques, mettez à niveau vos exécuteurs vers la version de l’application d’exécuteur que votre instance mise à niveau exécutera.

  4. Si vous effectuez une mise à niveau à partir d’un package de mise à niveau, planifiez une fenêtre de maintenance pour les utilisateurs finaux de GitHub Enterprise Server. Si vous utilisez un patch à chaud, le mode maintenance n’est pas obligatoire.

    Remarque : La fenêtre de maintenance dépend du type de mise à niveau que vous effectuez. Les mises à niveau utilisant un patch à chaud ne nécessitent généralement pas de fenêtre de maintenance. Parfois, un redémarrage est exigé, ce que vous pouvez faire ultérieurement. Suivant le schéma de contrôle de version de MAJOR.FEATURE.PATCH, les versions correctives utilisant un package de mise à niveau demandent généralement un temps d’arrêt de moins de cinq minutes. Les mises en production de fonctionnalités qui incluent des migrations de données prennent plus de temps, selon le niveau de performance du stockage et la quantité de données à migrer. Pour plus d’informations, consultez « Activation et planification du mode maintenance ».

Capture d’un instantané

Un instantané est un point de contrôle d’une machine virtuelle à un moment donné. Nous vous recommandons vivement de capturer un instantané avant de mettre à niveau votre machine virtuelle. En cas d’échec de la mise à niveau, vous pourrez ainsi restaurer l’instantané de votre machine virtuelle. Veillez à effectuer la capture d’instantané de la machine virtuelle une fois l’appliance hors tension ou en mode maintenance et après que tous les travaux en arrière-plan ont abouti.

Si vous effectuez une mise à niveau vers une nouvelle mise en production de fonctionnalité, vous devez capturer un instantané de machine virtuelle. Si vous effectuez une mise à niveau vers une version corrective, vous pouvez joindre le disque de données existant.

Il existe deux types d’instantanés :

  • Les instantanés de machine virtuelle enregistrent l’état complet de la machine virtuelle, avec les données utilisateur et les données de configuration. Cette méthode de capture d’instantané demande une grande quantité d’espace disque et s’avère fastidieuse.

  • Les instantanés de disque de données enregistrent uniquement vos données utilisateur.

    Remarques :

    • Certaines plateformes ne vous permettent pas de capturer seulement un instantané de votre disque de données. Pour ces plateformes, vous devez capturer un instantané de l’ensemble de la machine virtuelle.
    • Si votre hyperviseur ne prend pas en charge les instantanés complets de machines virtuelles, vous devez capturer un instantané du disque racine et du disque de données de manière successive et rapide.
PlateformeSnapshot (méthode)URL de la documentation sur la capture d’instantanés
Amazon AWSDisquehttps://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
AzureMachine virtuellehttps://docs.microsoft.com/azure/backup/backup-azure-vms-first-look-arm
Hyper-VMachine virtuellehttps://docs.microsoft.com/windows-server/virtualization/hyper-v/manage/enable-or-disable-checkpoints-in-hyper-v
Google Compute EngineDisquehttps://cloud.google.com/compute/docs/disks/create-snapshots
VMwareMachine virtuellehttps://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.hostclient.doc/GUID-64B866EF-7636-401C-A8FF-2B4584D9CA72.html

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, car ils sont dans la même série de fonctionnalités, mais pas de 2.10.9 à 2.11.0, car ils se trouvent 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 maintenance ».

La Management Console vous permet d’installer un patch à chaud immédiatement ou de planifier une installation ultérieure. Vous pouvez utiliser l’interpréteur de commandes d’administration pour installer un patch à chaud avec l’utilitaire ghe-upgrade. Pour plus d’informations, consultez « Conditions à remplir pour la mise à niveau ».

Notes :

  • Si votre instance GitHub Enterprise Server exécute une build de version finale (RC), vous ne pouvez pas effectuer de mise à niveau avec un patch à chaud.

  • Il n’est pas possible d’installer un patch à chaud à l’aide de la Management Console dans les environnements en cluster. Pour installer un patch à chaud dans un environnement en cluster, consultez « Mise à niveau d’un cluster ».

Mise à niveau d’une seule appliance avec un patch à chaud

Installation d’un patch à chaud à l’aide de la Management Console

Vous pouvez utiliser la Management Console pour effectuer une mise à niveau avec un patch à chaud en activant les mises à jour automatiques. La dernière version disponible de GitHub Enterprise Server vers laquelle effectuer une mise à niveau vous sera alors présentée.

Si la cible de mise à niveau qui vous êtes présentée est une mise en production de fonctionnalité et non une version corrective, vous ne pourrez pas utiliser vous servir de la Management Console pour installer un patch à chaud. Au lieu de cela, vous devrez installer le patch à chaud à l’aide de l’interpréteur de commandes d’administration. Pour plus d’informations, consultez « Installation d’un patch à chaud à l’aide de l’interpréteur de commandes d’administration ».

  1. Activer les mises à jour automatiques. Pour plus d’informations, consultez « Activation des mises à jour automatiques ».

  2. À partir d’un compte d’administration sur GitHub Enterprise Server, cliquez sur dans le coin supérieur droit de n’importe quelle page.

    Capture d’écran de l’icône représentant une fusée qui donne accès aux paramètres d’administration du site

  3. Si vous ne figurez pas déjà sur la page « Administrateur du site », dans le coin supérieur gauche, cliquez sur Administrateur du site.

    Capture d’écran du lien « Administrateur du site » 1. Dans la barre latérale gauche, cliquez sur Management Console . Onglet Management Console dans la barre latérale gauche 1. En haut de la Management Console, cliquez sur Mises à jour. Élément de menu Mises à jour

  4. Après avoir téléchargé un nouveau patch à chaud, utilisez le menu déroulant Installer le package :

    • Pour une installation immédiate, sélectionnez Maintenant :
    • Pour une installation ultérieure, sélectionnez une date ultérieure. Liste déroulante des dates d’installation de patch à chaud
  5. Cliquez sur Installer. Bouton d’installation de patch à chaud

Installation d’un patch à chaud à l’aide de l’interpréteur de commandes d’administration

Remarque : Si vous avez activé les vérifications de mises à jour automatiques, vous n’avez pas besoin de télécharger le package de mise à niveau et pouvez utiliser le fichier qui a été téléchargé automatiquement. Pour plus d’informations, consultez « Activation des vérifications de mises à jour automatiques ».

  1. Connexion SSH à votre instance GitHub Enterprise Server. Si votre instance comprend plusieurs nœuds, par exemple si la haute disponibilité ou la géoréplication sont configurées, connectez-vous via SSH au nœud principal. Si vous utilisez un cluster, vous pouvez vous connecter via SSH à n’importe quel nœud. Pour plus d’informations sur l’accès via SSH, consultez « Accès à l’interpréteur de commandes d’administration (SSH) ».

    $ ssh -p 122 admin@HOSTNAME
  2. Accédez à la page des versions de GitHub Enterprise Server. En regard de la version vers laquelle vous effectuez une mise à niveau, cliquez sur Télécharger, puis sur l’onglet Mise à niveau. Copiez l’URL du package à chaud de mise à niveau (fichier .hpkg).

  3. Téléchargez le package de mise à niveau sur votre instance GitHub Enterprise Server en utilisant curl  :

    admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
  4. Exécutez la commande ghe-upgrade en utilisant le nom de fichier du package :

    admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.hpkg
    *** verifying upgrade package signature...
  5. Si un redémarrage est nécessaire pour les mises à jour du noyau, de MySQL, d’Elasticsearch ou d’autres programmes, le script de mise à niveau corrective à chaud vous le notifie.

Mise à niveau d’une appliance qui possède des instances réplicas à l’aide d’un patch à chaud

Remarque : Si vous installez un patch à chaud, vous n’avez pas besoin de passer en mode maintenance ou d’arrêter la réplication.

Les appliances configurées pour la haute disponibilité et la géoréplication utilisent des instances réplicas en plus des instances principales. Pour mettre à niveau ces appliances, vous devez mettre à niveau l’instance principale et toutes les instances réplicas, l’une après l’autre.

Mise à niveau de l’instance principale

  1. Mettez à niveau l’instance principale en suivant les instructions qui se trouvent dans la section « Installation d’un patch à chaud à l’aide de l’interpréteur de commandes d’administration ».

Mise à niveau d’instances réplicas

Remarque : Si vous exécutez plusieurs instances réplicas dans le cadre de la géoréplication, répétez cette procédure pour chaque instance réplica, l’une après l’autre.

  1. Mettez à niveau l’instance réplica en suivant les instructions qui se trouvent dans la section « Installation d’un patch à chaud à l’aide de l’interpréteur de commandes d’administration ». Si vous utilisez plusieurs réplicas pour la géoréplication, vous devez répéter cette procédure pour mettre à niveau chaque réplica, l’un après l’autre.

  2. Connectez-vous à l’instance de réplica via SSH en tant qu’utilisateur « administrateur » sur le port 122 :

    $ ssh -p 122 admin@REPLICA_HOST
    1. Vérifiez la mise à niveau en exécutant :
    $ ghe-version

Mise à niveau avec un package de mise à niveau

Bien que vous puissiez utiliser un patch à chaud pour effectuer une mise à niveau vers la dernière mise en production de fonctionnalité d’une série de fonctionnalités, vous devez utiliser un package de mise à niveau pour effectuer une mise à niveau vers une mise en production de fonctionnalité plus récente. Par exemple, pour effectuer une mise à niveau de 2.11.10 vers 2.12.4, vous devez utiliser un package de mise à niveau, car il ne s’agit pas de la même séries de fonctionnalités. Pour plus d’informations, consultez « Conditions à remplir pour la mise à niveau ».

Mise à niveau d’une seule appliance avec un package de mise à niveau

Remarque : Si vous avez activé les vérifications de mises à jour automatiques, vous n’avez pas besoin de télécharger le package de mise à niveau et pouvez utiliser le fichier qui a été téléchargé automatiquement. Pour plus d’informations, consultez « Activation des vérifications de mises à jour automatiques ».

  1. Connexion SSH à votre instance GitHub Enterprise Server. Si votre instance comprend plusieurs nœuds, par exemple si la haute disponibilité ou la géoréplication sont configurées, connectez-vous via SSH au nœud principal. Si vous utilisez un cluster, vous pouvez vous connecter via SSH à n’importe quel nœud. Pour plus d’informations sur l’accès via SSH, consultez « Accès à l’interpréteur de commandes d’administration (SSH) ».

    $ ssh -p 122 admin@HOSTNAME
  2. Accédez à la page des versions de GitHub Enterprise Server. En regard de la version vers laquelle vous effectuez une mise à niveau, cliquez sur Télécharger, puis sur l’onglet Mise à niveau. Sélectionnez la plateforme appropriée et copiez l’URL du package de mise à niveau (fichier .pkg).

  3. Téléchargez le package de mise à niveau sur votre instance GitHub Enterprise Server en utilisant curl  :

    admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
  4. Activez le mode maintenance et attendez que tous les processus actifs se terminent sur l’instance GitHub Enterprise Server. Pour plus d’informations, consultez « Activation et planification du mode maintenance ».

    Remarque : Si vous mettez à niveau de l’appliance principale dans une configuration à haute disponibilité, l’appliance doit déjà être en mode maintenance si vous suivez les instructions qui se trouvent dans la section « Mise à niveau de l’instance principale ».

  5. Exécutez la commande ghe-upgrade en utilisant le nom de fichier du package :

    admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg
    *** verifying upgrade package signature...
  6. Confirmez votre volonté de poursuivre la mise à niveau et de redémarrer une fois la signature du package vérifiée. Le nouveau système de fichiers racine écrit dans la partition secondaire et l’instance redémarre automatiquement en mode maintenance :

    *** 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. Si vous le souhaitez, pour valider la mise à niveau, configurez une liste d’exceptions d’IP pour autoriser l’accès à une liste d’adresses IP spécifiée. Pour plus d’informations, consultez « Validation des modifications en mode maintenance à l’aide de la liste des exceptions d’IP ».

  8. Pour les mises à niveau d’appliance unique, désactivez le mode maintenance pour permettre aux utilisateurs d’utiliser votre instance GitHub Enterprise Server.

    Remarque : Si vous mettez à niveau des appliances dans une configuration à haute disponibilité, vous devez rester en mode maintenance tant que vous n’avez pas mis à niveau tous les réplicas et que la réplication est en cours. Pour plus d’informations, consultez « Mise à niveau d’une instance réplica ».

Mise à niveau d’une appliance qui possède des instances réplicas à l’aide d’un package de mise à niveau

Les appliances configurées pour la haute disponibilité et la géoréplication utilisent des instances réplicas en plus des instances principales. Pour mettre à niveau ces appliances, vous devez mettre à niveau l’instance principale et toutes les instances réplicas, l’une après l’autre.

Mise à niveau de l’instance principale

Avertissement : Quand la réplication est arrêtée, une défaillance de l’instance principale fait perdre tout travail effectué avant la mise à niveau du réplica et le redémarrage de la réplication.

  1. Sur l’instance principale, activez le mode maintenance et attendez que tous les processus actifs se terminent. Pour plus d’informations, consultez « Activation du mode maintenance ».
  2. Connectez-vous à l’instance de réplica via SSH en tant qu’utilisateur « administrateur » sur le port 122 :
    $ ssh -p 122 admin@REPLICA_HOST
  3. Sur l’instance réplica, ou sur toutes les instances réplicas si vous exécutez plusieurs instances réplicas dans le cadre de la géoréplication, exécutez ghe-repl-stop pour arrêter la réplication.
  4. Mettez à niveau l’instance principale en suivant les instructions de la section « Mise à niveau d’une seule appliance avec un package de mise à niveau ».

Mise à niveau d’instances réplicas

Remarque : Si vous exécutez plusieurs instances réplicas dans le cadre de la géoréplication, répétez cette procédure pour chaque instance réplica, l’une après l’autre.

  1. Mettez à niveau l’instance réplica en suivant les instructions de la section « Mise à niveau d’une seule appliance avec un package de mise à niveau ». Si vous utilisez plusieurs réplicas pour la géoréplication, vous devez répéter cette procédure pour mettre à niveau chaque réplica, l’un après l’autre.

  2. Connectez-vous à l’instance de réplica via SSH en tant qu’utilisateur « administrateur » sur le port 122 :

    $ ssh -p 122 admin@REPLICA_HOST
    1. Vérifiez la mise à niveau en exécutant :
    $ ghe-version
  3. Sur l’instance de réplica, pour démarrer la réplication, exécutez ghe-repl-start.

  4. Sur l’instance de réplica, pour vérifier que les services de réplication s’exécutent correctement, exécutez ghe-repl-status. Cette commande retourne OK pour tous les services quand une réplication réussie est en cours et que le réplica a été mis à niveau. Si la commande retourne Replication is not running, la réplication peut encore démarrer. Attendez environ une minute avant de réexécuter ghe-repl-status.

    Remarque : Pendant la resynchronisation, ghe-repl-status peut indiquer que la réplication est en retard. Par exemple, vous pouvez voir le message d’erreur suivant.

    CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists
    
    • Si vous avez mis à niveau chaque nœud vers GitHub Enterprise Server 3.6.0 ou ultérieur et que vous avez démarré la réplication, mais que git replication is behind the primary continue à apparaître après 45 minutes, contactez GitHub Enterprise Support. Pour plus d’informations, consultez « Obtention d’aide auprès du GitHub Support ».

    • Sinon, si ghe-repl-status ne retourne pas OK, contactez GitHub Enterprise Support. Pour plus d’informations, consultez « Obtention d’aide auprès du GitHub Support ».

  5. Une fois que la mise à niveau du dernier réplica a abouti et que la resynchronisation est terminée, désactivez le mode maintenance pour permettre aux utilisateurs de se servir de votre instance GitHub Enterprise Server.

Restauration à partir d’une mise à niveau avortée

En cas d’échec ou d’interruption d’une mise à niveau, vous devez restaurer votre instance dans son état précédent. La procédure permettant d’effectuer cette opération dépend du type de mise à niveau.

Annulation d’une version corrective

Pour annuler une version corrective, utilisez la commande ghe-upgrade avec le commutateur --allow-patch-rollback. Avant cela, la réplication doit être temporairement arrêtée en exécutant ghe-repl-stop sur toutes les instances réplicas. Quand vous restaurez une mise à niveau, vous devez utiliser un fichier de package de mise à niveau avec l’extension .pkg. Les fichiers de package de patch à chaud avec l’extension .hpkg ne sont pas pris en charge.

ghe-upgrade --allow-patch-rollback EARLIER-RELEASE-UPGRADE-PACKAGE.pkg

Un redémarrage est nécessaire après l’exécution de cette commande. La restauration n’affecte pas la partition de données, car les migrations ne sont pas exécutées sur les versions de patch.

Une fois l’opération terminée, redémarrez la réplication en exécutant ghe-repl-start sur tous les réplicas.

Pour plus d’informations, consultez « Utilitaires en ligne de commande ».

Annulation d’une mise en production de fonctionnalité

Pour une restauration à partir d’une mise en production de fonctionnalité, restaurez l’instantané d’une machine virtuelle de sorte que les partitions racine et de données se trouvent dans un état cohérent. Pour plus d’informations, consultez « Capture d’un instantané ».

Pour aller plus loin