Architektur des Cloud Deploy-Dienstes

In diesem Dokument werden die Beziehungen zwischen Cloud Deploy und den externen Systemen beschrieben, mit denen es zum Bereitstellen Ihrer Anwendungen arbeitet. Diese Systeme sind andere Google Cloud-Dienste und Tools von Drittanbietern.

Gesamtansicht

Das folgende Diagramm zeigt die Beziehungen zwischen Cloud Deploy und den verschiedenen Systemen, auf die 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 Ihres CI-Prozesses ein Aufruf an die API oder die CLI zum Erstellen eines Release sein kann.

  • 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 und somit Ihre Anwendung bereitzustellen.

  • Cloud Storage

    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 Cloud Deploy zur Verfügung.

    Siehe auch Audit-Logging.

  • Pub/Sub

    Cloud Deploy veröffentlicht Nachrichten an mehrere 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 (GKE oder GKE Enterprise) bereitzustellen.

Cloud Deploy-Ressourcen

Das folgende Diagramm zeigt die Ressourcen, die Cloud Deploy zur Bereitstellung Ihrer Anwendungen verwendet, sowie 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 zurückgeben und auf ein oder mehrere Ziele verweisen, einschließlich Multi-Zielen und den zugehörigen untergeordneten Zielen.

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

  • Jeder Release kann null oder mehr Rollouts liefern und auf null oder mehr Artefakte verweisen.

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

    Jede Phase umfasst einen oder mehrere Jobs, die angeben, was bei dem Rollout zu tun ist – entweder bereitstellen oder prüfen. Jeder Job kann eine oder mehrere Jobausführungen enthalten, bei denen es sich um Instanzen von Jobs handelt, z. B. einen Bereitstellungsversuch. Eine Jobausführung ist eine untergeordnete Ressource des Roll-outs.

    Multi-Ziele werden für die parallele Bereitstellung verwendet. Sie erstellen Controller-Rollouts, die untergeordnete Roll-outs erstellen, die untergeordneten Zielen entsprechen.

  • Jedes Roll-out ist einem Ziel zugeordnet.

    Bei der parallelen Bereitstellung ist jedes untergeordnete Ziel einem untergeordneten Roll-out zugeordnet.

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

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

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

Ein Roll-out umfasst außerdem eine oder mehrere Phasen. Die Phasen umfassen einen oder mehrere Jobs und eine oder mehrere Jobausführungen.

Roll-out-Ressourcen

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

  • Phasen

    Eine Phase enthält einen oder mehrere Jobs (z. B. bereitstellen, bereitstellen und prüfen). Jedes Roll-out umfasst eine oder mehrere Phasen. Eine Phase ist eine untergeordnete Botschaft in einer Einführung.

  • Jobs

    Der spezifische Vorgang, der für ein Rollout 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 Versuch zur Bestätigung. Jeder Job kann null oder mehr JobRuns haben. JobRun ist eine untergeordnete Ressource eines Roll-outs.

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 und dabei die Build-Artefakte oder Verweise auf Images zu übergeben.

    Weitere Informationen zum Einbinden Ihres CI-Systems finden Sie unter Cloud Deploy in andere Systeme einbinden.

  2. Wenn ein neuer Release erstellt wird, geht Cloud Deploy so vor:

    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. In den meisten Fällen ist dies die Standard-Skaffold-Version. 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 im 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.

      Cloud Deploy ersetzt die 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 angegeben sind, auf die dieser Befehl verweist.

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

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

    5. Durch Aufrufen von skaffold apply wird automatisch ein Roll-out erstellt und für das erste Ziel bereitgestellt.

      Dies gilt nur, wenn 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 Konfiguration der Bereitstellungspipeline den Wert true hat 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 Cloud Deploy eine Pub/Sub-Nachricht, die Sie abonnieren können, um automatisch einen Genehmigungsworkflow zu starten.

    Cloud Deploy verwendet die Skaffold-Version und die Pipelineinstanz, die diesem Release zugeordnet sind, und führt diesen Schritt in der standardmäßigen oder benutzerdefinierten Ausführungsumgebung aus.

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

  4. Bei allen Cloud Deploy-Vorgängen veröffentlicht der Dienst Benachrichtigungen in mehreren Pub/Sub-Themen, z. B. wenn ein Roll-out eine Genehmigung erfordert.

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

  5. Während des gesamten Cloud Deploy-Vorgangs schreibt der Dienst Plattformlogs und Audit-Logs in die Operations-Suite von Google Cloud und in 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