Riferimento allo schema di configurazione

Il file o i file di configurazione di Cloud Deploy definiscono la pipeline di distribuzione, i target su cui eseguire il deployment e la progressione di questi target.

Il file di configurazione della pipeline di distribuzione può includere definizioni di destinazione oppure queste possono trovarsi in un file o file separati. Per convenzione, un file contenente sia la configurazione della pipeline di distribuzione sia le configurazioni di destinazione è denominato clouddeploy.yaml, mentre una configurazione della pipeline senza destinazioni è denominata delivery-pipeline.yaml. ma puoi assegnare a questi file il nome che preferisci. Altre definizioni di risorse, come automazioni e deploy policies, possono trovarsi anche nello stesso file di una pipeline di distribuzione o di una definizione di destinazione.

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 della pipeline di distribuzione

Di seguito è riportata la struttura di una configurazione della pipeline di distribuzione, incluse le proprietà per le definizioni di destinazione. Alcune proprietà di destinazione non sono incluse qui. Consulta Definizioni di destinazione per tutte le proprietà di configurazione della 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:
       predeploy:
         tasks: []
       verify:
         tasks: []
       analysis:
       postdeploy:
         tasks: []
   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:
 dnsEndpoint:
 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 | ANALYSIS]
  workerPool:
  serviceAccount:
  artifactStorage:
  executionTimeout:
  verbose:
---

# Custom target type config
apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name:
  annotations:
  labels:
description:
tasks:
  render:
  deploy:
---

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

Questo file YAML ha tre componenti principali:

  • La pipeline di distribuzione principale e la progressione

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

  • Definizioni dei target

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

  • Definizioni dei tipi di target personalizzati

    I target personalizzati richiedono una definizione di 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 pubblicazione o in un file separato.

  • Definizioni di Automation

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

Questi componenti sono definiti nel resto del documento.

Definizione e progressione della pipeline

Oltre ai metadati della pipeline, come name, la definizione della pipeline principale include un elenco di riferimenti ai target nell'ordine della sequenza di deployment. ovvero il primo target elencato è il primo target di deployment. Dopo aver eseguito il deployment nel target, la promozione della release viene eseguita nel target successivo 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 memorizzate con la risorsa della pipeline di pubblicazione dopo la registrazione della pipeline.

Per saperne di più, vedi Utilizzare etichette e annotazioni con Cloud Deploy.

description

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

suspended

Un valore booleano che, se true sospende la pipeline di pubblicazione in modo che non possa essere utilizzata 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 questa pipeline.

Il valore predefinito è false.

serialPipeline

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

stages

Un elenco di tutti i target per cui è configurata questa pipeline di distribuzione.

L'elenco deve essere nell'ordine della sequenza di consegna che preferisci. Ad esempio, se hai target chiamati dev, staging e production, elencali nello stesso ordine, in modo che la prima implementazione sia in dev e l'ultima 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 del target.

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

profiles

Accetta un elenco di zero o più nomi di profili Skaffold da skaffold.yaml. Cloud Deploy utilizza il profilo con skaffold render quando crea la release. I profili Skaffold ti consentono di variare la configurazione tra le destinazioni utilizzando un unico file di configurazione.

strategy

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

  • standard:

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

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

Per saperne di più, consulta Utilizzare una strategia di implementazione.

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:
      tasks: []
    analysis:

La proprietà verify consente di fare riferimento a una o più attività da eseguire per verificare il deployment. Se configurate, le attività di verifica verranno eseguite in sequenza, immediatamente dopo il job "deploy".

La proprietà verify è facoltativa. Se non specificato, non verrà eseguito alcun job verify nei rollout risultanti.

La sezione analysis è facoltativa e viene utilizzata con l'analisi di Cloud Deploy.

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

Strategia di deployment canary

Le sezioni seguenti descrivono la configurazione per 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:
        tasks: []
      analysis:

