Einschränkungen für Toolchains und „ Delivery Pipeline “

Die Migration von Ressourcen von einer Region in eine andere unterliegt den folgenden Einschränkungen.

1. Klassische Pipelines werden nicht unterstützt.
2. DevOps Insights wird nicht unterstützt.
3. Geheimnisse, die direkt in Toolchains oder Delivery Pipeline gespeichert sind (Umgebungseigenschaften oder Triggereigenschaften), werden nicht kopiert. Der Befehl export-secrets ermöglicht den Export von Geheimnissen in eine Secrets Manager instanz zu exportieren, wobei die gespeicherten Geheimnisse durch Geheimreferenzen ersetzt werden. Geheime Referenzen werden unterstützt.
4. Tekton-Pipeline-Webhook-Trigger-Geheimnisse werden nicht kopiert, da Referenzen für Webhook-Trigger-Geheimnisse nicht unterstützt werden. Sie müssen das Geheimnis hinzufügen, nachdem Sie die Toolchain kopiert haben.
5. Die Ausführungshistorie, Protokolle und Assets der Tekton-Pipeline werden nicht kopiert. Sie können die ursprünglichen Pipelines für einige Zeit aufbewahren, um die Historie zu erhalten.
6. GitHub und Git Repos and Issue Tracking Tool-Integrationen, die mit OAuth Typ-Authentifizierung konfiguriert sind, werden automatisch konvertiert, um die OAuth Identität des Benutzers zu verwenden, der die Kopie durchführt (der Eigentümer des API-Schlüssels), anstatt des ursprünglichen Benutzers. Dies dient der Vereinfachung des Kopiervorgangs. Sie können die Tool-Integrationen nach dem Kopieren neu konfigurieren, um einen anderen Benutzer zu verwenden.
7. Git Repos and Issue Tracking tool-Integrationen, die Personal Access Tokens (PATs) für die Authentifizierung verwenden, werden automatisch auf die Verwendung von OAuth umgestellt. Sie können die Tool-Integrationen nach dem Kopieren neu konfigurieren, um wieder ein PAT zu verwenden.

Einschränkungen für „ Git Repos and Issue Tracking “

Die folgenden Einschränkungen gelten nur, wenn Sie Projekte Git Repos and Issue Tracking migrieren.

1. Persönliche Projekte werden nicht unterstützt. Wenn Sie ein Projekt unter einem persönlichen Namensraum erstellt haben, können Sie entweder Ihr persönliches Projekt in eine Gruppe verschieben oder Ihren persönlichen Namensraum in eine Gruppe umwandeln und dann die Referenzen in der Toolchain mit der neuen URL aktualisieren. Es wird empfohlen, Projekte in Gruppen zu speichern, da diese mehrere Administratoren zulassen und eine bessere Kontinuität eines Projekts über einen längeren Zeitraum ermöglichen.
2. Das Kopieren von Projekten erfolgt mit der Direktübertragungsfunktion GitLab, die bestimmten Einschränkungen unterliegt.
3. Das Kopieren großer Projekte oder Projekte mit großen Dateien oder vielen Ressourcen kann einige Zeit in Anspruch nehmen.
4. Da jede Region von Git Repos and Issue Tracking unabhängig ist, sind die Benutzer Ihrer Projekte möglicherweise noch nicht in der Zielregion vorhanden. Der copy-project-group Befehl stellt sicher, dass die Benutzer in der neuen Region vorhanden sind, jedoch kann es zu Konflikten mit Benutzernamen anderer Benutzer in der Zielregion kommen. Im Falle eines Benutzernamenkonflikts kann der Benutzername in der Zielregion durch Hinzufügen eines Suffixes leicht geändert werden.

Wichtige Hinweise

Bevor Sie mit der Migration beginnen, müssen Sie die folgenden wichtigen Hinweise lesen.

Aspekte der Abrechnung

