Referenz zum Konfigurationsschema

Die Cloud Deploy-Konfigurationsdatei(en) definieren die Bereitstellungspipeline, die Ziele für die Bereitstellung und den Fortschritt dieser Ziele.

Die Konfigurationsdatei der Bereitstellungspipeline kann Zieldefinitionen enthalten oder sich in einer separaten Datei bzw. Dateien befinden. Konventionsgemäß wird eine Datei, die sowohl die Konfiguration der Bereitstellungspipeline als auch die Zielkonfigurationen enthält, clouddeploy.yaml und eine Pipelinekonfiguration ohne Ziele als delivery-pipeline.yaml bezeichnet. Sie können diesen Dateien aber einen beliebigen Namen geben.

Aufbau

Cloud Deploy verwendet zwei Hauptkonfigurationsdateien:

Dies können separate Dateien sein oder die Bereitstellungspipeline und Ziele können in derselben Datei konfiguriert werden.

Struktur einer Konfigurationsdatei für eine Lieferpipeline.

Die folgende Konfiguration enthält eine Zieldefinition:

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

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

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

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

Dieser YAML-Code besteht aus drei Hauptkomponenten:

  • Hauptlieferpipeline und Fortschritt

    Die Konfigurationsdatei kann eine beliebige Anzahl an Pipelinedefinitionen enthalten.

  • Die Zieldefinitionen

    Der Einfachheit halber wird in diesem Beispiel nur ein Ziel gezeigt, aber es kann eine beliebige Anzahl von Zielen geben. Außerdem können Ziele in einer oder mehreren separaten Dateien definiert werden.

  • Definitionen benutzerdefinierter Zieltypen

    Für benutzerdefinierte Ziele ist eine benutzerdefinierte Zieltypdefinition erforderlich. Wie Ziele und Automatisierungen können benutzerdefinierte Zieltypen in derselben Datei wie die Bereitstellungspipeline oder in einer separaten Datei definiert werden.

  • Automatisierungsdefinitionen

    Sie können beliebige Bereitstellungsautomatisierungen in derselben Datei wie Ihre Bereitstellungspipeline und ‐ziele oder in einer oder mehreren separaten Dateien erstellen. Der Einfachheit halber wird hier nur ein Automation angezeigt. Sie können jedoch beliebig viele erstellen.

Diese Komponenten werden im weiteren Verlauf dieses Dokuments definiert.

Pipelinedefinition und -fortschritt

Zusätzlich zu Pipeline-Metadaten wie name enthält die Hauptpipeline-Definition eine Liste von Verweisen auf Ziele in der Reihenfolge der Bereitstellungssequenz. Das bedeutet, dass das erste aufgeführte Ziel das erste Bereitstellungsziel ist. Nach der Bereitstellung für dieses Ziel wird der Release für das nächste Ziel in der Liste hochgestuft.

Im Folgenden sind die Konfigurationsattribute für eine Bereitstellungspipeline ohne Zieldefinitionen aufgeführt.

metadata.name

Das name-Feld verwendet einen String, der pro Projekt und Standort einmalig sein muss.

metadata.annotations und metadata.labels

Die Konfiguration der Lieferpipeline kann Annotationen und Labels enthalten. Annotationen und Labels werden mit der Ressource der Lieferpipeline gespeichert, nachdem die Pipeline registriert wurde.

Weitere Informationen finden Sie unter Labels und Annotationen mit Cloud Deploy verwenden.

description

Beliebiger String, der diese Lieferpipeline beschreibt. Diese Beschreibung wird in den Details zur Bereitstellungspipeline in der Google Cloud Console angezeigt.

suspended

Ein boolescher Wert, der, wenn true die Bereitstellungspipeline sperrt, sodass er nicht zum Erstellen, Hochstufen, Rollback oder erneutes Bereitstellen von Releases verwendet werden kann. Außerdem können Sie ein Rollout, das aus dieser Pipeline erstellt wurde, nicht genehmigen oder ablehnen, wenn die Bereitstellungspipeline ausgesetzt ist.

