Die Cloud Deploy-Konfigurationsdatei(en) definieren die Bereitstellungspipeline, die Ziele für die Bereitstellung und den Fortschritt dieser Ziele.
Die Konfigurationsdatei der Bereitstellungspipeline kann Zieldefinitionen enthalten oder sich in einer separaten Datei bzw. Dateien befinden. Konventionsgemäß wird eine Datei, die sowohl die Konfiguration der Bereitstellungspipeline als auch die Zielkonfigurationen enthält, clouddeploy.yaml
und eine Pipelinekonfiguration ohne Ziele als delivery-pipeline.yaml
bezeichnet. Sie können diesen Dateien aber
einen beliebigen Namen geben.
Aufbau
Cloud Deploy verwendet zwei Hauptkonfigurationsdateien:
- Definition der Bereitstellungspipeline
- Zieldefinition
Dies können separate Dateien sein oder die Bereitstellungspipeline und Ziele können in derselben Datei konfiguriert werden.
Struktur einer Konfigurationsdatei für eine Lieferpipeline.
Die folgende Konfiguration enthält eine Zieldefinition:
# Delivery pipeline config
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
name:
annotations:
labels:
description:
suspended:
serialPipeline:
stages:
- targetId:
profiles: []
# Deployment strategies
# One of:
# standard:
# canary:
# See the strategy section in this document for details.
strategy:
standard:
verify:
predeploy:
actions: []
postdeploy:
actions: []
deployParameters:
- values:
matchTargetLabels:
- targetId:
profiles: []
strategy:
deployParameters:
---
# Target config
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name:
annotations:
labels:
description:
multiTarget:
targetIds: []
deployParameters:
requireApproval:
#
# Runtimes
# one of the following runtimes:
gke:
cluster:
internalIp:
#
# or:
anthosCluster:
membership:
#
# or:
run:
location:
#
# or:
customTarget:
customTargetType:
#
# (End runtimes. See documentation in this article for more details.)
#
executionConfigs:
- usages:
- [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]
workerPool:
serviceAccount:
artifactStorage:
executionTimeout:
---
# Custom target type config
apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
name:
annotations:
labels:
description:
customActions:
renderAction:
deployAction:
includeSkaffoldModules:
- configs:
# either:
googleCloudStorage:
source:
path:
# or:
git:
repo:
path:
ref:
---
# Automation config
apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
name:
labels:
annotations:
description:
suspended:
serviceAccount:
selector:
- target:
id:
# or
labels:
rules:
- [RULE_TYPE]:
name:
[RULE-SPECIFIC_CONFIG]
Dieser YAML-Code besteht aus drei Hauptkomponenten:
Hauptlieferpipeline und Fortschritt
Die Konfigurationsdatei kann eine beliebige Anzahl an Pipelinedefinitionen enthalten.
Die Zieldefinitionen
Der Einfachheit halber wird in diesem Beispiel nur ein Ziel gezeigt, aber es kann eine beliebige Anzahl von Zielen geben. Außerdem können Ziele in einer oder mehreren separaten Dateien definiert werden.
Definitionen benutzerdefinierter Zieltypen
Für benutzerdefinierte Ziele ist eine benutzerdefinierte Zieltypdefinition erforderlich. Wie Ziele und Automatisierungen können benutzerdefinierte Zieltypen in derselben Datei wie die Bereitstellungspipeline oder in einer separaten Datei definiert werden.
Automatisierungsdefinitionen
Sie können beliebige Bereitstellungsautomatisierungen in derselben Datei wie Ihre Bereitstellungspipeline und ‐ziele oder in einer oder mehreren separaten Dateien erstellen. Der Einfachheit halber wird hier nur ein
Automation
angezeigt. Sie können jedoch beliebig viele erstellen.
Diese Komponenten werden im weiteren Verlauf dieses Dokuments definiert.
Pipelinedefinition und -fortschritt
Zusätzlich zu Pipeline-Metadaten wie name
enthält die Hauptpipeline-Definition eine Liste von Verweisen auf Ziele in der Reihenfolge der Bereitstellungssequenz. Das bedeutet, dass das erste aufgeführte Ziel das erste Bereitstellungsziel ist. Nach der Bereitstellung für dieses Ziel wird der Release für das nächste Ziel in der Liste hochgestuft.
Im Folgenden sind die Konfigurationsattribute für eine Bereitstellungspipeline ohne Zieldefinitionen aufgeführt.
metadata.name
Das name
-Feld verwendet einen String, der pro Projekt und Standort einmalig sein muss.
metadata.annotations
und metadata.labels
Die Konfiguration der Lieferpipeline kann Annotationen und Labels enthalten. Annotationen und Labels werden mit der Ressource der Lieferpipeline gespeichert, nachdem die Pipeline registriert wurde.
Weitere Informationen finden Sie unter Labels und Annotationen mit Cloud Deploy verwenden.
description
Beliebiger String, der diese Lieferpipeline beschreibt. Diese Beschreibung wird in den Details zur Bereitstellungspipeline in der Google Cloud Console angezeigt.
suspended
Ein boolescher Wert, der, wenn true
die Bereitstellungspipeline sperrt, sodass er nicht zum Erstellen, Hochstufen, Rollback oder erneutes Bereitstellen von Releases verwendet werden kann.
Außerdem können Sie ein Rollout, das aus dieser Pipeline erstellt wurde, nicht genehmigen oder ablehnen, wenn die Bereitstellungspipeline ausgesetzt ist.
Der Standardwert ist false
.
serialPipeline
Der Anfang der Definition einer Pipeline für die serielle Bereitstellung. Diese Stanza ist erforderlich.
stages
Liste aller Ziele, für die diese Lieferpipeline konfiguriert wurde.
Die Liste muss in der gewünschten Reihenfolge der Auslieferung angeordnet sein. Beispiel: Wenn Sie Ziele mit den Namen dev
, staging
und production
haben, listen Sie diese in dieser Reihenfolge auf, damit Ihre erste Bereitstellung für dev
und Ihre letzte Bereitstellung für production
erfolgt.
Füllen Sie jedes stages.targetId
-Feld mit dem Wert des Felds metadata.name
in der entsprechenden Zieldefinition. Fügen Sie unter targetId
Folgendes hinzu: profiles
:
serialPipeline:
stages:
- targetId:
profiles: []
strategy:
standard:
verify:
targetId
Gibt das spezifische Ziel an, das für diese Phase der Lieferpipeline verwendet werden soll.
Der Wert ist das metadata.name
-Attribut aus der Zieldefinition.
Wenn strategy.standard.verify
auf true
gesetzt ist, wird die Bereitstellungsprüfung für das Ziel aktiviert. Wenn keine Bereitstellungsstrategie angegeben ist, wird die Bereitstellungsstrategie standard
verwendet, wobei die Überprüfung auf false
gesetzt ist.
profiles
Ruft eine Liste mit null oder mehr Skaffold-Profilnamen aus skaffold.yaml
auf.
Cloud Deploy verwendet beim Erstellen des Release das Profil mit skaffold render
. Mit Skaffold-Profilen können Sie die Konfiguration zwischen Zielen unter Verwendung einer einzigen Konfigurationsdatei variieren.
strategy
Enthält Attribute zum Angeben einer Bereitstellungsstrategie. Die folgenden Strategien werden unterstützt:
standard:
Die Anwendung wird vollständig auf dem angegebenen Ziel bereitgestellt.
Dies ist die Standardbereitstellungsstrategie. Wenn Sie
strategy
weglassen, verwendet Cloud Deploy die Bereitstellungsstrategiestandard
.canary:
Bei einem Canary-Deployment stellen Sie schrittweise eine neue Version Ihrer Anwendung bereit. Dabei wird die bereits ausgeführte Version prozentual ersetzt (z. B. 25%, dann 50%, dann 75 % und dann vollständig).
Die Bereitstellungsstrategie wird pro Ziel definiert. Angenommen, Sie haben eine Canary-Strategie für das prod
-Ziel und eine Standardstrategie (ohne strategy
angegeben) für die anderen Ziele.
Weitere Informationen finden Sie unter Bereitstellungsstrategie verwenden.
strategy
Konfiguration
Dieser Abschnitt enthält die Konfigurationselemente für strategy
für jede unterstützte Laufzeit.
Standardbereitstellungsstrategie
Die Standardstrategie umfasst nur die folgenden Elemente:
strategy:
standard:
verify: true|false
Das Attribut verify
ist optional. Der Standardwert ist false
, was bedeutet, dass es keine Überprüfungsphase für die resultierenden Roll-outs gibt.
Für eine Standardbereitstellungsstrategie können Sie das Element strategy
weglassen.
Canary-Bereitstellungsstrategie
In den folgenden Abschnitten wird die Konfiguration einer Canary-Deployment-Strategie für jede von Cloud Deploy unterstützte Laufzeit beschrieben.
Für Cloud Run-Ziele
strategy:
canary:
runtimeConfig:
cloudRun:
automaticTrafficControl: true | false
canaryDeployment:
percentages: [PERCENTAGES]
verify: true | false
Für GKE- und GKE Enterprise-Ziele
Die folgende YAML-Datei zeigt, wie Sie eine Bereitstellungsstrategie für ein GKE- oder GKE Enterprise-Ziel mithilfe eines dienstbasierten Netzwerks konfigurieren:
canary:
runtimeConfig:
kubernetes:
serviceNetworking:
service: "SERVICE_NAME"
deployment: "DEPLOYMENT_NAME"
disablePodOverprovisioning: true | false
canaryDeployment:
percentages: [PERCENTAGES]
verify: true | false
Die folgende YAML-Datei zeigt, wie Sie mithilfe der Gateway API eine Bereitstellungsstrategie für ein GKE- oder GKE Enterprise-Ziel konfigurieren:
canary:
runtimeConfig:
kubernetes:
gatewayServiceMesh:
httpRoute: "HTTP_ROUTE_NAME"
service: "SERVICE_NAME"
deployment: "DEPLOYMENT_NAME"
routeUpdateWaitTime: "WAIT_TIME"
canaryDeployment:
percentages: ["PERCENTAGES"]
verify: true | false
Beachten Sie in diesem Beispiel routeUpdateWaitTime
. Dies ist enthalten, da die Gateway API den Traffic mithilfe einer HTTPRoute
-Ressource aufteilt und es manchmal zu einer Verzögerung bei der Weitergabe von Änderungen an HTTPRoute
kommt. In solchen Fällen können Anfragen gelöscht werden, da der Traffic an nicht verfügbare Ressourcen gesendet wird. Sie können routeUpdateWaitTime
verwenden, damit Cloud Deploy nach dem Anwenden von HTTPRoute
-Änderungen wartet, wenn Sie diese Verzögerung beobachten.
Die folgende YAML-Datei zeigt, wie Sie eine benutzerdefinierte oder benutzerdefinierte automatisierte Canary-Bereitstellungsstrategie konfigurieren. Die laufzeitspezifische Konfiguration im Abschnitt runtimeConfig
wird für benutzerdefinierte Canary-Tests weggelassen, ist aber in der automatisierten und benutzerdefinierten automatisierten Canary-Konfiguration enthalten.
strategy:
canary:
# Runtime configs are configured as shown in the
# Canary Deployment Strategy section of this document.
runtimeConfig:
# Manual configuration for each canary phase
customCanaryDeployment:
- name: "PHASE1_NAME"
percent: PERCENTAGE1
profiles: [ "PROFILE1_NAME" ]
verify: true | false
- …
- name: "stable"
percent: 100
profiles: [ "LAST_PROFILE_NAME" ]
verify: true|false
verify
Optionaler boolescher Wert, der angibt, ob die Bereitstellungsüberprüfung für dieses Ziel unterstützt werden soll. Der Standardwert ist false
.
Für die Aktivierung der Deployment-Überprüfung ist außerdem eine verify
-Stanza im skaffold.yaml
erforderlich. Wenn Sie diese Eigenschaft nicht angeben, schlägt der Überprüfungsjob fehl.
deployParameters
Bei Verwendung von Bereitstellungsparametern können Sie Schlüssel/Wert-Paare angeben, um für Ziele mit Labelübereinstimmung Werte an Manifeste zu übergeben.
Sie können dies auch in Ziele einbeziehen.
Bereitstellungsparameter, die in einer Bereitstellungspipeline festgelegt wurden, verwenden Labels, um Ziele abzugleichen:
deployParameters:
- values:
someKey: "value1"
matchTargetLabels:
label1: firstLabel
- values:
someKey: "value2"
matchTargetLabels:
label2: secondLabel
In diesem Beispiel werden zwei Werte für den Schlüssel angegeben und für jeden Wert gibt es ein Label. Der Wert wird für jedes Ziel mit einem übereinstimmenden Label auf das Manifest angewendet.
predeploy
- und postdeploy
-Jobs
Damit können Sie auf benutzerdefinierte Aktionen (separat definiert in skaffold.yaml
) verweisen, die vor dem Bereitstellungsjob (predeploy
) und ggf. nach dem Überprüfungsjob (postdeploy
) ausgeführt werden. Wenn kein Überprüfungsjob vorhanden ist, wird der Post-Bereitstellungsjob ausgeführt.
Bereitstellungs-Hooks werden unter strategy.standard
oder strategy.canary
so konfiguriert:
serialPipeline:
stages:
- targetId:
strategy:
standard:
predeploy:
actions: [ACTION_NAME]
postdeploy:
actions: [ACTION_NAME]
Dabei ist ACTION_NAME der in skaffold.yaml
für customActions.name
konfigurierte Name.
Sie können Jobs vom Typ predeploy
und postdeploy
mit jeder Strategie konfigurieren (z. B. standard
, canary
).
Weitere Informationen zum Konfigurieren und Verwenden von Hooks vor und nach der Bereitstellung finden Sie unter Hooks vor und nach der Bereitstellung ausführen.
Zieldefinitionen
Die Definitionsdatei der Lieferpipeline kann Zieldefinitionen enthalten. Alternativ können Sie Ziele in einer separaten Datei angeben. Sie können Zielnamen innerhalb eines Projekts wiederholen, diese müssen aber innerhalb einer Lieferpipeline einmalig sein.
Sie können Ziele in mehreren Lieferpipelines wiederverwenden. Sie können jedoch nur einmal innerhalb einer einzelnen Lieferpipeline auf ein Ziel verweisen.
Weitere Informationen finden Sie unter Definitionen benutzerdefinierter Zieltypen.
Für GKE-Ziele
Die folgende YAML-Datei zeigt, wie ein Ziel konfiguriert wird, das in einem GKE-Cluster bereitgestellt wird:
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name:
annotations:
labels:
description:
deployParameters:
multiTarget:
targetIds: []
requireApproval:
gke:
cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
internalIp:
executionConfigs:
- usages:
- [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]
workerPool:
serviceAccount:
artifactStorage:
executionTimeout:
metadata.name
Der Name dieses Ziels. Dieser Name muss global eindeutig sein.
metadata.annotations
und metadata.labels
Die Zielkonfiguration unterstützt Kubernetes-Annotationen und Labels, sie sind jedoch für Cloud Deploy nicht erforderlich.
Annotationen und Labels werden mit der Zielressource gespeichert. Weitere Informationen finden Sie unter Labels und Annotationen mit Cloud Deploy verwenden.
description
Dieses Feld verwendet einen beliebigen String, der die Verwendung des Ziels beschreibt.
deployParameters
Sie können in jedem Ziel Bereitstellungsparameter zusammen mit Werten hinzufügen. Diese Werte werden nach dem Rendern den entsprechenden Schlüsseln im Manifest zugewiesen.
Die Stanza deployParameters
nimmt Schlüssel/Wert-Paare an, wie hier gezeigt:
deployParameters:
someKey: "someValue"
someOtherKey: "someOtherValue"
Wenn Sie Bereitstellungsparameter für ein multi-target festlegen, wird der Wert für alle untergeordneten Ziele dieses Multi-Ziels dem Manifest zugewiesen.
multiTarget.targetIds: []
Dieses Attribut ist optional und wird verwendet, um ein multi-target für die parallele Bereitstellung zu konfigurieren.
Der Wert ist eine durch Kommas getrennte Liste untergeordneter Ziele.
Untergeordnete Ziele sind als normale Ziele konfiguriert und enthalten nicht das Attribut multiTarget
.
requireApproval
Gibt an, ob das Hochstufen auf dieses Ziel manuell genehmigt werden muss. Kann true
oder false
sein.
Dieses Attribut ist optional. Der Standardwert ist false
.
Wenn Sie die parallele Bereitstellung konfigurieren, können Sie eine Genehmigung nur für das Multi-Ziel und nicht für untergeordnete Ziele anfordern.
gke
Nur für GKE-Cluster der Ressourcenpfad, der den Cluster identifiziert, in dem Ihre Anwendung bereitgestellt wird:
gke:
cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
project_name
Das Google Cloud-Projekt, in dem sich der Cluster befindet.
location
Der Standort, an dem sich der Cluster befindet. Beispiel:
us-central1
. Der Cluster kann auch zonal sein (us-central1-c
).cluster_name
Der Name des Clusters, wie er in der Liste der Cluster in der Google Cloud Console angezeigt wird.
Beispiel:
gke:
cluster: projects/cd-demo-01/locations/us-central1/clusters/prod
Lassen Sie das Attribut gke
weg, wenn Sie ein multi-target konfigurieren.
Der GKE-Cluster wird stattdessen innerhalb des entsprechenden untergeordneten Ziels konfiguriert.
Unter executionConfigs
in diesem Artikel finden Sie Beschreibungen der Attribute der Ausführungsumgebung.
internalIp
Gibt an, ob der angegebene GKE-Cluster eine private IP-Adresse verwendet. Dieses Attribut ist optional. Cloud Deploy verwendet standardmäßig die öffentlich verfügbare IP-Adresse für den Cluster. Wenn eine private IP-Adresse vorhanden ist und Sie diese verwenden möchten, legen Sie dafür true
fest.
Für Cloud Run-Ziele
Die folgende YAML-Datei zeigt, wie ein Ziel konfiguriert wird, das in einem Cloud Run-Dienst bereitgestellt wird:
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name:
annotations:
labels:
description:
multiTarget:
targetIds: []
requireApproval:
run:
location: projects/[project_name]/locations/[location]
executionConfigs:
- usages:
- [RENDER | PREDEPLOY| DEPLOY | VERIFY | POSTDEPLOY]
workerPool:
serviceAccount:
artifactStorage:
executionTimeout:
metadata.name
Der Name dieses Ziels. Dieser Name darf für jede Region nur einmal vorkommen.
metadata.annotations
und metadata.labels
Die Zielkonfiguration unterstützt Annotationen und Labels, diese sind jedoch für Cloud Deploy nicht erforderlich.
Annotationen und Labels werden mit der Zielressource gespeichert. Weitere Informationen finden Sie unter Labels und Annotationen mit Cloud Deploy verwenden.
description
Dieses Feld verwendet einen beliebigen String, der die Verwendung des Ziels beschreibt.
multiTarget.targetIds: []
Dieses Attribut ist optional und wird verwendet, um ein multi-target für die parallele Bereitstellung zu konfigurieren.
Der Wert ist eine durch Kommas getrennte Liste untergeordneter Ziele.
Untergeordnete Ziele sind als normale Ziele konfiguriert und enthalten nicht das Attribut multiTarget
.
requireApproval
Gibt an, ob das Hochstufen auf dieses Ziel manuell genehmigt werden muss. Kann true
oder false
sein.
Dieses Attribut ist optional. Der Standardwert ist false
.
Wenn Sie die parallele Bereitstellung konfigurieren, können Sie eine Genehmigung nur für das Multi-Ziel und nicht für untergeordnete Ziele anfordern.
run
Der Standort, an dem der Dienst erstellt wird (nur für Cloud Run-Dienste):
run:
location: projects/[project_name]/locations/[location]
project_name
Das Google Cloud-Projekt, in dem der Dienst ausgeführt wird.
location
Der Standort, an dem sich der Dienst befindet. Beispiel:
us-central1
.
Lassen Sie das Attribut run
weg, wenn Sie ein [Multi-Ziel] konfigurieren. Der Speicherort des Cloud Run-Dienstes wird stattdessen im entsprechenden untergeordneten Ziel konfiguriert.
Unter executionConfigs
in diesem Artikel finden Sie Beschreibungen der Attribute der Ausführungsumgebung.
Für GKE Enterprise-Ziele
Die Zielkonfiguration für die Bereitstellung in einem GKE-Cluster ähnelt der Konfiguration eines Ziels für ein GKE-Ziel, mit der Ausnahme, dass das Attribut anthosCluster.membership
anstelle von gke.cluster
ist, der Ressourcenpfad anders ist und internalIp
nicht anwendbar ist.
anthosCluster:
membership: projects/[project_name]/locations/global/memberships/[membership_name]
project_name
Das Google Cloud-Projekt, in dem sich der GKE Enterprise-Cluster befindet.
/location/global/
Der Standort, an dem der Cluster registriert ist.
global
, in allen Fällen.membership_name
Der Name der GKE Enterprise-Clustermitgliedschaft.
Beispiel:
anthosCluster:
membership: projects/cd-demo-01/locations/global/memberships/prod
Lassen Sie das Attribut anthosCluster
weg, wenn Sie ein [Multi-Ziel] konfigurieren. Der GKE Enterprise-Cluster wird stattdessen innerhalb des entsprechenden untergeordneten Ziels konfiguriert.
Weitere Informationen zum Bereitstellen in GKE-Clustern finden Sie unter In Anthos-Nutzerclustern bereitstellen.
Für benutzerdefinierte Ziele
Die Konfiguration für benutzerdefinierte Ziele ähnelt allen anderen Zieltypen, mit der Ausnahme, dass sie weder eine gke
-Stanza noch eine run
- oder anthosCluster
-Stanza enthält.
Stattdessen enthalten benutzerdefinierte Ziele eine customTarget
-Stanza:
customTarget:
customTargetType: [CUSTOM_TARGET_TYPE_NAME]
Dabei ist CUSTOM_TARGET_TYPE_NAME
der Name, den Sie in der Definition des benutzerdefinierten Zieltyps verwendet haben.
Beispiel:
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name: sample-env
customTarget:
customTargetType: basic-custom-target
executionConfigs
Eine Reihe von Feldern, um eine nicht standardmäßige Ausführungsumgebung für dieses Ziel anzugeben.
usages
Entweder
RENDER
oderDEPLOY
oder beides sowiePREDEPLOY
,VERIFY
oderPOSTDEPLOY
, wenn die Überprüfung oder Bereitstellungs-Hooks für das Ziel aktiviert sind. Sie geben an, welche der Vorgänge für dieses Ziel in der Ausführungsumgebung ausgeführt werden sollen. Wenn Sie angeben möchten, dass eine benutzerdefinierte Ausführungsumgebung für den Hook, das Rendering, die Bereitstellung, den Postdeploy-Hook und die Überprüfung vor der Bereitstellung und für die Überprüfung verwendet werden soll, konfigurieren Sie diese wie folgt:usages: - RENDER - PREDEPLOY - DEPLOY - VERIFY - POSTDEPLOY
Wenn die Überprüfung in der Pipelinephase aktiviert ist und Sie
VERIFY
nicht in einerusages
-Stanza angeben, verwendet Cloud Deploy die standardmäßige Ausführungsumgebung zur Überprüfung. Die Hooks „Predeploy“ und „postdeploy“ funktionieren auf die gleiche Weise.Wenn jedoch eine benutzerdefinierte Ausführungsumgebung für
RENDER
undDEPLOY
vorhanden ist, müssen Sie eine fürVERIFY
,PREDEPLOY
ODERPOSTDEPLOY
angeben, wenn sie in der Bereitstellungspipeline konfiguriert sind.VERIFY
,PREDEPLOY
undPOSTDEPLOY
können sich im selbenusages
wieRENDER
oderDEPLOY
oder in einer separatenusages
befinden.Sie können
usages.VERIFY
,usages.PREDEPLOY
oderusages.POSTDEPLOY
nur dann angeben, wennRENDER
undDEPLOY
in derselben oder in separaten benutzerdefinierten Ausführungsumgebungen angegeben sind.workerPool
Konfiguration für den zu verwendenden Worker-Pool. Dabei wird ein Ressourcenpfad angegeben, der den Cloud Build-Worker-Pool identifiziert, der für dieses Ziel verwendet werden soll. Beispiel:
projects/p123/locations/us-central1/workerPools/wp123
.Wenn Sie den Cloud Build-Standardpool verwenden möchten, lassen Sie dieses Attribut weg.
Ein bestimmtes Ziel kann zwei
workerPool
s haben (eine fürRENDER
und eine fürDEPLOY
). Wenn Sie den Standardpool konfigurieren, können Sie ein alternatives Dienstkonto, einen alternativen Speicherort oder beides angeben.serviceAccount
Name des Dienstkontos, das für diesen Vorgang verwendet werden soll (
RENDER
oderDEPLOY
) für dieses Ziel.artifactStorage
Der Cloud Storage-Bucket, der für diesen Vorgang verwendet werden soll (
RENDER
oderDEPLOY
) für dieses Ziel anstelle des Standard-Buckets.executionTimeout
Optional. Legt das Zeitlimit in Sekunden für Vorgänge fest, die Cloud Build für Cloud Deploy ausführt. Standardmäßig beträgt dies
3600
Sekunden (1 Stunde).
Beispiel:executionTimeout: "5000s"
Alternative unterstützte Syntax
Die in diesem Dokument beschriebene executionConfigs
-Konfiguration ist neu. Die vorherige Syntax wird weiterhin unterstützt:
executionConfigs:
- privatePool:
workerPool:
serviceAccount:
artifactStorage:
usages:
- [RENDER | DEPLOY]
- defaultPool:
serviceAccount:
artifactStorage:
usages:
- [RENDER | DEPLOY]
Wenn Sie eine executionConfigs
-Stanza für ein multi-target konfigurieren, kann jedes untergeordnete Ziel diese Ausführungsumgebung von diesem Multi-Ziel übernehmen.
Definitionen benutzerdefinierter Zieltypen
In diesem Abschnitt werden die Felder beschrieben, die zum Definieren von benutzerdefinierten Zieltypen verwendet werden.
Wie bei Standardzielen und Automatisierungen können CustomTargetType
-Definitionen in die Definition der Bereitstellungspipeline oder in einer oder mehreren separaten Dateien aufgenommen werden.
Die folgende YAML-Datei zeigt, wie ein benutzerdefinierter Zieltyp konfiguriert wird:
apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
name: [CUSTOM_TARGET_TYPE_NAME]
annotations:
labels:
description:
customActions:
renderAction: [RENDER_ACTION_NAME]
deployAction: [DEPLOY_ACTION_NAME]
includeSkaffoldModules:
- configs:
# either:
googleCloudStorage:
source:
path:
# or:
git:
repo:
path:
ref:
Wobei:
[CUSTOM_TARGET_TYPE_NAME]
Ist ein beliebiger Name, den Sie dieser benutzerdefinierten Zieltypdefinition geben. Auf diesen Namen wird in der Zieldefinition für jedes Ziel verwiesen, das den von Ihnen definierten benutzerdefinierten Zieltyp verwendet.
[RENDER_ACTION_NAME]
Ist der Name der benutzerdefinierten Renderingaktion. Dieser Wert ist der in
skaffold.yaml
definiertecustomAction.name
.[DEPLOY_ACTION_NAME]
Ist der Name der benutzerdefinierten Bereitstellungsaktion. Dieser Wert ist der in
skaffold.yaml
definiertecustomAction.name
.Informationen zu
includeSkaffoldModules
finden Sie unter Remote-Saffold-Konfigurationen verwenden.
Automatisierungsdefinitionen
In diesem Abschnitt werden die Felder beschrieben, die zum Definieren der Cloud Deploy-Ressourcen zur Automatisierung verwendet werden.
Wie bei Zielen können Automation
-Definitionen in die Definition der Bereitstellungspipeline oder in einer oder mehreren separaten Dateien aufgenommen werden.
Weitere Informationen zur Automatisierung in Cloud Deploy finden Sie in der Dokumentation zur Automatisierung.
Die folgende YAML-Datei zeigt, wie eine Automatisierung konfiguriert wird. Beachten Sie, dass sich die Details einer Automatisierungsregel je nach Regel unterscheiden. Informationen zur Konfiguration der verfügbaren Regeltypen für die Automatisierung finden Sie im Dokument Automatisierungsregeln verwenden.
apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
name: [PIPELINE_NAME]/[PURPOSE]
labels:
annotations:
description: [DESCRIPTION]
suspended: true | false
serviceAccount: [SERVICE_ACCOUNT_ID]
selector:
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 sind exklusiv für die Bereitstellungspipelines verfügbar, für die sie erstellt werden. Das heißt, Sie können eine Automatisierung nicht für mehr als eine Bereitstellungspipeline freigeben.[PURPOSE]
Ist ein anderer aussagekräftiger Name für diese Automatisierung? Üblicherweise ist dies eine automatisierte Aktion. Beispiel:
my-app-pipeline/promote
.labels
undannotations
sind alle Labels oder Anmerkungen, die Sie dieser Automatisierung zuordnen möchten.[DESCRIPTION]
Ist eine optionale Beschreibung für diese Automatisierung.
suspended
true
oderfalse
, was angibt, ob diese Automatisierung aktiv oder ausgesetzt ist. Ist die Richtlinie auftrue
gesetzt, wird die Automatisierung nicht verwendet. Dies kann nützlich sein, um eine Automatisierung zu testen, ohne die Bereitstellungspipeline zu beeinträchtigen.[SERVICE_ACCOUNT_ID]
Ist die ID des Dienstkontos, das zum Ausführen der Automatisierung verwendet wird. Wenn die Automatisierung beispielsweise das
promoteReleaseRule
verwendet, führt dieses Dienstkonto das Hochstufen des Release durch und benötigt daher die Berechtigungen, die zum Hochstufen eines Release erforderlich sind.Für diese Property ist ein Wert erforderlich. Cloud Deploy verwendet nicht das Standarddienstkonto für Automatisierungen.
Dieses Dienstkonto muss die folgenden Berechtigungen haben:
actAs
-Berechtigung, um die Identität des Ausführungsdienstkontos zu übernehmen.Berechtigung zum Ausführen des automatisierten Vorgangs, z. B.
clouddeploy.releases.promote
zum Hochstufen eines Release oderclouddeploy.rollouts.advance
zum Fortsetzen einer Rollout-Phase.
[TARGET_ID]
Ist die ID des Ziels, für das diese Automatisierung verwendet wird. Eine Automatisierung ist zwar an eine Bereitstellungspipeline gebunden, wird aber nur für die angegebenen Ziele ausgeführt.
Sie können dieses Feld auf
*
setzen, um alle Ziele in der Bereitstellungspipeline auszuwählen.[LABEL_KEY]:[LABEL_VALUE]
Ist ein Schlüssel/Wert-Paar, das mit einem für das Ziel definierten Schlüssel/Wert-Paar abgeglichen wird. Dadurch werden alle mit der Bereitstellungspipeline verknüpften Ziele ausgewählt, die dasselbe Label und denselben Wert haben.
[RULE_TYPE]
Der Name der Automatisierungsregel, die für diese Automatisierung verwendet wird. Dies ist entweder
promoteReleaseRule
oderadvanceRolloutRule
. Sie können mehr als eine Regel in einer Automatisierung verwenden, einschließlich mehrererRULE_TYPE
-Regeln. Beispielsweise können Sie mehrerepromoteReleaseRule
-Regeln in derselben Automatisierung verwenden. Weitere Informationen[RULE_NAME]
Ein Name für die Regel. Dieser Name darf innerhalb der Bereitstellungspipeline nur einmal vorkommen. Für diese Property ist ein Wert erforderlich.
[RULE-SPECIFIC_CONFIG]
Die Konfiguration ist für jeden unterstützten Automatisierungstyp unterschiedlich. Diese Konfigurationen werden unter Automatisierungsregeln verwenden beschrieben.
Nächste Schritte
Weitere Informationen zum Einrichten einer Lieferpipeline für Ihre Anwendung.
Erfahren Sie, wie Sie Manifeste verwalten.
Vermeiden Sie Nichtübereinstimmungen zwischen Ihrem Release und Ihrer Lieferpipeline. Dazu können sollten Sie mehr über Pipelineinstanzen erfahren.