Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui il deployment di un flusso di lavoro da un repository Git utilizzando Cloud Build

Puoi utilizzare un trigger di Cloud Build per avviare automaticamente una build ed eseguire il deployment di un flusso di lavoro da un repository Git. Puoi configurare il trigger per eseguire il deployment del flusso di lavoro per ogni modifica al repository di codice sorgente oppure solo quando la modifica soddisfa criteri specifici.

Questo approccio può aiutarti a gestire il ciclo di vita del deployment. Ad esempio, puoi eseguire il deployment delle modifiche a un flusso di lavoro in un ambiente di staging, eseguire test su quell'ambiente e poi implementare in modo incrementale queste modifiche nell'ambiente di produzione.

Prima di iniziare

Queste istruzioni presuppongono che tu disponga del ruolo Editor build Cloud (roles/cloudbuild.builds.editor) nel tuo progetto Google Cloud , in modo da poter creare trigger. Devi anche avere un flusso di lavoro in un repository di origine come GitHub o Bitbucket.

Console

Abilita le API Cloud Build e Workflows.

Abilita le API
Concedi il ruolo Amministratore di Workflows (roles/workflows.admin) all'account di servizio Cloud Build:
1. Nella console Google Cloud , vai alla pagina IAM.
  
  Vai a IAM
2. Seleziona il progetto.
3. Nella riga del account di servizio Cloud Build (PROJECT_NUMBER@cloudbuild.gserviceaccount.com), fai clic su Modifica entità.
4. Fai clic su Aggiungi un altro ruolo.
5. Nell'elenco Ruolo, seleziona il ruolo Amministratore Workflows.
6. Fai clic su Salva.
Concedi il ruolo Utente service account (roles/iam.serviceAccountUser) al service account Cloud Build nel account di servizio Compute Engine predefinito. Quando hai abilitato l'API Compute Engine, il account di servizio predefinito di Compute Engine è PROJECT_NUMBER-compute@developer.gserviceaccount.com.

Attenzione: l'assegnazione del ruolo Service Account User concede indirettamente all'utente il ruolo associato al account di servizio predefinito. Ad esempio, se l'account di servizio predefinito ha il ruolo Editor, l'utente può "agire come" un editor. Per ridurre al minimo l'impatto di queste assegnazioni di ruoli, ti consigliamo di configurare il account di servizio predefinito in base al principio del privilegio minimo. Per ulteriori informazioni, vedi Disattivare la concessione automatica dei ruoli ai service account predefiniti.
1. Nella console Google Cloud , vai alla pagina Service Accounts.
  
  Vai a Service account
2. Seleziona il progetto.
3. Fai clic sull'indirizzo email del account di servizio predefinito di Compute Engine (PROJECT_NUMBER-compute@developer.gserviceaccount.com).
4. Fai clic sulla scheda Autorizzazioni.
5. Fai clic sul pulsante Concedi l'accesso.
6. Per aggiungere un nuovo principal, inserisci l'indirizzo email del tuo account di servizio (SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com).
7. Nell'elenco Seleziona un ruolo, seleziona il ruolo Service Accounts > Utente service account.
8. Fai clic su Salva.

gcloud

Abilita le API Cloud Build e Workflows.

gcloud services enable cloudbuild.googleapis.com \
  workflows.googleapis.com

Concedi il ruolo Amministratore di Workflows (roles/workflows.admin) all'account di servizio Cloud Build:

PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format='value(projectNumber)')
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
  --role=roles/workflows.admin

Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud.

Concedi il ruolo Utente service account (roles/iam.serviceAccountUser) al service account Cloud Build nel account di servizio Compute Engine predefinito. Quando hai abilitato l'API Compute Engine, il account di servizio predefinito di Compute Engine è PROJECT_NUMBER-compute@developer.gserviceaccount.com.

