Referenz zum Konfigurationsschema

Die Cloud Deploy-Konfigurationsdatei oder ‑dateien definieren die Bereitstellungspipeline, die Ziele der Bereitstellung und den Fortschritt in der Sequenz dieser Ziele.

Die Konfigurationsdatei der Bereitstellungspipeline kann Zieldefinitionen enthalten. Alternativ können diese in einer separaten Datei oder in separaten Dateien enthalten sein. Konventionsgemäß heißt eine Datei, die sowohl die Pipeline-Konfiguration der Zustellung als auch die Zielkonfigurationen enthält, clouddeploy.yaml; eine Pipeline-Konfiguration ohne Ziele heißt delivery-pipeline.yaml. Sie können diesen Dateien jedoch einen beliebigen Namen geben. Andere Ressourcendefinitionen wie Automatisierungen und Bereitstellungsrichtlinien können sich auch in derselben Datei wie eine Lieferpipeline oder Zieldefinition befinden.

Aufbau

Cloud Deploy verwendet zwei Hauptkonfigurationsdateien:

Dabei kann es sich um separate Dateien handeln oder die Bereitstellungspipeline und die Ziele können in derselben Datei konfiguriert werden.

Struktur einer Konfigurationsdatei für eine Lieferpipeline.

Im Folgenden finden Sie die Struktur einer Lieferpipeline-Konfiguration, einschließlich Properties für Zieldefinitionen. Einige Ziel-Properties sind hier nicht enthalten. Alle Zielkonfigurationseigenschaften finden Sie unter Zieldefinitionen.

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

Diese YAML-Datei besteht aus drei Hauptkomponenten:

  • Hauptlieferpipeline und Fortschritt

    Die Konfigurationsdatei kann eine beliebige Anzahl an Pipelinedefinitionen enthalten.

  • Zieldefinitionen

    Der Einfachheit halber ist in diesem Beispiel nur ein Ziel zu sehen. Es kann aber beliebig viele geben. Ziele können auch in einer separaten Datei oder in separaten Dateien definiert werden.

  • Definitionen für benutzerdefinierte Zieltypen

    Für benutzerdefinierte Ziele ist eine Definition des benutzerdefinierten Zieltyps erforderlich. Wie bei Zielen und Automatisierungen können benutzerdefinierte Zieltypen in derselben Datei wie die Bereitstellungspipeline oder in einer separaten Datei definiert werden.

  • Automatisierungsdefinitionen

    Sie können Bereitstellungsautomatisierungen in derselben Datei wie die Lieferpipeline und die Ziele oder in einer separaten Datei bzw. in separaten Dateien erstellen. Zur Vereinfachung wird hier nur eine Automation angezeigt. Sie können aber beliebig viele erstellen.

Diese Komponenten werden im Rest dieses Dokuments definiert.

Pipelinedefinition und -fortschritt

Neben Pipeline-Metadaten wie name enthält die Hauptpipelinedefinition eine Liste mit Verweisen auf Ziele in der Reihenfolge der Bereitstellungssequenz. Das erste aufgeführte Ziel ist also das erste Bereitstellungsziel. Nachdem Sie die Bereitstellung auf dieses Ziel ausgeführt haben, wird der Release durch Hochstufen auf das nächste Ziel in der Liste bereitgestellt.

Im Folgenden finden Sie die Konfigurationseigenschaften für eine Bereitstellungspipeline, ohne Zieldefinitionen.

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 Anmerkungen mit Cloud Deploy verwenden.

description

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

suspended

Ein boolescher Wert, der bei true die Bereitstellungspipeline pausiert, sodass damit keine Releases mehr erstellt, hochgestuft, rückgängig gemacht oder neu bereitgestellt werden können. Wenn die Bereitstellungspipeline ausgesetzt ist, können Sie auch keine über diese Pipeline erstellten Roll-outs genehmigen oder ablehnen.

