Cloud Deploy in Ihr CI-System einbinden

In diesem Dokument wird beschrieben, wie Sie die Cloud Deploy-Bereitstellungspipeline aufrufen aus Ihrem Continuous-Integration-System (CI) entfernt.

Das Einbinden von Cloud Deploy in Ihr CI-System ist so einfach wie das Hinzufügen eines Aufrufs zu Cloud Deploy gcloud Befehlszeile. Dieser Aufruf findet an Ihrer CI-Pipeline statt, an der Ihre Anwendung bereitgestellt werden kann.

Hinweis: Ihr CI-Prozess ist für das Erstellen und Platzieren von Images verantwortlich, sodass Cloud Deploy kann für die Bereitstellung darauf verweisen.

Hinweise

Die Anleitung auf dieser Seite setzt voraus, dass Sie bereits die folgenden Bedingungen erfüllen:

• Sie haben die entsprechenden APIs aktiviert.

• Sie haben mindestens eine Bereitstellungspipeline definiert und registriert mit Cloud Deploy.

• Sie haben mindestens ein Ziel definiert und Ihre Bereitstellungspipeline verweist auf dieses Ziel.

Cloud Deploy über Ihre CI-Pipeline aufrufen

Hinweis: Das Hauptkonto, das diesen Befehl aufruft, muss die IAM-Rolle clouddeploy.releaser oder einen entsprechenden Satz von Berechtigungen verwenden. Sie benötigen actAs-Berechtigung für das Dienstkonto, das für die Bereitstellung auf dem ersten Ziel und für das Dienstkonto für den Rendering-Vorgang verwendet wird.

Mit dem folgenden Befehl wird ein neuer Release erstellt und damit eine Bereitstellungspipelineinstanz aufgerufen:

gcloud deploy releases create RELEASE_NAME \
  --delivery-pipeline=PIPELINE_NAME \
  --region=REGION \
  --annotations=[KEY=VALUE,...] \
  --images=[IMAGE_LIST]

Wobei:

• RELEASE_NAME

  ist der Name, den Sie diesem Release zuweisen. Dieser Wert ist erforderlich.

  Sie können dynamische Release-Namen angeben, indem Sie '$DATE' oder '$TIME' oder beides einfügen. Wenn Sie diesen Befehl beispielsweise um 15:07 Uhr UTC aufrufen, wird 'rel-$TIME' wird in rel-1507 aufgelöst. '$DATE' und '$TIME' müssen in einfachen Anführungszeichen stehen.

• PIPELINE_NAME

  ist der Name Ihrer registrierten Zustellungspipeline. Dieser Wert ist erforderlich.

• REGION

  ist die Region, in der Sie diese Version erstellen. Die Region muss nicht mit der Region übereinstimmen, in der Sie Ihre Anwendung letztendlich bereitstellen.

• [KEY=VALUE,...]

  ist eine optionale Liste mit einer oder mehreren Annotationen, die in Form von Schlüssel/Wert-Paaren auf den Release angewendet werden sollen.

  Sie können Annotationen verwenden, um die Releaseherkunft zu verfolgen, indem Sie beispielsweise eine Annotation wie commitId=0065ca0 übergeben. Alle Anmerkungen zur Veröffentlichung sind werden zurückgegeben, wenn Sie list oder get für den Release ausführen. Sie werden mit dem Release in der Google Cloud Console, sodass Sie auch dort die Herkunft der Versionen sehen können.

• [IMAGE_LIST]

  ist eine durch Kommas getrennte Liste von Ersetzungen von Image-Name, Bild-Pfad und Pfad. Beispiel: --images=image1=path/to/image1:v1@sha256:45db24,image2=path/to/image2:v1@sha256:55xy18.

  Dieser Wert ist nicht erforderlich, wenn Sie --build-artifacts übergeben, das eine Skaffold-Build-Artefakt-Ausgabedatei identifiziert.

  Wenn Cloud Deploy das Manifest rendert, wird der Image-Name in der nicht gerenderte Manifest-Datei durch die vollständige Bildreferenz im gerenderten Manifests. Das heißt, image1 in diesem Beispiel befindet sich im nicht gerenderten Manifest und wird im gerenderten Manifest durch path/to/image1:v1@sha256:45db24 ersetzt.