Per i target Cloud Run, AutomaticTrafficControl deve essere true a meno che tu non stia configurando un canary personalizzato.

Per le destinazioni GKE e i cluster collegati a GKE

Il seguente file YAML mostra come configurare una strategia di deployment per una destinazione che esegue il deployment in cluster GKE o GKE collegati, utilizzando il networking basato sui servizi:

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

Il seguente file YAML mostra come configurare una strategia di deployment per una destinazione che esegue il deployment in GKE o in cluster GKE collegati, utilizzando l'API Gateway:

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

Avviso 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 eliminate perché il traffico viene inviato a risorse non disponibili. Puoi utilizzare routeUpdateWaitTime per fare in modo che Cloud Deploy attenda dopo aver applicato le modifiche HTTPRoute, se noti questo ritardo.

Il seguente file YAML mostra come configurare una strategia di deployment canary personalizzata (per service networking, API Gateway o Cloud Run) o una strategia di deployment canary automatizzata personalizzata (per service networking, API Gateway o Cloud Run). La configurazione specifica per il runtime, nella sezione runtimeConfig, viene omessa per il canary personalizzato, ma inclusa nella configurazione canary automatica e automatica personalizzata.

Configurazione Canary 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:
          tasks: []
      - …
      - name: "stable"
        percent: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        analysis: [ANALYSIS_CONFIGS]
        verify:
          tasks: []

verify

La sezione verify può essere inclusa in strategy.standard, strategy.canary.canaryDeployment o in ogni fase di strategy.canary.customCanaryDeployment. Viene utilizzato per attivare la verifica del deployment per una destinazione. Questa sezione è facoltativa; se omessa, non viene eseguita alcuna verifica per l'implementazione o la fase canary.

Puoi configurare verify in due modi:

  • Imposta verify: true.

    Se lo fai, devi anche configurare una sezione verify nel tuo skaffold.yaml, come descritto in Configurare Skaffold per la verifica.

  • Configura verify utilizzando una o più attività da eseguire per la verifica:

    verify:
  tasks: [VERIFY_TASKS]

analysis

L'analisi del deployment, che puoi utilizzare per eseguire uno o più controlli sugli avvisi di Google Cloud Observability, viene configurata all'interno di una sezione strategy. Per i dettagli di configurazione, consulta Definizioni di analisi.

deployParameters

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

Puoi includerlo anche nei target.

I parametri di deployment impostati in una pipeline di distribuzione utilizzano le etichette per trovare le corrispondenze con le destinazioni:

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

In questo esempio, per la chiave sono forniti due valori e per ciascun valore è presente un'etichetta. Il valore viene applicato al manifest per qualsiasi destinazione con un'etichetta corrispondente.

predeploy e postdeploy job

Gli hook pre-deployment e post-deployment sono job da eseguire prima o dopo il job di deployment in un'implementazione. Puoi definire gli hook pre-deploy e post-deploy in due modi:

I job di pre-deployment vengono eseguiti immediatamente prima del job di deployment in un rollout. I job post-deployment vengono eseguiti dopo tutti gli altri job nel rollout, inclusi quelli di verifica e analisi, se applicabile.

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

  • Uso: tasks

    serialPipeline:
  stages:
  - targetId:
    strategy:
      standard:
        predeploy:
          tasks: [PREDEPLOY_TASKS]
        postdeploy:
          tasks: [POSTDEPLOY_TASKS]

    Dove:

    • PREDEPLOY_TASKS sono una o più attività che vuoi eseguire nell'hook predeploy.

    • POSTDEPLOY_TASKS sono una o più attività che vuoi eseguire nell'hook post-deployment.

  • Utilizzo di actions (e Skaffold)

    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 (standard, canary, ad esempio).

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

Definizioni dei target

Il file di definizione della pipeline di pubblicazione può contenere definizioni di target oppure puoi specificare i target in un file separato.

