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 la configurazione di destinazione si chiama clouddeploy.yaml, mentre una configurazione della pipeline target è delivery-pipeline.yaml. Ma puoi assegnare a questi file qualsiasi il nome che desideri. Altre definizioni di risorse, come automazioni e criteri di deployment, 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

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:
  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, le destinazioni possono essere definite 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 distribuzione o in un file separato.

  • Definizioni di automazione

    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 creare come quanti ne 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. Annotazioni vengono archiviate insieme alla risorsa della pipeline di distribuzione dopo 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. Questo la stanza è obbligatoria.

stages

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

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 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 attiva la verifica del deployment sul target. In caso contrario viene specificata la strategia di deployment, viene utilizzata la strategia di deployment standard, con 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 usando un solo 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, il deployment progressivo di una nuova versione dell'applicazione, sostituendo per incrementi in percentuale (ad esempio, 25%, 50%, 75% e poi 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 (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 uno standard la tua strategia di deployment.

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 Target GKE o GKE Enterprise, utilizzando 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 Target GKE o GKE Enterprise, utilizzando API Gateway:

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

Nota in questo esempio routeUpdateWaitTime Questo 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. Nella poiché il traffico viene inviato alle risorse, le richieste di questo tipo possono essere ignorate, che non sono disponibili. Puoi usare routeUpdateWaitTime per causare Cloud Deploy attende dopo l'applicazione di HTTPRoute modifiche, se osservare questo ritardo.

Il seguente file YAML mostra come configurare una strategia di deployment canary personalizzata o personalizzata-automatica. configurazione specifica per il runtime, Sezione runtimeConfig, omessa per la versione canary personalizzata, ma inclusa nella una 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

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, esiste 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 saperne di più sulla configurazione e sull'uso 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 ma devono essere univoci all'interno di una pipeline di distribuzione.

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 le destinazioni GKE

Il seguente YAML mostra come configurare una destinazione 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. Questo nome deve essere univoco a livello globale.

metadata.annotations e metadata.labels

La configurazione di destinazione supporta annotazioni ed etichette Kubernetes. ma Cloud Deploy non li 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 di questo target.

deployParameters

Puoi includere parametri di implementazione in qualsiasi target, insieme ai valori. Questi valori vengono assegnati alle chiavi corrispondenti 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 questi multiTarget proprietà.

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 in cui verrà eseguito il deployment della tua 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 viene visualizzato nell'elenco dei cluster in 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 è configurato invece all'interno target secondario.

Per le descrizioni, consulta executionConfigs in questo articolo. delle proprietà dell'ambiente di esecuzione.

internalIp

Indica se il cluster GKE specificato utilizza o meno un indirizzo IP privato. Questa proprietà è facoltativa. Per impostazione predefinita, Cloud Deploy utilizza l'indirizzo IP disponibile pubblicamente per il cluster. Se è 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 proxy GKE cluster, ovvero passato a kubectl quando ti connetti al cluster.

Per le destinazioni Cloud Run

Il seguente YAML mostra come configurare una destinazione 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 di 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 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 ed è utilizzata per configurare una multi-target da utilizzare per 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 si troverà 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 di GKE Enterprise

Configurazione di destinazione per il deployment in un cluster GKE è simile configurando una destinazione per un target GKE, tranne 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 attributo [multi-target]. La Il cluster GKE Enterprise è configurato invece all'interno del cluster target secondario.

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

Per target personalizzati

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

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, più PREDEPLOY, VERIFY oppure POSTDEPLOY se verifica o gli hook di deployment sono abilitati nella destinazione. che indicano quale di queste operazioni eseguire per questo target utilizzando questa dell'ambiente di esecuzione. Per indicare che un ambiente di esecuzione personalizzato deve essere utilizzato per l'hook predeploy, il rendering, il deployment, l'hook postdeploy 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 predeployment e postdeployment funzionano allo stesso modo.

    Tuttavia, se esiste un ambiente di esecuzione personalizzato per RENDER e DEPLOY, devi specificarne uno per VERIFY, PREDEPLOY O POSTDEPLOY se sono nella pipeline di distribuzione.VERIFY, PREDEPLOY e POSTDEPLOY può essere 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 vengano specificati nella stessa riga ambienti di esecuzione.

  • 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 quanto segue strumenti:

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

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

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

