Repository relativi alle applicazioni

Se si vuole impostare la propria catena di strumenti CI da zero, configurare questi repository durante la creazione della catena di strumenti CI.

Inventario

Le informazioni sulla distribuzione sono tracciate da questo repository. Per ogni esecuzione riuscita della pipeline CI, la pipeline CD crea un nuovo ramo che prende il nome del numero di CR creato e si fonde con il master al termine della distribuzione. Ad esempio, https://<region>.git.cloud.ibm.com/myorg/my-compliance-ci-inventory.

Problemi

Memorizza i problemi relativi agli incidenti che si verificano durante il processo di creazione e distribuzione. Ad esempio, https://<region>.git.cloud.ibm.com/myorg/my-compliance-ci-issues.

Prova

Raccoglie tutte le prove di conformità grezze che appartengono all'applicazione. Ad esempio, https://<region>.git.cloud.ibm.com/myorg/my-compliance-ci-evidence.

Toolchain

Le definizioni delle pipeline di tekton, come pipeline, trigger e ascoltatori, sono memorizzate in questo repository. Ad esempio, https://<region>.git.cloud.ibm.com/myorg/my-compliance-ci-toolchain.

Dopo aver acquisito i nomi dei repository dalla toolchain CI, procedere con il comando Guided Setup per iniziare la creazione della toolchain CD. Durante il processo di configurazione, per ogni repository è possibile fornire l' URL a a un repository IBM esistente ospitato su Git Repos and Issue Tracking. Attualmente, la toolchain supporta la creazione di soli repository di tipo " Git Repos and Issue Tracking ". Le versioni future forniscono supporto per creare repository con GitHub, GitHub Enterprise (GHE) e altri provider SCM.

Inventario

Il repository dell'inventario registra i dettagli degli artefatti costruiti dalle catene di strumenti CI. Il comportamento predefinito della catena di strumenti è Utilizzare l'inventario esistente per collegare un repository di inventario esistente per la catena di strumenti. La toolchain attualmente supporta il collegamento solo ai repository Git Repos and Issue Tracking esistenti. Per ulteriori informazioni, vedere Repository correlati alle applicazioni.

1. È possibile accettare la configurazione predefinita fornita nel modello.
2. Fai clic su Continue.

Problemi

Il repository dei problemi registra i problemi trovati durante l'esecuzione della pipeline CI.

1. È possibile accettare la configurazione predefinita fornita nel modello.
2. Fai clic su Continue

Configurazione del gasdotto

Il repository di configurazione della pipeline contiene file YAML e script necessari per la distribuzione, i test e altre attività personalizzate. Per ulteriori informazioni sui repository Git, vedere Configurazione dei Git Repos and Issue Tracking. Per ulteriori informazioni sugli script personalizzabili, vedere Script personalizzati.

1. Accettare le impostazioni predefinite per Source Provider e Crea un nuovo repository di configurazione dell'installazione client.

   La toolchain clona il campione hello-compliance-deployment nella tua organizzazione Git. Per ulteriori informazioni sui repository Git, consulta Configurazione di Git Repos and Issue Tracking. Per ulteriori informazioni sugli script personalizzabili, vedere Script personalizzati.

2. Inserire un Nome del nuovo repository.

3. Fai clic su Continue.

Segreti

Diversi strumenti di questa catena di strumenti, ed eventualmente gli script personalizzabili, richiedono segreti per accedere a risorse privilegiate. Una chiave API IBM Cloud è un esempio di tale segreto. Conservate questi segreti in modo sicuro in uno strumento di gestione dei segreti, ad esempio IBM Key Protect for IBM Cloud, IBM Cloud® Secrets Manager, o HashiCorp Vault. Il strumento di gestione dei segreti può essere integrato nella toolchain in modo da poter fare facilmente riferimento ai segreti nella pipeline Tekton.

È possibile utilizzare il AppRole metodo di autenticazione per leggere i valori segreti.

