Mit Cloud Deploy können Sie Parameter für Ihren Release übergeben.
werden dem Manifest oder den Manifesten übergeben, bevor diese Manifeste
die auf ihre jeweiligen Ziele angewendet werden. Diese Ersetzung erfolgt nach Manifesten
gerendert werden. Dies ist der letzte Schritt im
Renderingvorgang von Cloud Deploy Werte werden für alle Manifeste bereitgestellt
in Ihrer skaffold.yaml
-Datei identifiziert, die den entsprechenden
Platzhalter.
Sie müssen nur Platzhalter in Ihr Manifest einfügen und die Werte für diesen Platzhalter in Ihrer Cloud Deploy-Bereitstellungspipeline oder Zielkonfiguration oder beim Erstellen eines Release.
In diesem Artikel erfahren Sie, wie das funktioniert.
Vorteile von Bereitstellungsparametern
Ein typischer Anwendungsfall ist die Anwendung verschiedener Werte auf Manifeste für verschiedene Ziele in einer parallelen Bereitstellung zu verwenden. Aber Sie können Bereitstellungsparameter für alle Elemente verwenden, für die ein Schlüssel/Wert-Paar nach dem Rendering erforderlich ist Substitution in Ihrem Manifest.
Funktionsweise
In den folgenden Schritten wird der allgemeine Prozess zum Konfigurieren der Bereitstellung beschrieben und Bereitstellung von Werten:
Sie konfigurieren die Bereitstellungsparametrisierung wie beschrieben hier.
Der Support umfasst
Fügen Sie Ihrem Manifest die Platzhalter hinzu.
Fügen Sie Werte für diese Platzhalter hinzu.
Dafür gibt es drei Möglichkeiten, die hier beschrieben werden.
Wenn du einen Release erstellst, wird dein Manifest gerendert werden.
Wenn Sie mit einer Manifest-Vorlage beginnen, werden die Werte jetzt auf die Vorlage angewendet Variablen. Wenn Sie mit einem Raw-Manifest beginnen, bleibt es unverändert. Dieses wird von Skaffold gerendert.
Sie können Ihr Manifest aber auch durch zusätzliche Variablen definieren, für welche Werte werden beim Rendering nicht angewendet. Dies sind die beschriebenen Bereitstellungsparameter in diesem Dokument.
Beim Erstellen des Release werden alle Bereitstellungsparameter in eine dWörterbuch, mit dem Werte vor dem Präfix Manifeste angewendet werden.
Nach dem Rendering ersetzt Cloud Deploy Werte für die Bereitstellung Parameter.
Dies sind die Werte, die Sie im ersten Schritt konfiguriert haben.
Beim rendering-Prozess wurden bereits Werte auf Manifestvorlagen angewendet, Ersetzen einiger Werte und Hinzufügen von Labels, Cloud Deploy: Die Werte für diese Bereitstellungsparameter nach dem Rendering ersetzt werden. Die Unterschiede zwischen Manifestvorlagen und werden Bereitstellungsparameter beschrieben, hier.
Das Manifest wird auf die Ziellaufzeit angewendet, um Ihre Anwendung bereitzustellen.
Dazu gehören die Werte, die zum Zeitpunkt des Renderings ersetzt wurden, sowie die Werte für Bereitstellungsparameter
Verschiedene Möglichkeiten zum Übergeben von Werten
Sie können Parameter und Werte für diese Parameter auf drei Arten angeben:
In der Definition der Bereitstellungspipeline
Sie geben den Parameter und seinen Wert in der Definition für eine Phase in der Entwicklung der Bereitstellungspipeline. Der Parameter wird an die Ziel-URL diese Phase dargestellt wird. Wenn diese Phase auf ein Multi-Ziel verweist, ist der Parameter Werte, die hier festgelegt werden, werden für alle untergeordneten Ziele verwendet.
Mit dieser Methode können Sie einen Wert für alle Releases innerhalb einer bestimmten Pipeline für alle betroffenen Ziele. Die für eine Phase definierten Parameter kennzeichnen ein Label, und das entsprechende Ziel für diese Phase muss ein passendes Label haben.
-
Sie konfigurieren den Parameter und seinen Wert in der Definition für das Ziel selbst. Mit dieser Methode können Sie einen Wert für dieses Ziel für alle Releases ersetzen.
Über die Befehlszeile beim Erstellen eines Release
Sie geben den Parameter und seinen Wert mit dem Flag
--deploy-parameters
an mit dem Befehlgcloud deploy releases create
.Mit dieser Methode können Sie einen Wert bei der Erstellung des Release ersetzen, in die Manifeste aller betroffenen Ziele ein.
Die entsprechende Konfiguration wird ausführlicher erläutert. hier.
Kann ich mehrere dieser Methoden verwenden?
Ja, Sie können Bereitstellungsparameter in die Pipelinephase, im Zielbereich
config und und in die Befehlszeile eingeben. Das Ergebnis ist, dass alle Parameter
akzeptiert und zum Wörterbuch hinzugefügt. Wird jedoch ein bestimmter Parameter
an mehreren Stellen, aber mit unterschiedlichen Werten schlägt der Befehl gcloud deploy releases
create
mit einem Fehler fehl.
Wie unterscheidet sich das von Manifestvorlagen
Die in diesem Artikel beschriebenen Bereitstellungsparameter unterscheiden sich Platzhalter in einer Manifest-Vorlage durch die Syntax. Aber wenn Sie sich fragen, warum Sie Parameter bereitstellen sollten, Standardtechniken für Manifestvorlagen stehen, sehen Sie in der folgenden Tabelle für unterschiedliche Zwecke:
Verfahren | Ersetzungszeit | Gilt für |
---|---|---|
Manifestvorlage | Rendering phase | Bestimmter Release; spezifisches Ziel |
Über die Befehlszeile | Nach dem Rendern | Bestimmter Release; alle Ziele |
Pipeline für die Bereitstellung | Nach dem Rendern | Alle Releases: Spezifische Ziele (nach Label) |
Entspricht Ziel | Nach dem Rendern | Alle Releases: spezifisches Ziel |
In diesem Dokument geht es nur um Bereitstellungsparameter (in Befehlszeile, Pipeline und Ziel) und nicht Manifestvorlagen.
Beschränkungen
Für jeden Parametertyp können maximal 25 Parameter verwendet werden. Parameter.
Ein untergeordnetes Ziel kann zusätzlich bis zu 25 Parameter vom übergeordneten Ziel übernehmen mehrere Ziele und maximal 100 Parameter für die Ziele, einschließlich der in der Pipelinephase festgelegt.
Der Schlüsselname ist auf maximal 63 Zeichen beschränkt. Regulärer Ausdruck:
^[a-zA-Z0-9]([-A-Za-z0-9_.]{0,61}[a-zA-Z0-9])?$
Eine Ausnahme hiervon ist, wenn Sie einen Bereitstellungsparameter als in einem benutzerdefinierten Ziel verwenden, müssen Sie zwischen dem das Keyword
customTarget
und den Variablennamen (customTarget/VAR_NAME
). Weitere Informationen finden Sie unter Erforderliche Ein- und Ausgaben für die unterstützte Syntax.Das Präfix
CLOUD_DEPLOY_
ist reserviert und kann nicht für einen Schlüsselnamen verwendet werden.Zwei Schlüssel mit demselben Namen können nicht auf dasselbe Ziel angewendet werden.
Der Wert kann leer sein, hat aber maximal 512 Zeichen.
Platzhalter für Bereitstellungsparameter können nicht verwendet werden für Helm-Konfigurationswerte aber müssen gemäß der Konvention übergeben werden.
Bereitstellungsparameter konfigurieren
In diesem Abschnitt wird beschrieben, wie Sie Bereitstellungsparameterwerte konfigurieren, die auf Ihr Kubernetes-Manifest, Ihren Cloud Run-Dienst, oder Ihre Helm-Vorlage.
Neben der Konfiguration dieser Schlüssel/Wert-Paare müssen Sie den Platzhalter oder in Ihr Manifest einfügen, wie in diesem Abschnitt beschrieben.
Platzhalter zum Manifest hinzufügen
Im Kubernetes-Manifest (für GKE) oder im YAML-Dienst des Dienstes (für Cloud Run) können Sie Platzhalter für beliebige Werte nach dem Rendering ersetzen.
Syntax
Für Releases, in denen der Helm-Renderer nicht mit Skaffold, verwenden Sie die folgende Syntax für Ihre Platzhalter:
[PROPERTY]: [DEFAULT_VALUE] # from-param: ${VAR_NAME}
In dieser Zeile...
PROPERTY:
Ist das Konfigurationsattribut in Ihrem Kubernetes-Manifest oder YAML-Datei des Cloud Run-Dienstes.
DEFAULT_VALUE
Ist ein Wert, der verwendet wird, wenn für diese Eigenschaft keine Werte im oder in der Pipeline bzw. der Zielkonfiguration.
# from-param:
Verwendet ein Kommentarzeichen, um Cloud Deploy auszulösen
deploy-parameters
-Anweisung undfrom-param:
weist Cloud Deploy, dass der Platzhalterdeploy-parameters
folgt.${VAR_NAME}
Der zu ersetzende Platzhalter. Muss mit dem Schlüssel eines Schlüssel/Wert-Paars übereinstimmen in der Bereitstellungspipeline bzw. in der Zielkonfiguration oder bei der Releaseerstellung angegeben werden.
Parameter für Helm-Diagrammwerte
Wenn Sie ein Helm-Diagramm rendern,
Konfigurationswerte,
und Sie diese Werte mit Bereitstellungsparametern festlegen möchten,
muss deren Namen mit den Werten der Helm-Konfigurationen übereinstimmen, die Sie festlegen möchten.
Alle Bereitstellungsparameter werden zum Zeitpunkt des Renderings als --set
-Argumente an Helm übergeben.
Dabei ist keine Änderung der skaffold.yaml
erforderlich.
Wenn Ihre skaffold.yaml
beispielsweise ein Helm-Diagramm installiert,
Konfigurationsparameter von webserver.port
, um anzugeben, an welchen Port der Webserver angeschlossen ist
und Sie möchten dies dynamisch von einer Bereitstellung
Parameter erstellen, müssen Sie einen Bereitstellungsparameter
Name webserver.port
durch den gewünschten Wert für den Webserverport.
Wenn Sie also in skaffold.yaml
nicht nur auf Helm-Vorlagen verweisen,
aber auch durch die Erstellung
lassen sich mithilfe des Tools
Syntax der Standard-Helm-Variable
von {{ .Values.VAR_NAME }}
in Ihren Helm-Vorlagen.
Wenn beispielsweise der Bereitstellungsparameter webserver.port
konfiguriert ist,
könnten wir sie so nutzen:
apiVersion: apps/v1
kind: Deployment
metadata:
name: webserver
spec:
replicas: 3
selector:
matchLabels:
app: webserver
template:
metadata:
labels:
app: webserver
spec:
containers:
- name: webserver
image: gcr.io/example/webserver:latest
ports:
- containerPort: {{ .Values.webserver.port }} # replaced by deploy parameter `webserver.port`.
name: web
env:
- name: WEBSERVER_PORT
value: {{ .Values.webserver.port }} # replaced by deploy parameter `webserver.port`.
Parameter zur Pipelinephase hinzufügen
Sie können einer Phase in der Bereitstellungspipeline Schlüssel/Wert-Paare hinzufügen. Dies ist nützlich bei parallelen Bereitstellungen, um zwischen zwischen untergeordneten Zielen.
Platzhalter zu Kubernetes-Manifest oder zu Cloud Run hinzufügen wie hier beschrieben.
Beispiel:
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 1 # from-param: ${deploy_replicas} selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80
Konfigurieren Sie Ihre Bereitstellungspipeline so, dass
deployParameters
für den der entsprechenden Pipelinephase.Die folgende YAML-Datei ist die Konfiguration für eine Pipelinephase, deren Ziel ein Multi-Ziel, das in diesem Fall zwei untergeordnete Ziele hat:
serialPipeline: stages: - targetId: dev profiles: [] - targetId: prod # multi-target profiles: [] deployParameters: - values: deploy_replicas: 1 log_level: "NOTICE" matchTargetLabels: # optional, applies to all resources if unspecified; AND'd my-app: "post-render-config-1" - values: deploy_replicas: 2 log_level: "WARNING" matchTargetLabels: # optional, applies to all resources if unspecified; AND'd my-app: "post-render-config-2"
In dieser Bereitstellungspipeline-Konfiguration enthält die
deployParameters
-Stanza enthält zweivalues
mit jeweils folgendem Inhalt:Der Variablenname, also den gleichen Namen wie die Variable, die Sie in der Manifest
Ein Wert für diese Variable
Ein oder mehrere Labels (optional) für den Abgleich mit zielspezifischen Labels
Wenn Sie kein Label in einer
matchTargetLabels
-Stanza angeben, wird dieser Wert wird für alle Ziele in der Phase verwendet.
Wenn du
matchTargetLabels
angegeben hast , musst du auch fügen Sie Labels für die Ziele hinzu, um sie abzugleichen. Auf diese Weise Geben Sie an, welcher Wert welchem untergeordneten Ziel zugewiesen werden soll.Das Ziel muss mit allen Labels übereinstimmen, die in der
values
-Stanza festgelegt sind.Wenn Sie
matchTargetLabels
weglassen, werden die für die Pipeline festgelegtenvalues
auf alle untergeordneten Ziele angewendet. Wenn Sie aber mehr als einen Wert für denselben fehl, schlägt der Release fehl.
Nach dem Rendern jedes Manifests fügt Cloud Deploy den Wert für in das gerenderte Manifest.
Parameter zur Zielkonfiguration hinzufügen
Sie können einem Ziel Schlüssel/Wert-Paare hinzufügen. Wenn Sie Bereitstellungsparameter verwenden, zwischen mehreren untergeordneten Zielen unterscheiden, sie für diese untergeordneten Ziele konfigurieren nicht auf das Multi-Ziel.
Kubernetes-Manifest konfigurieren oder Cloud Run-Dienstdefinition mit einem Parameter anstelle des Werts die Sie bei der Bereitstellung festlegen möchten.
Beispiel:
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 env: - name: envvar1 value: example1 # from-param: ${application_env1} - name: envvar2 value: example2 # from-param: ${application_env2}
In diesem Manifest ist der Parameter
envvar1
auf den Standardwertexample1
gesetzt. undenvvar2
ist auf den Standardwertexample2
eingestellt.Konfigurieren Sie Ihre Ziele so, dass sie Folgendes enthalten:
deployParameters
Für jeden einzuschließenden Parameter geben Sie Folgendes an:
Der Schlüsselname, also den gleichen Namen wie der Schlüssel (Variable), den Sie in der Manifests.
Ein Wert für diesen Schlüssel. Wenn Sie keinen Wert angeben, wird der Standardwert im Manifest verwendet wird.
Die folgende YAML-Datei ist die Konfiguration für zwei Ziele. Jedes Ziel umfasst Eine
deployParameters
-Stanza, die einen Wert festlegt. Jedes Ziel enthält auch ein Label, das mit Bereitstellungsparametern abgeglichen werden soll in einer Pipelinephase konfiguriert.apiVersion: deploy.cloud.google.com/v1beta1 kind: Target metadata: name: prod1 labels: my-app: "post-render-config-1" description: development cluster deployParameters: application_env1: "newValue1" --- apiVersion: deploy.cloud.google.com/v1beta1 kind: target metadata: name: prod2 labels: my-app: "post-render-config-2" description: development cluster deployParameters: application_env1: "newValue2"
Wenn der Release erstellt wird, aber nach dem Rendern der Manifeste Cloud Deploy fügt diese Werte den gerenderten Manifesten hinzu, wenn sie die zugehörigen Schlüssel enthalten.
Parameter beim Erstellen des Release übergeben
Führen Sie die folgenden Schritte aus, um Parameter und Werte an den Release zu übergeben:
Kubernetes-Manifest konfigurieren oder Cloud Run-Dienstdefinition mit einem Parameter anstelle des Wert, den Sie bei der Bereitstellung festlegen möchten.
Beispiel:
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx annotations: commit: defaultShaValue # from-param: ${git-sha} spec: containers: - name: nginx image: nginx:1.14.2
In diesem Beispiel ist das Commit-SHA als Variable namens
${git-sha}
festgelegt. Ein Wert dafür wird beim Erstellen des Release übergeben. Dazu wird der Parameter--deploy-parameters=
, wie im nächsten Schritt beschrieben.Die Syntax für diese Variable lautet
$
plus dem Variablennamen in geschweiften Klammern. In dieser Beispiel:${git-sha}
.Füge beim Erstellen eines Release die Option
--deploy-parameters
in diegcloud deploy releases create
-Befehl.--deploy-parameters
verwendet eine durch Kommas getrennte Liste von Schlüssel/Wert-Paaren, wobei Der Schlüssel ist der Platzhalter, den Sie dem Manifest hinzugefügt haben.Der Befehl sieht in etwa so aus:
gcloud deploy releases create test-release-001 \ --project=my-example-project \ --region=us-central1 \ --delivery-pipeline=my-params-demo-app-1 \ --images=my-app-image=gcr.io/google-containers/nginx@sha256:f49a843c290594dcf4d193535d1f4ba8af7d56cea2cf79d1e9554f077f1e7aaa \ --deploy-parameters="git-sha=f787cac"
Wenn der Release erstellt wird, aber nach dem Rendern des Manifests Cloud Deploy stellt die Werte für die gerenderten Manifeste bereit, wenn sie die zugehörigen Schlüssel enthalten.
Parameter mit benutzerdefinierten Zielen bereitstellen
Sie können beliebige Bereitstellungsparameter als Umgebungsvariable in benutzerdefinierten Zielen. Verwenden Sie dabei die Methode syntax für benutzerdefinierten Zielen.
Bereitstellungsparameter, die als Eingaben für benutzerdefinierte Ziele dienen, können mit
customTarget/
, z. B. customTarget/vertexAIModel
. Wenn Sie diese
Präfix verwenden, verwenden Sie die folgende Syntax, wenn Sie auf einen Bereitstellungsparameter als
Umgebungsvariable:
CLOUD_DEPLOY_customTarget_[VAR_NAME]
Dabei ist VAR_NAME
der Name nach dem Schrägstrich im
Bereitstellungsparameter angeben. Wenn Sie beispielsweise eine
Bereitstellungsparameter mit dem Namen customTarget/vertexAIModel
, darauf verweisen als
CLOUD_DEPLOY_customTarget_vertexAIModel
.
Parameter mit Bereitstellungs-Hooks bereitstellen
Sie können beliebige Bereitstellungsparameter als Umgebungsvariable in Bereitstellungs-Hooks.
Parameter mit Bereitstellungsüberprüfung bereitstellen
Sie können beliebige Bereitstellungsparameter als Umgebungsvariable in Bereitstellungsprüfung
Alle Parameter für einen Release ansehen
Sie können sich die Parameter ansehen, die für einen bestimmten Release festgelegt wurden. Sie sind
werden in einer Tabelle auf der Seite Release-Details und in der Befehlszeile angezeigt
(gcloud deploy releases describe
)
Klicken Sie auf der Hauptseite von Cloud Deploy auf die Bereitstellungspipeline, enthält die gewünschte Veröffentlichung.
Wähle auf der Seite Release-Details den Tab Artefakte aus.
Alle Bereitstellungsparameter, die für diesen Release festgelegt wurden, werden in einer Tabelle angezeigt. durch den Variablennamen und den Variablenwert in einer Spalte und das betroffene Ziel oder Ziele in der anderen Spalte.