Während der Migration müssen Sie eine neue Continuous Delivery instanz in der Zielregion und Ressourcengruppe erstellen, um Ihre Toolchains, Pipelines und Projekte in der Zielregion zu aktivieren. Möglicherweise möchten Sie auch die ursprünglichen Ressourcen in der Quellregion zur Verfügung halten, bis Sie vollständig auf die neue Region umgestellt haben. Wenn Sie den Dienst Continuous Delivery mit dem Professional-Tarif nutzen, beachten Sie, dass Sie für beide Regionen entsprechend der Anzahl der in jeder Instanz konfigurierten autorisierten Benutzer berechnet werden. Wenn die Kosten eine Rolle spielen, können Sie den Plan in der Continuous Delivery Instanz der Quellregion in Lite ändern, sobald Sie in die neue Region umgezogen sind. Die Ressourcen sind schreibgeschützt, wenn Sie die Grenzen des Lite-Plans überschritten haben. Sie können jedoch jederzeit wieder zum Professional-Tarif zurückkehren, wenn Sie diesen erneut nutzen möchten. Erfahren Sie mehr über die Continuous Delivery Abrechnung und Pläne.

Doppelte Pipelineläufe

Während der Migration können Sie neue Pipelines in der Zielregion erstellen. Wenn diese Pipelines zeitgesteuerte Auslöser haben, die so eingestellt sind, dass sie automatisch nach einem Zeitplan ausgeführt werden, oder Git Auslöser, die so konfiguriert sind, dass sie automatisch bei Git Ereignissen wie PRs oder Commits ausgeführt werden, könnten diese Ereignisse doppelte Pipeline-Läufe auslösen (einen in der ursprünglichen Pipeline und einen in der neuen Pipeline). Um mögliche Störungen zu vermeiden, sind diese Arten von Triggern bei kopierten Pipelines standardmäßig deaktiviert. Es wird empfohlen, diese Trigger so zu verwalten, dass jeweils nur ein Satz aktiviert ist. Sobald Sie mit der Umstellung auf die neue Pipeline vertraut sind, können Sie die Trigger dafür aktivieren und die Trigger für die ursprüngliche Pipeline deaktivieren.

Hart kodierte Annahmen

Nach der Migration werden Ihre Git Repos and Issue Tracking Repos (falls zutreffend) eine andere URL haben, und Ihre Toolchains und Pipelines werden andere IDs und URLs haben. Es kann sein, dass in Ihren Tekton-Definitionen, Skripten, Umgebungseigenschaften oder anderen Automatisierungen Annahmen über die URL /ID oder den Standort Ihrer Ressourcen getroffen werden. Es liegt in Ihrer Verantwortung, diese nach der Migration zu aktualisieren.

macOS

Führen Sie die folgenden Befehle aus, um die Abhängigkeiten auf macOS zu installieren.

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

Andere Plattformen

• Node.js Installationsanweisungen
• Terra form-Installationsanweisungen

CRN

IBM Cloud Ressourcen werden durch einen Cloud-Ressourcennamen(CRN) eindeutig identifiziert. Sie benötigen die CRN der Toolchain, die Sie kopieren möchten. Es gibt mehrere Möglichkeiten, die CRN einer Toolchain zu erhalten:

1. Suchen Sie die Toolchain auf der Seite „Plattformautomatisierung > Toolchains“, öffnen Sie die Toolchain und klicken Sie auf „Details“, um die Details der Toolchain anzuzeigen, darunter auch die CRN.
2. Suchen Sie die Toolchain auf der Seite „Ressourcenliste“, klicken Sie auf die Zeile der Toolchain, um das Detailfenster zu erweitern, in dem die CRN angezeigt wird.
3. Mit der ibmcloud-CLI können Sie Toolchains und ihre CRNs über

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

4. Verwendung der Toolchain-API.

Prüfung auf gespeicherte Toolchain-/Pipeline-Geheimnisse

Toolchains und Tekton-Pipelines können Geheimnisse, d. h. sensible Werte wie API-Schlüssel oder Kennwörter, an folgenden Stellen enthalten:

• Eigenschaften der Tool-Integration, z. B. die Eigenschaft Service ID API Key des Tools Delivery Pipeline Private Worker Integration
• Eigenschaften der Tekton-Pipeline-Umgebung
• Eigenschaften der Tekton-Pipeline-Auslöser

Es gibt zwei Möglichkeiten, Geheimnisse zu konfigurieren:

1. Direkt in der Toolchain oder Pipeline gespeichert
2. Verweis auf Geheimnisse, die in einem Geheimhaltungsdienst wie IBM Cloud Secrets Manager oder IBM Cloud Key Protect.

