Migration du stockage externe de GitHub Actions

À propos de la migration du GitHub Actions stockage externe

Vous pouvez migrer le GitHub Actions stockage externe vers un nouveau compartiment, un compte ou une région sur le même fournisseur lors de la consolidation de comptes cloud, en répondant aux exigences de résidence ou en réorganisant la location de stockage.

La migration fonctionne, car GitHub Actions identifie les objets stockés par leur clé (chemin) dans un compartiment ou un conteneur, et non par le nom du compartiment ou du compte. Tant que vous conservez la disposition de clé interne et que vous mettez à jour votre configuration pour qu’elle pointe vers le nouvel emplacement, les journaux de flux de travail et les artefacts existants restent accessibles sans interruption.

Considerations

Avant de commencer, passez en revue les contraintes suivantes. Chacune forme l’approche de migration et plusieurs peuvent entraîner une perte de données si elle est ignorée.

Même fournisseur uniquement. Cette procédure prend en charge les migrations au sein du même type de fournisseur de stockage, par exemple, Amazon S3 vers Amazon S3, Azure Blob vers Azure Blob, Google Cloud Storage vers Google Cloud Storage ou MinIO vers MinIO. Les migrations entre fournisseurs ne sont pas abordées ici. Pour une migration inter-fournisseurs, contactez Support GitHub Enterprise.
Ne modifiez pas la méthode d’authentification pendant la migration. Si vous utilisez actuellement l’authentification basée sur les informations d’identification, votre configuration de destination doit également utiliser l’authentification basée sur les informations d’identification. La même chose s’applique à OpenID Connect. Le changement de méthode d’authentification pendant une modification de configuration de stockage peut entraîner une perte de données. Pour plus d’informations, consultez « Mise à jour des informations d’identification pour le stockage GitHub Actions ». Pour modifier la méthode d’authentification, effectuez d’abord la migration du stockage, puis planifiez une modification distincte.
L’agencement des clés dans le bac ou le conteneur doit être préservé. Les clés d’objet (chemins) dans votre compartiment ou conteneur source doivent rester inchangées dans la destination. Le nom du compartiment de destination, le compte de stockage, la région et d’autres paramètres de connexion peuvent changer. Vous les mettez à jour dans le Console de gestion au moment du basculement. La plupart des outils de copie de fournisseur natif conservent automatiquement la disposition des clés lors de la copie d’un compartiment ou d’un conteneur entier, mais vérifiez avant le basculement que la destination correspond à la source.
GitHub Packages a des contraintes supplémentaires. Si vous utilisez GitHub Packageségalement , consultez la GitHub Packages section considérations ci-dessous avant de commencer.

Prerequisites

Vous disposez d’un accès administrateur de site à votre instance GitHub Enterprise Server.
Vous avez approvisionné le stockage de destination sur le même fournisseur que la source, dans le compte, la région ou la location souhaités.
La destination est vide.
La destination accorde votre instance GitHub Enterprise Server les mêmes autorisations que la source. Pour obtenir les autorisations requises, consultez l’article de configuration approprié :
Vous disposez des identifiants administrateur pour le stockage source et le stockage de destination, ce qui est suffisant pour lire tous les objets sources et écrire dans le stockage de destination.
Vous avez une sauvegarde récente de votre instance GitHub Enterprise Server. Pour plus d’informations, consultez « Configuration des sauvegardes sur votre instance avec les utilitaires de sauvegarde ».
Vous avez répété la migration dans un environnement intermédiaire. Voir la section suivante.

Répétition de la migration dans un environnement intermédiaire

Avant d’effectuer la migration en production, répétez l’intégralité de la procédure sur une instance de préproduction. Créez une instance de préproduction GitHub Enterprise Server à partir d’une sauvegarde récente de la production, faites-la pointer vers une destination temporaire qui reflète la destination de production prévue, puis suivez toutes les étapes de cet article du début à la fin. Pour plus d’informations, consultez « Configuration d’une instance de préproduction » et « Utilisation d’un environnement intermédiaire ».

Une répétition en environnement de préproduction permet de valider les éléments suivants :

Les autorisations côté fournisseur, l’accès réseau et les stratégies sur la destination sont correctes.
L’outil de copie que vous avez choisi s’exécute correctement avec des volumes de données représentatifs.
Nombre d’objets attendus et correspondance de taille totale entre la source et la destination.
Les journaux et artefacts d’exécution des flux de travail existants peuvent être récupérés dans l’interface utilisateur après le basculement.