Der Standardwert ist false.

serialPipeline

Der Beginn der Definition einer Lieferpipeline mit serieller Abfolge. Diese Strophe 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.

Geben Sie in jedem Feld stages.targetId den Wert des Felds metadata.name in der entsprechenden Zieldefinition ein. Geben Sie unter targetId profiles an:

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 Bereitstellungsüberprüfung auf dem Ziel aktiviert. Wenn keine Bereitstellungsstrategie angegeben ist, wird die Bereitstellungsstrategie standard verwendet und die Überprüfung auf false festgelegt.

profiles

Nimmt eine Liste mit null oder mehr Skaffold-Profilnamen aus skaffold.yaml an. Cloud Deploy verwendet das Profil mit skaffold render beim Erstellen des Release. Mit Skaffold-Profilen können Sie die Konfiguration für verschiedene Ziele variieren, während Sie nur eine Konfigurationsdatei verwenden.

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 Standard-Bereitstellungsstrategie. Wenn Sie strategy weglassen, verwendet Cloud Deploy die Bereitstellungsstrategie standard.

  • canary:

    Bei einem Canary-Deployment stellen Sie eine neue Version Ihrer Anwendung schrittweise bereit und ersetzen die bereits laufende Version in prozentualen Schritten (z. B. 25%, dann 50%, dann 75 % und dann vollständig).

Die Bereitstellungsstrategie wird pro Ziel definiert. Beispiel: Sie haben möglicherweise eine Canary-Strategie für Ihr prod-Ziel, aber eine Standardstrategie (kein strategy angegeben) für Ihre anderen Ziele.

Weitere Informationen finden Sie unter Bereitstellungsstrategie verwenden.

strategy Konfiguration

In diesem Abschnitt werden die Konfigurationselemente für strategy für jede unterstützte Laufzeit angezeigt.

Standardbereitstellungsstrategie

Die Standardstrategie umfasst nur die folgenden Elemente:

strategy:
  standard:
    verify: true|false

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

Bei einer Standard-Bereitstellungsstrategie können Sie das Element strategy weglassen.

Canary-Bereitstellungsstrategie

In den folgenden Abschnitten wird die Konfiguration für eine Kanarienbereitstellung für jede Laufzeit beschrieben, die von Cloud Deploy unterstützt wird.

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

In der folgenden YAML-Datei wird gezeigt, wie Sie eine Bereitstellungsstrategie für ein GKE- oder GKE Enterprise-Ziel mithilfe von dienstbasiertem Networking konfigurieren:

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

Im folgenden YAML-Code wird beschrieben, wie Sie eine Bereitstellungsstrategie für ein GKE- oder GKE Enterprise-Ziel mithilfe der Gateway API konfigurieren:

      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

Beachten Sie in diesem Beispiel routeUpdateWaitTime. Das liegt daran, dass die Gateway API den Traffic mithilfe einer HTTPRoute-Ressource aufteilt und es manchmal zu einer Verzögerung bei der Weiterleitung von Änderungen an der HTTPRoute kommt. In solchen Fällen werden Anfragen möglicherweise gelöscht, weil Traffic an Ressourcen gesendet wird, die nicht verfügbar sind. Wenn Sie diese Verzögerung feststellen, können Sie mit routeUpdateWaitTime festlegen, dass Cloud Deploy nach dem Anwenden von HTTPRoute-Änderungen wartet.

In der folgenden YAML-Datei wird gezeigt, wie Sie eine benutzerdefinierte oder benutzerdefinierte automatisierte Canary-Deployment-Strategie konfigurieren. Die laufzeitspezifische Konfiguration im Abschnitt runtimeConfig wird für benutzerdefinierte Canary-Versionen weggelassen, aber in die Konfiguration für automatische und benutzerdefinierte automatische Canary-Versionen einbezogen.

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.

