Esegui il deployment dell'applicazione

Questa pagina descrive come utilizzare Cloud Deploy per distribuire l'applicazione negli ambienti di runtime di destinazione previsti. Prima di farlo, devi creare la pipeline di distribuzione e i target.

Prima di iniziare

Questa sezione descrive gli elementi che devi avere a disposizione prima di poter eseguire il deployment dell'applicazione utilizzando Cloud Deploy.

  • Assicurati che il tuo service account di esecuzione disponga dei ruoli e delle autorizzazioni IAM necessari.

  • Crea la pipeline di distribuzione e i target.

    Cloud Deploy può eseguire il deployment in Google Kubernetes Engine, Cloud Run, cluster collegati a GKE e target personalizzati. La configurazione del target varia a seconda della destinazione del deployment.

  • Disponi delle immagini container e dei manifest.

    Per eseguire il deployment, devi disporre di una o più immagini container e di uno o più manifest Kubernetes (per il deployment in GKE) o file YAML di servizio (per il deployment in Cloud Run).

    Per creare e inserire le immagini, devi disporre di una pipeline di integrazione continua o di un altro processo. Lo strumento CI può essere Cloud Build, Jenkins o qualsiasi altro strumento che generi immagini container che puoi fornire alla pipeline di distribuzione di Cloud Deploy.

  • Disponi di un file di configurazione skaffold.yaml.

    Cloud Deploy calls skaffold render per eseguire il rendering dei manifest Kubernetes utilizzando questo file e skaffold apply per eseguirne il deployment nel target. Per farlo, Skaffold richiede almeno un file skaffold.yaml minimo. Puoi ottenerne uno in due modi:

    • Creane uno.

      Tieni presente che il file skaffold.yaml deve fare riferimento a apiVersion supportato da Skaffold nella prima riga, come in questo esempio:

      `apiVersion: skaffold/v4beta7`

    • Fallo generare per te.

      Se non hai ancora un file skaffold.yaml, puoi chiedere a Cloud Deploy di crearne uno per te. Questo file è adatto per l'onboarding, l'apprendimento o la dimostrazione di Cloud Deploy e non deve essere utilizzato per i carichi di lavoro di produzione.

    Per ulteriori dettagli, consulta Utilizzare Skaffold con Cloud Deploy. Inoltre, Gestire i manifest in Cloud Deploy sono disponibili ulteriori dettagli sull'utilizzo di Skaffold e Cloud Deploy con strumenti di gestione dei manifest, come Helm, Kustomize e kpt.

Configurare Cloud Deploy per l'ambiente di runtime di tua scelta

Cloud Deploy può eseguire il deployment dell'applicazione in uno dei seguenti ambienti di runtime:

Richiamare la pipeline di distribuzione per creare una release

Dopo aver configurato Cloud Deploy per il deployment nel runtime, puoi inviare l'applicazione per il deployment in base alla pipeline di distribuzione che hai creato.

  1. Esegui il normale processo di integrazione continua (CI), creando l'artefatto o gli artefatti di cui è possibile eseguire il deployment.

  2. Avvia la pipeline di distribuzione chiamando Cloud Deploy per creare una release.

    Esegui il comando seguente dalla directory contenente la configurazione di Skaffold:

    gcloud deploy releases create RELEASE_NAME --delivery-pipeline=PIPELINE_NAME --region=REGION

    Poiché questo comando crea un file tar dell'intero contenuto della directory e di tutte le sottodirectory, potresti non volerlo eseguire dalla directory home o root. Esegui il comando dalla directory contenente la configurazione di Skaffold oppure includi l'opzione --source=, descritta di seguito.

    In questo comando...

    RELEASE_NAME è un nome da assegnare a questa release. Il nome deve essere univoco tra tutte le release per questa pipeline di distribuzione.

    Puoi specificare nomi di release dinamici includendo '$DATE' o '$TIME' o entrambi. Ad esempio, se richiami questo comando alle 15:07 UTC, 'rel-$TIME' viene risolto in rel-1507. '$DATE' e '$TIME' devono essere racchiusi tra virgolette singole e l'ora è l'ora UTC della macchina in cui richiami il comando.

    PIPELINE_NAME è il nome della pipeline di distribuzione che gestirà il deployment di questa release durante la progressione dei target. Questo nome deve corrispondere al campo name nella definizione della pipeline.

    REGION è il nome della regione in cui stai creando la release, ad esempio us-central1. Campo obbligatorio.

