Riferimento per lo schema di configurazione

Il file o i file di configurazione di Cloud Deploy definiscono la pipeline di distribuzione, i target in cui eseguire il deployment e l'avanzamento di questi target.

Il file di configurazione della pipeline di distribuzione può includere definizioni di target oppure in file separati. Per convenzione, un file contenente sia la configurazione della pipeline di distribuzione sia le configurazioni di destinazione è chiamato clouddeploy.yaml, mentre una configurazione della pipeline senza target è denominata delivery-pipeline.yaml. Ma puoi assegnare a questi file il nome che preferisci.

Istruzioni

Cloud Deploy utilizza due file di configurazione principali:

Possono essere file separati oppure la pipeline di distribuzione e i target possono essere configurati nello stesso file.

Struttura di un file di configurazione di una pipeline di distribuzione

La seguente configurazione include una definizione di target:

# Delivery pipeline config
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
 name:
 annotations:
 labels:
description:
suspended:
serialPipeline:
 stages:
 - targetId:
   profiles: []
# Deployment strategies
# One of:
#   standard:
#   canary:
# See the strategy section in this document for details.
   strategy:
     standard:
       verify:
       predeploy:
         actions: []
       postdeploy:
         actions: []
   deployParameters:
   - values:
     matchTargetLabels:
 - targetId:
   profiles: []
   strategy:
   deployParameters:
---

# Target config
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name:
 annotations:
 labels:
description:
multiTarget:
 targetIds: []
deployParameters:
requireApproval:
#
# Runtimes
# one of the following runtimes:
gke:
 cluster:
 internalIp:
#
# or:
anthosCluster:
 membership:
#
# or:
run:
 location:
#
# or:
customTarget:
  customTargetType:
#
# (End runtimes. See documentation in this article for more details.)
#
executionConfigs:
- usages:
  - [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]
  workerPool:
  serviceAccount:
  artifactStorage:
  executionTimeout:
---

# Custom target type config
apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name:
  annotations:
  labels:
description:
customActions:
  renderAction:
  deployAction:
  includeSkaffoldModules:
    - configs:
    # either:
    googleCloudStorage:
      source:
      path:
    # or:
    git:
      repo:
      path:
      ref:
---

# Automation config
apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name:
  labels:
  annotations:
description:
suspended:
serviceAccount:
selector:
- target:
    id:
    # or
    labels:
rules:
- [RULE_TYPE]:
  name:
  [RULE-SPECIFIC_CONFIG]

Questo YAML ha tre componenti principali:

  • La pipeline di distribuzione principale e l'avanzamento

    Il file di configurazione può includere un numero illimitato di definizioni di pipeline.

  • Definizioni dei target

    Per semplicità, in questo esempio viene mostrato un solo target, che però può essere qualsiasi numero. Inoltre, i target possono essere definiti in uno o più file separati.

  • Definizioni dei tipi di target personalizzati

    I target personalizzati richiedono una definizione del tipo di target personalizzato. Come per i target e le automazioni, i tipi di target personalizzati possono essere definiti nello stesso file della pipeline di distribuzione o in un file separato.

  • Definizioni di Automation

    Puoi creare qualsiasi automazione del deployment nello stesso file della pipeline di distribuzione e dei target oppure in uno o più file separati. Per semplicità, qui viene mostrato un solo valore Automation, ma puoi crearne tutti quelli che vuoi.

Questi componenti sono definiti nel resto del documento.

Definizione e avanzamento della pipeline

Oltre ai metadati della pipeline, ad esempio name, la definizione principale della pipeline include un elenco di riferimenti ai target in ordine di sequenza di deployment. In altre parole, il primo target è quello di deployment. Dopo aver eseguito il deployment in quella destinazione, se promuovi la release viene eseguito il deployment nella destinazione successiva nell'elenco.

Di seguito sono riportate le proprietà di configurazione per una pipeline di distribuzione, escluse le definizioni di destinazione.

metadata.name

Il campo name accetta una stringa che deve essere univoca per progetto e località.