Wenn Sie die Bereitstellungsüberprüfung aktivieren möchten, ist außerdem eine verify-Strophe im skaffold.yaml erforderlich. Wenn Sie diese Property nicht angeben, schlägt der Bestätigungsjob fehl.

deployParameters

Sie können Schlüssel/Wert-Paare angeben, um Werte an Manifeste für über Labels abgeglichene Ziele zu übergeben, wenn Sie Bereitstellungsparameter verwenden.

Sie können diese Option auch für Zielgruppen verwenden.

Bei Bereitstellungsparametern, die für eine Bereitstellungspipeline festgelegt sind, werden Labels verwendet, um Ziele abzugleichen:

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

In diesem Beispiel sind für den Schlüssel zwei Werte und für jeden Wert ein Label angegeben. Der Wert wird auf das Manifest für alle Ziele angewendet, die ein übereinstimmendes Label haben.

predeploy- und postdeploy-Jobs

Damit können Sie auf benutzerdefinierte Aktionen verweisen, die separat in skaffold.yaml definiert wurden, um sie vor dem Bereitstellungsjob (predeploy) und nach dem Überprüfungsjob auszuführen, falls vorhanden (postdeploy). Wenn kein Überprüfungsjob vorhanden ist, wird der Job nach der Bereitstellung nach dem Bereitstellungsjob ausgeführt.

Bereitstellungshooks 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 predeploy- und postdeploy-Jobs für jede Strategie konfigurieren (z. B. standard oder canary).

Weitere Informationen zum Konfigurieren und Verwenden von Pre- und Post-Deploy-Hooks 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

Im folgenden YAML-Code wird gezeigt, 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:
      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

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

metadata.annotations und metadata.labels

Die Zielkonfiguration unterstützt Kubernetes-Anmerkungen und Labels, ist für Cloud Deploy jedoch nicht erforderlich.

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

description

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

deployParameters

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

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

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

Wenn Sie Bereitstellungsparameter für ein Multitarget festlegen, wird der Wert dem Manifest für alle untergeordneten Ziele dieses Multitargets zugewiesen.

multiTarget.targetIds: []

Diese Property ist optional und wird verwendet, um ein Multi-Target für die parallele Bereitstellung zu konfigurieren.

Der Wert ist eine durch Kommas getrennte Liste von untergeordneten Zielen. Untergeordnete Ziele werden wie normale Ziele konfiguriert und enthalten diese multiTarget-Property nicht.

requireApproval

Ob eine Hochstufung zu diesem Ziel eine manuelle Genehmigung erfordert. Kann true oder false sein.

Dieses Attribut ist optional. Der Standardwert ist false.

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

gke

Nur für GKE-Cluster: Der Ressourcenpfad, der den Cluster angibt, 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 Speicherort des Clusters. 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 die Property gke weg, wenn Sie ein Multi-Target konfigurieren. Der GKE-Cluster wird stattdessen im entsprechenden untergeordneten Ziel konfiguriert.

Beschreibungen der Eigenschaften der Ausführungsumgebung finden Sie in diesem Dokument unter executionConfigs. Informationen zum Bereitstellen der HTTPRoute in einem alternativen Cluster, der nicht das Ziel ist, finden Sie unter HTTPRoute in einem anderen Cluster bereitstellen.

internalIp

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

proxyUrl

Wenn Sie über einen Proxy auf Cluster zugreifen, geben Sie hier die proxyUrl-Eigenschaft an. Der Wert ist die URL Ihres Proxy-GKE-Clusters, die an kubectl übergeben wird, wenn eine Verbindung zum Cluster hergestellt wird.

Für Cloud Run-Ziele

In der folgenden YAML-Datei wird gezeigt, 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:
       verbose:

metadata.name

Der Name dieses Ziels. Dieser Name muss pro Region eindeutig sein.

metadata.annotations und metadata.labels

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

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

description

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

multiTarget.targetIds: []