1. Questa esercitazione utilizza IBM Cloud® Secrets Manager come cassaforte per i segreti. I campi Regione, Gruppo di risorse e Nome del servizio vengono popolati automaticamente in base alle scelte disponibili. Fare clic sugli indicatori a discesa per visualizzare le altre scelte.
2. Digitate il vostro Secrets Manager nome istanza.
3. Selezionare il tipo di autorizzazione dall'elenco a discesa.
4. Fai clic su Continue.

Conservazione delle prove

L'archivio delle prove memorizza tutte le prove e gli artefatti generati dalla pipeline DevSecOps CI.

1. Selezionare un Utilizzare il deposito di prove esistente.
2. Selezionare l' URL e Repository che è stato creato quando si è configurato il toolchain di integrazione continua (CI). Per ulteriori informazioni sull'archiviazione delle prove, vedere Evidenze.
3. Attivare il cursore del secchio IBM Cloud Object Storage per memorizzare tutte le prove nel secchio IBM Cloud Object Storage.
4. Fai clic su Continue.

Bucket Cloud Object Storage

È necessario disporre dell 'istanza IBM Cloud Object Storage e di un bucket che funga da archivio delle prove di conformità.

1. I campi Istanza Cloud Object Storage, Nome del bucket e Cloud Object Storage endpoint sono popolati automaticamente.
2. Inserite la vostra chiave API ID servizio.
   • Preferibile: È possibile importare una chiave esistente da un caveau dei segreti facendo clic sull'icona della chiave.
   • È possibile copiare e incollare una chiave esistente.
3. Fai clic su Continue.

Il campo endpoint è facoltativo. Si raccomanda di selezionare o fornire l'endpoint durante la configurazione della toolchain o durante l'esecuzione della pipeline.

Distribuisci

Configurare la destinazione dell'inventario e il cluster Kubernetes dove viene distribuita l'applicazione:

1. Il nome predefinito di App è hello-compliance-app.

2. Digitare la propria IBM Cloud chiave API. La chiave API viene usata per interagire con lo strumento IBM Cloud CLI in diverse attività.

   • Preferibile: È possibile importare una chiave esistente da un caveau dei segreti facendo clic sull'icona della chiave.
   • È possibile copiare e incollare una chiave esistente.
   • Da qui è possibile creare una nuova chiave facendo clic sul pulsante Nuovo +.

   La nuova chiave API generata può essere immediatamente salvata in un archivio di segreti.

3. Se la chiave API è valida e ha un accesso sufficiente, il Container Registry, Container Registry namespace, Regione del cluster Dev, Gruppo di risorse, Nome del cluster, Spazio dei nomi del cluster sono popolati automaticamente. È possibile modificare uno qualsiasi di questi campi per adattarlo alla propria configurazione.

4. Fai clic su Continue.

Chiave API IBM Cloud

La chiave API viene utilizzata per interagire con lo strumento ibmcloud CLI in diverse attività.

• Una chiave API esistente può essere importata da un provider segreto esistente creato come prerequisito (consigliato)
• Una chiave esistente può essere copiata e incollata (non consigliato)
• È possibile creare una nuova chiave facendo clic su Nuovo +. Generare un api-key se non se ne ha uno. La nuova chiave API generata può essere immediatamente salvata in un'istanza esistente di Key Protect

Quando il campo Chiave API è compilato, i campi relativi al registro e al cluster vengono compilati automaticamente.

Inventario dei rami di destinazione e di origine

1. Accettare l'opzione Cluster singolo (distribuzione basata su push) per distribuire l'applicazione su obiettivi come Virtual Server Instance o personalizzare il processo di distribuzione, utilizzare l'opzione Custom.
2. Fare clic su Continua per visualizzare la pagina del cluster.
3. Immettere il campo IBM Cloud API Key per interagire con lo strumento CLI in diverse attività. Nota è possibile importare una chiave esistente da un caveau dei segreti facendo clic sull'icona della chiave.
4. Verificare i campi Regione cluster, Gruppo risorse, Nome cluster e Cluster namespace dove è stato creato il cluster di destinazione.
5. Fai clic su Continue.

Gestione delle richieste di modifica