metadata.annotations e metadata.labels

La configurazione della pipeline di distribuzione può includere annotazioni ed etichette. Le annotazioni e le etichette vengono archiviate con la risorsa della pipeline di distribuzione dopo che la pipeline è stata registrata.

Per saperne di più, consulta Utilizzo di etichette e annotazioni con Cloud Deploy.

description

Una stringa arbitraria che descrive questa pipeline di distribuzione. Questa descrizione è visualizzata nei dettagli della pipeline di distribuzione nella console Google Cloud.

suspended

Un valore booleano, che se true sospende la pipeline di distribuzione, in modo che non possa essere utilizzata per creare, promuovere, eseguire il rollback o eseguire nuovamente il deployment delle release. Inoltre, se la pipeline di distribuzione è sospesa, non puoi approvare o rifiutare un'implementazione creata da quella pipeline.

Il valore predefinito è false.

serialPipeline

L'inizio della definizione di una pipeline di distribuzione di avanzamento seriale. Questa stanza è obbligatoria.

stages

Un elenco di tutte le destinazioni in cui è configurata la pipeline di distribuzione per il deployment.

L'elenco deve seguire l'ordine della sequenza di pubblicazione che vuoi. Ad esempio, se hai destinazioni chiamate dev, staging e production, elencale nello stesso ordine, in modo che il primo deployment sia in dev e il deployment finale sia in production.

Completa ogni campo stages.targetId con il valore del campo metadata.name nella definizione della destinazione corrispondente. In targetId, includi anche profiles:

serialPipeline:
 stages:
 - targetId:
   profiles: []
   strategy:
     standard:
       verify:

targetId

Identifica il target specifico da utilizzare per questa fase della pipeline di distribuzione. Il valore è la proprietà metadata.name della definizione di target.

strategy.standard.verify impostato su true abilita la verifica del deployment nella destinazione. Se non viene specificata alcuna strategia di deployment, viene utilizzata la strategia di deployment standard, con verifica impostata su false.

profiles

Crea un elenco di zero o più nomi di profilo Skaffold, da skaffold.yaml. Cloud Deploy utilizza il profilo con skaffold render durante la creazione della release. I profili Skaffold consentono di variare la configurazione tra i target utilizzando un unico file di configurazione.

strategy

Include le proprietà per specificare una strategia di deployment. Sono supportate le seguenti strategie:

  • standard:

    Il deployment dell'applicazione è stato eseguito completamente nella destinazione specificata.

    Questa è la strategia di deployment predefinita. Se ometti strategy, Cloud Deploy utilizza la strategia di deployment standard.

  • canary:

    In un deployment canary, esegui progressivamente il deployment di una nuova versione dell'applicazione, sostituendo la versione già in esecuzione con incrementi basati sulla percentuale (ad esempio, 25%, poi 50%, poi 75% e infine completamente).

La strategia di deployment è definita per destinazione. Ad esempio, potresti avere una strategia canary per il tuo target prod, ma una strategia standard (nessun strategy specificato) per gli altri target.

Per ulteriori informazioni, consulta Utilizzare una strategia di deployment.

Configurazione di strategy

Questa sezione mostra gli elementi di configurazione di strategy, per ogni runtime supportato.

Strategia di deployment standard

La strategia standard include solo i seguenti elementi:

strategy:
  standard:
    verify: true|false

La proprietà verify è facoltativa. Il valore predefinito è false, il che significa che non ci sarà alcuna fase di verifica per le implementazioni risultanti.

Puoi omettere l'elemento strategy per una strategia di deployment standard.

Strategia di deployment canary

Le seguenti sezioni descrivono la configurazione di una strategia di deployment canary per ogni runtime supportato da Cloud Deploy.

Per destinazioni Cloud Run
strategy:
  canary:
    runtimeConfig:
      cloudRun:
        automaticTrafficControl: true | false
    canaryDeployment:
      percentages: [PERCENTAGES]
      verify: true | false
Per target GKE e GKE Enterprise