Puoi riutilizzare le destinazioni in più pipeline di distribuzione. Tuttavia, puoi fare riferimento a un target una sola volta all'interno della progressione di una singola pipeline di distribuzione.

Vedi anche: Definizioni dei tipi di target personalizzati

Per le destinazioni GKE

Il seguente file YAML mostra come configurare una destinazione che esegue 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]
      dnsEndpoint:
      internalIp:
      proxyUrl:

     associatedEntities:
       [KEY]:
         gkeClusters:
         - cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
           dnsEndpoint: [true|false]
           internalIp: [true|false]
           proxyUrl:

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

metadata.name

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

metadata.annotations e metadata.labels

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

Le annotazioni e le etichette vengono memorizzate con la risorsa di destinazione. Per saperne di più, vedi Utilizzare etichette e annotazioni con Cloud Deploy.

description

Questo campo accetta una stringa arbitraria che descrive l'utilizzo di questo target.

deployParameters

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

La sezione deployParameters accetta coppie chiave-valore, come mostrato:

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

Se imposti i parametri di deployment su una destinazione multipla, il valore viene assegnato al manifest per tutte le destinazioni secondarie della destinazione multipla.

multiTarget.targetIds: []

Questa proprietà è facoltativa e viene utilizzata per configurare un multi-target da utilizzare per l'implementazione parallela.

Il valore è un elenco separato da virgole di target secondari. I target secondari sono configurati come target normali e non includono la 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 l'implementazione parallela, puoi richiedere l'approvazione solo per il target multiplo, non per i target secondari.

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 di zona (us-central1-c).

  • cluster_name

    Il nome del cluster, come viene visualizzato nell'elenco dei cluster nella consoleGoogle 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 configurato all'interno del target secondario corrispondente.

Consulta executionConfigs in questo documento per le descrizioni delle proprietà dell'ambiente di esecuzione. Consulta Esegui il deployment di un HTTPRoute in un cluster diverso per informazioni sul deployment di HTTPRoute in un cluster alternativo non di destinazione.

associatedEntities.[KEY]

In una configurazione canary, utilizzi questo nome per fare riferimento alle entità di routeDestinations. Scopri di più.

dnsEndpoint

Se impostato su true, Cloud Deploy si connette al cluster GKE utilizzando l'endpoint DNS anziché l'endpoint predefinito, che può essere un IP pubblico, un IP privato o l'endpoint DNS, a seconda della configurazione del cluster.

Questa opzione non può essere utilizzata contemporaneamente all'opzione internalIp.

internalIp

Se impostato su true, Cloud Deploy si connette al cluster GKE utilizzando l'indirizzo IP privato anziché l'endpoint predefinito, che può essere un IP pubblico, un IP privato o l'endpoint DNS, a seconda della configurazione del cluster.

Questa opzione non può essere utilizzata contemporaneamente all'opzione dnsEndpoint. Poiché la configurazione di rete per dnsEndpoint è molto più semplice, consigliamo di utilizzare questo metodo.

proxyUrl

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

Per le destinazioni Cloud Run

Il seguente file YAML mostra come configurare una destinazione che esegue 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 | ANALYSIS]
       workerPool:
       serviceAccount:
       artifactStorage:
       executionTimeout:
       verbose:

metadata.name

Il nome di questo target. Questo nome deve essere univoco per 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 memorizzate con la risorsa di destinazione. Per saperne di più, vedi Utilizzare etichette e annotazioni con Cloud Deploy.

description

Questo campo accetta una stringa arbitraria che descrive l'utilizzo di questo target.

multiTarget.targetIds: []

Questa proprietà è facoltativa e viene utilizzata per configurare un multi-target da utilizzare per l'implementazione parallela.

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 l'implementazione parallela, puoi richiedere l'approvazione solo per il target multiplo, non per i target secondari.

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 risiederà il servizio.

  • location

    La posizione in cui risiederà il servizio. Ad esempio, us-central1.

