Dienstarchitektur von Google Cloud Deploy

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

In diesem Dokument werden die Beziehungen zwischen Google Cloud Deploy und den externen Systemen beschrieben, mit denen die Anwendung bereitgestellt wird. Diese Systeme sind andere Google Cloud-Dienste und Tools von Drittanbietern.

Gesamtansicht

Das folgende Diagramm zeigt die Beziehungen zwischen Google Cloud Deploy und den separaten Systemen, auf denen es basiert.

Beziehungen zwischen Cloud Deploy-Komponenten

Wie in diesem Diagramm dargestellt, interagiert Google Cloud Deploy mit den folgenden Systemen:

  • Ihr CI-System

    Google Cloud Deploy unterstützt die meisten CI-Tools, solange eine Ausgabe Ihres CI-Prozesses ein Aufruf der Google Cloud Deploy API oderBefehlszeile sein kann, um eine Release zu erstellen.

  • Cloud Build

    Google Cloud Deploy ruft Cloud Build auf, um Ihre Manifeste zu rendern und in der Ziellaufzeit bereitzustellen.

  • Skaffold

    Google Cloud Deploy verwendet Skaffold über Cloud Build, um Ihre Manifeste zu rendern und bereitzustellen, sodass Ihre Anwendung bereitgestellt wird.

  • Cloud Storage

    Google Cloud Deploy speichert Renderingquellen und gerenderte Manifeste in einem Cloud Storage-Bucket.

  • Operations-Suite von Google Cloud und Cloud-Audit-Logs

    Die Operations-Suite von Google Cloud erfasst und stellt Logging-Daten für Google Cloud Deploy bereit.

    Siehe auch Audit-Logging.

  • Pub/Sub

    Google Cloud Deploy veröffentlicht Nachrichten zu mehreren Pub/Sub-Themen. Sie können diesen Dienst verwenden, um ihn in externe Workflows, Tests und andere zugehörige Systeme einzubinden.

    Weitere Informationen finden Sie unter Google Cloud Deploy-Benachrichtigungen abonnieren.

  • Ziellaufzeit

    Google Cloud Deploy verwendet skaffold apply über Cloud Build, um Ihre Anwendungen in Ihrer Ziellaufzeit (GKE oder Anthos) bereitzustellen.

Google Cloud Deploy-Ressourcen

Das folgende Diagramm zeigt die Ressourcen, die Google Cloud Deploy zum Bereitstellen Ihrer Anwendungen verwendet, und die Beziehungen zwischen diesen Ressourcen:

Beziehungen zwischen Cloud Deploy-Ressourcen

Wie in diesem Diagramm dargestellt, bestehen folgende Beziehungen zwischen den Ressourcen:

  • Die Bereitstellungspipeline kann null oder mehr Releases ergeben und auf ein oder mehrere Ziele verweisen.

  • Jeder Release enthält die Pipelineinstanz – einen Snapshot der Bereitstellungspipeline und der Ziele, die beim Erstellen des Release konfiguriert wurden.

  • Jeder Release kann null oder mehr Roll-outs ergeben und auf null oder mehr Artefakte verweisen.

    Jeder Roll-out umfasst mindestens eine Phase, die eine Sammlung von Vorgängen (Jobs) in einem Roll-out darstellt, die logisch gruppiert sind, z. B. eine Bereitstellung oder eine Bereitstellung und Überprüfung.

    Jede Phase enthält einen oder mehrere Jobs, die darstellen, was im Roll-out ausgeführt werden muss – entweder bereitstellen oder verifizieren. Jeder Job kann eine oder mehrere Jobausführungen enthalten, die Instanzen von Jobs sind, z. B. ein Bereitstellungsversuch. Eine Jobausführung ist eine untergeordnete Ressource des Roll-outs.

  • Jeder Roll-out ist einem Ziel zugeordnet.

  • Jedes Ziel ist einem GKE- oder Anthos-Cluster oder einem anderen Laufzeitziel für die Anwendung zugeordnet.

  • Ein Ziel kann einer oder mehreren Bereitstellungspipelines zugeordnet sein.

  • Ein Artefakt ist eine Ausgabe aus Ihrem CI-Prozess (z. B. ein Container-Image), die im Rahmen eines Roll-outs in einer Ziellaufzeit bereitgestellt wird.

Darüber hinaus umfasst ein Roll-out eine oder mehrere Phasen und Phasen haben einen oder mehrere Jobs und eine oder mehrere Jobausführungen.

Ressourcen zur Einführung

Wie in diesem Diagramm dargestellt, umfasst ein Roll-out Folgendes:

  • Phasen

    Eine Phase enthält einen oder mehrere Jobs (z. B. Bereitstellen oder Bereitstellen und Überprüfen). Jeder Roll-out umfasst eine oder mehrere Phasen. Eine Phase ist eine Untermitteilung in einem Roll-out.

  • Jobs

    Der spezifische Vorgang, der für ein Roll-out ausgeführt werden soll, z. B. Bereitstellen oder Überprüfen. Ein Job ist eine untergeordnete Nachricht in einem Roll-out.

  • Jobausführungen

    Eine Instanz eines Jobs, z. B. ein Bestätigungsversuch. Jeder Job kann null oder mehr JobRuns haben. Der JobRun ist eine untergeordnete Ressource eines Roll-outs.

