Architektur des Cloud Deploy-Dienstes

In diesem Dokument werden die Beziehungen zwischen 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 Cloud Deploy und den separaten Systemen, auf denen es basiert.

Beziehungen zwischen Cloud Deploy-Komponenten

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

  • Ihr CI-System

    Cloud Deploy unterstützt die meisten CI-Tools, solange eine Ausgabe von Ihrem CI-Prozess ein Aufruf der Cloud Deploy API oder CLI sein kann, um einen Release zu erstellen.

  • Cloud Build

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

  • Skaffold

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

  • Cloud Storage

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

  • Google Cloud Observability und Cloud-Audit-Logs.

    Google Cloud Observability erfasst und stellt Logging-Daten für Cloud Deploy bereit.

    Siehe auch Audit-Logging.

  • Pub/Sub

    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 Cloud Deploy-Benachrichtigungen abonnieren.

  • Ziellaufzeit

    Cloud Deploy verwendet skaffold apply, über Cloud Build, um Ihre Anwendungen in Ihrer Ziellaufzeit bereitzustellen (GKE, Cloud Run oder ein benutzerdefiniertes Ziel).

Cloud Deploy-Ressourcen

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

Beziehungen zwischen Cloud Deploy-Ressourcen

Wie in diesem Diagramm dargestellt, sind die Beziehungen zwischen den Ressourcen wie folgt:

  • Die Bereitstellungspipeline kann null oder mehr Releases erzeugen und auf ein oder mehrere Ziele verweisen, einschließlich Multi-Targets und der zugehörigen untergeordneten Ziele.

  • Die Bereitstellungspipeline kann auch auf eine oder mehrere Automatisierungen verweisen, die Aktionen für Cloud Deploy-Ressourcen automatisieren.

  • Jeder Release enthält die Pipelineinstanz – einen "Snapshot" der Bereitstellungspipeline und der Ziele, wie sie beim Erstellen des Releases konfiguriert waren.

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

    Jeder Roll-out enthält 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 zu tun ist – entweder bereitstellen oder überprüfen. Jeder Job kann einen oder mehrere Job-Ausführungen enthalten, die Instanzen von Jobs sind, z. B. ein Bereitstellungsversuch. Eine Job-Ausführung ist eine untergeordnete Ressource des Roll-outs.

    Multi-Targets, die für die parallele Bereitstellungverwendet werden, erstellen Controller-Roll-outs, die untergeordnete Roll-outs erstellen, die untergeordneten Zielen entsprechen.

  • Jeder Roll-out ist mit einem Ziel verknüpft.

    Bei der parallelen Bereitstellung ist jedes untergeordnete Ziel mit einem untergeordneten Roll-out verknüpft.

  • Jedes Ziel ist mit einem GKE-Cluster oder einem anderen Laufzeitziel für die Anwendung verknüpft.

  • Ein Ziel kann mit einer oder mehreren Bereitstellungspipelines verknüpft sein.

  • Ein Artefakt ist eine beliebige Ausgabe Ihres CI-Prozesses (z. B. ein Container-Image) das im Rahmen eines Roll-outs in einer Ziellaufzeit bereitgestellt wird.

Außerdem hat ein Roll-out eine oder mehrere Phasen und Phasen haben einen oder mehrere Jobs und eine oder mehrere Job-Ausführungen.

Ressourcen für den Roll-out

Wie in diesem Diagramm dargestellt, enthält ein Roll-out Folgendes:

  • Phasen

    Eine Phase enthält einen oder mehrere Jobs (z. B. „bereitstellen“ oder „bereitstellen und überprüfen“). Jeder Roll-out hat eine oder mehrere Phasen. Eine Phase ist eine untergeordnete Nachricht in einem Roll-out.

  • Jobs

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

  • JobRuns

    Eine Instanz eines Jobs, z. B. ein Überprüfungsversuch. Jeder Job kann null oder mehr JobRuns haben. Der JobRun ist eine untergeordnete Ressource eines Roll-outs.