di Gemini Advanced.

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 è il customAction.name definita in skaffold.yaml.

  • [DEPLOY_ACTION_NAME]

    È il nome dell'azione di deployment personalizzata. Questo valore è il 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 i deployment di Cloud Deploy di automazione.

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 a seconda della regola. (configurazione per tipi di regole di automazione sono nel documento Utilizzo delle regole di automazione.)

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

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

Dove:

  • [PIPELINE_NAME]

    È uguale al valore metadata.name nella pipeline di importazione che utilizza questa automazione. Tutte le automazioni sono esclusive delle pipeline di distribuzione con cui vengono create. Ciò significa che non puoi condividere un'automazione tra più di una pipeline di distribuzione.

  • [PURPOSE]

    È un nome aggiuntivo descrittivo per questa automazione. In genere si tratta di l'azione automatizzata. 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 la 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:

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

    • l'autorizzazione per eseguire l'operazione automatica, ad esempio clouddeploy.releases.promote promuovere una release o clouddeploy.rollouts.advance per far avanzare un'implementazione durante la fase di sviluppo.

  • [TARGET_ID]

    È l'ID del target per cui viene utilizzata l'automazione. Anche se un'automazione è associata a una pipeline di importazione, viene eseguita solo sul target o sui target specificati.

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

  • [LABEL_KEY]:[LABEL_VALUE]

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

  • [RULE_TYPE]

    È il nome della regola di automazione utilizzata per questa automazione. Questo è promoteReleaseRule, advanceRolloutRule o repairRolloutRule. Puoi includere più di una regola in un'automazione, inclusa più di una stessa RULE_TYPE. Ad esempio, puoi avere più di un 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 descritte in Utilizzare le regole di automazione.

Esegui il deployment delle definizioni dei criteri (anteprima)

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

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

Il seguente 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 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. Questo nome viene utilizzato come nome visualizzato nella console Google Cloud.

  • [ANNOTATIONS] e [LABELS]

    I criteri possono includere annotazioni ed etichette, che fanno parte del criterio dopo la creazione. Per ulteriori informazioni, consulta Utilizzare annotazioni ed etichette con Cloud Deploy.

  • suspended: [true | false]

    Se il criterio suspended viene impostato 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 del target su cui vuoi che venga applicato questo criterio. Puoi utilizzare * per indicano tutti i target. Questo ID corrisponde alla proprietà metadata.name sul target.

  • [LABEL_KEY]:[LABEL_VALUE]

    È una coppia chiave-valore da abbinare a una coppia chiave-valore definita al momento della pubblicazione una pipeline o un target. Vengono selezionate tutte le pipeline o tutte le destinazioni che hanno lo stesso l'etichetta e il 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 è in fase di creazione. La configurazione delle regole è descritta più avanti in questa sezione di questo documento di riferimento, per ciascuna delle regole disponibili.

Esegui il deployment delle regole dei criteri

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

rolloutRestriction

La regola rolloutRestriction impedisce l'esecuzione di Cloud Deploy alcune operazioni sulle implementazioni durante la finestra o le finestre temporali specificate per le pipeline di distribuzione e i target indicato 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, 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

      Impossibile creare le implementazioni.

    • IGNORE_JOB

      I job non possono essere ignorati.

    • RETRY_JOB

      Non è possibile ritentare i job.

    • ROLLBACK

      Non è possibile eseguire il rollback delle implementazioni.

    • TERMINATE_JOBRUN

      Le esecuzioni dei job non possono essere interrotte

  • INVOKERS

    La specifica degli invocatori filtra l'applicazione dei criteri a seconda che l'azione limitata sia stata invocata da un utente o da un'automazione di deployment. Valido 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 indichi la finestra temporale. Ad esempio, America/New_York. Campo obbligatorio.

  • START_DATE_TIME

    Per oneTimeWindows, la data e l'ora che indicano l'inizio del finestra delle limitazioni, 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 limitazione nel formato "yyyy-mm-dd hh:mm". A fine giornata, usa 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 un'ora di fine. All'inizio giorno, utilizza 00:00.

  • END_TIME

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

Passaggi successivi