Beim Kopieren einer Toolchain werden automatisch geheime Referenzen einbezogen, die in der neuen Toolchain erhalten bleiben. Um jedoch das Risiko zu minimieren, dass sensible Daten nach außen dringen, werden Geheimnisse, die direkt in Toolchains oder Pipelines gespeichert sind, nicht in die Toolchain-Kopie aufgenommen. Sie können den im nächsten Abschnitt beschriebenen Befehl export-secrets verwenden oder die Geheimnisse nach dem Kopieren erneut manuell in die kopierte Toolchain oder Pipeline eingeben. Beachten Sie jedoch, dass, wenn Sie die Geheimnisse nicht exportieren, einige Werkzeugintegrationen beim Kopieren der Werkzeugkette möglicherweise nicht erfolgreich bereitgestellt werden, wenn ihnen die erforderlichen geheimen Werte fehlen, und dass sie nach Ausführung des Befehls möglicherweise manuell neu erstellt werden müssen.

Prüfen Sie zunächst, ob Ihre Toolchain oder ihre Tekton-Pipelines gespeicherte Geheimnisse enthalten, die nicht durch die Ausführung referenziert werden:

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

Exportieren Sie gespeicherte Toolchain-/Pipeline-Geheimnisse nach Secrets Manager

Wenn Ihre Toolchain oder Pipelines keine gespeicherten Geheimnisse enthalten, können Sie diesen Schritt überspringen und mit dem Kopieren der Toolchain fortfahren. Durch den Export von Geheimnissen nach Secrets Manager werden Geheimnisse in der Instanz Secrets Manager erstellt und die ursprüngliche Toolchain so geändert, dass die vorhandenen Geheimnisse so konvertiert werden, dass sie auf die neu erstellten Geheimnisse in Secrets Manager verweisen. Dies ermöglicht das Kopieren der Toolchain mit intakten geheimen Verweisen und ist eine empfohlene Praxis für zusätzliche Sicherheit.

Um eine versehentliche Offenlegung von Geheimnissen zu verhindern, sollten Sie die IAM-Berechtigungen Ihrer Secrets Manager instanz überprüfen, um sicherzustellen, dass nur der beabsichtigte Zugriff auf Lesegeheimnisse gewährt wird.

Gehen Sie folgendermaßen vor, um in Ihrer Toolchain oder Pipeline gespeicherte Geheimnisse nach Secrets Manager zu exportieren:

1. Wenn Sie noch keine Secrets Manager instanz haben, erstellen Sie eine. Beachten Sie, dass die Instanz in dem Konto erstellt werden muss, das mit dem API-Schlüssel verbunden ist, den Sie verwenden werden.
2. Vergewissern Sie sich, dass der Besitzer des API-Schlüssels, den Sie verwenden werden, über die IAM-Berechtigung zum Erstellen von Geheimnissen in der Instanz Secrets Manager verfügt.
3. Öffnen Sie die Toolchain und Secrets Manager, erstellen Sie eine Autorisierungsrichtlinie, wenn Sie dazu aufgefordert werden, und erstellen Sie dann die Toolintegration.
4. Führen Sie den Befehl „ export-secrets “ aus, um die Geheimnisse zu exportieren:

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

5. Wenn Sie dazu aufgefordert werden, wählen Sie die Secrets Manager Instanz aus Ihrer Toolchain aus, um die Geheimnisse zu speichern. Wenn Ihre Instanz nicht aufgeführt ist, befindet sie sich möglicherweise in einem anderen Konto. Stellen Sie sicher, dass Sie einen API-Schlüssel verwenden, der sich auf demselben Konto wie die Instanz befindet.
6. Wenn Sie dazu aufgefordert werden, geben Sie für jedes gefundene Geheimnis an, ob es kopiert werden soll oder nicht, sowie den Namen und die Gruppe, in der das Geheimnis gespeichert werden soll, oder drücken Sie die Eingabetaste, um die Standardeinstellungen zu übernehmen.

Sie können den Befehl so oft wie nötig ausführen, um alle Ihre Geheimnisse zu exportieren.

Werkzeugketten kopieren

Um eine Toolchain zu kopieren, führen Sie den Befehl copy-toolchain@ibm-cloud/cd-tools aus. Um die verfügbaren Optionen anzuzeigen, führen Sie folgenden Befehl aus:

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