Der Standardwert ist false.

serialPipeline

Der Anfang der Definition einer Pipeline für die serielle Bereitstellung. Diese Stanza ist erforderlich.

stages

Liste aller Ziele, für die diese Lieferpipeline konfiguriert wurde.

Die Liste muss in der gewünschten Reihenfolge der Auslieferung angeordnet sein. Beispiel: Wenn Sie Ziele mit den Namen dev, staging und production haben, listen Sie diese in dieser Reihenfolge auf, damit Ihre erste Bereitstellung für dev und Ihre letzte Bereitstellung für production erfolgt.

Füllen Sie jedes stages.targetId-Feld mit dem Wert des Felds metadata.name in der entsprechenden Zieldefinition. Fügen Sie unter targetId Folgendes hinzu: profiles:

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

targetId

Gibt das spezifische Ziel an, das für diese Phase der Lieferpipeline verwendet werden soll. Der Wert ist das metadata.name-Attribut aus der Zieldefinition.

Wenn strategy.standard.verify auf true gesetzt ist, wird die Bereitstellungsprüfung für das Ziel aktiviert. Wenn keine Bereitstellungsstrategie angegeben ist, wird die Bereitstellungsstrategie standard verwendet, wobei die Überprüfung auf false gesetzt ist.

profiles

Ruft eine Liste mit null oder mehr Skaffold-Profilnamen aus skaffold.yaml auf. Cloud Deploy verwendet beim Erstellen des Release das Profil mit skaffold render. Mit Skaffold-Profilen können Sie die Konfiguration zwischen Zielen unter Verwendung einer einzigen Konfigurationsdatei variieren.

strategy

Enthält Attribute zum Angeben einer Bereitstellungsstrategie. Die folgenden Strategien werden unterstützt:

  • standard:

    Die Anwendung wird vollständig auf dem angegebenen Ziel bereitgestellt.

    Dies ist die Standardbereitstellungsstrategie. Wenn Sie strategy weglassen, verwendet Cloud Deploy die Bereitstellungsstrategie standard.

  • canary:

    Bei einem Canary-Deployment stellen Sie schrittweise eine neue Version Ihrer Anwendung bereit. Dabei wird die bereits ausgeführte Version prozentual ersetzt (z. B. 25%, dann 50%, dann 75 % und dann vollständig).

Die Bereitstellungsstrategie wird pro Ziel definiert. Angenommen, Sie haben eine Canary-Strategie für das prod-Ziel und eine Standardstrategie (ohne strategy angegeben) für die anderen Ziele.

Weitere Informationen finden Sie unter Bereitstellungsstrategie verwenden.

strategy Konfiguration

Dieser Abschnitt enthält die Konfigurationselemente für strategy für jede unterstützte Laufzeit.

Standardbereitstellungsstrategie

Die Standardstrategie umfasst nur die folgenden Elemente:

strategy:
  standard:
    verify: true|false

Das Attribut verify ist optional. Der Standardwert ist false, was bedeutet, dass es keine Überprüfungsphase für die resultierenden Roll-outs gibt.

Für eine Standardbereitstellungsstrategie können Sie das Element strategy weglassen.

Canary-Bereitstellungsstrategie

In den folgenden Abschnitten wird die Konfiguration einer Canary-Deployment-Strategie für jede von Cloud Deploy unterstützte Laufzeit beschrieben.

Für Cloud Run-Ziele
strategy:
  canary:
    runtimeConfig:
      cloudRun:
        automaticTrafficControl: true | false
    canaryDeployment:
      percentages: [PERCENTAGES]
      verify: true | false
Für GKE- und GKE Enterprise-Ziele

Die folgende YAML-Datei zeigt, wie Sie eine Bereitstellungsstrategie für ein GKE- oder GKE Enterprise-Ziel mithilfe eines dienstbasierten Netzwerks konfigurieren:

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

Die folgende YAML-Datei zeigt, wie Sie mithilfe der Gateway API eine Bereitstellungsstrategie für ein GKE- oder GKE Enterprise-Ziel konfigurieren:

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