Il seguente YAML mostra come configurare una strategia di deployment per un target GKE o GKE Enterprise, utilizzando il networking basato sui servizi:

      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              disablePodOverprovisioning: true | false
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true | false

Il seguente codice YAML mostra come configurare una strategia di deployment per un target GKE o GKE Enterprise, utilizzando l'API gateway:

      canary:
        runtimeConfig:
          kubernetes:
            gatewayServiceMesh:
              httpRoute: "HTTP_ROUTE_NAME"
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              routeUpdateWaitTime: "WAIT_TIME"
        canaryDeployment:
          percentages: ["PERCENTAGES"]
          verify: true | false

Nota in questo esempio: routeUpdateWaitTime. Questo è incluso perché l'API Gateway suddivide il traffico utilizzando una risorsa HTTPRoute e a volte si verifica un ritardo nella propagazione delle modifiche apportate a HTTPRoute. In questi casi, le richieste potrebbero essere ignorate, perché il traffico viene inviato a risorse non disponibili. Puoi utilizzare routeUpdateWaitTime per fare in modo che Cloud Deploy attenda dopo l'applicazione delle modifiche HTTPRoute, se noti questo ritardo.

Il seguente codice YAML mostra come configurare una strategia di deployment canary personalizzata o automatica personalizzata. La configurazione specifica per il runtime, nella sezione runtimeConfig, viene omessa per la versione canary personalizzata, ma è inclusa nella configurazione canary automatizzata e personalizzata.

strategy:
       canary:
         # Runtime configs are configured as shown in the
         # Canary Deployment Strategy section of this document.
         runtimeConfig:

         # Manual configuration for each canary phase
         customCanaryDeployment:
           - name: "PHASE1_NAME"
             percent: PERCENTAGE1
             profiles: [ "PROFILE1_NAME" ]
             verify: true | false
           - …
           - name: "stable"
             percent: 100
             profiles: [ "LAST_PROFILE_NAME" ]
             verify: true|false

verify

Booleano facoltativo che indica se supportare o meno la verifica del deployment per questo target. Il valore predefinito è false.

L'abilitazione della verifica del deployment richiede anche una stanza verify in skaffold.yaml. Se non fornisci questa proprietà, il job di verifica non andrà a buon fine.

deployParameters

Consente di specificare coppie chiave-valore per passare valori ai manifest per i target con corrispondenza di etichetta, quando utilizzi i parametri di deployment.

Puoi includerlo anche nei target.

Esegui il deployment dei parametri impostati su una pipeline di distribuzione utilizzando le etichette per corrispondere ai target:

deployParameters:
- values:
    someKey: "value1"
  matchTargetLabels:
    label1: firstLabel
- values:
    someKey: "value2"
  matchTargetLabels:
    label2: secondLabel

In questo esempio sono forniti due valori per la chiave e, per ogni valore, è presente un'etichetta. Il valore viene applicato al manifest per tutti i target con un'etichetta corrispondente.

predeploy e postdeploy job

che ti consentono di fare riferimento ad azioni personalizzate (definite separatamente, in skaffold.yaml) da eseguire prima del job di deployment (predeploy) e dopo il job di verifica, se presente (postdeploy). Se non è presente alcun job di verifica, il job di post-deployment viene eseguito dopo il job di deployment.

Gli hook di deployment sono configurati in strategy.standard o strategy.canary nel seguente modo:

serialPipeline:
  stages:
  - targetId:
    strategy:
      standard:
        predeploy:
          actions: [ACTION_NAME]
        postdeploy:
          actions: [ACTION_NAME]

Dove ACTION_NAME è il nome configurato in skaffold.yaml per customActions.name.

Puoi configurare i job predeploy e postdeploy in qualsiasi strategia (ad esempio standard, canary).

Per saperne di più sulla configurazione e sull'utilizzo degli hook pre e post-deployment, consulta Eseguire gli hook prima e dopo il deployment.

Definizioni di target

