Riferimento allo schema di configurazione

Il file o i file di configurazione di Cloud Deploy definiscono la pipeline di distribuzione, i target di destinazione e la progressione di questi target.

Il file di configurazione della pipeline di importazione può includere definizioni di target oppure queste possono trovarsi in un file o in più 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 destinazioni è chiamata delivery-pipeline.yaml. Tuttavia, puoi assegnare a questi file qualsiasi nome. Altre definizioni di risorse, come automazioni e criteri di implementazione, possono trovarsi anche nello stesso file di una pipeline di importazione o di una definizione di target.

Istruzioni

Cloud Deploy utilizza due file di configurazione principali:

Possono essere file separati oppure la pipeline di importazione 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 dei target. Alcune proprietà target non sono incluse qui. Consulta la sezione Definizioni dei target per tutte le proprietà di configurazione del 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:
 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:
  verbose:
---

# 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 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.

  • Le definizioni di target

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

  • Definizioni dei tipi di target personalizzati

    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 importazione o in un file separato.

  • Definizioni di Automation

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

Questi componenti sono definiti nel resto del documento.

Definizione e avanzamento della pipeline

Oltre ai metadati della pipeline, come name, la definizione della pipeline principale include un elenco di riferimenti ai target nell'ordine di sequenza di implementazione. In altre parole, il primo target elencato è il primo target di deployment. Dopo aver eseguito il deployment in questo target, la promozione della release consente di eseguire il deployment nel target successivo nell'elenco.

Di seguito sono riportate le proprietà di configurazione per una pipeline di importazione, escluse le definizioni dei target.

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 nella risorsa della pipeline di distribuzione dopo che la pipeline è stata registrata.

Per ulteriori informazioni, vedi Utilizzare 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 importazione 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 rollout creato da questa pipeline.

Il valore predefinito è false.

serialPipeline

L'inizio della definizione di una pipeline di importazione con progressione seriale. Questa disposizione è obbligatoria.

stages

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

L'elenco deve essere nell'ordine della sequenza di importazione che preferisci. Ad esempio, se hai target denominati dev, staging e production, elencali nello stesso ordine, in modo che il primo deployment venga eseguito in dev e quello finale in production.

Compila ogni campo stages.targetId con il valore del campo metadata.name nella definizione del target 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 importazione. Il valore è la proprietà metadata.name della definizione del target.

strategy.standard.verify impostato su true attiva la verifica del deployment sul target. 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 durante la creazione della release. I profili Skaffold ti 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:

    L'applicazione viene dispiata completamente nel target specificato.

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

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

Per ulteriori informazioni, consulta Utilizzare una strategia di implementazione.

Configurazione di strategy

Questa sezione mostra gli elementi di configurazione per strategy, per ogni ambiente di 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 verrà eseguita la fase di verifica per le implementazioni risultanti.

Puoi omettere l'elemento strategy per una strategia di implementazione 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 i target GKE e GKE Enterprise

Il seguente codice YAML mostra come configurare una strategia di deployment per un destinazione GKE o GKE Enterprise utilizzando la networking basata su servizi:

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

Il seguente file YAML mostra come configurare una strategia di deployment per un destinazione 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"
              routeDestinations:
                destinationIds: ["KEY"]
                propagateService: [true|false]
        canaryDeployment:
          percentages: ["PERCENTAGES"]
          verify: true | false

Nota in questo esempio routeUpdateWaitTime. Questo valore è 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. Se noti questo ritardo, puoi utilizzare routeUpdateWaitTime per fare in modo che Cloud Deploy attenda dopo aver applicato le modifiche HTTPRoute.

Il seguente file YAML mostra come configurare una strategia di deployment canary personalizzata o personalizzata-automatica. La configurazione specifica per il runtime, nella sezione runtimeConfig, viene omessa per i canari personalizzati, ma è inclusa nella configurazione dei canari automatici e personalizzati automatici.

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

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

L'attivazione 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

Ti consente di specificare coppie chiave-valore per passare valori ai manifest per i target con corrispondenza delle etichette, quando utilizzi i parametri di implementazione.

Puoi includere questo valore anche nei target.

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

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 qualsiasi destinazione con un'etichetta corrispondente.