Attenzione: l'assegnazione del ruolo Service Account User concede indirettamente all'utente il ruolo associato al account di servizio predefinito. Ad esempio, se l'account di servizio predefinito ha il ruolo Editor, l'utente può "agire come" un editor. Per ridurre al minimo l'impatto di queste assegnazioni di ruoli, ti consigliamo di configurare il account di servizio predefinito in base al principio del privilegio minimo. Per ulteriori informazioni, vedi Disattivare la concessione automatica dei ruoli ai service account predefiniti.
```
gcloud iam service-accounts add-iam-policy-binding \
  $PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
  --role=roles/iam.serviceAccountUser
```

Connettersi al repository di origine

Devi connettere Cloud Build al repository di origine in modo che Cloud Build possa automatizzare le build in risposta a eventi che si verificano nel repository.

Per connetterti a GitHub o Bitbucket:

Nella Google Cloud console, vai alla pagina Trigger di Cloud Build:

Vai ai trigger
Se necessario, seleziona il progetto e fai clic su Apri.
Nell'elenco Regione, seleziona la regione in cui vuoi creare il trigger.

Nota: se selezioni globale come regione, vengono utilizzati i pool predefiniti per eseguire la build; in caso contrario, viene utilizzato un pool privato nella regione del trigger. Devi specificare il pool privato nel file di configurazione di compilazione o tramite gli argomenti di compilazione.
Fai clic su Connetti repository.
Seleziona il repository di origine in cui hai archiviato il codice sorgente.

Ad esempio: GitHub (app GitHub di Cloud Build)
Fai clic su Continua.
Autenticati nel repository di origine con il tuo nome utente e la tua password.

Se accedi a GitHub, ti viene chiesto di autorizzare l'app GitHub di Google Cloud Build ad accedere al tuo account GitHub per procedere.
Dall'elenco dei repository disponibili, seleziona quello che ti interessa e fai clic su Ok.

Per i repository esterni come GitHub e Bitbucket, devi disporre delle autorizzazioni a livello di proprietario per il progetto Google Cloud in cui stai lavorando.
Leggi la dichiarazione di non responsabilità e seleziona la casella di controllo accanto per indicare che accetti i termini.
Fai clic su Connetti.
Per continuare a creare un trigger di build per automatizzare le build per il codice sorgente nel repository, fai clic su Crea un trigger. In caso contrario, fai clic su Fine.

Crea un file di configurazione Cloud Build

Un file di configurazione della build definisce i campi necessari quando si utilizza un trigger di build per avviare una build. Crea il file di configurazione nella directory principale del progetto e scrivilo utilizzando YAML o JSON.

Ad esempio, il seguente file di configurazione esegue il deployment e l'esecuzione di un flusso di lavoro di test, quindi utilizza uno script per controllare l'output. Se il test viene superato, il flusso di lavoro viene implementato:

steps:
# Deploy the test workflow with the commit sha
- id: 'deploy-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', '$_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA', '--source', 'gitops/workflow.yaml']

# Run the test workflow and capture the output
- id: 'run-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args: ['-c', 'gcloud workflows run $_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA > /workspace/testoutput.log']

# Delete the test workflow
- id: 'delete-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'delete', '$_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA', '--quiet']

# Check the test output
- id: 'check-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args: ['gitops/test-$BRANCH_NAME.sh']

# Deploy the workflow
- id: 'deploy-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', '$_WORKFLOW_NAME-$BRANCH_NAME', '--source', 'gitops/workflow.yaml']

Le $BRANCH_NAME e $SHORT_SHA variabili di sostituzione vengono compilate da Cloud Build quando una build viene attivata da un repository Git. Rappresentano rispettivamente il nome del tuo branch e i primi sette caratteri dell'ID commit associato alla tua build.

La variabile di sostituzione $_WORKFLOW_NAME consente di riutilizzare un file di configurazione con valori di variabile diversi. Puoi specificarne il valore quando crei il trigger di build.

Per ulteriori informazioni, vedi Creare un file di configurazione della build.

Crea un trigger di build

Puoi automatizzare il deployment del flusso di lavoro creando un trigger di Cloud Build.

Per creare un trigger di build per il file di configurazione nella sezione precedente:

Nella Google Cloud console, vai alla pagina Trigger di Cloud Build:

Vai ai trigger
Fai clic su Crea trigger.
Nel campo Nome, inserisci un nome per il trigger.
Per Evento, seleziona l'evento per richiamare il trigger.

Ad esempio: Push su un branch
Per Origine, seleziona il repository e il nome del ramo o del tag che avvierà l'attivatore. Puoi utilizzare un'espressione regolare per specificare una corrispondenza con un ramo o un tag.

Ad esempio: GoogleCloudPlatform/workflows-demos (repository) e ^main$|^staging$ (corrisponde ai rami main e staging)
Espandi la sezione Mostra i filtri dei file inclusi e ignorati e specifica il tuo flusso di lavoro come file incluso in modo che, quando viene modificato, venga richiamata una build.

Ad esempio: gitops/workflow.yaml
Per Configurazione, seleziona File di configurazione di Cloud Build (YAML o JSON) come tipo e Repository come posizione.
Nel campo Posizione file di configurazione Cloud Build, specifica la posizione del file.

Ad esempio: gitops/cloudbuild.yaml
Se vuoi, per aggiungere una variabile di sostituzione, fai clic su Aggiungi variabile e specifica una combinazione di chiave e valore.

Ad esempio: _WORKFLOW_NAME (variabile) e workflows-gitops (valore)
Per salvare il trigger di build, fai clic su Crea.

Quando vengono eseguite modifiche al flusso di lavoro nel ramo specificato del repository Git, Cloud Build viene attivato automaticamente per eseguire il deployment del flusso di lavoro.

Per saperne di più, consulta la pagina Creare e gestire i trigger di build.

Testa il trigger di build

Puoi testare il trigger di build e il file di configurazione delle sezioni precedenti.

Nel ramo staging del repository Git, modifica workflow.yaml e modifica Hello World in Bye World:

main:
  steps:
    - init:
        assign:
          - message: "Hello World"
    - returnResult:
        return: ${message}

Esegui il commit e il push della modifica nel ramo staging.
```
git add workflow.yaml
git commit -m "Update workflow.yaml in staging"
git push
```
Il trigger di Cloud Build viene eseguito e avvia una build.
Per verificare l'esito positivo della build, nella console Google Cloud , vai alla pagina Cronologia build:

Vai alla cronologia delle build

Al termine di una build, Cloud Build fornisce uno stato generale per la build e per ogni singolo passaggio di build. Per saperne di più, consulta Visualizzare i risultati della build.
Per verificare che un workflow di staging sia stato eseguito il deployment, nella console Google Cloud vai alla pagina Workflows:

Vai a Flussi di lavoro

Dovresti visualizzare un flusso di lavoro denominato workflows-gitops-staging.

Per eseguire il deployment del flusso di lavoro di staging in produzione, unisci il ramo staging al ramo main:

git checkout main
git merge staging
git push

Tieni presente che poiché test-main.sh prevede Hello World nell'output del flusso di lavoro, la build non andrà a buon fine:

RESULT_EXPECTED="result: '\"Hello World\"'"
RESULT_ACTUAL=$(grep "result: " $FILE)
if [[ $RESULT_EXPECTED == $RESULT_ACTUAL ]]; then
  echo "Result test passed"
else
  echo "Result test failed. Expected: $RESULT_EXPECTED Actual: $RESULT_ACTUAL"; exit 1;
fi

Per eseguire il deployment di un flusso di lavoro di produzione, nel ramo staging, modifica di nuovo workflow.yaml e cambia la stringa in Hello World.
Esegui il commit e il push della modifica nel ramo staging, quindi unisci il ramo staging al ramo main.
Per verificare che un workflow di produzione sia stato implementato, nella console Google Cloud , vai alla pagina Workflows:

Vai a Flussi di lavoro

Dovresti visualizzare un flusso di lavoro denominato workflows-gitops-main.

Passaggi successivi

Scopri di più su Cloud Build.
Scopri come risolvere gli errori di build.
Scopri come risolvere i problemi relativi ai flussi di lavoro.