Diese Property ist optional und wird verwendet, um ein Multi-Target für die parallele Bereitstellung zu konfigurieren.

Der Wert ist eine durch Kommas getrennte Liste von untergeordneten Zielen. Untergeordnete Ziele werden wie normale Ziele konfiguriert und enthalten diese multiTarget-Property nicht.

requireApproval

Ob eine Hochstufung zu diesem Ziel eine manuelle Genehmigung erfordert. Kann true oder false sein.

Dieses Attribut ist optional. Der Standardwert ist false.

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

run

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

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

  • project_name

    Das Google Cloud-Projekt, in dem der Dienst bereitgestellt wird.

  • location

    Der Speicherort, an dem der Dienst bereitgestellt wird. Beispiel: us-central1.

Lassen Sie die Property run bei der Konfiguration eines [multi-target] weg. Der Speicherort des Cloud Run-Dienstes wird stattdessen im entsprechenden untergeordneten Ziel konfiguriert.

Beschreibungen der Eigenschaften der Ausführungsumgebung finden Sie in diesem Artikel unter executionConfigs.

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 die Property anthosCluster.membership anstelle von gke.cluster ist, der Ressourcenpfad sich unterscheidet und internalIp nicht zutrifft.

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 die Property anthosCluster bei der Konfiguration eines [multi-target] weg. Der GKE Enterprise-Cluster wird stattdessen im entsprechenden untergeordneten Ziel 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 der für alle anderen Zieltypen, mit der Ausnahme, dass sie weder einen gke-, noch einen run-, noch einen anthosCluster-Satz enthält.

Stattdessen enthalten benutzerdefinierte Ziele einen customTarget-Abschnitt:

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, mit denen eine nicht standardmäßige Ausführungsumgebung für dieses Ziel angegeben werden kann.

  • usages

    Entweder RENDER oder DEPLOY oder beides sowie PREDEPLOY, VERIFY oder POSTDEPLOY, wenn die Bestätigung oder Bereitstellungshooks auf dem Ziel aktiviert sind. Sie geben an, welche dieser Vorgänge für dieses Ziel mit dieser Ausführungsumgebung ausgeführt werden soll. Wenn Sie angeben möchten, dass eine benutzerdefinierte Ausführungsumgebung für Pre-Deploy-Hook, Rendering, Bereitstellung, Post-Deploy-Hook und Überprüfung verwendet werden soll, konfigurieren Sie sie so:

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

    Wenn die Überprüfung in der Pipeline-Phase aktiviert ist und Sie in einer usages-Strophe keine VERIFY angeben, verwendet Cloud Deploy die Standardausführungsumgebung für die Überprüfung. Hooks vor und nach der Bereitstellung funktionieren auf die gleiche Weise.

    Wenn es jedoch eine benutzerdefinierte Ausführungsumgebung für RENDER und DEPLOY gibt, müssen Sie eine für VERIFY, PREDEPLOY ODER POSTDEPLOY angeben, wenn diese in der Bereitstellungspipeline konfiguriert sind.VERIFY, PREDEPLOY und POSTDEPLOY können sich in derselben usages wie RENDER oder DEPLOY oder in separaten usages befinden.

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

  • workerPool

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

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

    Wenn Sie den Standard-Cloud Build-Pool verwenden möchten, lassen Sie diese Eigenschaft weg.

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

  • serviceAccount

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

  • artifactStorage

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

  • executionTimeout

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

  • verbose

    Optional. Bei true sind die Ausführlichkeitsstufen für die folgenden Tools auf debug festgelegt:

Alternative unterstützte Syntax

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

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

Wenn Sie einen executionConfigs-Abschnitt für ein Multi-Ziel konfigurieren, kann jedes untergeordnete Ziel diese Ausführungsumgebung von diesem Multi-Ziel übernehmen.

Definitionen für benutzerdefinierte Zieltypen