Il file di definizione della pipeline di distribuzione può contenere definizioni di destinazione oppure puoi specificare i target in un file separato. Puoi ripetere i nomi di destinazione all'interno di un progetto, ma devono essere univoci all'interno di una pipeline di distribuzione.

Puoi riutilizzare i target in più pipeline di distribuzione. Tuttavia, puoi fare riferimento a un target solo una volta nell'avanzamento di una singola pipeline di distribuzione.

Vedi anche: Definizioni dei tipi di target personalizzati

Per target GKE

Il seguente codice YAML mostra come configurare una destinazione per il deployment in un cluster GKE:

     apiVersion: deploy.cloud.google.com/v1
     kind: Target
     metadata:
      name:
      annotations:
      labels:
     description:
     deployParameters:
     multiTarget:
      targetIds: []

     requireApproval:
     gke:
      cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
      internalIp:

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

metadata.name

Il nome del target. Questo nome deve essere univoco a livello globale.

metadata.annotations e metadata.labels

La configurazione di destinazione supporta le annotazioni e le etichette di Kubernetes, ma non sono richieste da Cloud Deploy.

Le annotazioni e le etichette vengono archiviate con la risorsa di destinazione. Per ulteriori informazioni, consulta Utilizzo di etichette e annotazioni con Cloud Deploy.

description

Questo campo accetta una stringa arbitraria che descrive l'uso del target.

deployParameters

Puoi includere parametri di deployment su qualsiasi target, insieme ai valori. Questi valori vengono assegnati alle chiavi corrispondenti nel manifest, dopo il rendering.

La stanza deployParameters prende coppie chiave-valore, come mostrato di seguito:

deployParameters:
  someKey: "someValue"
  someOtherKey: "someOtherValue"

Se imposti parametri di deployment su un multi-target, il valore viene assegnato al manifest per tutti i target secondari di quel target multiplo.

multiTarget.targetIds: []

Questa proprietà è facoltativa e viene utilizzata per configurare un multi-target da utilizzare per il deployment parallelo.

Il valore è un elenco separato da virgole di target secondari. I target secondari sono configurati come target normali e non includono questa proprietà multiTarget.

requireApproval

Se la promozione a questo target richiede l'approvazione manuale. Può essere true o false.

Questa proprietà è facoltativa. Il valore predefinito è false.

Quando configuri il deployment parallelo, puoi richiedere l'approvazione solo per i target multipli, non per quelli figlio.

gke

Solo per i cluster GKE, il percorso della risorsa che identifica il cluster in cui verrà eseguito il deployment dell'applicazione:

gke:
  cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]

  • project_name

    Il progetto Google Cloud in cui si trova il cluster.

  • location

    La località in cui si trova il cluster. Ad esempio, us-central1. Il cluster può anche essere a livello di zona (us-central1-c).

  • cluster_name

    Il nome del cluster, così come viene visualizzato nell'elenco dei cluster nella console Google Cloud.

Ecco un esempio:

gke:
  cluster: projects/cd-demo-01/locations/us-central1/clusters/prod

Ometti la proprietà gke quando configuri un multi-target. Il cluster GKE viene invece configurato all'interno della destinazione figlio corrispondente.

Consulta executionConfigs in questo articolo per le descrizioni delle proprietà dell'ambiente di esecuzione.

internalIp

Indica se il cluster GKE specificato utilizza o meno un indirizzo IP privato. Questa proprietà è facoltativa. Per impostazione predefinita, Cloud Deploy utilizza l'indirizzo IP disponibile pubblicamente per il cluster. Se esiste un indirizzo IP privato e vuoi utilizzarlo, impostalo su true.

Per destinazioni Cloud Run

Il seguente codice YAML mostra come configurare una destinazione per il deployment in un servizio Cloud Run:

     apiVersion: deploy.cloud.google.com/v1
     kind: Target
     metadata:
      name:
      annotations:
      labels:
     description:
     multiTarget:
      targetIds: []

     requireApproval:
     run:
      location: projects/[project_name]/locations/[location]

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

metadata.name

