Parameter an die Bereitstellung übergeben

Mit Cloud Deploy können Sie Parameter für Ihren Release übergeben. werden dem Manifest oder den Manifesten übermittelt, 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:

  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.

      Dafür gibt es drei Möglichkeiten, die hier beschrieben werden.

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

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

  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. Die für eine Phase definierten Parameter identifizieren 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.

  • Über die Befehlszeile beim Erstellen eines Release

    Sie geben den Parameter und seinen Wert mit dem Flag --deploy-parameters an mit dem Befehl gcloud 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.

Parameter mit benutzerdefinierten Zielen bereitstellen

Sie können beliebige Bereitstellungsparameter als Umgebungsvariablen in benutzerdefinierten Zielen. Verwenden Sie dabei die Methode syntax für benutzerdefinierten Zielen.

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; bestimmtes 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: bestimmtes 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 und from-param: weist Cloud Deploy, dass der Platzhalter deploy-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 verwenden, 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 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 zwei values 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.

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

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

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

  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.

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

  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