Beachten Sie in diesem Beispiel routeUpdateWaitTime. Dies ist enthalten, da die Gateway API den Traffic mithilfe einer HTTPRoute-Ressource aufteilt und es manchmal zu einer Verzögerung bei der Weitergabe von Änderungen an HTTPRoute kommt. In solchen Fällen können Anfragen gelöscht werden, da der Traffic an nicht verfügbare Ressourcen gesendet wird. Sie können routeUpdateWaitTime verwenden, damit Cloud Deploy nach dem Anwenden von HTTPRoute-Änderungen wartet, wenn Sie diese Verzögerung beobachten.

Die folgende YAML-Datei zeigt, wie Sie eine benutzerdefinierte oder benutzerdefinierte automatisierte Canary-Bereitstellungsstrategie konfigurieren. Die laufzeitspezifische Konfiguration im Abschnitt runtimeConfig wird für benutzerdefinierte Canary-Tests weggelassen, ist aber in der automatisierten und benutzerdefinierten automatisierten Canary-Konfiguration enthalten.

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

Optionaler boolescher Wert, der angibt, ob die Bereitstellungsüberprüfung für dieses Ziel unterstützt werden soll. Der Standardwert ist false.

Für die Aktivierung der Deployment-Überprüfung ist außerdem eine verify-Stanza im skaffold.yaml erforderlich. Wenn Sie diese Eigenschaft nicht angeben, schlägt der Überprüfungsjob fehl.

deployParameters

Bei Verwendung von Bereitstellungsparametern können Sie Schlüssel/Wert-Paare angeben, um für Ziele mit Labelübereinstimmung Werte an Manifeste zu übergeben.

Sie können dies auch in Ziele einbeziehen.

Bereitstellungsparameter, die in einer Bereitstellungspipeline festgelegt wurden, verwenden Labels, um Ziele abzugleichen:

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

In diesem Beispiel werden zwei Werte für den Schlüssel angegeben und für jeden Wert gibt es ein Label. Der Wert wird für jedes Ziel mit einem übereinstimmenden Label auf das Manifest angewendet.

predeploy- und postdeploy-Jobs

Damit können Sie auf benutzerdefinierte Aktionen (separat definiert in skaffold.yaml) verweisen, die vor dem Bereitstellungsjob (predeploy) und ggf. nach dem Überprüfungsjob (postdeploy) ausgeführt werden. Wenn kein Überprüfungsjob vorhanden ist, wird der Post-Bereitstellungsjob ausgeführt.

Bereitstellungs-Hooks werden unter strategy.standard oder strategy.canary so konfiguriert:

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

Dabei ist ACTION_NAME der in skaffold.yaml für customActions.name konfigurierte Name.

Sie können Jobs vom Typ predeploy und postdeploy mit jeder Strategie konfigurieren (z. B. standard, canary).

Weitere Informationen zum Konfigurieren und Verwenden von Hooks vor und nach der Bereitstellung finden Sie unter Hooks vor und nach der Bereitstellung ausführen.

Zieldefinitionen

Die Definitionsdatei der Lieferpipeline kann Zieldefinitionen enthalten. Alternativ können Sie Ziele in einer separaten Datei angeben. Sie können Zielnamen innerhalb eines Projekts wiederholen, diese müssen aber innerhalb einer Lieferpipeline einmalig sein.

Sie können Ziele in mehreren Lieferpipelines wiederverwenden. Sie können jedoch nur einmal innerhalb einer einzelnen Lieferpipeline auf ein Ziel verweisen.

Weitere Informationen finden Sie unter Definitionen benutzerdefinierter Zieltypen.

Für GKE-Ziele

Die folgende YAML-Datei zeigt, wie ein Ziel konfiguriert wird, das in einem GKE-Cluster bereitgestellt wird:

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

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

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

metadata.name

Der Name dieses Ziels. Dieser Name muss global eindeutig sein.

metadata.annotations und metadata.labels

Die Zielkonfiguration unterstützt Kubernetes-Annotationen und Labels, sie sind jedoch für Cloud Deploy nicht erforderlich.

