Limitazioni per Toolchain e Delivery Pipeline

Il trasferimento di risorse da una regione all'altra è soggetto alle seguenti limitazioni.

1. Le pipeline classiche non sono supportate.
2. DevOps Insights non è supportato.
3. I segreti memorizzati direttamente nelle catene di strumenti o in Delivery Pipeline (proprietà dell'ambiente o proprietà dei trigger) non verranno copiati. È disponibile un comando export-secrets che consente di esportare i segreti in un'istanza Secrets Manager sostituendo i segreti memorizzati con riferimenti ai segreti. Sono supportati i riferimenti segreti.
4. I segreti di attivazione dei webhook della pipeline Tekton non verranno copiati, poiché i riferimenti non sono supportati per i segreti di attivazione dei webhook. Dopo aver copiato la toolchain, dovrai aggiungere il segreto.
5. La cronologia delle esecuzioni, i registri e le risorse di Tekton Pipeline non verranno copiati. È possibile conservare le pipeline originali per un certo periodo di tempo per mantenere la cronologia.
6. GitHub e le integrazioni di strumenti Git Repos and Issue Tracking configurate con l'autenticazione di tipo OAuth saranno automaticamente convertite in modo da utilizzare l'identità OAuth dell'utente che esegue la copia (il proprietario della chiave API) anziché l'utente originale. Questo serve a semplificare l'operazione di copia. È possibile riconfigurare le integrazioni degli strumenti dopo la copia per utilizzare un utente diverso.
7. Git Repos and Issue Tracking le integrazioni di strumenti che utilizzano i Personal Access Token (PAT) per l'autenticazione saranno automaticamente convertite all'uso di OAuth. È possibile riconfigurare le integrazioni degli strumenti dopo la copia per utilizzare nuovamente un PAT.

Limitazioni per l' Git Repos and Issue Tracking

Le seguenti limitazioni si applicano solo se stai migrando Git Repos and Issue Tracking progetti.

1. I progetti personali non sono supportati. Se si è creato un progetto in uno spazio dei nomi personale, si può spostare il progetto personale in un gruppo o convertire lo spazio dei nomi personale in un gruppo, quindi aggiornare i riferimenti nella toolchain con il nuovo URL. Si consiglia di archiviare i progetti in gruppi, poiché consentono di avere più amministratori e garantiscono una migliore continuità del progetto nel tempo.
2. I progetti vengono copiati utilizzando la funzione di trasferimento diretto di GitLab, che è soggetta ad alcune limitazioni.
3. La copia di progetti di grandi dimensioni, o di progetti con file di grandi dimensioni o molte risorse, può richiedere tempo.
4. Poiché ogni regione di Git Repos and Issue Tracking è indipendente, gli utenti dei tuoi progetti potrebbero non essere ancora presenti nella regione di destinazione. Il copy-project-group comando garantirà che gli utenti esistano nella nuova regione, tuttavia potrebbero verificarsi conflitti di nomi utente con altri utenti nella regione di destinazione. In caso di conflitto tra nomi utente, il nome utente nella regione di destinazione potrebbe essere leggermente modificato aggiungendo un suffisso.

Note importanti

Prima di iniziare la migrazione, è necessario leggere le seguenti note importanti.

Considerazioni sulla fatturazione

Durante la migrazione, è necessario creare una nuova istanza nella regione di destinazione e un gruppo di risorse per abilitare i Continuous Delivery nella regione e nel gruppo di risorse di destinazione per abilitare i toolchain, le pipeline e i progetti nella regione di destinazione. È inoltre possibile mantenere disponibili le risorse originali nella regione di origine fino al completamento della transizione alla nuova regione. Se utilizzate il servizio Continuous Delivery con il piano Professional, sappiate che vi verranno addebitati i costi per entrambe le regioni in base al numero di utenti autorizzati configurati in ciascuna istanza. Se i costi sono un problema, è possibile modificare il piano nell'istanza Continuous Delivery della regione di origine in Lite dopo la transizione alla nuova regione. Le risorse saranno di sola lettura se si è superato il limite di Limiti del piano Lite. Tuttavia, puoi tornare al piano Professional in qualsiasi momento se desideri utilizzarlo nuovamente. Per saperne di più sulla fatturazione e sui piani di Continuous Delivery.

Esecuzioni duplicate della pipeline

Durante la migrazione, è possibile creare nuove pipeline nella regione di destinazione. Se queste pipeline hanno trigger temporizzati impostati per essere eseguiti automaticamente in base a una pianificazione, o trigger Git configurati per essere eseguiti automaticamente su eventi Git come PR o commit, questi eventi potrebbero innescare l'esecuzione di pipeline duplicate (una nella pipeline originale e una nella nuova pipeline). Per evitare potenziali interruzioni, i trigger di questo tipo saranno disabilitati per impostazione predefinita nelle pipeline copiate. Si consiglia di gestire questi trigger in modo tale che sia abilitato un solo set alla volta. Una volta che ti senti a tuo agio con la transizione alla nuova pipeline, puoi abilitare i trigger su di essa e disabilitare i trigger sulla pipeline originale.

Ipotesi codificate in modo rigido

Dopo la migrazione, i repository Git Repos and Issue Tracking (se applicabili) avranno un diverso URL, e le toolchain e le pipeline avranno ID e URL diversi. È possibile che nelle definizioni di Tekton, negli script, nelle proprietà dell'ambiente o in altre automazioni siano presenti alcune ipotesi sull'indirizzo URL /ID o sulla posizione delle risorse. È responsabilità dell'utente aggiornarli dopo la migrazione.

macOS

Eseguire i seguenti comandi per installare le dipendenze su macOS.

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

Altre piattaforme

• Node.js istruzioni di installazione
• Istruzioni per l'installazione di Terraform

CRN

IBM Cloud Le risorse sono identificate in modo univoco tramite un nome di risorsa cloud(CRN). Avrai bisogno del CRN della toolchain che desideri copiare. È possibile ottenere il CRN di una toolchain in diversi modi:

1. Individuare la toolchain nella pagina Platform Automation > Toolchains, aprire la toolchain e fare clic su Details per visualizzare i dettagli della toolchain, che mostrano il CRN.
2. Individua la toolchain nella pagina Elenco risorse, fai clic sulla riga della toolchain per espandere il pannello dei dettagli, che mostra il CRN.
3. Utilizzando la CLI ibmcloud, è possibile elencare le toolchain e i relativi CRN tramite

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

4. Utilizzo dell'API della catena degli strumenti.

Verifica dei segreti della toolchain/pipeline memorizzati

Le toolchain e le pipeline Tekton possono contenere segreti, ovvero valori sensibili come chiavi API o password, nei seguenti punti:

• Proprietà dell'integrazione dello strumento, ad esempio la proprietà Service ID API Key dell'integrazione dello strumento Delivery Pipeline Private Worker
• Proprietà dell'ambiente della condotta Tekton
• Proprietà di attivazione della pipeline Tekton

Esistono due modi per configurare i segreti:

1. Memorizzati direttamente nella toolchain o nella pipeline
2. Fare riferimento ai segreti memorizzati in un servizio di archiviazione dei segreti, ad esempio IBM Cloud Secrets Manager o IBM Cloud Key Protect.

La copia di una toolchain includerà automaticamente i riferimenti segreti, che rimarranno intatti nella nuova toolchain. Tuttavia, per ridurre al minimo il rischio di fuga di dati sensibili, i segreti memorizzati direttamente nelle toolchain o nelle pipeline non saranno inclusi nella copia della toolchain. È possibile utilizzare il comando export-secrets descritto nella sezione successiva o inserire manualmente i segreti nella catena di strumenti o nella pipeline copiata dopo la copia. Si noti, tuttavia, che se non si esportano i segreti, alcune integrazioni di strumenti potrebbero non essere fornite correttamente durante la copia della toolchain se mancano i valori segreti richiesti e potrebbero dover essere ricreate manualmente dopo l'esecuzione del comando.

Innanzitutto, verificare se la propria toolchain o le pipeline Tekton contengono segreti memorizzati che non sono riferimenti all'esecuzione:

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

Esportazione dei segreti della catena di strumenti/pipeline memorizzati in Secrets Manager

Se la propria toolchain o pipeline non contiene segreti memorizzati, si può saltare questo passaggio e continuare a copiare la toolchain. L'esportazione dei segreti in Secrets Manager creerà dei segreti nell'istanza Secrets Manager e modificherà anche la catena di strumenti originale per convertire i segreti esistenti in riferimenti ai segreti appena creati in Secrets Manager. Questo permette di copiare la toolchain con i riferimenti segreti intatti ed è una pratica consigliata per una maggiore sicurezza.

Per evitare l'esposizione accidentale dei segreti, è necessario rivedere le autorizzazioni IAM dell'istanza per assicurarsi che sia concesso solo l'accesso previsto ai segreti di lettura Secrets Manager per assicurarsi che sia concesso solo l'accesso alla lettura dei segreti.

Per esportare i segreti memorizzati nella propria toolchain o pipeline in Secrets Manager, procedere come segue:

1. Se non si dispone ancora di un'istanza Secrets Managercreare un' istanza. Si noti che l'istanza deve essere creata nell'account associato alla chiave API che si utilizzerà.
2. Assicurarsi che il proprietario della chiave API da utilizzare abbia l'autorizzazione IAM per creare segreti nell'istanza Secrets Manager.
3. Aprire la toolchain e Secrets Manager, creare un criterio di autorizzazione quando richiesto, quindi creare l'integrazione dello strumento.
4. Esegui il comando export-secrets per esportare i segreti:

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

5. Quando viene richiesto, selezionare l'istanza di Secrets Manager dalla propria toolchain per memorizzare i segreti. Se la vostra istanza non compare nell'elenco, è possibile che si trovi in un altro account. Assicurarsi di utilizzare una chiave API dello stesso account dell'istanza.
6. Quando viene richiesto, per ogni segreto trovato, specificare se copiare o meno il segreto e il nome e il gruppo in cui memorizzare il segreto, oppure premere Invio per accettare i valori predefiniti.

È possibile eseguire il comando tutte le volte necessarie per esportare tutti i segreti.

Copia catene di strumenti

Per copiare una toolchain, eseguire il comando copy-toolchain@ibm-cloud/cd-tools. Per visualizzare le opzioni disponibili, eseguire:

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

copy-toolchain funziona traducendo prima la catena di strumenti in file Terraform (.tf) e poi applicando Terraform per creare una nuova catena di strumenti nella regione di destinazione. Il comando visualizzerà l'output di Terraform e chiederà conferma prima di creare la catena di strumenti. È possibile esaminare l'output di Terraform prima di creare la nuova copia della catena di strumenti.

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

Verifica delle risorse

Dopo aver copiato i toolchain, le pipeline Tekton e i progetti Git Repos and Issue Tracking (se applicabili) in una nuova regione, è necessario verificare che siano stati copiati correttamente e che funzionino correttamente prima di disabilitare o eliminare le risorse originali. Tieni presente:

• La pipeline Tekton **trigger temporizzati e Git ** non era abilitata per impostazione predefinita nelle pipeline copiate, per evitare la duplicazione delle corse tra la nuova pipeline e quella originale. Una volta che ci si sente a proprio agio, si possono abilitare i trigger nella nuova pipeline e disabilitare quelli della pipeline originale.
• Se si dispone di trigger della pipeline Tekton di tipo webhook, è necessario riconfigurare il trigger e inserire nuovamente il segreto. Questo segreto non supporta i riferimenti al segreto e non viene copiato con la pipeline.
• Gli utenti con token di accesso personali nei progetti Git Repos and Issue Tracking copiati dovranno ricreare nuovi token, poiché non sono stati copiati.
• Le integrazioni degli strumenti per i repository Git Repos and Issue Tracking sono state convertite in modo da utilizzare l'identità OAuth dell'utente che ha eseguito la copia. Se desiderate utilizzare un'identità diversa, accedete con quell'utente e salvate nuovamente le integrazioni dello strumento, oppure passate all'uso dei Gettoni di accesso personali.
• Nelle definizioni di Tekton, negli script, nelle proprietà dell'ambiente o in altre automazioni potrebbero esserci delle ipotesi sull'ID, su URL o sulla posizione delle risorse. Si consiglia di rivederli per assicurarsi che vengano utilizzati i nuovi ID, URL e posizioni.

Disattivare le risorse originali

Dopo aver verificato che le risorse copiate funzionino correttamente, è possibile disattivare le risorse originali per evitare conflitti o confusione.

• Per le pipeline Tekton, è possibile disattivare i trigger per evitare esecuzioni indesiderate della pipeline e per segnalare agli altri utenti che questi trigger non devono più essere utilizzati.
• Per le istanze di servizio Continuous Delivery istanze di servizio, se si utilizzava il piano Professional, è possibile passare al piano Lite per evitare ulteriori addebiti per le risorse originali. In questo modo le risorse potrebbero diventare di sola lettura se si sono superati i limiti del piano Lite, ma è possibile tornare a Professional in qualsiasi momento se si desidera utilizzarle di nuovo.
• Per i progetti Git Repos e Issue tracking (se applicabile), è possibile archiviare i progetti originali per renderli di sola lettura e impedire agli utenti di apportare ulteriori modifiche e, facoltativamente, aggiornare la descrizione del progetto o il readme per indicare dove si trova il nuovo progetto.

Anche se non avete intenzione di conservare le risorse originali, potreste volerle conservare per qualche tempo come backup, nel caso in cui doveste scoprire dei problemi in seguito. Una volta che ci si sente a proprio agio, è possibile eliminare le risorse originali.