Il nome del target. Il nome deve essere univoco per ogni regione.

metadata.annotations e metadata.labels

La configurazione di destinazione supporta annotazioni ed etichette, ma Cloud Deploy non le richiede.

Le annotazioni e le etichette vengono archiviate con la risorsa di destinazione. Per ulteriori informazioni, consulta Utilizzo di etichette e annotazioni con Cloud Deploy.

description

Questo campo accetta una stringa arbitraria che descrive l'uso del target.

multiTarget.targetIds: []

Questa proprietà è facoltativa e viene utilizzata per configurare un multi-target da utilizzare per il deployment parallelo.

Il valore è un elenco separato da virgole di target secondari. I target secondari sono configurati come target normali e non includono questa proprietà multiTarget.

requireApproval

Se la promozione a questo target richiede l'approvazione manuale. Può essere true o false.

Questa proprietà è facoltativa. Il valore predefinito è false.

Quando configuri il deployment parallelo, puoi richiedere l'approvazione solo per i target multipli, non per quelli figlio.

run

Solo per i servizi Cloud Run, la località in cui verrà creato il servizio:

run:
  location: projects/[project_name]/locations/[location]

  • project_name

    Il progetto Google Cloud in cui sarà attivo il servizio.

  • location

    La località in cui si troverà il servizio. Ad esempio, us-central1.

Ometti la proprietà run durante la configurazione di un target [multi-target]. La località del servizio Cloud Run viene invece configurata all'interno del target figlio corrispondente.

Consulta executionConfigs in questo articolo per le descrizioni delle proprietà dell'ambiente di esecuzione.

Per destinazioni GKE Enterprise

La configurazione di destinazione per il deployment in un cluster GKE è simile alla configurazione di una destinazione per una destinazione GKE, ad eccezione del fatto che la proprietà è anthosCluster.membership, anziché gke.cluster, il percorso della risorsa è diverso e internalIp non è applicabile.

anthosCluster:
  membership: projects/[project_name]/locations/global/memberships/[membership_name]

  • project_name

    Il progetto Google Cloud in cui si trova il cluster GKE Enterprise.

  • /location/global/

    La località in cui è registrato il cluster. global, in tutti i casi.

  • membership_name

    Il nome dell'appartenenza al cluster GKE Enterprise.

Ecco un esempio:

anthosCluster:
  membership: projects/cd-demo-01/locations/global/memberships/prod

Ometti la proprietà anthosCluster durante la configurazione di un target [multi-target]. Il cluster GKE Enterprise viene configurato invece all'interno della destinazione figlio corrispondente.

Per ulteriori informazioni sul deployment nei cluster GKE, consulta Deployment in cluster utente Anthos.

Per target personalizzati

La configurazione dei target personalizzati è simile a tutti gli altri tipi di destinazione, ad eccezione del fatto che non include una stanza gke, né una run stanza, né una anthosCluster.

I target personalizzati includono invece una stanza customTarget:

customTarget:
  customTargetType: [CUSTOM_TARGET_TYPE_NAME]

Dove CUSTOM_TARGET_TYPE_NAME è il nome utilizzato nella definizione del tipo di target personalizzato.

Ecco un esempio:

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: sample-env
customTarget:
  customTargetType: basic-custom-target

executionConfigs

Un insieme di campi per specificare un ambiente di esecuzione non predefinito per questo target.

  • usages

    RENDER, DEPLOY o entrambi, più PREDEPLOY, VERIFY o POSTDEPLOY se la verifica o il deployment degli hook sono attivati nella destinazione. Indicano quali operazioni eseguire per questo target utilizzando l'ambiente di esecuzione. Per indicare che deve essere utilizzato un ambiente di esecuzione personalizzato per hook pre-deployment, rendering, deployment, hook post-deployment e verifica, devi configurarlo come segue:

    usages:
- RENDER
- PREDEPLOY
- DEPLOY
- VERIFY
- POSTDEPLOY

    Se la verifica è abilitata nella fase della pipeline e non specifichi VERIFY in una stanza usages, Cloud Deploy utilizza l'ambiente di esecuzione predefinito per la verifica. Gli hook pre-deployment e post-deployment funzionano allo stesso modo.

    Tuttavia, se esiste un ambiente di esecuzione personalizzato per RENDER e DEPLOY, devi specificarne uno per VERIFY, PREDEPLOY OPPURE POSTDEPLOY se sono configurati nella pipeline di distribuzione.VERIFY, PREDEPLOY e POSTDEPLOY possono essere nello stesso usages di RENDER o DEPLOY o in usages separati.

    Non puoi specificare usages.VERIFY, usages.PREDEPLOY o usages.POSTDEPLOY a meno che RENDER e DEPLOY non siano specificati negli stessi ambienti di esecuzione personalizzati o distinti.

  • workerPool

    Configurazione per il pool di worker da utilizzare. Segui un percorso della risorsa che identifica il pool di worker Cloud Build da utilizzare per questo target. Ad esempio:

    projects/p123/locations/us-central1/workerPools/wp123.

    Per utilizzare il pool Cloud Build predefinito, ometti questa proprietà.

    Un determinato target può avere due workerPool (uno per RENDER e uno per DEPLOY). Quando configuri il pool predefinito, puoi specificare un account di servizio alternativo, una località di archiviazione o entrambi.

  • serviceAccount

    Il nome dell'account di servizio da utilizzare per questa operazione (RENDER o DEPLOY) per questa destinazione.

  • artifactStorage

    Il bucket Cloud Storage da utilizzare per questa operazione (RENDER o DEPLOY) per questo target, anziché il bucket predefinito.

  • executionTimeout

    Facoltativo. Imposta il timeout, in secondi, per le operazioni eseguite da Cloud Build per Cloud Deploy. Per impostazione predefinita, è di 3600 secondi (1 ora).
    Esempio: executionTimeout: "5000s"

Sintassi alternativa supportata

La configurazione di executionConfigs descritta in questo documento è nuova. La sintassi precedente è ancora supportata:

executionConfigs:
- privatePool:
    workerPool:
    serviceAccount:
    artifactStorage:
  usages:
  - [RENDER | DEPLOY]
- defaultPool:
    serviceAccount:
    artifactStorage:
  usages:
  - [RENDER | DEPLOY]

Quando configuri una stanza executionConfigs per un multi-target, ogni target figlio può ereditare l'ambiente di esecuzione da quel target multiplo.

Definizioni dei tipi di target personalizzati

Questa sezione descrive i campi utilizzati per definire i tipi di target personalizzati

Come con i target e le automazioni standard, le definizioni di CustomTargetType possono essere incluse nella definizione della pipeline di distribuzione o in uno o più file separati.

Il seguente codice YAML mostra come configurare un tipo di target personalizzato:

apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name: [CUSTOM_TARGET_TYPE_NAME]
  annotations:
  labels:
description:
customActions:
  renderAction: [RENDER_ACTION_NAME]
  deployAction: [DEPLOY_ACTION_NAME]
  includeSkaffoldModules:
    - configs:
    # either:
    googleCloudStorage:
      source:
      path:
    # or:
    git:
      repo:
      path:
      ref:

Dove:

  • [CUSTOM_TARGET_TYPE_NAME]

    È un nome arbitrario assegnato a questa definizione del tipo di target personalizzato. Questo nome fa riferimento nella definizione del target per qualsiasi target che utilizza il tipo di target personalizzato che stai definendo.

  • [RENDER_ACTION_NAME]

    È il nome dell'azione di rendering personalizzato. Questo valore è il customAction.name definito in skaffold.yaml.

  • [DEPLOY_ACTION_NAME]

    È il nome dell'azione di deployment personalizzato. Questo valore è il customAction.name definito in skaffold.yaml.

  • Per includeSkaffoldModules, consulta Utilizzare le configurazioni Skaffold remote.

Definizioni di Automation

Questa sezione descrive i campi utilizzati per definire le risorse di automazione di Cloud Deploy.