Auf copy-toolchain wird die Toolchain zunächst in Terraform (.tf)-Dateien übersetzt, und dann wird Terraform angewendet, um eine neue Toolchain in der Zielregion zu erstellen. Der Befehl zeigt die Terraform-Ausgabe an und fordert zur Bestätigung auf, bevor die Toolchain erstellt wird. Sie können die Terraform-Ausgabe überprüfen, bevor Sie die neue Toolchain-Kopie erstellen.

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

Überprüfung der Ressourcen

Nachdem Sie Ihre Toolchains, Tekton-Pipelines und Git Repos and Issue Tracking Projekte (falls zutreffend) in eine neue Region kopiert haben, sollten Sie überprüfen, ob diese korrekt kopiert wurden und einwandfrei funktionieren, bevor Sie die ursprünglichen Ressourcen deaktivieren oder löschen. Dabei ist Folgendes zu beachten:

• Zeitgesteuerte Tekton-Pipeline- und Git-Trigger waren in kopierten Pipelines nicht standardmäßig aktiviert, um doppelte Pipeline-Läufe zwischen der neuen und der ursprünglichen Pipeline zu verhindern. Wenn Sie damit zufrieden sind, können Sie die Auslöser in der neuen Pipeline aktivieren und die Auslöser in der ursprünglichen Pipeline deaktivieren.
• Wenn Sie einen Tekton-Pipeline-Trigger vom Typ Webhook haben, müssen Sie den Trigger neu konfigurieren und das Geheimnis erneut eingeben. Dieses Geheimnis unterstützt keine Geheimreferenzen und wird nicht mit der Pipeline kopiert.
• Benutzer mit persönlichen Zugangstoken in den kopierten Git Repos and Issue Tracking Projekten müssen neue Token erstellen, da sie nicht kopiert wurden.
• Tool-Integrationen für Git Repos and Issue Tracking Repos wurden so umgestellt, dass sie die OAuth Identität des Benutzers verwenden, der die Kopie durchgeführt hat. Wenn Sie eine andere Identität verwenden möchten, melden Sie sich mit diesem Benutzer an und speichern Sie die Tool-Integrationen erneut, oder wechseln Sie zur Verwendung von persönlichen Zugangstoken.
• In Ihren Tekton-Definitionen, Skripten, Umgebungseigenschaften oder anderen Automatisierungen kann es Annahmen über die ID, URL oder den Standort Ihrer Ressourcen geben. Es wird empfohlen, dass Sie diese überprüfen, um sicherzustellen, dass die neuen IDs, URLs und Standorte verwendet werden.

Deaktivieren der ursprünglichen Ressourcen

Nachdem Sie sich vergewissert haben, dass die kopierten Ressourcen korrekt funktionieren, können Sie Ihre ursprünglichen Ressourcen deaktivieren, um Konflikte oder Verwirrung zu vermeiden.

• Für Tekton-Pipelines können Sie Ihre Auslöser deaktivieren, um unerwünschte Pipeline-Läufe zu vermeiden und um anderen Benutzern zu signalisieren, dass diese Auslöser nicht mehr verwendet werden sollen.
• Für Continuous Delivery service-Instanzen können Sie, wenn Sie den Professional-Tarif verwendet haben, zum Lite-Tarif wechseln, um weitere Gebühren für die ursprünglichen Ressourcen zu vermeiden. Dies kann dazu führen, dass Ihre Ressourcen schreibgeschützt werden, wenn Sie die Grenzen des Lite-Tarifs überschritten haben, aber Sie können jederzeit zu Professional zurückwechseln, wenn Sie sie wieder verwenden müssen.
• Für Git Repos und Issue-Tracking-Projekte (falls zutreffend) können Sie Ihre ursprünglichen Projekte archivieren, um sie schreibgeschützt zu machen und zu verhindern, dass Benutzer weitere Änderungen vornehmen, und optional die Projektbeschreibung oder Readme aktualisieren, um anzugeben, wo sich das neue Projekt befindet.

Auch wenn Sie nicht beabsichtigen, die Originalressourcen aufzubewahren, sollten Sie sie für eine gewisse Zeit als Backup aufbewahren, falls Sie später Probleme entdecken. Wenn Sie damit zufrieden sind, können Sie die ursprünglichen Ressourcen löschen.