So passen sie zusammen, um Ihren Release bereitzustellen

In diesem Abschnitt wird beschrieben, wie Google Cloud Deploy mit den in diesem Dokument aufgeführten Komponenten interagiert, um die Bereitstellung Ihrer Anwendung als Release zu automatisieren.

  1. Ihr CI-System ruft eine Google Cloud Deploy-Zustellungspipeline auf.

    Ihr CI-Prozess ruft Google Cloud Deployment über die Befehlszeile oder die API auf, um einen neuen Release zu erstellen, der die Build-Artefakte oder Verweise auf Images übergibt.

    Weitere Informationen zur Integration Ihres CI-Systems finden Sie unter Google Cloud Deploy in andere Systeme einbinden.

  2. Wenn ein neuer Release erstellt wird, führt Google Cloud Deploy Folgendes aus:

    1. Speichert eine Instanz der Bereitstellungspipeline als Teil des Releases.

      Diese Pipelineinstanz bleibt für diese Version unverändert, auch wenn die Konfiguration der Bereitstellungspipeline geändert wird. Weitere Informationen finden Sie unter Pipelineinstanzen pro Release.

      Außerdem wird die Skaffold-Version als Teil des Release gespeichert.

    2. Ruft Cloud Build auf, das die Skaffold-Rendering-Quelle aus Cloud Storage abruft.

      Google Cloud Deploy speichert die Renderingquelle im standardmäßigen oder alternativen Cloud Storage-Bucket.

    3. Ruft skaffold diagnose auf (mit der beim Erstellen erstellten Skaffold-Version), um ein einzelnes effektives Manifest zu generieren.

    4. Ruft skaffold render auf, um das Manifest mit den bereitgestellten Images oder Build-Artefakten zu rendern.

      Google Cloud Deploy ersetzt Image-Namen in spec.templates.spec.containers.image durch die vollständigen Image-Pfade (einschließlich Digests oder Tags), die im Befehl gcloud deploy releases create oder in einer Build-Artefaktdatei bereitgestellt werden, auf die durch diesen Befehl verwiesen wird.

      Google Cloud Deploy speichert das gerenderte Manifest im standardmäßigen oder alternativen Cloud Storage-Bucket.

      Google Cloud Deploy führt diese Aktionen mit der Standard- oder einer alternativen Ausführungsumgebung aus.

    5. Erstellt automatisch ein Roll-out und stellt es für das erste Ziel bereit, indem skaffold apply aufgerufen wird.

      Dies gilt nur, wenn Google Cloud Deploy über die Befehlszeile aufgerufen wird, um einen Release zu erstellen.

      Der Prozess für die Bereitstellung auf dem ersten Ziel entspricht dem Vorgang für Hochstufungen, wie im nächsten Schritt beschrieben.

    6. Ruft skaffold verify auf, wenn verify für das Ziel in der Bereitstellungspipeline config true ist und die Überprüfung in der Skaffold-Konfiguration angegeben ist.

  3. Wenn es Zeit ist, den Release zum nächsten Ziel hochzustufen, ruft Cloud Build das zielspezifische Manifest aus Cloud Storage ab. Anschließend ruft Cloud Build skaffold apply auf, um das gerenderte Manifest auf die angegebene Ziellaufzeit anzuwenden.

    Wenn das Ziel eine Genehmigung erfordert, können Sie die Genehmigung über die Befehlszeile oder über die Konsole vornehmen oder ablehnen.

    Außerdem generiert Google Cloud Deploy eine Pub/Sub-Nachricht, die Sie abonnieren können, um automatisch einen Genehmigungsworkflow zu starten.

    Google Cloud Deploy verwendet die Skaffold-Version und die Pipelineinstanz, die mit diesem Release verknüpft ist, und führt diesen Schritt in der Standard- oder benutzerdefinierten Ausführungsumgebung aus.

    Dieser Prozess gilt nicht nur für Werbeaktionen, sondern auch für Rollbacks und für erneute Bereitstellungen.

  4. Während der Bereitstellung von Google Cloud-Vorgängen veröffentlicht der Dienst Benachrichtigungen in mehreren Pub/Sub-Themen (z. B. wenn eine Einführung eine Genehmigung erfordert).

    Diese und andere Integrationen werden unter Google Cloud Deploy in externe Systeme einbinden weiter beschrieben.

  5. Während des gesamten Google Cloud-Bereitstellungsvorgangs schreibt der Dienst Plattformlogs und Audit-Logs in die Operations-Suite von Google Cloud und Cloud-Audit-Logs.

Durch alle diese Schritte werden die Ablaufsteuerung und der Zugriff auf Ressourcen mithilfe der Identitäts- und Zugriffsverwaltung eingeschränkt.

Nächste Schritte