Parameter an die Bereitstellung übergeben

Mit Cloud Deploy können Sie Parameter für Ihre Version übergeben. Diese Werte werden an das Manifest oder die Manifeste übergeben, bevor sie auf die 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.

Fügen Sie dazu einfach Platzhalter in Ihr Manifest ein und legen Sie die Werte für diese Platzhalter entweder in Ihrer Cloud Deploy-Auslieferungspipeline oder in der Zielkonfiguration oder beim Erstellen einer Version fest.

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:

  1. 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.

      Dazu gibt es drei Möglichkeiten, die hier beschrieben werden.

  2. Wenn Sie einen Release erstellen, wird Ihr Manifest gerendert.

    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. Das Rendering wird von Skaffold ausgeführt.

    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.

  3. 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 wurden bereits Werte auf Manifestvorlagen angewendet, einige Werte ersetzt und Cloud Deploy-spezifische Labels hinzugefügt. Die Werte für diese Bereitstellungsparameter nach dem Rendering ersetzt werden. Die Unterschiede zwischen Manifestvorlagen und werden Bereitstellungsparameter beschrieben, hier.

  4. 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 ersetzen. Die für eine Phase definierten Parameter kennzeichnen ein Label, und das entsprechende Ziel für diese Phase muss ein passendes Label haben.

  • In der Zieldefinition

    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.

  • In der Befehlszeile, wenn Sie einen Release erstellen

    Sie fügen den Parameter und seinen Wert mit dem Flag --deploy-parameters in den Befehl gcloud deploy releases create ein.

    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

Bereitstellungsparameter, wie in diesem Artikel beschrieben, unterscheiden sich durch die Syntax von Platzhaltern in einem Vorlagenmanifest. 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.

  • Es ist nicht möglich, zwei Schlüssel mit demselben Namen auf dasselbe Ziel anzuwenden.

  • Der Wert kann leer sein, hat aber maximal 512 Zeichen.

  • Platzhalter für Bereitstellungsparameter können nicht für Helm-Konfigurationswerte verwendet werden, sondern müssen gemäß Konvention übergeben werden.

Bereitstellungsparameter konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie Werte für Bereitstellungsparameter konfigurieren, die auf Ihr Kubernetes-Manifest, Ihren Cloud Run-Dienst oder Ihre Helm-Vorlage angewendet werden.

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

    Dieser Wert wird verwendet, wenn für diese Property in der Befehlszeile oder in der Pipeline- oder Zielkonfiguration keine Werte angegeben sind.

  • # from-param:

    Verwendet ein Kommentarzeichen, um Cloud Deploy auszulösen deploy-parameters-Anweisung und from-param: weist Cloud Deploy, dass der Platzhalter deploy-parameters folgt.

  • ${VAR_NAME}

    Ist der Platzhalter, der ersetzt werden soll. 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.

  1. 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

  2. Konfigurieren Sie Ihre Bereitstellungspipeline so, dass deployParameters für die entsprechende Pipelinephase enthalten ist.

    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-Strophe zwei values, die jeweils Folgendes haben:

    • Der Variablenname, der mit dem Namen der Variablen im Manifest übereinstimmt

    • Einen Wert für diese Variable

    • Ein oder mehrere Labels (optional), die mit zielspezifischen Labels abgeglichen werden sollen

      Wenn Sie kein Label in einer matchTargetLabels-Stanza angeben, wird dieser Wert wird für alle Ziele in der Phase verwendet.

  3. 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 festgelegten values auf alle untergeordneten Ziele angewendet. Wenn Sie jedoch für denselben Parameter mehr als einen Wert festlegen, schlägt der Release fehl.

Nachdem jedes Manifest gerendert wurde, fügt Cloud Deploy den Wert für jede Variable in das gerenderte Manifest ein.

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.

  1. 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 Standardwert example1 gesetzt. und envvar2 ist auf den Standardwert example2 eingestellt.

  2. Konfigurieren Sie Ihre Ziele so, dass sie Folgendes enthalten: deployParameters

    Für jeden einzuschließenden Parameter geben Sie Folgendes an:

    • Der Schlüsselname, der mit dem Schlüssel (Variable) übereinstimmt, den Sie im Manifest festgelegt haben.

    • 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

So übergeben Sie Parameter und Werte an die Version:

  1. Konfigurieren Sie Ihr Kubernetes-Manifest oder Ihre Cloud Run-Dienstdefinition mit einem Parameter anstelle des Werts, 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. Dies geschieht mithilfe der Methode --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}.

  2. Füge beim Erstellen eines Release die Option --deploy-parameters in die gcloud 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 customTarget/vertexAIModel, darauf verweisen als CLOUD_DEPLOY_customTarget_vertexAIModel.

Bereitstellungsparameter mit Bereitstellungshooks

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 eine bestimmte Version festgelegt wurden. Sie sind werden in einer Tabelle auf der Seite Release-Details und in der Befehlszeile angezeigt (gcloud deploy releases describe).

  1. Klicken Sie auf der Hauptseite von Cloud Deploy auf die Bereitstellungspipeline, enthält die gewünschte Veröffentlichung.

  2. 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.

In der Google Cloud Console angezeigte Bereitstellungsparameter und -werte

Nächste Schritte