Referenz zum Konfigurationsschema

Die Cloud Deploy-Konfigurationsdatei bzw. -dateien definieren die Lieferpipeline, die Ziele der Bereitstellung und den Fortschritt in der Sequenz dieser Ziele.

Die Konfigurationsdatei der Lieferpipeline 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 Lieferpipeline 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 der Eigenschaften für Zieldefinitionen. Einige Ziel-Properties sind hier nicht enthalten. Informationen zu allen Eigenschaften der Zielkonfiguration 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:
 dnsEndpoint:
 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]

Dieses YAML hat drei Hauptkomponenten:

  • Hauptlieferpipeline und Fortschritt

    Die Konfigurationsdatei kann eine beliebige Anzahl an Pipelinedefinitionen enthalten.

  • Die Zieldefinitionen

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

  • Definitionen benutzerdefinierter 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 Lieferpipeline oder in einer separaten Datei definiert werden.

  • Automatisierungsdefinitionen

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

Diese Komponenten werden im Rest dieses Dokuments definiert.

Pipelinedefinition und -fortschritt

Zusätzlich zu den Pipeline-Metadaten, z. B. name, enthält die Hauptpipelinedefinition eine Liste von Verweisen auf Ziele in der Reihenfolge der Bereitstellung. Das erste aufgeführte Ziel ist also das erste Bereitstellungsziel. Nachdem Sie den Release in diesem Ziel bereitgestellt haben, wird er durch das Hochstufen im nächsten Ziel in der Liste bereitgestellt.

Im Folgenden finden Sie die Konfigurationseigenschaften für eine Lieferpipeline, 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 der Lieferpipeline in der Google Cloud -Konsole angezeigt.

suspended

Ein boolescher Wert, der bei true die Bereitstellungspipeline unterbricht, sodass sie nicht zum Erstellen, Hochstufen, Zurücksetzen oder erneuten Bereitstellen von Releases verwendet werden kann. Wenn die Bereitstellungspipeline ausgesetzt ist, können Sie auch keinen Roll-out genehmigen oder ablehnen, der über diese Pipeline erstellt wurde.

Der Standardwert ist false.

serialPipeline

Der Beginn der Definition einer Lieferpipeline für die Serienprogression. Dieser Abschnitt 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 jedes stages.targetId-Feld den Wert des metadata.name-Felds in der entsprechenden Zieldefinition ein. Fügen Sie unter targetId profiles ein:

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

profiles

Akzeptiert eine Liste mit null oder mehr Skaffold-Profilnamen aus skaffold.yaml. Cloud Deploy verwendet das Profil mit skaffold render beim Erstellen des Releases. Mit Skaffold-Profilen können Sie die Konfiguration zwischen Zielen variieren, während Sie eine einzelne 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-Deployment-Strategie. 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 ausgeführte Version in prozentualen Schritten (z. B. 25%, dann 50%, dann 75%, dann vollständig).

Die Bereitstellungsstrategie wird pro Ziel definiert. Sie haben beispielsweise möglicherweise eine Canary-Strategie für Ihr prod-Ziel, aber eine Standardstrategie (ohne Angabe von strategy) 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.

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

Canary-Deployment-Strategie

In den folgenden Abschnitten wird die Konfiguration für eine Canary-Bereitstellungsstrategie 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 mit 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 sehen Sie, wie Sie eine Bereitstellungsstrategie für ein GKE- oder GKE Enterprise-Ziel mit 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 ist erforderlich, weil in der Gateway API Traffic mithilfe einer HTTPRoute-Ressource aufgeteilt wird und es manchmal zu Verzögerungen bei der Übertragung von Änderungen an der HTTPRoute kommt. In solchen Fällen werden Anfragen möglicherweise verworfen, 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 feststellen.

Das folgende YAML zeigt, wie Sie eine benutzerdefinierte Canary-Bereitstellungsstrategie (für Service Networking, Gateway API oder Cloud Run) oder eine benutzerdefinierte automatisierte Canary-Bereitstellungsstrategie (für Service Networking, Gateway API oder Cloud Run) konfigurieren. Die laufzeitspezifische Konfiguration im Abschnitt runtimeConfig wird für benutzerdefinierte Canary-Versionen ausgelassen, ist aber in der automatischen und benutzerdefinierten automatischen Canary-Konfiguration enthalten.

Benutzerdefinierte Canary-Konfiguration

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, ist auch ein verify-Abschnitt in der skaffold.yaml erforderlichskaffold.yaml. Wenn Sie diese Property nicht angeben, schlägt der Bestätigungsjob fehl.