Annotationen und Labels werden mit der Zielressource gespeichert. Weitere Informationen finden Sie unter Labels und Annotationen mit Cloud Deploy verwenden.

description

Dieses Feld verwendet einen beliebigen String, der die Verwendung des Ziels beschreibt.

deployParameters

Sie können in jedem Ziel Bereitstellungsparameter zusammen mit Werten hinzufügen. Diese Werte werden nach dem Rendern den entsprechenden Schlüsseln im Manifest zugewiesen.

Die Stanza deployParameters nimmt Schlüssel/Wert-Paare an, wie hier gezeigt:

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

Wenn Sie Bereitstellungsparameter für ein multi-target festlegen, wird der Wert für alle untergeordneten Ziele dieses Multi-Ziels dem Manifest zugewiesen.

multiTarget.targetIds: []

Dieses Attribut ist optional und wird verwendet, um ein multi-target für die parallele Bereitstellung zu konfigurieren.

Der Wert ist eine durch Kommas getrennte Liste untergeordneter Ziele. Untergeordnete Ziele sind als normale Ziele konfiguriert und enthalten nicht das Attribut multiTarget.

requireApproval

Gibt an, ob das Hochstufen auf dieses Ziel manuell genehmigt werden muss. Kann true oder false sein.

Dieses Attribut ist optional. Der Standardwert ist false.

Wenn Sie die parallele Bereitstellung konfigurieren, können Sie eine Genehmigung nur für das Multi-Ziel und nicht für untergeordnete Ziele anfordern.

gke

Nur für GKE-Cluster der Ressourcenpfad, der den Cluster identifiziert, in dem Ihre Anwendung bereitgestellt wird:

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

    Das Google Cloud-Projekt, in dem sich der Cluster befindet.

  • location

    Der Standort, an dem sich der Cluster befindet. Beispiel: us-central1. Der Cluster kann auch zonal sein (us-central1-c).

  • cluster_name

    Der Name des Clusters, wie er in der Liste der Cluster in der Google Cloud Console angezeigt wird.

Beispiel:

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

Lassen Sie das Attribut gke weg, wenn Sie ein multi-target konfigurieren. Der GKE-Cluster wird stattdessen innerhalb des entsprechenden untergeordneten Ziels konfiguriert.

Unter executionConfigs in diesem Artikel finden Sie Beschreibungen der Attribute der Ausführungsumgebung.

internalIp

Gibt an, ob der angegebene GKE-Cluster eine private IP-Adresse verwendet. Dieses Attribut ist optional. Cloud Deploy verwendet standardmäßig die öffentlich verfügbare IP-Adresse für den Cluster. Wenn eine private IP-Adresse vorhanden ist und Sie diese verwenden möchten, legen Sie dafür true fest.

Für Cloud Run-Ziele

Die folgende YAML-Datei zeigt, wie ein Ziel konfiguriert wird, das in einem Cloud Run-Dienst bereitgestellt wird:

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

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

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

metadata.name

Der Name dieses Ziels. Dieser Name darf für jede Region nur einmal vorkommen.

metadata.annotations und metadata.labels

Die Zielkonfiguration unterstützt Annotationen und Labels, diese sind jedoch für Cloud Deploy nicht erforderlich.

Annotationen und Labels werden mit der Zielressource gespeichert. Weitere Informationen finden Sie unter Labels und Annotationen mit Cloud Deploy verwenden.

description

Dieses Feld verwendet einen beliebigen String, der die Verwendung des Ziels beschreibt.

multiTarget.targetIds: []

Dieses Attribut ist optional und wird verwendet, um ein multi-target für die parallele Bereitstellung zu konfigurieren.

Der Wert ist eine durch Kommas getrennte Liste untergeordneter Ziele. Untergeordnete Ziele sind als normale Ziele konfiguriert und enthalten nicht das Attribut multiTarget.

requireApproval

Gibt an, ob das Hochstufen auf dieses Ziel manuell genehmigt werden muss. Kann true oder false sein.