Questo comando carica un file tar contenente le configurazioni in un bucket Cloud Storage e crea la release. Cloud Deploy crea anche automaticamente un rollout ed esegue il deployment dell'immagine nel primo target definito nella pipeline di distribuzione.

Oltre ai parametri mostrati con questo comando, puoi includere una delle seguenti opzioni:

  • --images=<name=path/name:$IMAGE_SHA>,<name=path/name:$IMAGE_SHA>

    Una raccolta di sostituzioni del nome dell'immagine con il percorso completo dell'immagine.

  • --build-artifacts=<path/file>

    Un riferimento a un file di output degli artefatti di build di Skaffold, che può essere passato per rappresentare le sostituzioni del percorso completo dell'immagine.

Queste due opzioni si escludono a vicenda.

Puoi anche includere uno dei seguenti flag per chiedere a Cloud Deploy di generare un file skaffold.yaml per te:

Queste due opzioni si escludono a vicenda.

Puoi anche includere un file .gcloudignore se nella directory sono presenti file che non vuoi includere nel file tar.

Creare una release dalla Google Cloud console

Puoi utilizzare la Google Cloud console per creare una release per una pipeline di distribuzione. Questa opzione è utile per provare Cloud Deploy, ma non è adatta per i carichi di lavoro di produzione.

La procedura seguente presuppone che tu abbia già creato una pipeline di distribuzione e uno o più target. (Puoi anche utilizzare la Google Cloud console) per creare la pipeline di distribuzione.)

  1. Dalla pagina Dettagli pipeline di distribuzione, per una pipeline di distribuzione specifica, fai clic su Crea release.

    Dettagli della pipeline di distribuzione, che mostrano il pulsante Crea release

  2. Nel campo Scegli un container, incolla o digita il percorso dell'immagine container di cui vuoi eseguire il deployment. Puoi anche utilizzare il container precompilato predefinito in questo campo per la valutazione.

    Puoi anche fare clic su Seleziona per scegliere un'immagine container da Artifact Registry.

  3. Fornisci un nome univoco per questa release nel campo Nome release o utilizza il nome predefinito fornito.

  4. Fornisci un nome per il rollout nel campo Nome rollout o utilizza il nome predefinito fornito.

    Questo nome viene utilizzato per il rollout al primo target per questa release. Per i target successivi, puoi assegnare un nome al rollout nella finestra di dialogo Promuovi o nel comando gcloud deploy releases promote.

  5. (Facoltativo) Includi una descrizione per questa release nel campo Descrizione.

  6. In Dettagli deployment, inserisci un nome per il deployment GKE o il servizio Cloud Run oppure utilizza il nome predefinito fornito.

    Per GKE, Cloud Deploy genera il manifest per te. Per Cloud Run, Cloud Deploy genera la definizione del servizio, che viene utilizzata per creare il servizio.

  7. Fai clic su Crea.

    Finestra di dialogo Crea release

Cloud Deploy utilizza il manifest generato o la definizione del servizio Cloud Run e il file skaffold.yaml generato per creare la release.

Modificare il timeout del deployment

