Limitations pour les chaînes d'outils et l' Delivery Pipeline

La migration des ressources d'une région à une autre est soumise aux restrictions suivantes.

1. Les pipelines classiques ne sont pas pris en charge.
2. DevOps Insights n'est pas pris en charge.
3. Les secrets stockés directement dans les chaînes d'outils ou sur le site Delivery Pipeline (propriétés d'environnement ou de déclenchement) ne seront pas copiés. Une commande export-secrets permet d'exporter des secrets dans une instance Secrets Manager en remplaçant les secrets stockés par des références de secrets. Les références secrètes sont prises en charge.
4. Les secrets de déclenchement des webhooks Tekton Pipeline ne seront pas copiés, car les références ne sont pas prises en charge pour les secrets de déclenchement des webhooks. Vous devrez ajouter le secret après avoir copié la chaîne d'outils.
5. L'historique d'exécution, les journaux et les ressources du pipeline Tekton ne seront pas copiés. Vous pouvez conserver les pipelines d'origine pendant un certain temps afin de conserver l'historique.
6. GitHub et les intégrations d'outils Git Repos and Issue Tracking configurées avec une authentification de type OAuth seront automatiquement converties pour utiliser l'identité OAuth de l'utilisateur effectuant la copie (le propriétaire de la clé API) plutôt que l'utilisateur d'origine. Ceci afin de simplifier l'opération de copie. Vous pouvez reconfigurer les intégrations d'outils après la copie afin d'utiliser un autre utilisateur.
7. Git Repos and Issue Tracking les intégrations d'outils qui utilisent des jetons d'accès personnels (PAT) pour l'authentification seront automatiquement converties pour utiliser OAuth. Vous pouvez reconfigurer les intégrations d'outils après la copie pour utiliser à nouveau un PAT.

Limitations d' Git Repos and Issue Tracking

Les restrictions suivantes s'appliquent uniquement si vous migrez Git Repos and Issue Tracking des projets.

1. Les projets personnels ne sont pas pris en charge. Si vous avez créé un projet dans un espace de noms personnel, vous pouvez soit déplacer votre projet personnel dans un groupe, soit convertir votre espace de noms personnel en groupe, puis mettre à jour les références dans la chaîne d'outils avec la nouvelle adresse URL. Il est recommandé de stocker les projets par groupes, car cela permet d'avoir plusieurs administrateurs et d'assurer une meilleure continuité du projet dans le temps.
2. Les projets sont copiés à l'aide de la fonction de transfert direct de GitLab, qui est soumise à certaines limitations.
3. La copie de projets volumineux, ou de projets contenant des fichiers volumineux ou de nombreuses ressources, peut prendre du temps.
4. Chaque région d' Git Repos and Issue Tracking s étant indépendante, il est possible que les utilisateurs de vos projets n'existent pas encore dans la région de destination. La copy-project-group commande garantira que les utilisateurs existent dans la nouvelle région, mais il peut y avoir des conflits de noms d'utilisateurs avec d'autres utilisateurs dans la région de destination. En cas de conflit de nom d'utilisateur, le nom d'utilisateur dans la région de destination peut être légèrement modifié en ajoutant un suffixe.

Remarques importantes

Vous devez lire attentivement les remarques importantes suivantes avant de commencer la migration.

Remarques sur la facturation

Pendant la migration, vous devrez créer une nouvelle instance Continuous Delivery dans la région de destination et le groupe de ressources pour activer vos chaînes d'outils, pipelines et projets dans la région de destination. Vous pouvez également conserver les ressources d'origine dans la région source afin de pouvoir les utiliser jusqu'à ce que vous ayez effectué la transition vers la nouvelle région. Si vous utilisez le service Continuous Delivery avec le plan professionnel, sachez que vous serez facturé pour les deux régions en fonction du nombre d'utilisateurs autorisés configurés dans chaque instance. Si les coûts sont un problème, vous pouvez changer le plan dans l'instance Continuous Delivery de la région source en Lite une fois que vous avez effectué la transition vers la nouvelle région. Les ressources seront en lecture seule si vous avez dépassé les limites du plan Lite. Cependant, vous pouvez revenir au forfait Professionnel à tout moment si vous souhaitez l'utiliser à nouveau. Pour en savoir plus sur la facturation et les plans de Continuous Delivery.

Duplication de l'exécution du pipeline