In diesem Abschnitt werden die Felder beschrieben, mit denen benutzerdefinierte Zieltypen definiert werden.

Wie bei Standardzielen und Automatisierungen können CustomTargetType-Definitionen in der Definition der Lieferpipeline oder in einer separaten Datei oder in separaten Dateien enthalten sein.

Im folgenden YAML-Code wird gezeigt, 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]

    Ein beliebiger Name, den Sie dieser benutzerdefinierten Zieltypdefinition geben. Auf diesen Namen wird in der Zieldefinition für alle Ziele verwiesen, für die der von Ihnen definierte benutzerdefinierte Zieltyp verwendet wird.

  • [RENDER_ACTION_NAME]

    Der Name der benutzerdefinierten Rendering-Aktion. Dieser Wert ist der in skaffold.yaml definierte customAction.name.

  • [DEPLOY_ACTION_NAME]

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

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

Automatisierungsdefinitionen

In diesem Abschnitt werden die Felder beschrieben, mit denen die Automatisierungsressourcen von Cloud Deploy definiert werden.

Wie bei Zielen können Automation-Definitionen in der Definition der Lieferpipeline oder in einer separaten Datei oder in separaten Dateien enthalten sein.

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

Im folgenden YAML-Code wird gezeigt, wie eine Automatisierung konfiguriert wird. Die Details einer Automatisierungsregel unterscheiden sich je nach Regel. Die Konfiguration der verfügbaren Arten von Automatisierungsregeln 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:
  targets:
    -  id: [TARGET_ID]
       labels:
         [LABEL_KEY]:[LABEL_VALUE]

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

Wobei:

  • [PIPELINE_NAME]

    Muss mit dem metadata.name-Wert in der Auslieferungspipeline übereinstimmen, in der diese Automatisierung verwendet wird. Alle Automatisierungen sind exklusiv für die Bereitstellungspipelines gedacht, für die sie erstellt wurden. Das bedeutet, dass Sie eine Automatisierung nicht für mehrere Bereitstellungspipelines freigeben können.

  • [PURPOSE]

    Ein weiterer beschreibender Name für diese Automatisierung. Normalerweise ist dies die automatisierte Aktion. Beispiel: my-app-pipeline/promote.

  • labels und annotations sind beliebige Labels oder Anmerkungen, die Sie mit dieser Automatisierung verknüpfen möchten.

  • [DESCRIPTION]

    Optionale Beschreibung für diese Automatisierung.

  • suspended

    true oder false, was angibt, ob diese Automatisierung aktiv oder pausiert ist. Wenn true festgelegt ist, wird die Automatisierung nicht verwendet. Das kann nützlich sein, um eine Automatisierung zu testen, ohne die Bereitstellungspipeline zu beeinflussen.

  • [SERVICE_ACCOUNT_ID]

    Die ID des Dienstkontos, das für die Automatisierung verwendet wird. Wenn für die Automatisierung beispielsweise das promoteReleaseRule verwendet wird, führt dieses Dienstkonto die Veröffentlichungswerbung durch und benötigt daher die erforderlichen Berechtigungen, um für eine Veröffentlichung zu werben.

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

    Dieses Dienstkonto muss die folgenden Berechtigungen haben:

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

    • Berechtigung zum Ausführen der automatisierten Aktion, z. B. clouddeploy.releases.promote, um einen Release zu veröffentlichen, oder clouddeploy.rollouts.advance, um eine Roll-out-Phase fortzusetzen.

  • [TARGET_ID]

    Die ID des Ziels, für das diese Automatisierung verwendet wird. Eine Automatisierung ist zwar an eine Bereitstellungs-Pipeline gebunden, wird aber nur für das oder die angegebenen Ziele ausgeführt.

    Sie können diese Einstellung auf * festlegen, um alle Ziele in der Auslieferungspipeline auszuwählen.

  • [LABEL_KEY]:[LABEL_VALUE]

    Ein Schlüssel/Wert-Paar, das mit einem Schlüssel/Wert-Paar abgeglichen werden soll, das für das Ziel definiert ist. Dadurch werden alle mit der Auslieferungspipeline verknüpften Ziele mit demselben Label und Wert ausgewählt.

  • [RULE_TYPE]

    Der Name der Automatisierungsregel, die für diese Automatisierung verwendet wird. Das kann promoteReleaseRule, timedPromoteReleaseRule, advanceRolloutRule oder repairRolloutRule sein. Sie können einer Automatisierung mehrere Regeln hinzufügen, auch mehrere derselben RULE_TYPE. Sie können beispielsweise mehrere promoteReleaseRule-Regeln in derselben Automatisierung haben. 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 angezeigt.

