Konfigurationsschemareferenz

Die Cloud Deploy-Konfigurationsdatei oder -Dateien definieren die Bereitstellungspipeline, die Ziele für die Bereitstellung und den Fortschritt dieser Ziele.

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

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.

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:
 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:
---

# 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 wird in diesem Beispiel nur ein Ziel gezeigt, es kann aber beliebig viele davon geben. Außerdem können Ziele in einer oder mehreren separaten Dateien definiert werden.

  • Definitionen benutzerdefinierter Zieltypen

    Benutzerdefinierte Ziele – erfordern eine Definition des benutzerdefinierten Zieltyps. 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 beliebige Bereitstellungsautomatisierungen in derselben Datei wie Ihre Bereitstellungspipeline und Ziele oder in einer oder mehreren separaten Dateien erstellen. Der Einfachheit halber wird hier nur eine Automation angezeigt, Sie können aber beliebig viele erstellen.

Diese Komponenten werden im Rest 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 Deployment-Sequenz. Das heißt, das erste aufgelistete Ziel ist das erste Bereitstellungsziel. Nach der Bereitstellung auf diesem Ziel wird der Release auf das nächste Ziel in der Liste hochgestuft.

Im Folgenden finden Sie die Konfigurationsattribute 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 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, mit dem true die Bereitstellungspipeline sperrt, sodass sie nicht zum Erstellen, Hochstufen, Rollback oder erneuten Bereitstellen von Releases verwendet werden kann. Wenn die Bereitstellungspipeline ausgesetzt ist, können Sie ein aus dieser Pipeline erstelltes Rollout weder genehmigen noch ablehnen.

Der Standardwert ist false.

serialPipeline

Der Anfang der Definition einer Pipeline für die Bereitstellung serieller Fortsetzungen. 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 profiles hinzu:

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 Prüfung auf false gesetzt ist.

profiles

Erstellt eine Liste mit null oder mehr Skaffold-Profilnamen aus skaffold.yaml. 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 und nur eine einzige Konfigurationsdatei verwenden.