1. Selezionare il repository IBM Cloud ospitato Git Repos and Issue Tracking per gestire le richieste di modifica. Per ulteriori informazioni, vedere Automazione della gestione delle modifiche.
2. Fai clic su Continue.

DevOps Insights catena di strumenti

Collegare un'istanza DevOps Insights esistente di un'altra catena di strumenti a questa pipeline, in modo che tutti i record di compilazione, distribuzione e test delle pipeline delle catene di strumenti CI e CD possano essere raccolti nello stesso posto.

La catena di strumenti CD può pubblicare i record di distribuzione su un'istanza DevOps Insights esistente. Per abilitare questa funzione, fornire l'ID della catena di strumenti che contiene l'istanza esistente DevOps Insights selezionandola nell'elenco degli ID della catena di strumenti DevOps Insights.

1. Fornire la propria DevOps Insights IBM Cloud chiave API.
2. Accettare la configurazione predefinita.
3. Verificare i campi Regione, Gruppo di risorse, DevOps Insights ID della catena di strumenti e DevOps Insights ambiente di destinazione in cui è stato creato l'ambiente di destinazione.
4. Fai clic su Continue.

Collegamento alla catena di strumenti esistente DevOps Insights

DevOps Insights può essere incluso facoltativamente nella toolchain creata e dopo la pubblicazione di ogni prova di verifica della conformità. La toolchain può usare un'istanza DevOps Insights esistente per pubblicare i record di distribuzione su Insights. È possibile collegare l'integrazione DevOps Insights da un'altra toolchain fornendo l'ID dell'integrazione.

1. Accettare la catena degli strumenti corrente.
2. Fai clic su Continue.

È possibile copiare l'ID della toolchain dalla pagina " URL " della propria toolchain. L' URL e di una toolchain segue questo schema: https://cloud.ibm.com/devops/toolchains/<toolchain-ID-comes-here>?env_id=ibm:yp:us-south. Se l' URL e è: https://cloud.ibm.com/devops/toolchains/aaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee?env_id=ibm:yp:us-south allora l'ID della toolchain è: aaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee. Includere solo l'ID, non l' URL completo.

Si può anche impostare un ambiente di destinazione per le interazioni DevOps Insights. Questo parametro è opzionale e viene usato al posto dell'ambiente di destinazione dall'inventario.

Strumenti opzionali

nodo di lavoro privato

L'integrazione dello strumento delivery pipeline private worker si collega a uno o più worker privati che possono eseguire i carichi di lavoro della delivery pipeline in modo isolato. Per ulteriori informazioni, vedere Lavorare con i lavoratori privati.

1. Inserire un nome per il lavoratore privato della pipeline di consegna.
2. Inserite la vostra chiave API ID servizio.
   • Preferibile: È possibile importare una chiave esistente da un caveau dei segreti facendo clic sull'icona della chiave.
   • È possibile copiare e incollare una chiave esistente.
3. Fai clic su Continue.

Eseguire la pipeline di promozione

Assicurarsi che la pipeline CI sia stata eseguita correttamente prima di eseguire la pipeline di promozione.

1. Fare clic su cd-pipeline.

2. Fare clic su Esegui per la pipeline Avvio promozione manuale.

3. Fare clic su Esegui per attivare la pipeline.

4. Fare clic su Avvio manuale della promozione > #1promotion-pipelinerun pipeline. Attendere il completamento dell'esecuzione della pipeline di promozione e controllare il registro di esecuzione.

   La pipeline di promozione crea una richiesta di pull con il contenuto dell'inventario sull'ambiente di origine dell'inventario, come il ramo master, che punta al ramo dell'ambiente di destinazione dell'inventario, come staging o production.

5. Dopo che la pipeline di promozione è stata completata con successo, il task log promote fornisce un link alla richiesta di pull nel repository dell'inventario. Il nome della richiesta di pull è del formato promote <inventory source environment> to <inventory target environment>, ad esempio, promote master to prod