Per i deployment in GKE e nei cluster collegati a GKE, esistono tre timeout separati che influiscono sul tempo di attesa del sistema prima che Kubernetes segnali un deployment stabile:

  • Cloud Build ha un timeout di 1 ora per le operazioni eseguite da Cloud Build per Cloud Deploy.

    Puoi modificare questo timeout nella configurazione dell'ambiente di esecuzione.

  • Skaffold ha un timeout del controllo di integrità (deploy.statusCheckDeadlineSeconds), ovvero la quantità di tempo, in secondi, da attendere prima che i deployment si stabilizzino.

    Il valore predefinito è 600 secondi (10 minuti). Per utilizzare questo timeout, deploy.statusCheck deve essere impostato su true. Per impostazione predefinita, è così. Se statusCheck è false, non viene eseguito alcun controllo dello stato, il rollout viene contrassegnato come riuscito al termine di kubectl apply.

  • Per le risorse Kubernetes di kind: Deployment, esiste Deployment.spec.progressDeadlineSeconds, ovvero la quantità di tempo che Kubernetes attende prima che il deployment venga segnalato come stabile.

    Questo timeout è applicabile solo alle risorse Deployment. Ecco come funzionano insieme i primi due timeout:

    • Se Deployment.spec.progressDeadlineSeconds in Kubernetes non è impostato, il timeout effettivo è il timeout del controllo di integrità di Skaffold, sia che sia il valore predefinito sia che sia impostato in modo esplicito.

    • Se Deployment.spec.progressDeadlineSeconds in Kubernetes è impostato, Skaffold ignora il proprio timeout del controllo di integrità e il timeout effettivo è il timeout di avanzamento di Kubernetes. Tuttavia, se il timeout di Kubernetes è impostato in modo esplicito su 600 (10 minuti), Skaffold presuppone che sia il valore predefinito (non impostato) e lo ignora, mentre viene utilizzato il timeout di Skaffold (se impostato).

    • Se non è impostato alcun timeout, il timeout effettivo è il valore predefinito di Skaffold, ovvero 600 (10 minuti).

    Oltre a Deployment, altre risorse Kubernetes possono avere timeout che non influiscono sul timeout di stabilità. Se ne sono presenti, esaminali per assicurarti che non siano in conflitto con il timeout di stabilità.

    Se Skaffold (o Cloud Build) raggiunge il timeout, il deployment GKE continua a essere eseguito. Cloud Deploy mostra un errore, ma il deployment può comunque riuscire o non riuscire nel cluster GKE.

Per modificare il timeout di stabilità del deployment:

  1. Assicurati che deploy.statusCheck sia impostato su true in skaffold.yaml.

    true è il valore predefinito. Quando è impostato su true, Skaffold attende che i controlli di integrità segnalino un deployment stabile, in base al valore di timeout nel passaggio successivo.

  2. In skaffold.yaml, imposta statusCheckDeadlineSeconds sul numero di secondi che vuoi attendere.

    deploy:
  ...
  statusCheck: true
  statusCheckDeadlineSeconds: 600
  ...

    Il valore predefinito è 600 (10 minuti). Skaffold attende questo periodo di tempo per un deployment stabile. Se questo periodo di tempo viene superato prima che il deployment sia stabile, il deployment non riesce.

  3. (Facoltativo) Puoi aggiungere tolerateFailuresUntilDeadline: true dopo statusCheckDeadlineSeconds.

    Questa impostazione indica a Skaffold di non uscire se un singolo deployment non riesce, ma di tollerare gli errori fino alla scadenza di statusCheckDeadlineSeconds. Questa impostazione può essere utile in situazioni in cui le risorse potrebbero richiedere più tempo (fino alla scadenza del controllo dello stato) per raggiungere uno stato stabile.

    Ad esempio, se utilizzi Istio o Cloud Service Mesh, potresti avere un deployment non riuscito con un messaggio simile al seguente:

    error iptables validation failed; workload is not ready for Istio.
When using Istio CNI, this can occur if a pod is scheduled before the node is ready.

  4. Nel manifest Kubernetes, per le risorse di kind: Deployment, imposta Deployment.spec.progressDeadlineSeconds sullo stesso valore impostato per statusCheckDeadlineSeconds.

Passaggi successivi