Job predeploy e postdeploy

Questi 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 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 i job predeploy e postdeploy in qualsiasi strategia (ad es. standard, canary).

Per ulteriori informazioni 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 importazione può contenere definizioni di target oppure puoi specificare i target in un file separato. Puoi ripetere i nomi dei target all'interno di un progetto, ma devono essere univoci all'interno di una pipeline di importazione.

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

Vedi anche: Definizioni dei tipi di target personalizzati

Per i target GKE

Il seguente codice YAML mostra come configurare un target 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]
      internalIp:
      proxyUrl:

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

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

metadata.name

Il nome di questo target. Questo nome deve essere univoco a livello globale.

metadata.annotations e metadata.labels

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

Le annotazioni e le etichette vengono memorizzate con la risorsa di destinazione. Per ulteriori informazioni, consulta 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 implementazione in qualsiasi target, insieme ai valori. Questi valori vengono assegnati alle chiavi corrispondenti nel manifest dopo il rendering.

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

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

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

multiTarget.targetIds: []

Questa proprietà è facoltativa e viene utilizzata per configurare un multitarget 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 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à eseguita 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ò essere anche di zona (us-central1-c).

  • cluster_name

    Il nome del cluster, così come appare 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 targeting multiplo. 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 Eseguire il deployment di un percorso HTTP in un cluster diverso per informazioni su come eseguire il deployment di un percorso HTTP in un cluster alternativo non di destinazione.

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 è presente 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 trasmesso a kubectl quando ti connetti al cluster.

Per le destinazioni Cloud Run

Il seguente codice YAML mostra come configurare una destinazione di 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 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 ulteriori informazioni, consulta 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 multitarget 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 per il target multiplo, non per i target secondari.

run

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

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

  • project_name

    Il progetto Google Cloud in cui verrà eseguito il servizio.

  • location

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

Ometti la proprietà run quando configuri un [multi-target]. La posizione del servizio Cloud Run viene configurata all'interno del target secondario corrispondente.

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

Per i target GKE Enterprise

La configurazione del target per il deployment in un cluster GKE è simile alla configurazione di un target per un target GKE, a parte per il 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 [multi-target]. Il cluster GKE Enterprise viene configurato all'interno del target secondario corrispondente.

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

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 stanza gke, né una stanza run né una stanza anthosCluster.

I target personalizzati includono invece una customTarget stanza:

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, oltre a PREDEPLOY, VERIFY o POSTDEPLOY se la verifica o gli hook di deployment sono attivati nel target. Indicano quali 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, devi configurarlo come segue:

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

    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 predeploy e postdeploy 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 se RENDER e DEPLOY non sono specificati nello stesso ambiente di esecuzione personalizzato o in ambienti di esecuzione personalizzati separati.

  • workerPool

    Configurazione da utilizzare per il pool di worker. Viene utilizzato un percorso della risorsa che identifica il pool di worker di 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 o una posizione di archiviazione alternativi o entrambi.

  • serviceAccount

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

  • 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, sono 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 il debug. Il valore predefinito di kubectl è 2.

    • Google Cloud CLI --verbosity è impostato 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 stanza executionConfigs per un target multiplo, 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 per i target e le automazioni standard, le definizioni CustomTargetType possono essere incluse nella definizione della pipeline di importazione 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. A questo nome viene fatto 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 personalizzata. Questo valore è customAction.name definito in skaffold.yaml.

  • [DEPLOY_ACTION_NAME]

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

  • Per includeSkaffoldModules, consulta Utilizzare le configurazioni di Skaffold remote.

Definizioni di Automation

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

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

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