Pendant la migration, vous pouvez créer de nouveaux pipelines dans la région de destination. Si ces pipelines ont des déclencheurs temporels configurés pour s'exécuter automatiquement selon un calendrier, ou des déclencheurs Git configurés pour s'exécuter automatiquement sur des événements Git tels que des PR ou des commits, ces événements peuvent déclencher des exécutions dupliquées du pipeline (une dans le pipeline d'origine et une dans le nouveau pipeline). Pour éviter toute perturbation potentielle, ces types de déclencheurs seront désactivés par défaut pour les pipelines copiés. Il est recommandé de gérer ces déclencheurs de manière à ce qu'un seul ensemble soit activé à la fois. Une fois que vous êtes à l'aise avec la transition vers le nouveau pipeline, vous pouvez activer les déclencheurs sur celui-ci et désactiver les déclencheurs sur le pipeline d'origine.

Hypothèses codées en dur

Après la migration, votre dépôt Git Repos and Issue Tracking (si applicable) aura un URL différent, et vos chaînes d'outils et pipelines auront des ID et URL différents. Il peut y avoir des hypothèses sur le URL /ID ou l'emplacement de vos ressources dans vos définitions Tekton, vos scripts, vos propriétés d'environnement ou d'autres automatismes. Il est de votre responsabilité de les mettre à jour après la migration.

macOS

Exécutez les commandes suivantes pour installer les dépendances sur macOS.

brew install node
brew tap hashicorp/tap
brew install hashicorp/tap/terraform

Autres plateformes

• Node.js instructions d'installation
• Instructions d'installation de Terraform

CRN

IBM Cloud Les ressources sont identifiées de manière unique par un nom de ressource cloud(CRN). Vous aurez besoin du CRN de la chaîne d'outils que vous souhaitez copier. Vous pouvez obtenir le CRN d'une chaîne d'outils de plusieurs façons :

1. Recherchez la chaîne d'outils dans la page Automatisation de la plateforme > Chaînes d'outils, ouvrez la chaîne d'outils, puis cliquez sur Détails pour afficher les détails de la chaîne d'outils, qui indiquent le CRN.
2. Recherchez la chaîne d'outils dans la page Liste des ressources, cliquez sur la ligne correspondant à la chaîne d'outils pour développer le panneau de détails, qui affiche le CRN.
3. À l'aide de l'interface CLI ibmcloud, vous pouvez répertorier les chaînes d'outils et leurs CRN via

   ibmcloud resource service-instances --service-name toolchain --long
   

4. Utilisation de l'API Toolchain.

Vérification des secrets de chaîne d'outils et de pipeline stockés

Les chaînes d'outils et les pipelines Tekton peuvent contenir des secrets, qui sont des valeurs sensibles telles que des clés d'API ou des mots de passe, aux endroits suivants :

• Propriétés de l'intégration de l'outil, par exemple la propriété Service ID API Key de l'intégration de l'outil Delivery Pipeline Private Worker
• Propriétés de l'environnement du pipeline Tekton
• Propriétés de déclenchement du pipeline Tekton

Il existe deux façons de configurer les secrets :

1. Stocké directement dans la chaîne d'outils ou le pipeline
2. Référencement de secrets stockés dans un service de stockage de secrets tel que IBM Cloud Secrets Manager ou IBM Cloud Key Protect.

La copie d'une chaîne d'outils inclura automatiquement les références secrètes et ces références resteront intactes dans la nouvelle chaîne d'outils. Toutefois, pour minimiser le risque de fuite de données sensibles, les secrets stockés directement dans les chaînes d'outils ou le pipeline ne seront pas inclus dans la copie de la chaîne d'outils. Vous pouvez utiliser la commande export-secrets décrite dans la section suivante ou saisir manuellement les secrets dans la chaîne d'outils ou le pipeline copié après la copie. Notez cependant que si vous n'exportez pas les secrets, certaines intégrations d'outils peuvent ne pas être approvisionnées avec succès lors de la copie de la chaîne d'outils s'il leur manque des valeurs secrètes requises, et peuvent devoir être recréées manuellement après l'exécution de la commande.

Tout d'abord, vérifiez si votre chaîne d'outils ou ses pipelines Tekton contiennent des secrets stockés qui ne sont pas référencés lors de l'exécution :

npx @ibm-cloud/cd-tools export-secrets -c ${CRN} --check

Exporter les secrets de chaîne d'outils/pipeline stockés vers Secrets Manager

Si votre chaîne d'outils ou vos pipelines ne contiennent pas de secrets stockés, vous pouvez sauter cette étape et continuer à copier la chaîne d'outils. L'exportation de secrets vers Secrets Manager créera des secrets dans l'instance Secrets Manager et modifiera également votre chaîne d'outils d'origine pour convertir les secrets existants afin qu'ils fassent référence aux secrets nouvellement créés dans Secrets Manager. Cela permet de copier la chaîne d'outils en conservant les références secrètes, et c'est une pratique recommandée pour plus de sécurité.

Pour éviter l'exposition accidentelle de secrets, vous devez vérifier les autorisations IAM de votre instance pour vous assurer que seul l'accès prévu aux secrets de lecture est accordé Secrets Manager afin de vous assurer que seul l'accès prévu aux secrets de lecture est accordé.

Pour exporter des secrets stockés dans votre chaîne d'outils ou votre pipeline vers Secrets Manager, procédez comme suit :

1. Si vous n'avez pas encore d'instance Secrets Managercréez-en une. Notez que l'instance doit être créée dans le compte associé à la clé API que vous utiliserez.
2. Assurez-vous que le propriétaire de la clé API que vous utiliserez dispose d'une autorisation IAM pour créer des secrets dans l'instance Secrets Manager.
3. Ouvrez la chaîne d'outils et Secrets Manager intégration d'outils, créez une politique d'autorisation lorsque vous y êtes invité, puis créez l'intégration d'outils.
4. Exécutez la commande « export-secrets » pour exporter les secrets :

   npx @ibm-cloud/cd-tools export-secrets -c ${CRN}
   

5. Lorsque vous y êtes invité, sélectionnez l'instance Secrets Manager de votre chaîne d'outils pour stocker les secrets. Si votre instance ne figure pas dans la liste, il se peut qu'elle se trouve dans un autre compte. Veillez à utiliser une clé API qui se trouve dans le même compte que l'instance.
6. Lorsque vous y êtes invité, pour chaque secret trouvé, indiquez si le secret doit être copié ou non, ainsi que le nom et le groupe dans lesquels le secret doit être stocké, ou appuyez sur la touche Entrée pour accepter les valeurs par défaut.

Vous pouvez exécuter la commande autant de fois que nécessaire pour exporter tous vos secrets.

Copier les chaînes d'outils

Pour copier une chaîne d'outils, exécutez la commande copy-toolchain@ibm-cloud/cd-tools. Pour afficher les options disponibles, exécutez la commande suivante :

npx @ibm-cloud/cd-tools copy-toolchain -h
Usage: @ibm-cloud/cd-tools copy-toolchain [options]

Copies a toolchain, including tool integrations and Tekton pipelines, to another region or resource group.

Examples:
  export IBMCLOUD_API_KEY='...'
  npx @ibm-cloud/cd-tools copy-toolchain -c ${TOOLCHAIN_CRN} -r us-south
      Copy a toolchain to the Dallas region with the same name, in the same resource group.
  npx @ibm-cloud/cd-tools copy-toolchain -c ${TOOLCHAIN_CRN} -r eu-de -n new-toolchain-name -g new-resource-group --apikey ${APIKEY}
      Copy a toolchain to the Frankfurt region with the specified name and target resource group, using the given API key

Environment Variables:
  IBMCLOUD_API_KEY                       API key used to authenticate. Must be a user API key, with IAM permission to read and create toolchains and service-to-service authorizations in source and target
region / resource group

Basic options:
  -c, --toolchain-crn <crn>              The CRN of the source toolchain to copy
  -r, --region <region>                  The destination region of the copied toolchain (choices: "br-sao", "eu-de", "eu-gb", "jp-tok", "us-south")
  -a, --apikey <api_key>                 API key used to authenticate. Must be a user API key, with IAM permission to read and create toolchains and service-to-service authorizations in source and target
                                         region / resource group
  -n, --name <name>                      (Optional) The name of the copied toolchain (default: same name as original)
  -g, --resource-group <resource_group>  (Optional) The name or ID of destination resource group of the copied toolchain (default: same resource group as original)
  -t, --tag <tag>                        (Optional) The tag to add to the copied toolchain
  -h, --help                             Display help for command

Advanced options:
  -d, --terraform-dir <path>             (Optional) The target local directory to store the generated Terraform (.tf) files
  -D, --dry-run                          (Optional) Skip running terraform apply; only generate the Terraform (.tf) files
  -f, --force                            (Optional) Force the copy toolchain command to run without user confirmation
  -S, --skip-s2s                         (Optional) Skip creating toolchain-generated service-to-service authorizations
  -T, --skip-disable-triggers            (Optional) Skip disabling Tekton pipeline Git or timed triggers. Note: This may result in duplicate pipeline runs
  -C, --compact                          (Optional) Generate all resources in a single resources.tf file
  -v, --verbose                          (Optional) Increase log output
  -q, --quiet                            (Optional) Suppress non-essential output, only errors and critical warnings are displayed

Le site copy-toolchain traduit d'abord la chaîne d'outils en fichiers Terraform (.tf), puis applique Terraform pour créer une nouvelle chaîne d'outils dans la région de destination. La commande affichera la sortie de Terraform et demandera une confirmation avant de créer la chaîne d'outils. Vous pouvez examiner la sortie de Terraform avant de créer la nouvelle copie de la chaîne d'outils.

export IBMCLOUD_API_KEY='<your_api_key>'
npx @ibm-cloud/cd-tools copy-toolchain -c 'crn:v1:bluemix:public:toolchain:au-syd:a/9d5d528aa786af01ce99593a827a05f0:69e8d78b-0d1a-49ed-9a46-3b4c1bb4f24a::' -r jp-tok

npx @ibm-cloud/cd-tools copy-toolchain -c "${CRN}" -r eu-de --apikey '<your_api_key>'

export IBMCLOUD_API_KEY='<your_api_key>'
npx @ibm-cloud/cd-tools copy-toolchain -c "${CRN}" -r us-south -n 'toolchain-dallas'

for i in $(ibmcloud resource service-instances --service-name toolchain --location ca-tor --all-resource-groups -o json | jq -r '.[].crn'); do
    npx @ibm-cloud/cd-tools copy-toolchain -c ${i} -r us-south --dry-run -f
done

for i in $(ibmcloud resource service-instances --service-name toolchain -g my-resource-group -o json | jq -r '.[].crn'); do
    npx @ibm-cloud/cd-tools copy-toolchain -c ${i} -r eu-de -q
done

for i in $(ibmcloud resource service-instances --service-name toolchain --all-resource-groups -o json | jq -r '.[] | select(.name | startswith("test-")) | .crn'); do
    npx @ibm-cloud/cd-tools copy-toolchain -c ${i} -r jp-tok
done

$ cd output-1764102115772
$ terraform apply
var.ibmcloud_api_key
  Enter a value: {api_key}
...

Vérifier les ressources

Après avoir copié vos chaînes d'outils, vos pipelines Tekton et vos projets Git Repos and Issue Tracking (le cas échéant) dans une nouvelle région, vous devez vérifier qu 'ils ont été correctement copiés et qu'ils fonctionnent correctement avant de désactiver ou de supprimer les ressources d'origine. Remarque :

• Les déclencheurs temporisés et Git du pipeline Tekton n'ont pas été activés par défaut dans les pipelines copiés afin d'éviter les doubles exécutions entre le nouveau pipeline et le pipeline d'origine. Une fois que vous êtes à l'aise, vous pouvez activer les déclencheurs dans la nouvelle canalisation et désactiver les déclencheurs dans la canalisation d'origine.
• Si vous avez des déclencheurs de pipeline Tekton de type webhook, vous devrez reconfigurer le déclencheur et réintroduire le secret. Ce secret ne prend pas en charge les références secrètes et n'est pas copié avec le pipeline.
• Les utilisateurs disposant de jetons d'accès personnels dans les projets Git Repos and Issue Tracking copiés devront recréer de nouveaux jetons, car ils n'ont pas été copiés.
• Les intégrations d'outils pour les dépôts Git Repos and Issue Tracking auront été converties pour utiliser l'identité OAuth de l'utilisateur qui a effectué la copie. Si vous souhaitez utiliser une autre identité, connectez-vous avec cet utilisateur et réenregistrez les intégrations d'outils, ou passez à l'utilisation de jetons d'accès personnels.
• Vos définitions Tekton, vos scripts, vos propriétés d'environnement ou d'autres automatismes peuvent contenir des hypothèses concernant l'ID, URL ou l'emplacement de vos ressources. Il est recommandé de les passer en revue pour s'assurer que les nouveaux ID, URL et emplacements sont utilisés.

Désactiver les ressources originales

Après avoir vérifié que les ressources copiées fonctionnent correctement, vous pouvez désactiver vos ressources d'origine afin d'éviter tout conflit ou confusion.

• Pour les pipelines Tekton, vous pouvez désactiver vos déclencheurs afin d'éviter des exécutions indésirables et de signaler aux autres utilisateurs que ces déclencheurs ne doivent plus être utilisés.
• Pour les instances de service Continuous Delivery si vous utilisiez le plan Professional, vous pouvez passer au plan Lite pour éviter d'autres frais pour les ressources d'origine. Vos ressources peuvent ainsi passer en lecture seule si vous avez dépassé les limites du plan Lite, mais vous pouvez revenir au plan Professional à tout moment si vous avez besoin de les utiliser à nouveau.
• Pour Git Repos et Issue tracking projects (si applicable), vous pouvez archiver vos projets originaux pour les rendre en lecture seule et empêcher les utilisateurs d'y apporter d'autres modifications, et éventuellement mettre à jour la description du projet ou le readme pour indiquer où se trouve le nouveau projet.

Même si vous n'avez pas l'intention de conserver les ressources originales, vous pouvez vouloir les conserver pendant un certain temps à titre de sauvegarde au cas où vous découvririez des problèmes ultérieurement. Une fois que vous vous sentez à l'aise, vous pouvez supprimer les ressources originales.