Automatisierungen enthalten Automatisierungsregeln, auf die von null oder mehr AutomationRun-Ressourcen verwiesen werden kann. AutomationRuns sind Instanzen von ausgeführten Automatisierungsregeln, z. B. eine automatisierte Hochstufung von einem Ziel zu einem anderen. Automation- und AutomationRun-Ressourcen sind gleichrangige untergeordnete Ressourcen unter einer Bereitstellungspipeline.

Automatisierungsressourcen

So passen sie zusammen, um Ihren Release bereitzustellen

In diesem Abschnitt wird beschrieben, wie 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 Cloud Deploy-Bereitstellungspipeline auf.

    Ihr CI-Prozess ruft Cloud Deploy über die CLI 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 Cloud Deploy in andere Systeme einbinden.

  2. Wenn ein neuer Release erstellt wird, führt 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 werden die Toolversionen als Teil des Release gespeichert. In den meisten Fällen sind das die Standard versionen der Tools. Da Sie jedoch andere Versionen angeben können, werden diese Informationen gespeichert.

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

      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 den Vorgang render auf.

      Wenn Sie integrierte Ziele verwenden, ruft Cloud Deploy skaffold render auf, um das Manifest mit den bereitgestellten Images oder Build-Artefakten zu rendern. 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.

      Wenn Sie ein benutzerdefiniertes Ziel verwenden, ruft Cloud Deploy den Vorgang render auf, der für den benutzerdefinierten Zieltyp definiert ist.

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

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

  3. Wenn ein Roll-out erstellt wird (automatisch nach dem Erstellen des Releases oder später auf Anfrage), führt Cloud Deploy Folgendes aus:

    1. Ruft Pre-Deploy-Hooks auf, falls welche angegeben sind.

      Wenn Sie eine Canary Bereitstellungsstrategie verwenden, werden Pre-Deploy-Hooks am Anfang der ersten Phase aufgerufen.

    2. Ruft den Vorgang deploy auf.

      Wenn Sie integrierte Ziele verwenden, erstellt und stellt Cloud Deploy automatisch einen Roll-out für das erste Ziel bereit, indem skaffold apply aufgerufen wird. Wenn Sie ein integriertes Ziel verwenden, wird der erste Roll-out automatisch beim Erstellen des Releases erstellt.

      Wenn Sie ein benutzerdefiniertes Ziel verwenden, erstellt Cloud Deploy automatisch einen Roll-out für das erste Ziel und ruft den Vorgang deploy auf, der für den benutzerdefinierten Zieltyp definiert ist.

      Bei integrierten und benutzerdefinierten Zielen erfolgt der Roll-out zum ersten Ziel nur dann automatisch, wenn der Release über die Befehlszeile erstellt wird.

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

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

    4. Ruft nach verify Post-Deploy-Hooks auf, falls welche angegeben sind, wenn verify angegeben ist. Andernfalls werden Post-Deploy-Hooks nach deploy aufgerufen.

      Wenn Sie eine Canary-Bereitstellungsstrategie verwenden, werden Post-Deploy-Hooks als letzter Job in der letzten Roll-out-Phase ausgeführt.

  4. 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 Cloud Deploy eine Pub/Sub-Nachricht, die Sie abonnieren können, um automatisch einen Genehmigungs workflow zu starten.

    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.

  5. Während der Bereitstellung von Cloud Deploy-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 Cloud Deploy in externe Systeme einbinden weiter beschrieben.

  6. Sie können eine Automatisierung angeben, um verschiedene Vorgänge in der Bereitstellungspipeline automatisch auszuführen. Diese können zum festgelegten Zeitpunkt ausgeführt werden. An automationRun stellt die Ausführung einer Automatisierungsregel dar.

  7. Während des gesamten Cloud Deploy-Vorgangs schreibt der Dienst Plattform Logs und Audit-Logs in Google Cloud Observability 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