Ometti la proprietà run quando configuri un [multi-target]. La posizione del servizio Cloud Run è configurata invece all'interno della destinazione secondaria corrispondente.

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

Per i target dei cluster collegati a GKE

La configurazione della destinazione per il deployment nei cluster GKE collegati è simile alla configurazione di una destinazione per una destinazione GKE, tranne per il fatto che la proprietà è anthosCluster.membership anziché gke.cluster, il percorso della risorsa è diverso e i metodi di connessione specifici (dnsEndpoint o internalIp) non sono applicabili.

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

  • project_name

    Il progetto Google Cloud in cui si trova il cluster.

  • /location/global/

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

  • membership_name

    Il nome dell'appartenenza al cluster.

Ecco un esempio:

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

Ometti la proprietà anthosCluster quando configuri un [multi-target]. Il cluster viene configurato invece all'interno del target secondario corrispondente.

Per saperne di più sul deployment nei cluster collegati a GKE, consulta Eseguire il deployment nei cluster collegati a GKE.

Per i target personalizzati

La configurazione per i target personalizzati è simile a tutti gli altri tipi di target, tranne per il fatto che non include una sezione gke, una sezione run o una sezione anthosCluster.

I target personalizzati, invece, includono una stanza customTarget:

customTarget:
  customTargetType: [CUSTOM_TARGET_TYPE_NAME]

Dove CUSTOM_TARGET_TYPE_NAME è il nome che hai 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 verifica o deploy hooks sono attivati sulla destinazione. Indicano quale di queste operazioni eseguire per questo target utilizzando questo ambiente di esecuzione. Per indicare che un ambiente di esecuzione personalizzato deve essere utilizzato per l'hook pre-deployment, il rendering, il deployment, l'hook post-deployment e la verifica, configuralo nel seguente modo:

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

    Se la verifica è attivata 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-deploy e post-deploy funzionano allo stesso modo.

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

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

  • workerPool

    Configurazione del pool di worker da utilizzare. Questo accetta un percorso della risorsa che identifica il pool di worker di Cloud Build da utilizzare per questa destinazione. 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 o una posizione di archiviazione alternativi o entrambi.

  • serviceAccount

    Il nome del 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 che Cloud Build esegue per Cloud Deploy. Per impostazione predefinita, questo valore è 3600 secondi (1 ora).
    Esempio: executionTimeout: "5000s"

  • verbose

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

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

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

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

Sintassi alternativa supportata

La configurazione 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 sezione executionConfigs per un target multiplo, ogni target figlio può ereditare l'ambiente di esecuzione dal target multiplo.

Definizioni dei tipi di target personalizzati

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

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

Il seguente 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 che assegni a questa definizione del tipo di target personalizzato. Questo nome viene indicato 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 personalizzata. Questo valore è il customAction.name definito in skaffold.yaml.

  • [DEPLOY_ACTION_NAME]

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

  • Per includeSkaffoldModules, vedi 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 o in uno o più file separati.

Per saperne di più sull'automazione in Cloud Deploy, consulta la documentazione sull'automazione.

Il seguente YAML mostra come configurare un'automazione. Tieni presente che i dettagli di una regola di automazione variano a seconda della regola. La configurazione per i tipi di regole di automazione disponibili è descritta 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]:
    id:[RULE_NAME]
  [RULE-SPECIFIC_CONFIG]