deployParameters

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

Sie können diese auch in Zielen verwenden.

Für die Bereitstellungsparameter, 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 werden zwei Werte für den Schlüssel angegeben und für jeden Wert gibt es ein Label. Der Wert wird auf das Manifest für jedes Ziel angewendet, das ein entsprechendes Label hat.

predeploy- und postdeploy-Jobs

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

Deploy-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 Name, der in skaffold.yaml für customActions.name konfiguriert ist.

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.

Siehe auch Definitionen benutzerdefinierter Zieltypen

Für GKE-Ziele

Das folgende YAML 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]
      dnsEndpoint:
      internalIp:
      proxyUrl:

     associatedEntities:
       [KEY]:
         gkeClusters:
         - cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
           dnsEndpoint: [true|false]
           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-Annotationen und Labels, Cloud Deploy erfordert sie jedoch 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 Bereitstellungsparameter zusammen mit Werten in jedes Ziel einfügen. Diese Werte werden nach dem Rendern den entsprechenden Schlüsseln in Ihrem Manifest zugewiesen.

Der deployParameters-Abschnitt enthält Schlüssel/Wert-Paare, wie unten dargestellt:

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

Wenn Sie Bereitstellungsparameter für ein Multi-Target festlegen, wird der Wert dem Manifest für alle untergeordneten Targets dieses Multi-Targets 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 Zielvorhaben. Untergeordnete Ziele werden wie normale Ziele konfiguriert und enthalten nicht die Property multiTarget.

requireApproval

Ob für die Hochstufung zu diesem Ziel eine manuelle Genehmigung erforderlich ist. 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, 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 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 derGoogle 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 der Zielcluster ist, finden Sie unter HTTPRoute in einem anderen Cluster bereitstellen.

dnsEndpoint

Wenn diese Option auf true festgelegt ist, stellt Cloud Deploy über den DNS-Endpunkt eine Verbindung zum GKE-Cluster her. Der Standardendpunkt kann je nach Clusterkonfiguration eine öffentliche IP-Adresse, eine private IP-Adresse oder der DNS-Endpunkt sein.

Diese Option kann nicht gleichzeitig mit der Option internalIp verwendet werden.

internalIp

Wenn diese Option auf true festgelegt ist, stellt Cloud Deploy über die private IP-Adresse eine Verbindung zum GKE-Cluster her. Dies ist anstelle des Standardendpunkts, der je nach Clusterkonfiguration eine öffentliche IP-Adresse, eine private IP-Adresse oder der DNS-Endpunkt sein kann.

Diese Option kann nicht gleichzeitig mit der Option dnsEndpoint verwendet werden. Da die Netzwerkkonfiguration für dnsEndpoint viel einfacher ist, empfehlen wir, stattdessen diese zu verwenden.

proxyUrl

Wenn Sie über einen HTTP-Proxy auf Cluster zugreifen, geben Sie hier die Eigenschaft proxyUrl an. Der Wert ist die URL des Proxys, die an kubectl übergeben wird, wenn eine Verbindung zu Ihrem Cluster hergestellt wird.

Für Cloud Run-Ziele

Das folgende YAML 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 pro Region eindeutig sein.

metadata.annotations und metadata.labels

Die Zielkonfiguration unterstützt Annotationen und Labels, Cloud Deploy erfordert sie jedoch 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: []

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 Zielvorhaben. Untergeordnete Ziele werden wie normale Ziele konfiguriert und enthalten nicht die Property multiTarget.

requireApproval

Ob für die Hochstufung zu diesem Ziel eine manuelle Genehmigung erforderlich ist. 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, nicht für untergeordnete Ziele anfordern.

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 sich der Dienst befindet.

  • location

    Der Ort, an dem der Dienst gehostet wird. Beispiel: us-central1.

Lassen Sie die Property run weg, wenn Sie ein [multi-target] konfigurieren. Der Standort des Cloud Run-Dienstes wird stattdessen im entsprechenden untergeordneten Ziel konfiguriert.

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

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. Die Eigenschaft ist jedoch anthosCluster.membership anstelle von gke.cluster, der Ressourcenpfad ist anders und bestimmte Verbindungsmethoden (dnsEndpoint oder internalIp) sind nicht anwendbar.

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 weg, wenn Sie ein [multi-target] konfigurieren. Der GKE Enterprise-Cluster wird stattdessen im entsprechenden untergeordneten Ziel konfiguriert.

Weitere Informationen zur Bereitstellung in GKE-Clustern finden Sie unter Bereitstellung in Anthos-Nutzerclustern.