Il seguente file YAML mostra come configurare un'automazione. Tieni presente che le specifiche di una regola di automazione sono diverse in base alla regola. La configurazione per i tipi di regole di automazione disponibili è descritta 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]

    È uguale al valore metadata.name nella pipeline di importazione che utilizza questa automazione. Tutte le automazioni sono esclusive delle pipeline di distribuzione per le quali vengono create. In altre parole, non puoi condividere un'automazione in più pipeline di distribuzione.

  • [PURPOSE]

    È un nome aggiuntivo descrittivo per questa automazione. In genere, si tratta dell'azione automatica. Ad esempio, my-app-pipeline/promote.

  • labels e annotations sono le etichette o le annotazioni da associare a questa automazione.

  • [DESCRIPTION]

    È una descrizione facoltativa per questa automazione.

  • suspended

    true o false, a indicare 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, di conseguenza, richiede le autorizzazioni necessarie per promuovere una release.

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

    Questo account di servizio deve avere le seguenti autorizzazioni:

    • actAs per rubare l'identità dell'account di servizio di esecuzione.

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

  • [TARGET_ID]

    È l'ID del target per il quale viene utilizzata questa automazione. Anche se un'automazione è associata a una pipeline di importazione, 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 nel target. Vengono selezionati tutti i target associati 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, incluso più di un RULE_TYPE dello stesso tipo. 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 importazione. Per questa proprietà è obbligatorio un valore.

  • [RULE-SPECIFIC_CONFIG]

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

Esegui il deployment delle definizioni dei criteri (anteprima)

Questa sezione descrive i campi utilizzati per definire i criteri di implementazione.

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

Il seguente codice YAML mostra come configurare un criterio 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 queste norme.

  • [POLICY_NAME]

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

  • [ANNOTATIONS] e [LABELS]

    Le norme possono includere annotazioni ed etichette, che fanno parte della risorsa della norma dopo la sua creazione. Per ulteriori informazioni, consulta Utilizzare annotazioni ed etichette con Cloud Deploy.

  • suspended: [true | false]

    Se imposti suspended su true, questo criterio viene disattivato.

  • [PIPELINE_ID]

    È l'ID della pipeline di importazione a cui vuoi applicare questo criterio. Puoi utilizzare * per indicare tutte le pipeline. Questo ID corrisponde alla proprietà metadata.name nella pipeline di distribuzione.

  • [TARGET_ID]

    È l'ID della destinazione che vuoi che venga interessata da questo criterio. Puoi utilizzare * per indicare tutti i target. Questo ID corrisponde alla proprietà metadata.name sul target.

  • [LABEL_KEY]:[LABEL_VALUE]

    È una coppia chiave-valore da associare a una coppia chiave-valore definita nella pipeline o nel target di importazione. In questo modo vengono selezionate tutte le pipeline o tutti i target che hanno la stessa etichetta e lo stesso valore. Puoi specificare labels anziché o in aggiunta a id.

  • [RULE_TYPE]

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

  • [CONFIGS]

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

Regole di deployment dei criteri

Questa sezione descrive come configurare ogni regola del criterio di deployment.

rolloutRestriction

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

Il seguente codice 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, con il primo carattere una lettera, l'ultimo carattere una lettera o un numero e un massimo di 63 caratteri. Deve essere univoco all'interno del criterio di deployment.

  • ACTIONS

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

    • ADVANCE

      Non è possibile andare avanti con le fasi di implementazione.

    • APPROVE

      Impossibile approvare la promozione di implementazione.

    • CANCEL

      I rollout non possono essere annullati.

    • CREATE

      Non è possibile creare implementazioni.

    • IGNORE_JOB

      I job non possono essere ignorati.

    • RETRY_JOB

      Non è possibile riprovare i job.

    • ROLLBACK

      Non è possibile eseguire il rollback dei rollout.

    • TERMINATE_JOBRUN

      Le esecuzioni dei job non possono essere interrotte

  • INVOKERS

    La specifica degli invocatori filtra l'applicazione delle norme a seconda che l'azione limitata sia stata invocata da un utente o da un'automazione di deployment. I valori validi sono:

    • USER

      L'azione è basata sull'utente. Ad esempio, la creazione di un'implementazione manualmente utilizzando un comando gcloud CLI.

    • DEPLOY_AUTOMATION

      Un'azione automatica di Cloud Deploy.

    Puoi specificare uno o entrambi i valori. Se non specifichi nulla, il valore predefinito è entrambi.

  • TIMEZONE

    Il fuso orario, in 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 dell'intervallo di tempo del divieto in 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 viene applicata a tutti i giorni della settimana

  • START_TIME

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

  • END_TIME

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

Passaggi successivi