Dieses Attribut ist optional. Der Standardwert ist false.

Wenn Sie die parallele Bereitstellung konfigurieren, können Sie eine Genehmigung nur für das Multi-Ziel und nicht für untergeordnete Ziele anfordern.

run

Der Standort, an dem der Dienst erstellt wird (nur für Cloud Run-Dienste):

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

    Das Google Cloud-Projekt, in dem der Dienst ausgeführt wird.

  • location

    Der Standort, an dem sich der Dienst befindet. Beispiel: us-central1.

Lassen Sie das Attribut run weg, wenn Sie ein [Multi-Ziel] konfigurieren. Der Speicherort des Cloud Run-Dienstes wird stattdessen im entsprechenden untergeordneten Ziel konfiguriert.

Unter executionConfigs in diesem Artikel finden Sie Beschreibungen der Attribute der Ausführungsumgebung.

Für GKE Enterprise-Ziele

Die Zielkonfiguration für die Bereitstellung in einem GKE-Cluster ähnelt der Konfiguration eines Ziels für ein GKE-Ziel, mit der Ausnahme, dass das Attribut anthosCluster.membership anstelle von gke.cluster ist, der Ressourcenpfad anders ist und internalIp nicht anwendbar ist.

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

    Das Google Cloud-Projekt, in dem sich der GKE Enterprise-Cluster befindet.

  • /location/global/

    Der Standort, an dem der Cluster registriert ist. global, in allen Fällen.

  • membership_name

    Der Name der GKE Enterprise-Clustermitgliedschaft.

Beispiel:

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

Lassen Sie das Attribut anthosCluster weg, wenn Sie ein [Multi-Ziel] konfigurieren. Der GKE Enterprise-Cluster wird stattdessen innerhalb des entsprechenden untergeordneten Ziels konfiguriert.

Weitere Informationen zum Bereitstellen in GKE-Clustern finden Sie unter In Anthos-Nutzerclustern bereitstellen.

Für benutzerdefinierte Ziele

Die Konfiguration für benutzerdefinierte Ziele ähnelt allen anderen Zieltypen, mit der Ausnahme, dass sie weder eine gke-Stanza noch eine run- oder anthosCluster-Stanza enthält.

Stattdessen enthalten benutzerdefinierte Ziele eine customTarget-Stanza:

customTarget:
  customTargetType: [CUSTOM_TARGET_TYPE_NAME]

Dabei ist CUSTOM_TARGET_TYPE_NAME der Name, den Sie in der Definition des benutzerdefinierten Zieltyps verwendet haben.

Beispiel:

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

executionConfigs