Beispiel mit direktem Bildverweis

Mit dem folgenden Befehl wird ein neuer Release erstellt, dessen Image-Referenz direkt statt einer Build-Artefaktdatei weitergegeben wird:

gcloud deploy releases create my-release \
  --delivery-pipeline=web-app \
  --region=us-central1 \
  --images=image1=path/to/image1:v1@sha256:45db24

In diesem Beispiel ist my-release der Release-Name. Wenn Sie eine auf Basis des Datums oder der Uhrzeit veröffentlicht werden soll, kannst du '$DATE', 'TIME' oder beides. Die Zeit ist die UTC-Zeit auf dem Computer, auf dem Sie den Befehl aufrufen. '$DATE' und '$TIME' müssen in einfachen Anführungszeichen stehen.

Beispiel:

gcloud deploy releases create rel-'$DATE'-'$TIME' \
  --delivery-pipeline=web-app \
  --region=us-central1 \
  --images=image1=path/to/image1:v1@sha256:45db24

In diesem Beispiel generiert der Befehl einen Release-Namen mit dem Präfix rel- sowie dem Datum und der Uhrzeit, z. B. rel-20220131-1507.

Außerdem wird häufig das Git-SHA in einem Release-Namen verwendet. Weitere Informationen finden Sie in der Beispiele für Cloud Build und Docker in diesem Dokument.

Build-Artefakte im Vergleich zu Images

Mit dem Befehl gcloud deploy releases create können Sie entweder eine Gruppe von Imagereferenzen oder eine Build-Artefaktdateireferenz weitergeben.

• Verwenden Sie --images=[NAME=TAG,...], um auf ein oder mehrere einzelne Container-Images zu verweisen.

  Dieser Wert ist eine Referenz auf eine Sammlung von einzelnen Image-Namen zu vollständigen Image-Pfadersetzungen. Beispiel:

  gcloud deploy releases create my-release --images=image1=path/to/image1:v1@sha256:45db24

• Verwenden Sie --build-artifacts=, um auf eine Ausgabedatei der Skaffold-Build-Artefakte zu verweisen.

Cloud Build-Beispiele, wobei eine Build-Artefaktdatei übergeben wird

Hinweis: Das Dienstkonto, mit dem der Cloud Build-Trigger ausgeführt wird, muss die IAM-Rolle clouddeploy.releaser oder einen entsprechenden Satz von Berechtigungen verwenden und müssen die actAs-Berechtigung haben, um sie für das erste Ziel bereitzustellen.

Beispiel für Docker-Build

Die folgende YAML-Datei zeigt Cloud Build für ein Docker-Build und erstellt schließlich einen Cloud Deploy-Release.

In diesem Beispiel wird ein Image erstellt und in ein Artefakt-Repository übertragen. Außerdem wird ein Befehl zum Erstellen eines Release mit einem Releasenamen erstellt, der auf dem kurzen Commit-SHA basiert. Dieses Beispiel muss als Cloud Build-SCM-Trigger verwendet werden, da es auf der Variable $COMMIT_SHA basiert.

In diesem Beispiel wird ein Image per Push an ein Docker-Tag übertragen, das dem Commit entspricht. Hash des Quell-Repositorys. Dann wird derselbe Commit-Hash wie ein Docker-Tag erstellt, von den Release-Befehl-Argumenten referenziert wird.

