Utilizzo degli ambienti di esecuzione di Cloud Deploy

Un ambiente di esecuzione di Cloud Deploy è l'ambiente in cui Cloud Deploy esegue le operazioni di rendering, pre-deployment, deployment, verifica e post-deployment. L'ambiente di esecuzione è costituito dai seguenti componenti:

  • Il pool di worker di Cloud Build (predefinito o privato) in cui Cloud Deploy esegue le operazioni di rendering, pre-deployment, deployment, verifica e post-deployment

  • L'account di servizio (predefinito o alternativo) che chiama Cloud Deploy per eseguire queste azioni

  • La posizione di archiviazione (predefinita o alternativa) per i manifest sottoposti a rendering in Cloud Storage

  • Timeout di Cloud Build per le operazioni (predefinito o personalizzato)

Questo articolo descrive l'ambiente di esecuzione predefinito, gli account di servizio e l'archiviazione per Cloud Deploy, nonché il motivo per cui è possibile modificare questi valori predefiniti.

Predefiniti

Di seguito sono riportati i valori predefiniti utilizzati da Cloud Deploy per l'esecuzione, per eseguire il rendering e il deployment e per archiviare asset come i manifest sottoposti a rendering:

  • Pool di worker predefinito

    Per impostazione predefinita, Cloud Deploy viene eseguito nel pool di worker predefinito di Cloud Build. Tuttavia, puoi configurare Cloud Deploy per l'utilizzo di un pool di worker privato di Cloud Build.

    Per ulteriori dettagli sui pool di worker, consulta la Panoramica di pool predefiniti e pool privati di Cloud Build.

  • Account di servizio di esecuzione predefinito

    Per impostazione predefinita, Cloud Deploy utilizza l'account di servizio Compute Engine predefinito.

  • Località di archiviazione Cloud Deploy predefinita

    Questo valore è il bucket Cloud Storage in cui Cloud Deploy archivia i manifest sottoposti a rendering. Per impostazione predefinita, Cloud Deploy crea un bucket Cloud Storage nella stessa regione delle risorse Cloud Deploy, assumendo il seguente formato:

    <location>.deploy-artifacts.<project ID>.appspot.com

  • Timeout predefinito di Cloud Build

    Per impostazione predefinita, Cloud Build ha un timeout di 1 ora sulle operazioni eseguite per Cloud Deploy. Puoi modificare il timeout nelle specifiche dell'ambiente di esecuzione in Configurazione di destinazione.

  • Preferenze di lettura predefinite per Skaffold, gcloud CLI e kubectl

    Per impostazione predefinita, i livelli di log per questi strumenti sono impostati sui rispettivi valori predefiniti, in genere warn o equivalente. Puoi cambiarla in debug o equivalente.

Le sezioni che seguono descrivono le circostanze in cui si modifica uno qualsiasi di questi valori e i link alle istruzioni per farlo.

Informazioni sui pool di worker di Cloud Build

L'ambiente di esecuzione di Cloud Deploy può utilizzare uno dei seguenti:

  • Il pool predefinito di Cloud Build

    Il pool di worker predefinito è un ambiente sicuro e ospitato con accesso alla rete internet pubblica. Le operazioni di rendering, deployment, pre-deployment, post-deployment e verifica vengono eseguite in quel pool, isolate da altri carichi di lavoro.

  • Una piscina privata

    I pool di worker privati sono pool privati e dedicati che possono essere personalizzati maggiormente rispetto al pool di worker predefinito. che può includere la possibilità di accedere alle risorse in una rete privata. Come il pool di worker predefinito, i pool di worker privati sono ospitati e completamente gestiti da Cloud Build. È possibile fare lo scale up o fare lo scale down fino a zero di questi pool senza dover configurare, eseguire l'upgrade o la scalabilità.

    La panoramica sui pool privati di Cloud Build descrive in modo più dettagliato i pool di worker predefiniti e i pool di worker privati, includendo una tabella che mette a confronto le loro funzionalità.

Modifica dell'ambiente di esecuzione di Cloud Deploy