Eine Reihe von Feldern, um eine nicht standardmäßige Ausführungsumgebung für dieses Ziel anzugeben.

  • usages

    Entweder RENDER oder DEPLOY oder beides sowie PREDEPLOY, VERIFY oder POSTDEPLOY, wenn die Überprüfung oder Bereitstellungs-Hooks für das Ziel aktiviert sind. Sie geben an, welche der Vorgänge für dieses Ziel in der Ausführungsumgebung ausgeführt werden sollen. Wenn Sie angeben möchten, dass eine benutzerdefinierte Ausführungsumgebung für den Hook, das Rendering, die Bereitstellung, den Postdeploy-Hook und die Überprüfung vor der Bereitstellung und für die Überprüfung verwendet werden soll, konfigurieren Sie diese wie folgt:

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

    Wenn die Überprüfung in der Pipelinephase aktiviert ist und Sie VERIFY nicht in einer usages-Stanza angeben, verwendet Cloud Deploy die standardmäßige Ausführungsumgebung zur Überprüfung. Die Hooks „Predeploy“ und „postdeploy“ funktionieren auf die gleiche Weise.

    Wenn jedoch eine benutzerdefinierte Ausführungsumgebung für RENDER und DEPLOY vorhanden ist, müssen Sie eine für VERIFY, PREDEPLOY ODER POSTDEPLOY angeben, wenn sie in der Bereitstellungspipeline konfiguriert sind.VERIFY, PREDEPLOY und POSTDEPLOY können sich im selben usages wie RENDER oder DEPLOY oder in einer separaten usages befinden.

    Sie können usages.VERIFY, usages.PREDEPLOY oder usages.POSTDEPLOY nur dann angeben, wenn RENDER und DEPLOY in derselben oder in separaten benutzerdefinierten Ausführungsumgebungen angegeben sind.

  • workerPool

    Konfiguration für den zu verwendenden Worker-Pool. Dabei wird ein Ressourcenpfad angegeben, der den Cloud Build-Worker-Pool identifiziert, der für dieses Ziel verwendet werden soll. Beispiel:

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

    Wenn Sie den Cloud Build-Standardpool verwenden möchten, lassen Sie dieses Attribut weg.

    Ein bestimmtes Ziel kann zwei workerPools haben (eine für RENDER und eine für DEPLOY). Wenn Sie den Standardpool konfigurieren, können Sie ein alternatives Dienstkonto, einen alternativen Speicherort oder beides angeben.

  • serviceAccount

    Name des Dienstkontos, das für diesen Vorgang verwendet werden soll (RENDER oder DEPLOY) für dieses Ziel.

  • artifactStorage

    Der Cloud Storage-Bucket, der für diesen Vorgang verwendet werden soll (RENDER oder DEPLOY) für dieses Ziel anstelle des Standard-Buckets.

  • executionTimeout

    Optional. Legt das Zeitlimit in Sekunden für Vorgänge fest, die Cloud Build für Cloud Deploy ausführt. Standardmäßig beträgt dies 3600 Sekunden (1 Stunde).
    Beispiel: executionTimeout: "5000s"

Alternative unterstützte Syntax

Die in diesem Dokument beschriebene executionConfigs-Konfiguration ist neu. Die vorherige Syntax wird weiterhin unterstützt:

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

Wenn Sie eine executionConfigs-Stanza für ein multi-target konfigurieren, kann jedes untergeordnete Ziel diese Ausführungsumgebung von diesem Multi-Ziel übernehmen.

Definitionen benutzerdefinierter Zieltypen

In diesem Abschnitt werden die Felder beschrieben, die zum Definieren von benutzerdefinierten Zieltypen verwendet werden.

Wie bei Standardzielen und Automatisierungen können CustomTargetType-Definitionen in die Definition der Bereitstellungspipeline oder in einer oder mehreren separaten Dateien aufgenommen werden.

Die folgende YAML-Datei zeigt, wie ein benutzerdefinierter Zieltyp konfiguriert wird:

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:

Wobei:

  • [CUSTOM_TARGET_TYPE_NAME]

    Ist ein beliebiger Name, den Sie dieser benutzerdefinierten Zieltypdefinition geben. Auf diesen Namen wird in der Zieldefinition für jedes Ziel verwiesen, das den von Ihnen definierten benutzerdefinierten Zieltyp verwendet.

  • [RENDER_ACTION_NAME]

    Ist der Name der benutzerdefinierten Renderingaktion. Dieser Wert ist der in skaffold.yaml definierte customAction.name.

  • [DEPLOY_ACTION_NAME]

    Ist der Name der benutzerdefinierten Bereitstellungsaktion. Dieser Wert ist der in skaffold.yaml definierte customAction.name.

  • Informationen zu includeSkaffoldModules finden Sie unter Remote-Saffold-Konfigurationen verwenden.

Automatisierungsdefinitionen

In diesem Abschnitt werden die Felder beschrieben, die zum Definieren der Cloud Deploy-Ressourcen zur Automatisierung verwendet werden.

Wie bei Zielen können Automation-Definitionen in die Definition der Bereitstellungspipeline oder in einer oder mehreren separaten Dateien aufgenommen werden.

Weitere Informationen zur Automatisierung in Cloud Deploy finden Sie in der Dokumentation zur Automatisierung.