Come per i target, le definizioni di Automation possono essere incluse nella definizione della pipeline di pubblicazione oppure in uno o più file separati.

Per ulteriori informazioni sull'automazione in Cloud Deploy, consulta la documentazione sull'automazione.

Il seguente codice YAML mostra come configurare un'automazione. Tieni presente che le specifiche di una regola di automazione sono diverse per ogni regola. La configurazione dei tipi di regole di automazione disponibili è riportata nel documento Utilizzo delle regole di automazione.

apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name: [PIPELINE_NAME]/[PURPOSE]
  labels:
  annotations:
description: [DESCRIPTION]
suspended: true | false
serviceAccount: [SERVICE_ACCOUNT_ID]
selector:
  targets:
    -  id: [TARGET_ID]
       labels:
         [LABEL_KEY]:[LABEL_VALUE]

rules:
- [RULE_TYPE]:
    name:[RULE_NAME]
  [RULE-SPECIFIC_CONFIG]

Dove:

  • [PIPELINE_NAME]

    È uguale al valore metadata.name nella pipeline di distribuzione che utilizza questa automazione. Tutte le automazioni sono esclusive delle pipeline di distribuzione per cui sono create. ovvero non puoi condividere un'automazione tra più pipeline di distribuzione.

  • [PURPOSE]

    È un nome descrittivo aggiuntivo per questa automazione. In genere, questa è l'azione automatizzata. Ad esempio, my-app-pipeline/promote.

  • labels e annotations sono etichette o annotazioni che vuoi associare a questa automazione.

  • [DESCRIPTION]

    È una descrizione facoltativa per questa automazione.

  • suspended

    true o false, a indicare se l'automazione è attiva o sospesa. Se impostata su true, l'automazione non viene utilizzata. Questo può essere utile per testare un'automazione senza influire sulla pipeline di distribuzione.

  • [SERVICE_ACCOUNT_ID]

    È l'ID dell'account di servizio utilizzato per eseguire l'automazione. Ad esempio, se l'automazione utilizza promoteReleaseRule, questo account di servizio esegue la promozione della release e richiede quindi le autorizzazioni necessarie per promuovere una release.

    Per questa proprietà è obbligatorio indicare un valore. Cloud Deploy non utilizza l'account di servizio predefinito per le automazioni.

    Questo account di servizio deve avere le seguenti autorizzazioni:

    • Autorizzazione actAs per impersonare l'account di servizio di esecuzione.

    • autorizzazione per eseguire l'automazione, ad esempio clouddeploy.releases.promote per promuovere una release o clouddeploy.rollouts.advance per avanzare una fase dell'implementazione.

  • [TARGET_ID]

    È l'ID del target per cui viene utilizzata l'automazione. Sebbene un'automazione sia legata a una pipeline di distribuzione, viene eseguita solo sul target o sui target specificati.

    Puoi impostarlo su * per selezionare tutti i target nella pipeline di distribuzione.

  • [LABEL_KEY]:[LABEL_VALUE]

    È una coppia chiave-valore da abbinare a una coppia chiave-valore definita nel target. Vengono selezionati tutti i target associati alla pipeline di distribuzione che hanno la stessa etichetta e lo stesso valore.

  • [RULE_TYPE]

    È il nome della regola utilizzata per questa automazione. È promoteReleaseRule o advanceRolloutRule. Puoi includere più di una regola in un'automazione, comprese più regole dello stesso tipo RULE_TYPE. Ad esempio, puoi avere più di una regola promoteReleaseRule nella stessa automazione. Scopri di più.

  • [RULE_NAME]

    Un nome per la regola. Questo nome deve essere univoco all'interno della pipeline di distribuzione. Per questa proprietà è obbligatorio indicare un valore.

  • [RULE-SPECIFIC_CONFIG]

    La configurazione è diversa per ogni tipo di automazione supportato. Queste configurazioni sono mostrate in Utilizzo delle regole di automazione.

Passaggi successivi