Puoi modificare l'ambiente di esecuzione di Cloud Deploy nelle seguenti circostanze:

  • Vuoi eseguire il deployment in un cluster Google Kubernetes Engine privato

  • Le operazioni di rendering, deployment, pre-deployment, post-deployment o verifica, o una combinazione dei cinque, devono essere eseguite in un ambiente isolato dalle altre organizzazioni.

  • Vuoi che queste operazioni vengano eseguite in un ambiente non connesso alla rete internet pubblica.

  • Vuoi ambienti separati per il rendering e il deployment.

  • Vuoi utilizzare un account di servizio dedicato con autorizzazioni più specifiche del tuo utilizzo rispetto a quelle disponibili nell'account di servizio predefinito.

  • Vuoi archiviare i manifest sottoposti a rendering in una località diversa dal bucket Cloud Storage predefinito.

La configurazione di tutte e tre le parti dell'ambiente di esecuzione (pool di worker, account di servizio e archiviazione) viene eseguita per ogni destinazione, nella configurazione YAML di ogni destinazione.

Passaggio dal pool predefinito a un pool privato

Devi configurare i pool di worker per destinazione, in modo che il pool venga utilizzato per RENDER, DEPLOY, PREDEPLOY, POSTDEPLOY o VERIFY (o una combinazione dei cinque) solo per quella destinazione.

Per utilizzare il pool di worker predefinito per le operazioni di rendering e di deployment, non devi fare nulla.

Di seguito è riportato un esempio di configurazione di destinazione che specifica un pool di worker privato per DEPLOY e il pool di worker predefinito per RENDER, PREDEPLOY, POSTDEPLOY e VERIFY:

executionConfigs:
- usages:
  - DEPLOY
  privatePool:
    workerPool: "projects/p123/locations/us-central1/workerPools/wp123"
- usages:
  - RENDER
  - PREDEPLOY
  - VERIFY
  - POSTDEPLOY

Per saperne di più su come configurare pool privati per le destinazioni, consulta la documentazione sulla configurazione della pipeline di distribuzione.

Passaggio dall'account di servizio predefinito all'esecuzione personalizzata

Come per il pool di worker, puoi specificare un account di servizio alternativo da utilizzare per il rendering o il deployment (o entrambi) per destinazione. Per farlo, aggiungi la seguente riga alla configurazione di destinazione, dopo l'elemento workerPool:

serviceAccount: "[name]@[project_name].iam.gserviceaccount.com"

L'account di servizio specificato deve includere il ruolo clouddeploy.jobRunner, come descritto nel documento sugli account di servizio di Cloud Deploy.

Per ulteriori dettagli su questa configurazione, consulta Definizioni delle destinazioni.

Modifica della posizione di archiviazione

Per modificare il bucket di archiviazione dal valore predefinito di Cloud Deploy, aggiungi la seguente riga alla definizione della destinazione nella stanza workerPool:

artifactStorage: "gs://[bucket_name]/[dir]"

Questa configurazione cambia la posizione in cui vengono archiviati i manifest visualizzati, ma non influisce su dove è archiviata l'origine di rendering.

Modifica del livello di log per Skaffold, gcloud CLI e kubectl

Per modificare il livello di log per Skaffold, gcloud CLI e kubectl, dai rispettivi valori predefiniti a debug (o un valore equivalente), imposta verbose su true nelle configurazioni di esecuzione. Ecco un esempio:

executionConfigs:
- usages:
  - [RENDER | PREDEPLOY|  DEPLOY | VERIFY | POSTDEPLOY]
  workerPool:
  serviceAccount:
  artifactStorage:
  executionTimeout:
  verbose: true

Utilizzo di Cloud Deploy in un perimetro dei Controlli di servizio VPC

Cloud Deploy supporta i Controlli di servizio VPC.

Puoi seguire la guida rapida di Controlli di servizio VPC per configurare un perimetro di servizio.

Limitazioni

  • Devi utilizzare un pool di worker privato di Cloud Build per l'ambiente di esecuzione della destinazione, non il pool di worker predefinito.

  • Il progetto che contiene il pool di worker e il progetto che contiene le risorse di Cloud Deploy devono rimanere nello stesso perimetro di sicurezza dei Controlli di servizio VPC.

  • Qualsiasi cluster GKE in cui esegui il deployment nel perimetro dei Controlli di servizio VPC deve essere un cluster privato.

    Per configurare un pool privato per un cluster privato, vedi questo tutorial.

Passaggi successivi