strategy

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

  • standard:

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

    Dies ist die standardmäßige Bereitstellungsstrategie. Wenn Sie strategy weglassen, verwendet Cloud Deploy die Bereitstellungsstrategie standard.

  • canary:

    Bei einem Canary-Deployment stellen Sie eine neue Version der Anwendung nach und nach bereit. Dabei wird die bereits ausgeführte Version in prozentualen Schritten 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 Ziel prod, aber eine Standardstrategie (keine 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 aufgeführt.

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 es für die resultierenden Roll-outs keine verify-Phase gibt.

Für eine Standard-Bereitstellungsstrategie können Sie das Element strategy weglassen.

Canary-Bereitstellungsstrategie

In den folgenden Abschnitten wird die Konfiguration einer Strategie für eine Canary-Bereitstellung 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 mit 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 Verzögerungen bei der Weitergabe von Änderungen an der HTTPRoute kommt. In solchen Fällen können Anfragen verworfen werden, da 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 benutzerdefiniert automatisierte Canary-Bereitstellungsstrategie konfigurieren. Die laufzeitspezifische Konfiguration im Abschnitt runtimeConfig wird bei der benutzerdefinierten Canary-Version weggelassen, 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 Bereitstellungsprüfung für dieses Ziel unterstützt werden soll. Der Standardwert ist false.

Das Aktivieren der Bereitstellungsprüfung erfordert auch eine verify-Stanza im skaffold.yaml. Wenn Sie dieses Attribut nicht angeben, schlägt der Überprüfungsjob fehl.

deployParameters

Mit Bereitstellungsparametern können Sie Schlüssel/Wert-Paare angeben, um Werte an Manifeste für Ziele zu übergeben, die mit Labels übereinstimmen.

Sie können es auch in Ziele aufnehmen.

Stellen Sie Parameter, die in einer Bereitstellungspipeline festgelegt wurden, mithilfe von Labels bereit, 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 nach dem Überprüfungsjob, falls vorhanden (postdeploy), ausgeführt werden. Wenn kein Prüfjob vorhanden ist, wird der Job nach dem 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 unter 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.

Siehe auch: 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:
      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-Annotationen und Labels, aber Cloud Deploy erfordert sie nicht.

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 für jedes Ziel Bereitstellungsparameter zusammen mit Werten hinzufügen. Diese Werte werden nach dem Rendering den entsprechenden Schlüsseln in Ihrem 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 Ziels dem Manifest zugewiesen.

multiTarget.targetIds: []

Dieses Attribut ist optional und wird zum Konfigurieren eines multi-target für die parallele Bereitstellung verwendet.

Der Wert ist eine durch Kommas getrennte Liste von untergeordneten Zielen. Untergeordnete Ziele werden als normale Ziele konfiguriert und enthalten das Attribut multiTarget nicht.

requireApproval

Gibt an, ob das Hochstufen zu diesem Ziel eine manuelle Genehmigung erfordert. Kann true oder false sein.

Dieses Attribut ist optional. Der Standardwert ist false.

Wenn Sie eine parallele Bereitstellung konfigurieren, können Sie eine Genehmigung nur für mehrere Ziele anfordern, nicht für untergeordnete Ziele.

gke

Nur bei GKE-Clustern 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. Standardmäßig verwendet Cloud Deploy die öffentlich verfügbare IP-Adresse für den Cluster. Wenn Sie eine private IP-Adresse verwenden möchten, legen Sie dafür true fest.

proxyUrl

Wenn Sie über einen Proxy auf Cluster zugreifen, geben Sie hier das Attribut proxyUrl an. Der Wert ist die URL Ihres Proxy-GKE-Clusters, der beim Herstellen einer Verbindung zum Cluster an kubectl übergeben wird.

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:
       verbose:

metadata.name

Der Name dieses Ziels. Dieser Name muss in jeder Region eindeutig sein.

metadata.annotations und metadata.labels

Die Zielkonfiguration unterstützt Annotationen und Labels, aber Cloud Deploy erfordert sie nicht.

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 zum Konfigurieren eines multi-target für die parallele Bereitstellung verwendet.

Der Wert ist eine durch Kommas getrennte Liste von untergeordneten Zielen. Untergeordnete Ziele werden als normale Ziele konfiguriert und enthalten das Attribut multiTarget nicht.

requireApproval

Gibt an, ob das Hochstufen zu diesem Ziel eine manuelle Genehmigung erfordert. Kann true oder false sein.

Dieses Attribut ist optional. Der Standardwert ist false.

Wenn Sie eine parallele Bereitstellung konfigurieren, können Sie eine Genehmigung nur für mehrere Ziele anfordern, nicht für untergeordnete Ziele.

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 gespeichert wird.

  • location

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

Lassen Sie das Attribut run weg, wenn Sie ein [mehreres Ziel] konfigurieren. Der Speicherort des Cloud Run-Dienstes wird stattdessen innerhalb des entsprechenden untergeordneten Ziels 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. In allen Fällen global.

  • 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 [mehreres Ziel] konfigurieren. 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 allen anderen Zieltypen, mit der Ausnahme, dass sie weder eine gke-Stanza noch eine run-Stanza oder eine 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 zur Angabe einer nicht standardmäßigen Ausführungsumgebung für dieses Ziel.

  • usages

    Entweder RENDER oder DEPLOY oder beide, plus PREDEPLOY, VERIFY oder POSTDEPLOY, wenn Verifizierung oder Bereitstellungs-Hooks für das Ziel aktiviert sind. Diese geben an, welche dieser Vorgänge für dieses Ziel in dieser Ausführungsumgebung ausgeführt werden sollen. Um anzugeben, dass eine benutzerdefinierte Ausführungsumgebung für den Pre-Deploy-Hook, -Rendering, -Deploy, -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 Pipelinephase aktiviert ist und Sie VERIFY nicht in einer usages-Stanza angeben, verwendet Cloud Deploy die Standardausführungsumgebung zur Prüfung. Hooks vor und nach der Bereitstellung 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 diese in der Bereitstellungspipeline konfiguriert sind.VERIFY, PREDEPLOY und POSTDEPLOY können sich im selben usages wie RENDER oder DEPLOY oder in separaten usages befinden.

    Sie können usages.VERIFY, usages.PREDEPLOY oder usages.POSTDEPLOY nicht angeben, es sei denn, RENDER und DEPLOY werden in derselben oder in separaten benutzerdefinierten Ausführungsumgebungen angegeben.

  • 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 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). Beim Konfigurieren des Standardpools 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. Legt das Zeitlimit in Sekunden für Vorgänge fest, die Cloud Build für Cloud Deploy ausführt. Der Standardwert ist 3600 Sekunden (1 Stunde).
    Beispiel: executionTimeout: "5000s"

  • verbose

    Optional. Wenn true, werden die Ausführlichkeitsstufen für die folgenden Tools auf debug gesetzt:

    • Skaffold --verbosity ist auf debug festgelegt. Der Skaffold-Standardwert ist warn.

    • kubectl --v ist auf 4 gesetzt, was der Fehlerbehebung entspricht. Der kubectl-Standardwert ist 2.

    • --verbosity der Google Cloud CLI ist auf debug eingestellt. Der Standardwert ist warning.

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 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, mit denen benutzerdefinierte Zieltypen definiert werden.