Dove:

  • [PIPELINE_NAME]

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

  • [PURPOSE]

    È un nome descrittivo aggiuntivo 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 per 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 pubblicazione.

  • [SERVICE_ACCOUNT_ID]

    È l'ID del 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 pertanto richiede le autorizzazioni necessarie per promuovere una release.

    È obbligatorio specificare un valore per questa proprietà. Cloud Deploy non utilizza il service account predefinito per le automazioni.

    Questo account di servizio deve disporre delle seguenti autorizzazioni:

    • actAs per rappresentare il account di servizio di esecuzione.

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

  • [TARGET_ID]

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

    Puoi impostare questo valore su * per selezionare tutti i target nella pipeline di pubblicazione.

  • [LABEL_KEY]:[LABEL_VALUE]

    È una coppia chiave-valore da confrontare con una coppia chiave-valore definita nella destinazione. Seleziona tutte le destinazioni associate alla pipeline di pubblicazione che hanno la stessa etichetta e lo stesso valore.

  • [RULE_TYPE]

    È il nome della regola di automazione utilizzata per questa automazione. Può essere promoteReleaseRule, timedPromoteReleaseRule, advanceRolloutRule o repairRolloutRule. Puoi includere più di una regola in un'automazione, inclusi più RULE_TYPE uguali. 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 risorsa di automazione. È obbligatorio specificare un valore per questa proprietà.

  • [RULE-SPECIFIC_CONFIG]

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

Definizioni delle policy di deployment

Questa sezione descrive i campi utilizzati per definire le policy di deployment.

Come per le altre risorse Cloud Deploy, puoi includere le definizioni DeployPolicy con la definizione della pipeline di distribuzione o in un file separato.

Il seguente file YAML mostra come configurare una policy di deployment:

apiVersion: deploy.cloud.google.com/v1
kind: DeployPolicy
metadata:
  name: [POLICY_NAME]
  annotations: [ANNOTATIONS]
  labels: [LABELS]
description: [DESCRIPTION]
suspended: [true | false]
selectors:
- deliveryPipeline:
    id: [PIPELINE_ID]
    labels:
      [LABEL_KEY]:[LABEL_VALUE]
  target:
    id: [TARGET_ID]
    labels:
      [LABEL_KEY]:[LABEL_VALUE]
rules:
  - [RULE_TYPE]
      [CONFIGS]

Dove:

  • [DESCRIPTION]

    È un testo facoltativo che descrive questa policy.

  • [POLICY_NAME]

    Un nome da assegnare al criterio. Questo campo accetta una stringa che deve essere univoca per progetto e località. Deve essere composto da lettere minuscole, numeri e trattini, il primo carattere deve essere una lettera, l'ultimo carattere una lettera o un numero e la lunghezza massima è di 63 caratteri. Questo nome viene utilizzato come nome visualizzato nella consoleGoogle Cloud .

  • [ANNOTATIONS] e [LABELS]

    Le norme possono includere annotazioni ed etichette, che fanno parte della risorsa dopo la sua creazione. Per saperne di più, consulta Utilizzo di annotazioni ed etichette con Cloud Deploy.

  • suspended: [true | false]

    Se suspended viene impostato su true, questa policy viene disattivata.

  • [PIPELINE_ID]

    È l'ID della pipeline di pubblicazione che vuoi che questo criterio influenzi. Puoi utilizzare * per indicare tutte le pipeline. Questo ID corrisponde alla proprietà metadata.name nella pipeline di pubblicazione.

  • [TARGET_ID]

    È l'ID della destinazione che vuoi che sia interessata da questa policy. Puoi utilizzare * per indicare tutti i target. Questo ID è uguale alla proprietà metadata.name nella destinazione.

  • [LABEL_KEY]:[LABEL_VALUE]

    È una coppia chiave-valore da confrontare con una coppia chiave-valore definita nella pipeline di distribuzione o nella destinazione. In questo modo vengono selezionate tutte le pipeline o tutti i target con la stessa etichetta e lo stesso valore. Puoi specificare labels anziché id o in aggiunta a questa proprietà.

  • [RULE_TYPE]

    È il tipo di regola specifica del criterio che stai configurando. L'unico valore valido è rolloutRestriction.

  • [CONFIGS]

    È l'insieme delle proprietà di configurazione per la regola di policy specifica che stai creando. La configurazione delle regole è descritta più avanti in questa sezione di questo riferimento per ciascuna delle regole disponibili.

Regole dei criteri di deployment

