Riferimento allo schema di configurazione

I file di configurazione di Cloud Deploy definiscono la pipeline di distribuzione, i target in cui eseguire il deployment e la progressione di queste destinazioni.

Il file di configurazione della pipeline di distribuzione può includere definizioni dei target oppure queste possono essere in uno o più file separati. Per convenzione, un file contenente sia la configurazione della pipeline di distribuzione che le configurazioni di destinazione viene 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:

Può trattarsi di 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 destinazione:

# 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:
 proxyUrl:
#
# 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 la progressione

    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, ma ce ne possono essere un numero qualsiasi. Inoltre, le destinazioni possono essere definite in uno o più file separati.

  • Definizioni dei tipi di target personalizzati

    I target personalizzati richiedono una definizione del tipo di target personalizzata. 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 di 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 Automation, ma puoi crearne quanto vuoi.

Questi componenti sono definiti nel resto del documento.

Definizione e avanzamento della pipeline

Oltre ai metadati della pipeline, come name, la definizione principale della pipeline include un elenco di riferimenti ai target nell'ordine di sequenza di deployment. Il primo target in elenco è il primo target del deployment. Dopo aver eseguito il deployment nella destinazione, la promozione della release viene eseguita nella destinazione successiva nell'elenco.

Di seguito sono riportate le proprietà di configurazione per una pipeline di distribuzione, escluse le definizioni della 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 ulteriori informazioni, consulta Utilizzo di etichette e annotazioni con Cloud Deploy.

description

Una stringa arbitraria che descrive questa pipeline di distribuzione. Questa descrizione viene mostrata 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 utilizzato per creare, promuovere, eseguire il rollback o rieseguire 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

Inizio della definizione di una pipeline di distribuzione della progressione seriale. Questa stanza è obbligatoria.

stages

Un elenco di tutti i target in cui è configurata la configurazione del deployment per questa pipeline di distribuzione.

L'elenco deve seguire l'ordine della sequenza di pubblicazione che preferisci. 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.

Compila ogni campo stages.targetId con il valore del campo metadata.name nella definizione della destinazione corrispondente. In targetId, includi 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 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 la verifica impostata su false.

profiles

Prende 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 le destinazioni utilizzando un singolo file di configurazione.

strategy

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

  • standard:

    Il deployment dell'applicazione viene 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 il deployment progressivamente di una nuova versione dell'applicazione, sostituendo la versione già in esecuzione con incrementi basati sulla percentuale (ad esempio, 25%, 50%, 75% e infine completamente).

La strategia di deployment viene definita in base al target. Ad esempio, potresti avere una strategia canary per il 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 per 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à una fase di verifica per le implementazioni risultanti.

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

Strategia di deployment canary

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

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

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

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

Il seguente YAML mostra come configurare una strategia di deployment per un target di 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. È incluso perché l'API Gateway divide 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 che non sono disponibili. Puoi utilizzare routeUpdateWaitTime per far sì che Cloud Deploy attenda dopo l'applicazione di HTTPRoute modifiche, se noti questo ritardo.

Il seguente YAML mostra come configurare una strategia di deployment canary personalizzata o automatica personalizzata. La configurazione specifica del 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

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

Per abilitare la verifica del deployment, è richiesta 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 le coppie chiave-valore per passare valori ai manifest per le destinazioni corrispondenti alle etichette quando si utilizzano i parametri di deployment.

Puoi includere questo indirizzo anche nei target.

Esegui il deployment dei parametri impostati su una pipeline di distribuzione e utilizza le etichette per creare corrispondenze tra i 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 che hanno un'etichetta corrispondente.

predeploy e postdeploy job

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 esistono job di verifica, il job post-deployment viene eseguito dopo il job di deployment.

Gli hook di deployment sono configurati in strategy.standard o strategy.canary come segue:

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 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 dei target

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

Puoi riutilizzare i target tra più pipeline di distribuzione. Tuttavia, puoi fare riferimento a una destinazione solo una volta dall'avanzamento di una singola pipeline di distribuzione.

Vedi anche: Definizioni dei tipi di target personalizzati

Per le destinazioni GKE

Il seguente YAML mostra come configurare una destinazione di cui viene eseguito 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:
      proxyUrl:

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

metadata.name

Il nome di questo target. Deve essere univoco a livello globale.

metadata.annotations e metadata.labels

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

Le annotazioni e le etichette vengono archiviate insieme alla 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'utilizzo del target.

deployParameters

Puoi includere i parametri di deployment in qualsiasi destinazione, insieme ai valori. Questi valori vengono assegnati alle chiavi corrispondenti nel file manifest, dopo il rendering.

La stanza deployParameters accetta coppie chiave-valore, come indicato di seguito:

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

Se imposti i 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