Für benutzerdefinierte Ziele

Die Konfiguration für benutzerdefinierte Ziele ähnelt allen anderen Zieltypen, mit der Ausnahme, dass sie keinen gke-Abschnitt, keinen run-Abschnitt und keinen anthosCluster-Abschnitt enthält.

Benutzerdefinierte Ziele enthalten stattdessen 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 wird.

  • usages

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

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

    Wenn die Bestätigung in der Pipelinephase aktiviert ist und Sie VERIFY in einem usages-Abschnitt nicht angeben, verwendet Cloud Deploy die Standardausführungsumgebung für die Bestätigung. Predeploy- und Postdeploy-Hooks 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 sie 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 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. Hier 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 Standard-Cloud Build-Pool verwenden möchten, lassen Sie diese Eigenschaft weg.

    Ein bestimmtes Ziel kann zwei workerPool-Elemente 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 für dieses Ziel verwendet werden soll (RENDER oder DEPLOY), 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 der Wert 3600 Sekunden (1 Stunde).
    Beispiel: executionTimeout: "5000s"

  • verbose

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

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

    • kubectl --v ist auf 4 festgelegt, was „debug“ entspricht. Der Standardwert für kubectl ist 2.

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

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 einen executionConfigs-Abschnitt für ein Multi-Ziel konfigurieren, kann jedes untergeordnete Ziel diese Ausführungsumgebung vom Multi-Ziel übernehmen.

Definitionen benutzerdefinierter Zieltypen

In diesem Abschnitt werden die Felder beschrieben, die zum Definieren benutzerdefinierter Zielgruppentypen verwendet werden.

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

Das folgende YAML 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]

    Ein beliebiger Name, den Sie dieser benutzerdefinierten Zielgruppentypdefinition geben. Auf diesen Namen wird in der Zieldefinition für alle Ziele verwiesen, die den benutzerdefinierten Zieltyp verwenden, den Sie definieren.

  • [RENDER_ACTION_NAME]

    Ist der Name der benutzerdefinierten Rendering-Aktion. Dieser Wert ist der customAction.name, der in skaffold.yaml definiert ist.

  • [DEPLOY_ACTION_NAME]

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

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

Automatisierungsdefinitionen

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

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

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

Das folgende YAML zeigt, wie eine Automatisierung konfiguriert wird. Die Details einer Regel für die Automatisierung sind je nach Regel unterschiedlich. Die Konfiguration für die verfügbaren Arten von automatisierten Regeln finden Sie im Dokument Automatisierte Regeln 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]

    Entspricht dem metadata.name-Wert in der Auslieferungspipeline, in der diese Automatisierung verwendet wird. Alle automatisierten Abläufe sind exklusiv für die Bereitstellungspipelines, für die sie erstellt wurden. Das bedeutet, dass Sie eine Automatisierung nicht für mehr als eine Bereitstellungspipeline freigeben können.

  • [PURPOSE]

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

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

  • [DESCRIPTION]

    Eine optionale Beschreibung für diese Automatisierung.

  • suspended

    true oder false, um anzugeben, ob dieser automatisierte Ablauf aktiv oder pausiert ist. Wenn die Einstellung auf true gesetzt ist, wird die Automatisierung nicht verwendet. Das kann nützlich sein, um eine Automatisierung zu testen, ohne die Bereitstellungspipeline zu beeinträchtigen.

  • [SERVICE_ACCOUNT_ID]

    Die ID des Dienstkontos, das zum Ausführen der Automatisierung verwendet wird. Wenn für die Automatisierung beispielsweise promoteReleaseRule verwendet wird, führt dieses Dienstkonto die Release-Promotion durch und benötigt daher die erforderlichen Berechtigungen, um ein Release zu bewerben.

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

    Dieses Dienstkonto muss die folgenden Berechtigungen haben:

    • actAs-Berechtigung zum Übernehmen der Identität des Ausführungsdienstkontos.

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

  • [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 angegebene Ziel oder die angegebenen Ziele ausgeführt.

    Wenn Sie * festlegen, werden alle Ziele in der Auslieferungspipeline ausgewählt.

  • [LABEL_KEY]:[LABEL_VALUE]

    Ein Schlüssel/Wert-Paar, das mit einem auf dem Ziel definierten Schlüssel/Wert-Paar abgeglichen werden soll. Damit werden alle Ziele ausgewählt, die mit der Auslieferungspipeline verknüpft sind und dasselbe Label und denselben Wert haben.

  • [RULE_TYPE]

    Der Name der Automatisierungsregel, die für diese Automatisierung verwendet wird. Das ist entweder promoteReleaseRule, timedPromoteReleaseRule, advanceRolloutRule oder repairRolloutRule. Eine Automatisierung kann mehrere Regeln enthalten, auch mehrere Regeln desselben 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 beschrieben.

Richtliniendefinitionen bereitstellen

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

Wie bei anderen Cloud Deploy-Ressourcen können Sie DeployPolicy-Definitionen in die Definition Ihrer Lieferpipeline oder in eine separate Datei einfügen.

Das folgende YAML zeigt, 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]

    Ist 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. Sie muss aus Kleinbuchstaben, Ziffern und Bindestrichen bestehen, wobei das erste Zeichen ein Buchstabe und das letzte Zeichen ein Buchstabe oder eine Ziffer sein muss. Die maximale Länge beträgt 63 Zeichen. Dieser Name wird als Anzeigename in derGoogle Cloud -Konsole verwendet.

  • [ANNOTATIONS] und [LABELS]

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

  • suspended: [true | false]

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

  • [PIPELINE_ID]

    Die ID der Bereitstellungspipeline, auf die sich diese Richtlinie auswirken soll. Sie können * verwenden, um alle Pipelines anzugeben. Diese ID entspricht dem Attribut metadata.name der Bereitstellungspipeline.

  • [TARGET_ID]

    Die ID des Ziels, auf das sich diese Richtlinie auswirken soll. Mit * können Sie alle Ziele angeben. Diese ID entspricht der Property metadata.name des Ziels.

  • [LABEL_KEY]:[LABEL_VALUE]

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

  • [RULE_TYPE]

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

  • [CONFIGS]

    Die Konfigurationseigenschaften für die spezifische Richtlinienregel, die Sie erstellen. Die Konfiguration für Regeln wird später in diesem Abschnitt dieser Referenz 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