Avertissement

Votre instance intermédiaire doit utiliser un stockage différent de votre instance de production. Si vous ne modifiez pas la configuration du stockage, l’instance intermédiaire peut écrire dans votre stockage de production et entraîner une perte de données. Pour plus d’informations, consultez « Utilisation d’un environnement intermédiaire ».

Exécution de la migration

Suivez les étapes suivantes dans l’ordre. GitHub Actions peut continuer à traiter le trafic jusqu’à ce que vous activiez le mode maintenance.

Effectuez la copie initiale des données. Copiez tous les objets de la source vers la destination à l’aide d’un outil natif fournisseur. Les nouveaux objets ajoutés à la source pendant la copie seront pris en compte par la synchronisation delta finale après le basculement.

Utilisez les exemples de commandes comme point de départ. Reportez-vous à la documentation en amont pour obtenir l’ensemble complet d’options, notamment les informations d’identification, le chiffrement et le réglage du débit.

Pour Amazon S3, utilisez aws s3 sync l’interface de ligne de commande AWS. Exécutez d’abord une exécution sèche pour valider l’opération, puis effectuez la copie.
```
aws s3 sync s3://SOURCE-BUCKET s3://DESTINATION-BUCKET --dryrun
aws s3 sync s3://SOURCE-BUCKET s3://DESTINATION-BUCKET
```
Pour Stockage Blob Azure, utilisez azcopy copy une signature d’accès partagé sur la source.
```
azcopy copy 'https://SOURCE-STORAGE-ACCOUNT-NAME.blob.core.windows.net/CONTAINER?SAS-TOKEN' 'https://DESTINATION-STORAGE-ACCOUNT-NAME.blob.core.windows.net/CONTAINER' --recursive
```
Pour Google Cloud Storage, utilisez gcloud storage rsync l’interface de ligne de commande Google Cloud.
```
gcloud storage rsync --recursive gs://SOURCE-BUCKET gs://DESTINATION-BUCKET
```
Pour MinIO, utilisez mc mirror le client MinIO.
```
mc mirror SOURCE-ALIAS/SOURCE-BUCKET DESTINATION-ALIAS/DESTINATION-BUCKET
```
Une fois la copie terminée, vérifiez le nombre d’objets et la taille totale sur la destination à l’aide des outils de référencement standard de votre fournisseur. Examinez toute différence avant de continuer.
Activez le mode de maintenance. Pour empêcher l’écriture de nouveaux objets sur la source pendant le basculement, activez le mode maintenance sur votre instance GitHub Enterprise Server. Cela met brièvement l’instance hors ligne pour les utilisateurs finaux. Pour plus d’informations, consultez « Activation et planification du mode de maintenance ».
Effectuez la synchronisation delta finale. Une fois le mode de maintenance activé, exécutez à nouveau la même commande de copie à partir de l’étape de copie initiale. Cela récupère tous les objets ajoutés à la source après le début de la copie initiale.

Par exemple, pour Amazon S3 :
```
aws s3 sync s3://SOURCE-BUCKET s3://DESTINATION-BUCKET
```
Mettez à jour la configuration du stockage. Mettez à jour votre instance GitHub Enterprise Server pour pointer vers le nouvel emplacement de stockage. Conservez la même méthode d’authentification que précédemment.
1. Connectez-vous à Console de gestion. Pour plus d’informations, consultez « Accès à la console de gestion ».
2. Dans la barre latérale « Paramètres », cliquez sur Actions.
3. Sous « Stockage des artefacts et des journaux », mettez à jour les champs qui servent à identifier l’emplacement de stockage, par exemple le nom du compartiment, le nom du compte, la région, l’ARN du rôle ou la chaîne de connexion. Ne modifiez pas la méthode d’authentification.
4. Cliquez sur Tester les paramètres de stockage pour valider la nouvelle configuration.
  
  Avertissement
  
  Si le test échoue, n’enregistrez pas les paramètres. Examinez l’échec et retestez avant de continuer. L’enregistrement d’une configuration de stockage non valide peut entraîner une panne.