6. Aprire la richiesta di pull nel browser con il link fornito nel log. Completare i dettagli nelle sezioni seguenti:

   • Priorità: (obbligatorio) Impostare come Critical, High, Moderate, Low o Planning.
   • Richiesta di modifica dell'assegnatario: (obbligatorio) Email-ID dell'assegnatario.
   • Descrizione aggiuntiva: Descrizione delle modifiche apportate all'applicazione.
   • Scopo/Obiettivo: Scopo delle modifiche apportate all'applicazione.
   • Spiegazione dell'impatto: Impatto della modifica sul comportamento o sull'ambiente dell'applicazione.
   • Piano di backout: Passi per il backout in caso di fallimento dell'installazione.

7. Completate i campi della Richiesta di estrazione e fate clic su salva.

8. Aggiungere l'etichetta EMERGENCY alla richiesta di pull se i controlli di conformità in CI non sono andati a buon fine e si vuole continuare con la distribuzione

9. Unire la richiesta di pull da Git Repos and Issue Tracking.

I dettagli della richiesta di pull vengono utilizzati durante la pipeline CD che viene eseguita per creare e aggiornare il repository delle richieste di modifica.

Eseguire la pipeline di promozione

1. Assicurarsi che la pipeline CI sia stata eseguita correttamente prima di eseguire il file Promotion Pipeline.

2. La pipeline di promozione crea un Pull Request con il contenuto dell'inventario nell'ambiente di origine dell'inventario. Ad esempio, master ramo che punta al ramo dell'ambiente di destinazione dell'inventario, ad esempio staging o prod. Viene creato un ramo intermedio per la PR, che può essere scartato dopo la fusione della PR.

   

3. Dopo che l'operazione Promotion Pipeline è stata completata con successo, l'attività promote fornisce un collegamento al già citato Pull Request nel repository dell'inventario. Il nome della richiesta di pull è nel seguente formato:

   promote <Inventory Source Environment> to <Inventory Target Environment>
   

4. Aprire il file Pull Request nel browser con il link fornito nel log. Completare le sezioni come segue:

   • Priorità: (obbligatorio) Una delle seguenti opzioni: Critico, Alto, Moderato, Basso, Pianificazione
   • Assegnatario della richiesta di modifica: (obbligatorio) ID e-mail dell'assegnatario
   • Descrizione aggiuntiva: Descrizione delle modifiche apportate all'applicazione
   • Scopo: Scopo delle modifiche apportate all'applicazione
   • Spiegazione dell'impatto: Impatto della modifica sul comportamento o sull'ambiente dell'applicazione
   • Piano di backout: Passi per il backout in caso di fallimento dell'installazione

5. Completare i campi nel campo Pull Request e salvare.

6. Unire il Pull Request dal Git Repos and Issue Tracking.

I dettagli del Pull Request sono usati dalla pipeline CD per creare una richiesta di modifica nel repository di gestione delle richieste di modifica durante l'esecuzione della pipeline CD.

Eseguire la pipeline del CD

È possibile attivare una pipeline di CD in modo manuale o automatico. È possibile attivare la pipeline CD manualmente in qualsiasi momento, ma se non ci sono state modifiche dall'ultima distribuzione andata a buon fine, la pipeline CD si arresta presto perché non c'è nulla da distribuire. Un Git Repos and Issue Tracking trigger è impostato per attivare la pipeline automatica del CD, ma è disabilitato per impostazione predefinita e può essere abilitato dopo la prima promotion.You può aggiungere e usare force-redeploy variabile per eseguire nuovamente il CD senza modifiche al codice. Visualizzare la cattura della schermata di successo della pipeline CD DevSecOps.

Si può anche attivare il CD Pipeline manualmente in qualsiasi momento, ma se non ci sono modifiche dall'ultima distribuzione riuscita, il CD Pipeline non distribuisce nulla di nuovo.

Un'esecuzione corretta della pipeline CD si presenta come segue:

Flusso dei compiti nella pipeline CD:

Dopo un'esecuzione corretta della pipeline CD, è possibile trovare l'applicazione di esempio in esecuzione nello spazio dei nomi prod. L'app URL si trova sotto run stage sottosezione di prod deployment fase di esecuzione della pipeline CD. Utilizza l' URL a per verificare che l'app sia in esecuzione.