Migration de GitHub Enterprise 11.10.x vers 2.1.23

Pour effectuer une migration de GitHub Enterprise 11.10.x vers 2.1.23, vous devez configurer une nouvelle instance de l’appliance et migrer les données à partir de l’instance précédente.

Dans cet article

Note

GitHub Enterprise Server 11.10 est une version non prise en charge de 2014. Pour obtenir la liste des versions prises en charge, consultez « Versions de GitHub Enterprise Server ».

Les migrations à partir de GitHub Enterprise version 11.10.348 et ultérieures sont prises en charge. Les migrations à partir de GitHub Enterprise version 11.10.348 et antérieures ne sont pas prises en charge. Vous devez d’abord effectuer une mise à niveau vers la version 11.10.348 en plusieurs mises à niveau. Pour plus d’informations, consultez la procédure de mise à niveau 11.10.348, « Mise à niveau vers la dernière version ».

Pour effectuer une mise à niveau vers la dernière version de GitHub Enterprise, vous devez d’abord migrer vers GitHub Enterprise Server 2.1, puis suivre le processus de mise à niveau normal. Pour plus d’informations, consultez « Vue d'ensemble du processus de mise à niveau ».

Se préparer à la migration

  1. Consultez le guide de provisionnement et d’installation et vérifiez que tous les prérequis nécessaires au provisionnement et à la configuration de GitHub Enterprise 2.1.23 dans votre environnement sont respectés. Pour plus d’informations, consultez « Provisionnement et installation ».

  2. Vérifiez que l’instance active exécute une version de mise à niveau prise en charge.

  3. Configurez la dernière version de GitHub Enterprise Server Backup Utilities. Pour plus d’informations, consultez GitHub Enterprise Server Backup Utilities.

    • Si vous avez déjà configuré des sauvegardes planifiées à l’aide de GitHub Enterprise Server Backup Utilities, vérifiez que vous avez procédé à une mise à jour vers la dernière version.
    • Si vous n’exécutez pas actuellement de sauvegardes planifiées, configurez GitHub Enterprise Server Backup Utilities.

  4. Capturez un instantané initial de sauvegarde complète de l’instance active à l’aide de la commande ghe-backup. Si vous avez déjà configuré des sauvegardes planifiées pour votre instance active, vous n’avez pas besoin de capturer un instantané de votre instance.

    Tip

    Vous pouvez laisser l’instance en ligne et en activité pendant la capture de l’instantané. Vous capturerez un autre instantané durant la phase de maintenance de la migration. Sachant que les sauvegardes sont incrémentielles, cet instantané initial limite la quantité de données transférées dans l’instantané final, ce qui peut raccourcir la fenêtre de maintenance.

  5. Déterminez la méthode pour aiguiller le trafic réseau utilisateur vers la nouvelle instance. Après avoir effectué la migration, l’ensemble du trafic réseau HTTP et Git est dirigé vers la nouvelle instance.

    • DNS – Nous recommandons cette méthode pour tous les environnements, car elle est simple et fonctionne bien même quand il s’agit de migrer d’un centre de données vers un autre. Avant de commencer la migration, réduisez la durée de vie TTL de l’enregistrement DNS existant à cinq minutes ou moins et autorisez que la modification se propage. Une fois la migration terminée, mettez à jour les enregistrements DNS pour les faire pointer vers l’adresse IP de la nouvelle instance.
    • Attribution d’adresse IP – Cette méthode est disponible uniquement dans le cadre d’une migration de VMware vers VMware et n’est pas recommandée, sauf si la méthode DNS n’est pas disponible. Avant de commencer la migration, vous devez arrêter l’ancienne instance et affecter son adresse IP à la nouvelle instance.

  6. Planifiez une fenêtre de maintenance. La fenêtre de maintenance doit être suffisamment longue pour permettre le transfert de données de l’hôte de sauvegarde vers la nouvelle instance, qui variera en fonction de la taille de l’instantané de sauvegarde et de la bande passante réseau disponible. Pendant la migration vers la nouvelle instance, votre instance active sera indisponible et en mode maintenance.

Effectuer la migration

  1. Provisionnez une nouvelle instance GitHub Enterprise 2.1. Pour plus d’informations, consultez le guide « Provisionnement et installation » pour votre plateforme cible.

  2. Dans un navigateur, accédez à l’adresse IP de la nouvelle appliance réplica et chargez votre licence GitHub Enterprise.

  3. Définissez un mot de passe d’administrateur.

  4. Cliquez sur Migrer.

  5. Dans le champ de texte « Ajouter une nouvelle clé SSH », collez votre clé SSH d’accès à l’hôte de sauvegarde.

  6. Cliquez sur Ajouter la clé, puis sur Continuer.

  7. Copiez la commande ghe-restore que vous allez exécuter sur l’hôte de sauvegarde pour migrer les données vers la nouvelle instance.

  8. Activez le mode maintenance sur l’ancienne instance et attendez que tous les processus actifs se terminent. Pour plus d’informations, consultez « Activation et planification du mode de maintenance ».

    Note

    L’instance ne pourra pas être utilisée normalement à partir de cet instant.

  9. Sur l’hôte de sauvegarde, exécutez la commande ghe-backup pour capturer un instantané de sauvegarde final. Vous serez ainsi assuré que toutes les données de l’ancienne instance seront capturées.

  10. Sur l’hôte de sauvegarde, exécutez la commande ghe-restore que vous avez copiée dans l’écran d’état de restauration de la nouvelle instance pour restaurer le dernier instantané.

    $ ghe-restore 169.254.1.1
The authenticity of host '169.254.1.1:122' can't be established.
RSA key fingerprint is fe:96:9e:ac:d0:22:7c:cf:22:68:f2:c3:c9:81:53:d1.
Are you sure you want to continue connecting (yes/no)? yes
Connect 169.254.1.1:122 OK (v2.0.0)
Starting restore of 169.254.1.1:122 from snapshot 20141014T141425
Restoring Git repositories ...
Restoring GitHub Pages ...
Restoring asset attachments ...
Restoring hook deliveries ...
Restoring MySQL database ...
Restoring Redis database ...
Restoring SSH authorized keys ...
Restoring Elasticsearch indices ...
Restoring SSH host keys ...
Completed restore of 169.254.1.1:122 from snapshot 20141014T141425
Visit https://169.254.1.1/setup/settings to review appliance configuration.

  11. Revenez à l’écran d’état de restauration de la nouvelle instance pour vérifier que la restauration a bien abouti.

  12. Cliquez sur Continuer vers les paramètres pour examiner et ajuster les informations et les paramètres de configuration importés à partir de l’instance précédente.

  13. Cliquez sur Enregistrer les paramètres.

    Note

    Vous pouvez utiliser la nouvelle instance après avoir appliqué les paramètres de configuration et redémarré le serveur.

  14. Aiguillez le trafic réseau utilisateur de l’ancienne instance vers la nouvelle instance via l’affectation DNS ou d’adresse IP.

  15. Effectuez une mise à niveau vers la dernière version corrective de GitHub Enterprise Server. Pour plus d’informations, consultez « Vue d'ensemble du processus de mise à niveau ».