Wie bei Standardzielen und Automatisierungen können CustomTargetType-Definitionen in die Definition Ihrer Bereitstellungspipeline oder in eine oder mehrere separate 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]

    Dies ist ein beliebiger Name, den Sie dieser benutzerdefinierten Zieltypdefinition geben. Auf diesen Namen wird in der Zieldefinition für alle Ziele verwiesen, die den von Ihnen definierten benutzerdefinierten Zieltyp verwenden.

  • [RENDER_ACTION_NAME]

    Der Name der benutzerdefinierten Renderingaktion. 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-Skafffold-Konfigurationen verwenden.

Automatisierungsdefinitionen

In diesem Abschnitt werden die Felder beschrieben, die zum Definieren der Automatisierungsressourcen von Cloud Deploy verwendet werden.

Wie bei Zielen können Automation-Definitionen in die Definition Ihrer Bereitstellungspipeline oder in eine oder mehrere separate Dateien aufgenommen werden.

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

Der folgende YAML-Code zeigt, wie eine Automatisierung konfiguriert wird. Beachten Sie, dass die Eigenschaften einer Automatisierungsregel pro Regel unterschiedlich sind. (Die Konfiguration der verfügbaren Automatisierungsregeltypen 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]

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

  • [PURPOSE]

    Gibt einen weiteren beschreibenden Namen für diese Automatisierung an. In der Regel erfolgt dies automatisch. Beispiel: my-app-pipeline/promote.

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

  • [DESCRIPTION]

    Ist eine optionale Beschreibung für diese Automatisierung.

  • suspended

    true oder false: gibt an, ob diese Automatisierung aktiv oder gesperrt ist. Wenn true festgelegt ist, wird die Automatisierung nicht verwendet. Dies kann nützlich sein, wenn Sie eine Automatisierung testen möchten, ohne die Bereitstellungspipeline zu beeinträchtigen.

  • [SERVICE_ACCOUNT_ID]

    Die ID des Dienstkontos, das zum Ausführen der Automatisierung verwendet wird. Wenn die Automatisierung beispielsweise promoteReleaseRule verwendet, führt dieses Dienstkonto die Releasehochstufung 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.

    • permission zum Ausführen des automatisierten Vorgangs, z. B. clouddeploy.releases.promote, um einen Release hochzustufen, oder clouddeploy.rollouts.advance, um eine Roll-out-Phase voranzutreiben.

  • [TARGET_ID]

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

    Sie können diesen Wert auf * festlegen, um alle Ziele in der Bereitstellungspipeline auszuwählen.

  • [LABEL_KEY]:[LABEL_VALUE]

    Ist ein Schlüssel/Wert-Paar zum Abgleich mit einem auf dem Ziel definierten Schlüssel/Wert-Paar. Dadurch werden alle Ziele ausgewählt, die mit der Bereitstellungspipeline verknüpft sind und dasselbe Label und denselben Wert haben.

  • [RULE_TYPE]

    Der Name der Automatisierungsregel, die für diese Automatisierung verwendet wird. Dies ist entweder promoteReleaseRule oder advanceRolloutRule. Sie können mehrere Regeln in eine Automatisierung aufnehmen, einschließlich mehrerer Regeln desselben RULE_TYPE. Sie können beispielsweise mehr als eine promoteReleaseRule-Regel in derselben Automatisierung haben. Weitere Informationen

  • [RULE_NAME]

    Ein Name für die Regel. Dieser Name muss innerhalb der Bereitstellungspipeline eindeutig sein. 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