Indica 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 sulle destinazioni multi-target, non sulle destinazioni 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 è configurato invece all'interno della destinazione secondaria corrispondente.

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

internalIp

Indica se il cluster GKE specificato usa 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.

proxyUrl

Se accedi ai cluster tramite un proxy, fornisci la proprietà proxyUrl qui. Il valore è l'URL del tuo cluster GKE proxy, che viene passato a kubectl quando ti connetti al cluster.

Per le destinazioni Cloud Run

Il seguente YAML mostra come configurare una destinazione di cui viene eseguito 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:
       verbose:

metadata.name

Il nome di questo target. Questo nome deve essere univoco per ogni regione.

metadata.annotations e metadata.labels

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

Le annotazioni e le etichette vengono archiviate insieme alla 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'utilizzo 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

Indica 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 sulle destinazioni multi-target, non sulle destinazioni 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 si troverà il servizio.

  • location

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

Ometti la proprietà run quando configuri un attributo [multi-target]. La località del servizio Cloud Run è configurata invece all'interno del target figlio corrispondente.

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

Per i target di GKE Enterprise

La configurazione di destinazione per il deployment in un cluster GKE è simile alla configurazione di un target per un target 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 quando configuri un attributo [multi-target]. Il cluster GKE Enterprise è configurato invece all'interno della destinazione secondaria corrispondente.

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

Per target personalizzati

La configurazione per i 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 stanza 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 o DEPLOY o entrambi, più PREDEPLOY, VERIFY o POSTDEPLOY se la verifica o gli hook di deployment sono abilitati nella destinazione. Indicano quali di queste operazioni eseguire per la destinazione utilizzando l'ambiente di esecuzione. Per indicare che deve essere utilizzato un ambiente di esecuzione personalizzato per l'hook pre-deployment, il rendering, il deployment, l'hook post-deployment e la 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 di 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 trovarsi nello stesso usages di RENDER o DEPLOY oppure in usages separati.

    Non puoi specificare usages.VERIFY, usages.PREDEPLOY o usages.POSTDEPLOY a meno che RENDER e DEPLOY non siano specificati nello stesso ambiente di esecuzione personalizzato o in ambienti di esecuzione personalizzati separati.

  • workerPool

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

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

    Per utilizzare il pool di 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 questa destinazione, anziché il bucket predefinito.

  • executionTimeout

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

  • verbose

    Facoltativo. Se true, i livelli di dettaglio sono impostati su debug per i seguenti strumenti:

    • Lo Skaffold --verbosity è impostato su debug. Il valore predefinito di Skaffold è warn.

    • kubectl --v è impostato su 4, che è debug. Il valore predefinito di kubectl è 2.

    • Google Cloud CLI --verbosity è impostato su debug. Il valore predefinito è warning.

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 destinazione secondaria 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 per i target e le automazioni standard, le definizioni di CustomTargetType possono essere incluse nella definizione della pipeline di distribuzione oppure in uno o più file separati.

Il seguente YAML mostra come configurare un tipo di destinazione 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 che assegni 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]

    Indica 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 distribuzione oppure in uno o più file separati.

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

Il seguente YAML mostra come configurare un'automazione. Tieni presente che le specifiche di una regola di automazione variano in base alla regola. La configurazione dei tipi di regole di automazione disponibili è riportata nel documento Utilizzare le 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]

    Corrisponde al valore metadata.name nella pipeline di distribuzione che utilizza questa automazione. Tutte le automazioni sono esclusive delle pipeline di distribuzione per le quali vengono create. Ciò significa che non puoi condividere un'automazione in più di una pipeline di distribuzione.

  • [PURPOSE]

    Un altro nome descrittivo per questa automazione. In genere, si tratta dell'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 di questa automazione.

  • suspended

    true o false, che indica se l'automazione è attiva o sospesa. Se impostato 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 quindi richiede le autorizzazioni necessarie per promuovere una release.

    È richiesto un valore per questa proprietà. Cloud Deploy non utilizza l'account di servizio predefinito per le automazioni.

    Questo account di servizio deve disporre delle seguenti autorizzazioni:

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

    • Autorizzazione per eseguire l'operazione automatizzata, ad esempio clouddeploy.releases.promote per promuovere una release o clouddeploy.rollouts.advance per avanzare una fase di implementazione.

  • [TARGET_ID]

    È l'ID del target per cui viene utilizzata l'automazione. Sebbene un'automazione sia collegata 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. Seleziona tutti i target associati alla pipeline di distribuzione che hanno la stessa etichetta e lo stesso valore.

  • [RULE_TYPE]

    È il nome della regola di automazione utilizzata per questa automazione. Questo è promoteReleaseRule o advanceRolloutRule. Puoi includere più di una regola in un'automazione, incluse 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. È richiesto un valore per questa proprietà.

  • [RULE-SPECIFIC_CONFIG]

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

Passaggi successivi