Die folgende YAML-Datei zeigt, wie eine Automatisierung konfiguriert wird. Beachten Sie, dass sich die Details einer Automatisierungsregel je nach Regel unterscheiden. Informationen zur Konfiguration der verfügbaren Regeltypen für die Automatisierung finden Sie im Dokument Automatisierungsregeln verwenden.

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:
- target:
    id: [TARGET_ID]
    #or
    labels: `[LABEL_KEY]:[LABEL_VALUE]`
rules:
- [RULE_TYPE]:
    name:[RULE_NAME]
  [RULE-SPECIFIC_CONFIG]

Wobei:

  • [PIPELINE_NAME]

    Ist mit dem Wert metadata.name in der Bereitstellungspipeline identisch, die diese Automatisierung verwendet. Alle Automatisierungen sind exklusiv für die Bereitstellungspipelines verfügbar, für die sie erstellt werden. Das heißt, Sie können eine Automatisierung nicht für mehr als eine Bereitstellungspipeline freigeben.

  • [PURPOSE]

    Ist ein anderer aussagekräftiger Name für diese Automatisierung? Üblicherweise ist dies eine automatisierte Aktion. Beispiel: my-app-pipeline/promote.

  • labels und annotations sind alle Labels oder Anmerkungen, die Sie dieser Automatisierung zuordnen möchten.

  • [DESCRIPTION]

    Ist eine optionale Beschreibung für diese Automatisierung.

  • suspended

    true oder false, was angibt, ob diese Automatisierung aktiv oder ausgesetzt ist. Ist die Richtlinie auf true gesetzt, wird die Automatisierung nicht verwendet. Dies kann nützlich sein, um eine Automatisierung zu testen, ohne die Bereitstellungspipeline zu beeinträchtigen.

  • [SERVICE_ACCOUNT_ID]

    Ist die ID des Dienstkontos, das zum Ausführen der Automatisierung verwendet wird. Wenn die Automatisierung beispielsweise promoteRelease lautet, führt dieses Dienstkonto das Hochstufen des Release durch und benötigt daher die Berechtigungen, die zum Hochstufen eines Release erforderlich sind.

    Für diese Property ist ein Wert erforderlich. Cloud Deploy verwendet nicht das Standarddienstkonto für Automatisierungen.

    Dieses Dienstkonto muss die folgenden Berechtigungen haben:

    • actAs-Berechtigung, um die Identität des Ausführungsdienstkontos zu übernehmen.

    • Berechtigung zum Ausführen des automatisierten Vorgangs, z. B. clouddeploy.releases.promote zum Hochstufen eines Release oder clouddeploy.rollouts.advance zum Fortsetzen einer Rollout-Phase.

  • [TARGET_ID]

    Ist die ID des oder der Ziele, für die diese Automatisierung verwendet wird. Obwohl eine Automatisierung an eine Bereitstellungspipeline gebunden ist, wird sie nur für die angegebenen Ziele ausgeführt.

  • [LABEL_KEY]:[LABEL_VALUE]

    Ist ein Schlüssel/Wert-Paar, das mit einem für das Ziel definierten Schlüssel/Wert-Paar abgeglichen wird. Dadurch werden alle mit der Bereitstellungspipeline verknüpften Ziele ausgewählt, die dasselbe Label und denselben Wert haben.

  • [RULE_TYPE]

    Der Name der Automatisierungsregel, die für diese Automatisierung verwendet wird. Dies ist entweder promoteRelease oder advanceRollout. Sie können mehrere Regeln in eine Automatisierung einbeziehen, einschließlich mehrerer Regeln desselben RULE_TYPE. Sie können beispielsweise mehrere promoteRelease-Regeln in derselben Automatisierung verwenden. Weitere Informationen

  • [RULE_NAME]

    Ein Name für die Regel. Dieser Name darf innerhalb der Bereitstellungspipeline nur einmal vorkommen. Für diese Property ist ein Wert erforderlich.

  • [RULE-SPECIFIC_CONFIG]

    Die Konfiguration ist für jeden unterstützten Automatisierungstyp unterschiedlich. Diese Konfigurationen werden unter Automatisierungsregeln verwenden beschrieben.

Nächste Schritte