Richtliniendefinitionen bereitstellen (Vorabversion)

In diesem Abschnitt werden die Felder beschrieben, mit denen Bereitstellungsrichtlinien definiert werden.

Wie bei anderen Cloud Deploy-Ressourcen können Sie DeployPolicy-Definitionen in die Definition Ihrer Bereitstellungspipeline oder in eine separate Datei aufnehmen.

Im folgenden YAML-Code wird gezeigt, wie eine Bereitstellungsrichtlinie konfiguriert wird:

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]

Wobei:

  • [DESCRIPTION]

    Optionaler Text, der diese Richtlinie beschreibt.

  • [POLICY_NAME]

    Ein Name für die Richtlinie. Dieses Feld verwendet einen String, der pro Projekt und Standort einmalig sein muss. Er darf nur Kleinbuchstaben, Ziffern und Bindestriche enthalten. Das erste Zeichen muss ein Buchstabe, das letzte ein Buchstabe oder eine Ziffer sein. Er darf maximal 63 Zeichen lang sein. Dieser Name wird in der Google Cloud Console als Anzeigename verwendet.

  • [ANNOTATIONS] und [LABELS]

    Richtlinien können Anmerkungen und Labels enthalten, die nach der Erstellung Teil der Richtlinienressource sind. Weitere Informationen finden Sie unter Anmerkungen und Labels mit Cloud Deploy verwenden.

  • suspended: [true | false]

    Wenn Sie suspended auf true festlegen, wird diese Richtlinie deaktiviert.

  • [PIPELINE_ID]

    Die ID der Auslieferungspipeline, auf die diese Richtlinie angewendet werden soll. Sie können * verwenden, um alle Pipelines anzugeben. Diese ID entspricht der Property metadata.name in der Lieferpipeline.

  • [TARGET_ID]

    Die ID des Ziels, auf das diese Richtlinie angewendet werden soll. Sie können * verwenden, um alle Ziele anzugeben. Diese ID entspricht der Property metadata.name auf dem Ziel.

  • [LABEL_KEY]:[LABEL_VALUE]

    Ein Schlüssel/Wert-Paar, das mit einem Schlüssel/Wert-Paar abgeglichen werden soll, das in der Auslieferungspipeline oder dem Ziel definiert ist. Dadurch werden alle Pipelines oder Ziele mit demselben Label und Wert ausgewählt. Sie können labels anstelle oder zusätzlich zu id angeben.

  • [RULE_TYPE]

    Der spezifische Richtlinienregeltyp, den Sie konfigurieren. Der einzige gültige Wert ist rolloutRestriction.

  • [CONFIGS]

    Enthält die Konfigurationseigenschaften für die spezifische Richtlinienregel, die Sie erstellen. Die Konfiguration von Regeln wird später in diesem Abschnitt für jede der verfügbaren Regeln beschrieben.

Richtlinienregeln bereitstellen

In diesem Abschnitt wird beschrieben, wie Sie die einzelnen Regeln für Bereitstellungsrichtlinien konfigurieren.

rolloutRestriction