Questa sezione descrive come configurare ogni regola della policy di deployment.

rolloutRestriction

La regola rolloutRestriction impedisce a Cloud Deploy di eseguire determinate operazioni sui rollout durante la finestra o le finestre temporali specificate, per le pipeline di distribuzione e le destinazioni indicate da selectors per il criterio di deployment.

Il seguente YAML mostra come configurare una regola rolloutRestriction:

rules:
- rolloutRestriction:
    id: [RULE_ID]
    actions:
    - [ACTIONS]
    invokers:
    - [INVOKERS]
    timeWindows:
      timeZone: [TIMEZONE]
      oneTimeWindows:
      - start: [START_DATE_TIME]
        end: [END_DATE_TIME]
      weeklyWindows:
      - daysOfWeek:
        - [DAY_OF_WEEK]
        - [DAY_OF_WEEK]
        startTime: [START_TIME]
        endTime: [END_TIME]

Dove:

  • RULE_ID

    Un identificatore per questa regola. Campo obbligatorio. Deve essere composto da lettere minuscole, numeri e trattini. Il primo carattere deve essere una lettera e l'ultimo una lettera o un numero. La lunghezza massima è di 63 caratteri. Deve essere univoco all'interno del criterio di deployment.

  • ACTIONS

    (Facoltativo) Azioni di implementazione da limitare nell'ambito delle norme. Se è vuoto, tutte le azioni sono limitate. I valori validi sono:

    • ADVANCE

      Le fasi di implementazione non possono essere avanzate.

    • APPROVE

      La promozione di implementazione non può essere approvata.

    • CANCEL

      I rollout non possono essere annullati.

    • CREATE

      Non è possibile creare lanci.

    • IGNORE_JOB

      I job non possono essere ignorati.

    • RETRY_JOB

      I job non possono essere riprovati.

    • ROLLBACK

      I rollout non possono essere annullati.

    • TERMINATE_JOBRUN

      Impossibile terminare le esecuzioni dei job

  • INVOKERS

    La specifica degli autori della chiamata filtra l'applicazione delle policy a seconda che l'azione soggetta a limitazioni sia stata richiamata da un utente o da un'automazione del deployment. I valori validi sono:

    • USER

      L'azione è guidata dall'utente. Ad esempio, la creazione manuale di un rollout utilizzando un comando gcloud CLI.

    • DEPLOY_AUTOMATION

      Un'azione automatica di Cloud Deploy.

    Puoi specificare uno o entrambi i valori. Il valore predefinito, se non specifichi nulla, è entrambi.

  • TIMEZONE

    Il fuso orario, nel formato IANA, in cui esprimi la finestra temporale. Ad esempio, America/New_York. Campo obbligatorio.

  • START_DATE_TIME

    Per oneTimeWindows, la data e l'ora che segnano l'inizio della finestra di limitazione, nel formato "yyyy-mm-dd hh:mm". Per l'inizio della giornata, utilizza 00:00. Questo campo è obbligatorio.

  • END_DATE_TIME

    Per oneTimeWindows, la data e l'ora che segnano la fine della finestra di limitazione, nel formato "yyyy-mm-dd hh:mm". Per la fine della giornata, utilizza 24:00. Questo campo è obbligatorio.

  • DAY_OF_WEEK

    Per weeklyWindows, il giorno della settimana, SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY o SATURDAY. Se lasci vuoto questo campo, la corrispondenza riguarda tutti i giorni della settimana

  • START_TIME

    Per weeklyWindows, l'ora di inizio nel giorno della settimana specificato. Se includi un orario di inizio, devi includere un orario di fine. Per l'inizio della giornata, usa 00:00.

  • END_TIME

    Per weeklyWindows, l'ora di fine nel giorno della settimana specificato. Se includi un orario di inizio, devi includere un orario di fine. Per la fine della giornata, utilizza 24:00.

Definizioni dell'analisi