5. Cliquez sur Enregistrer les paramètres et attendez que les services redémarrent complètement.
Vous pouvez également mettre à jour la configuration à partir de la ligne de commande à l’aide ghe-actions-precheck de l’authentification basée sur les informations d’identification. Pour plus d’informations, consultez « Utilitaires de ligne de commande ».
Validez la migration. Après la modification de la configuration, vérifiez que GitHub Actions peut lire depuis le nouvel emplacement de stockage.
1. Désactivez le mode maintenance. Pour plus d’informations, consultez « Activation et planification du mode de maintenance ».
2. Dans l’interface utilisateur web pour votre instance GitHub Enterprise Server, ouvrez une exécution de flux de travail récente qui s’est terminée avant la migration. Confirmez que :
  - Chargement des journaux d’exécution de flux de travail.
  - Les artefacts de build sont téléchargés avec succès.
3. Déclenchez une nouvelle exécution de flux de travail et vérifiez que :
  - L’exécution se termine avec succès.
  - Les journaux et tous les artefacts générés par l’exécution sont visibles.
Si l’un de ces contrôles de validation échoue, conservez l’espace de stockage source et reportez-vous à la section Annulation ci-dessous.
Désaffectez le stockage source. Ne poursuivez qu’une fois la validation terminée avec succès et après avoir laissé passer suffisamment de temps pour vous assurer que le nouvel emplacement de stockage fonctionne correctement. En règle générale, conservez le stockage source dans un état en lecture seule pour au moins un cycle de sauvegarde complet avant de le supprimer.

Lorsque vous êtes prêt à supprimer le stockage source, suivez la procédure standard de votre fournisseur pour supprimer un compartiment ou un conteneur.

Restauration

Si la validation échoue ou que vous rencontrez des problèmes après le basculement, revenez en arrière en repointant votre instance GitHub Enterprise Server vers l’emplacement de stockage source. Le stockage source est votre copie de référence connue comme étant fiable. Ne recopiez pas les données de la destination vers la source lors d’un retour arrière, car les données écrites sur la destination pendant un basculement ayant échoué peuvent être partielles ou incohérentes, et les réécrire dans la source risque d’endommager votre seule copie fiable.

Avertissement

Le retour arrière entraînera la perte de toutes les données écrites ou supprimées après le basculement. En cas d’échec de la validation, effectuez immédiatement un retour arrière plutôt que de tenter un dépannage approfondi. Plus vous attendez, plus les données sont en danger.

Si la validation échoue ou que vous rencontrez des problèmes :

Activez immédiatement le mode maintenance.
Dans le Console de gestion, restaurez les valeurs de configuration de stockage d’origine, puis cliquez sur Tester les paramètres de stockage, puis Enregistrez les paramètres.
Désactivez le mode maintenance et réexécutez les étapes de validation avec le stockage d’origine.

Après un rétablissement réussi, examinez l’échec et planifiez une nouvelle tentative de migration.

Considérations relatives à GitHub Packages

Vous pouvez appliquer la même approche de migration au GitHub Packages stockage externe, avec les différences importantes suivantes. Lisez cette section complète avant de migrer le stockage sur une instance activée GitHub Packages .

OpenID Connect n’est pas disponible pour GitHub Packages. GitHub Packages prend uniquement en charge l’authentification basée sur les informations d’identification pour le stockage externe. La contrainte de méthode d’authentification de cet article s’applique toujours : conservez la méthode d’authentification inchangée pendant la migration.
GitHub Packages est plus sensible aux désynchronisations de temporisation. Lorsque des packages sont publiés pendant la fenêtre de migration, le système crée à la fois de nouveaux objets de stockage et des enregistrements de base de données. Pour éviter toute incohérence, maintenez le mode maintenance activé en continu à partir du début de la synchronisation delta finale via la validation réussie de la nouvelle configuration.
Mettez à jour les deux configurations ensemble si le même fournisseur sert les deux produits. Si vous avez configuré GitHub Actions et GitHub Packages utilisé le même type de fournisseur et que vous migrez les deux, planifiez le basculement en tant que fenêtre de maintenance unique et mettez à jour les deux configurations avant de désactiver le mode maintenance.
Pour les migrations inter-fournisseurs de GitHub Packages stockage, contactez Support GitHub Enterprise. Les déplacements entre fournisseurs ne sont pas couverts ici.

Pour plus d’informations sur la configuration du GitHub Packages stockage, consultez Prise en main des packages GitHub pour votre entreprise.

Qui peut utiliser cette fonctionnalité ?

Dans cet article