Mit der Regel rolloutRestriction wird verhindert, dass Cloud Deploy während des oder der angegebenen Zeitfenster für die Bereitstellungspipelines und Ziele, die durch die selectors für die Bereitstellungsrichtlinie angegeben sind, bestimmte Vorgänge für Roll-outs ausführt.

Im folgenden YAML-Code wird gezeigt, wie eine rolloutRestriction-Regel konfiguriert wird:

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]

Wobei:

  • RULE_ID

    Eine Kennung für diese Regel. Das ist ein Pflichtfeld. Er muss aus Kleinbuchstaben, Ziffern und Bindestrichen bestehen. Das erste Zeichen muss ein Buchstabe, das letzte Zeichen ein Buchstabe oder eine Ziffer sein. Er darf maximal 63 Zeichen lang sein. Er darf in der Bereitstellungsrichtlinie nur einmal vorkommen.

  • ACTIONS

    Optional: Roll-out-Aktionen, die im Rahmen der Richtlinie eingeschränkt werden sollen. Wenn das Feld leer ist, sind alle Aktionen eingeschränkt. Gültige Werte sind:

    • ADVANCE

      Roll-out-Phasen können nicht fortgesetzt werden.

    • APPROVE

      Das Einführungsangebot kann nicht genehmigt werden.

    • CANCEL

      Einführungen können nicht abgebrochen werden.

    • CREATE

      Es können keine Roll-outs erstellt werden.

    • IGNORE_JOB

      Jobs können nicht ignoriert werden.

    • RETRY_JOB

      Jobs können nicht erneut ausgeführt werden.

    • ROLLBACK

      Einführungen können nicht rückgängig gemacht werden.

    • TERMINATE_JOBRUN

      Jobausführungen können nicht beendet werden

  • INVOKERS

    Wenn Sie Auslöser angeben, wird die Richtliniendurchsetzung je nachdem gefiltert, ob die eingeschränkte Aktion von einem Nutzer oder von einer Bereitstellungsautomatisierung aufgerufen wurde. Gültige Werte sind:

    • USER

      Die Aktion wird vom Nutzer initiiert. Beispiel: Sie erstellen ein Roll-out manuell mit einem gcloud CLI-Befehl.

    • DEPLOY_AUTOMATION

      Eine automatische Aktion von Cloud Deploy.

    Sie können einen oder beide Werte angeben. Wenn Sie nichts angeben, ist standardmäßig „beide“ ausgewählt.

  • TIMEZONE

    Die Zeitzone, in IANA-Format, in der Sie den Zeitraum angeben. Beispiel: America/New_York. Das ist ein Pflichtfeld.

  • START_DATE_TIME

    Für oneTimeWindows das Datum und die Uhrzeit, die den Beginn des Einschränkungszeitraums markieren, im Format "yyyy-mm-dd hh:mm". Verwenden Sie 00:00 für den Beginn des Tages. Dies ist ein Pflichtfeld.

  • END_DATE_TIME

    Für oneTimeWindows das Datum und die Uhrzeit, die das Ende des Zeitraums für die Einschränkung markieren, im Format "yyyy-mm-dd hh:mm". Verwenden Sie für das Tagesende 24:00. Dies ist ein Pflichtfeld.

  • DAY_OF_WEEK

    Für weeklyWindows den Wochentag SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY oder SATURDAY. Wenn Sie dieses Feld leer lassen, wird die Benachrichtigung an allen Wochentagen gesendet.

  • START_TIME

    Bei weeklyWindows ist es die Startzeit des angegebenen Wochentags. Wenn Sie eine Startzeit angeben, müssen Sie auch eine Endzeit angeben. Verwenden Sie für den Beginn des Tages 00:00.

  • END_TIME

    Bei weeklyWindows ist es die Endzeit des angegebenen Wochentags. Wenn Sie eine Startzeit angeben, müssen Sie auch eine Endzeit angeben. Verwenden Sie für das Tagesende 24:00.

Nächste Schritte