Una sezione analysis ti consente di configurare un job di analisi per eseguire uno o più controlli sugli avvisi di Google Cloud Observability o su dati simili di altri fornitori di monitoraggio, al fine di intraprendere azioni in base a questi avvisi.

La sezione analysis varia a seconda che tu la stia configurando per Google Cloud Observability o per un altro provider che utilizza l'analisi personalizzata.

analysis per Google Cloud Observability

La sezione analysis può essere utilizzata direttamente all'interno di una configurazione della strategia di deployment (strategy.standard.analysis, per una strategia standard). Se vuoi configurare l'analisi per fase, utilizza un canary personalizzato (strategy.canary.customCanaryDepolyment.phaseConfigs.phaseId.analysis).

analysis:
  duration: DURATION
  googleCloud:
    alertPolicyChecks:
    - id: CHECK_ID
      alertPolicies:
      - ALERT_POLICY_NAME
      labels:
        LABEL_KEY: LABEL_VALUE

Di seguito sono riportate le proprietà di configurazione per analysis quando utilizzi Google Cloud Observability:

  • Puoi avere un numero qualsiasi di alertPolicyChecks.

  • DURATION è il periodo di tempo, in secondi, minuti o ore, per eseguire l'analisi. Al termine di questo periodo, l'analisi non è più influenzata dagli avvisi di Google Cloud Observability. Ad esempio: 200s.

    CHECK_ID è un ID univoco per il controllo della norma di avviso. Questo valore viene visualizzato nei risultati dell'analisi, per ogni controllo.

  • ALERT_POLICY_NAME è il nome del criterio di avviso che hai creato in Google Cloud Observability.

  • LABEL_KEY è il nome di un'etichetta che il controllo utilizzerà per la corrispondenza con la criterio di avviso di Google Cloud Observability.

  • LABEL_VALUE è il valore da corrispondere per ogni etichetta.

Personalizzato analysis

Un job di analisi che utilizza controlli personalizzati (rispetto ai dati di un fornitore di monitoraggio diverso da Google Cloud Observability). Un controllo personalizzato utilizza un task per specificare il container che include il comportamento personalizzato e il comando o i comandi da eseguire su quel container.

La configurazione per un'analisi personalizzata è la seguente:

analysis:
  duration: DURATION
  customChecks:
  - id: CHECK_ID
    frequency: FREQUENCY
    task:
      type: container
      image: IMAGE_NAME
      command: [COMMAND]
      args: [ARGS]
      env:
        [VAR: VALUE]

  • DURATION è il periodo di tempo, in secondi, minuti o ore, per eseguire l'analisi. Una volta trascorso questo periodo, l'analisi non è più influenzata dalla telemetria in entrata dal sistema di monitoraggio. Ad esempio: 200s.

  • CHECK_ID è un ID univoco che fornisci per il controllo dei criteri di avviso. Questo valore viene visualizzato nei risultati dell'analisi, per ogni controllo.

  • FREQUENCY specifica la frequenza, in secondi, minuti o ore, con cui eseguire il controllo. Ad esempio, 300s.

  • IMAGE_NAME è il percorso dell'immagine container in un repository di immagini.

  • COMMAND è il punto di ingresso da eseguire sul container. "/bin/sh" è un comando tipico da specificare qui per richiamare una shell e includere il comando o i comandi da eseguire in quella shell negli argomenti.

  • ARGS è un elenco di argomenti da fornire al comando. Se il tuo COMMAND è "/bin/sh", uno degli argomenti qui sarebbe "-c" e un altro argomento sarebbe l'intero comando che vuoi eseguire nella shell che stai richiamando.

    Passaggi successivi

  • Scopri di più su come funziona Cloud Deploy.

  • Scopri come configurare una pipeline di distribuzione per la tua applicazione.

  • Scopri come gestire i manifest.

  • Evita le mancate corrispondenze tra la release e la pipeline di distribuzione scoprendo di più sulle istanze della pipeline.