steps:
# Build and tag using commit sha
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '.', '-t', 'REPO_LOCATION/$PROJECT_ID/IMAGE_NAME:${COMMIT_SHA}', '-f', 'Dockerfile']
# Push the container image
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'REPO_LOCATION/$PROJECT_ID/IMAGE_NAME:${COMMIT_SHA}']
# Create release in Google Cloud Deploy
- name: gcr.io/google.com/cloudsdktool/cloud-sdk
  entrypoint: gcloud
  args:
    [
      "deploy", "releases", "create", "rel-${SHORT_SHA}",
      "--delivery-pipeline", "PIPELINE_NAME",
      "--region", "us-central1",
      "--annotations", "commitId=${REVISION_ID}",
      "--images", "IMAGE_NAME=REPO_LOCATION/$PROJECT_ID/IMAGE_NAME:${COMMIT_SHA}"
    ]

Beachten Sie, dass der Image-Name am Ende dieses Beispiels "--images", "IMAGE_NAME= im gerenderten Manifest durch die vollständige Image-Referenz ersetzt wird.

Beispiel für eine Cloud Build-Konfiguration mit Skaffold

Die folgende YAML-Datei enthält den Inhalt einer Cloud Build-Datei. Build-Konfiguration mit einem Aufruf an Cloud Deploy zum Erstellen eines Release, wobei der Release-Name auf dem Datum basiert. Dieses Beispiel zeigt auch Skaffold, das für den Build verwendet wird.

steps:
- name: gcr.io/k8s-skaffold/skaffold
  args:
    - skaffold
    - build
    - '--interactive=false'
    - '--file-output=/workspace/artifacts.json'
- name: gcr.io/google.com/cloudsdktool/cloud-sdk
  entrypoint: gcloud
  args:
    [
      "deploy", "releases", "create", "rel-${SHORT_SHA}",
      "--delivery-pipeline", "PIPELINE_NAME",
      "--region", "us-central1",
      "--annotations", "commitId=${REVISION_ID}",
      "--build-artifacts", "/workspace/artifacts.json"
    ]

Hinweis: Im Befehl gcloud, der in diesem Beispiel enthalten ist, wird der Releasename als rel-${SHORT_SHA} übergeben. Diese dynamische Benennung gewährleistet, dass für jede zugesicherte Änderung ein eindeutiger Releasename verwendet wird.

GitHub Actions mit Cloud Deploy verbinden

Wenn Sie GitHub Actions für kontinuierliche Integration oder andere Software verwenden lieferbezogene Aktivitäten haben, können Sie eine Verbindung zu Cloud Deploy für mit der Funktion create-cloud-deploy-release GitHub-Aktion

GitLab mit Cloud Deploy verbinden

Vorschau

Für dieses Produkt gelten die „Bedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Wenn Sie GitLab für Continuous Integration verwenden, können Sie die GitLab Cloud Deploy-Komponente create-cloud-deploy-release verwenden, um einen Cloud Deploy-Release zu erstellen.

Sie können auch die End-to-End-Anleitung zur Verwendung von GitLab mit Google Cloud ausprobieren.

Weitere Informationen finden Sie in der Übersicht zu GitLab on Google Cloud.

Herkunft mithilfe von Annotationen verfolgen

Mit dem Flag --annotations= können Sie ein oder mehrere beliebige Schlüssel/Wert-Paare auf den Release anwenden, der von diesem Befehl erstellt wird. Dieses Flag fügen Sie dem Befehl gcloud deploy releases create hinzu.

Sie können beispielsweise die folgenden Schlüssel/Wert-Paare verwenden, um die Quelle des bereitzustellenden Images zu verfolgen.

Beispiel:

gcloud deploy releases create web-app-1029rel \
  --delivery-pipeline=web-app \
  --region=us-central1 \
  --annotations=commitId=0065ca0,author=[e-mail] \
  --images=image1=path/to/image1:v1@sha256:45db24

Sie können auch eine Annotation erstellen, deren Wert beispielsweise die URL ist, die auf die Pull-Anfrage verweist. Weitere Informationen finden Sie unter Labels und Anmerkungen mit Cloud Deploy verwenden.