Die rolloutRestriction-Regel verhindert, dass Cloud Deploy bestimmte Vorgänge für Rollouts während des angegebenen Zeitraums oder der angegebenen Zeiträume für die Bereitstellungspipelines und Ziele ausführt, die durch die selectors für die Bereitstellungsrichtlinie angegeben werden.

Das folgende YAML zeigt, 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, wobei das erste Zeichen ein Buchstabe und das letzte Zeichen ein Buchstabe oder eine Ziffer sein muss. Die maximale Länge beträgt 63 Zeichen. Er muss in der Bereitstellungsrichtlinie eindeutig sein.

  • ACTIONS

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

    • ADVANCE

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

    • APPROVE

      Das Rollout-Angebot kann nicht genehmigt werden.

    • CANCEL

      Rollouts können nicht abgebrochen werden.

    • CREATE

      Roll-outs können nicht erstellt werden.

    • IGNORE_JOB

      Jobs können nicht ignoriert werden.

    • RETRY_JOB

      Jobs können nicht wiederholt werden.

    • ROLLBACK

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

    • TERMINATE_JOBRUN

      Jobläufe können nicht beendet werden.

  • INVOKERS

    Wenn Sie Aufrufer angeben, wird die Richtliniendurchsetzung gefiltert. Es wird dann unterschieden, ob die eingeschränkte Aktion von einem Nutzer oder von einer Bereitstellungsautomatisierung aufgerufen wurde. Gültige Werte sind:

    • USER

      Die Aktion wird vom Nutzer ausgelöst. Sie können beispielsweise ein Roll-out manuell mit einem gcloud CLI-Befehl erstellen.

    • DEPLOY_AUTOMATION

      Eine automatisierte Aktion von Cloud Deploy.

    Sie können einen oder beide Werte angeben. Wenn Sie nichts angeben, ist der Standardwert „beide“.

  • TIMEZONE

    Die Zeitzone im 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 für den Beginn des Tages 00:00. Dies ist ein Pflichtfeld.

  • END_DATE_TIME

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

  • DAY_OF_WEEK

    Für weeklyWindows ist der Wochentag SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY oder SATURDAY. Wenn Sie dieses Feld leer lassen, werden alle Wochentage berücksichtigt.

  • START_TIME

    Für weeklyWindows die Startzeit am angegebenen Wochentag. Wenn Sie einen Beginn angeben, müssen Sie auch ein Ende angeben. Verwenden Sie für den Tagesbeginn 00:00.

  • END_TIME

    Für weeklyWindows die Endzeit am angegebenen Wochentag. Wenn Sie einen Beginn angeben, müssen Sie auch ein Ende angeben. Verwenden Sie für das Ende des Tages 24:00.

Nächste Schritte