App Lifecycle Manager – Übersicht

Mit App Lifecycle Manager können Sie Software-as-a-Service-Anwendungen (SaaS) auf Google Cloudspeichern, hosten, verwalten und überwachen. App Lifecycle Manager verwaltet Terraform-Bereitstellungen in großem Umfang, sodass Sie sowohl Ihre SaaS-Anwendung als auch die Infrastruktur, auf der sie ausgeführt wird, verwalten können.

App Lifecycle Manager kann von verschiedenen Stakeholdern in der SaaS-Pipeline auf viele Arten verwendet werden. Wenn Ihre Arbeit einer dieser Rollen entspricht, ist App Lifecycle Manager möglicherweise für Sie interessant:

  • Plattformadministrator
  • Anwendungsentwickler
  • Architekt
  • Compliance-Administrator
  • Plattformentwickler*in
  • Finanzabteilung

App Lifecycle Manager bietet folgende Vorteile:

  • Vereinfachen Sie die Dienstverwaltung im großen Maßstab, indem Sie Aufgaben der Dienstverwaltung (z. B. Bereitstellung, Roll‑outs und Verwaltung von Funktions-Flags) für alle Ihre SaaS-Mandanten automatisieren.
  • Erweitern Sie Ihre Beobachtbarkeit und Kontrolle, indem Sie Ihre Updates und Releases für konfigurierbare Einheiten optimieren, um Ihr SaaS-Angebot im großen Maßstab präzise zu verwalten.
  • Sorgen Sie für Konsistenz in Ihrem Google Cloud Ökosystem, indem Sie Dienste in verschiedenen Google Cloud Produkten verwalten, darunter Google Cloud, Google Distributed Cloud, Billing, Observability und Resource Manager.
  • Verwenden Sie eine flexible und vorlagenbasierte Architektur, die gruppenbasierte Updates und Bereitstellungen auf Einheitenbasis fördert, um die Effizienz und Wiederverwendbarkeit zu verbessern.

Wie funktioniert App Lifecycle Manager?

App Lifecycle Manager stellt Artefakte bereit, die Ihr SaaS-Angebot definieren. Diese Artefakte müssen eine Terraform-Konfiguration haben. Die Bereitstellung ist in separate Einheiten unterteilt, die mit Releases aktualisiert werden können, die Änderungen an Ihrem Angebot enthalten. Dies erfolgt über einen konfigurierbaren Roll‑out-Prozess.

Weitere Informationen zur Nomenklatur von App Lifecycle Manager finden Sie im Glossar.

Arbeitslast für App Lifecycle Manager vorbereiten

Bevor Sie Ihr SaaS-Angebot bereitstellen, sollten Sie die ideale Anordnung Ihres SaaS-Angebots im App Lifecycle Manager-Ökosystem festlegen.

Organisieren Sie Teile Ihres SaaS-Angebots, die zusammen aktualisiert oder geändert werden sollen, in separaten Terraform-Konfigurationen. Verwenden Sie beim Planen Ihres SaaS-Angebots Einheitentypen für jede Gruppierung Ihres SaaS-Angebots.

Sobald Sie die ideale Struktur für Ihre Arbeitslast in App Lifecycle Manager festgelegt haben, können Sie Ihr SaaS-Angebot und die Einheitentypen erstellen und dann Ihre Einheiten mit einem Roll‑out bereitstellen.

Ein Beispiel für die Einrichtung von App Lifecycle Manager finden Sie in der Kurzanleitung.

App Lifecycle Manager-Dienstkonten

App Lifecycle Manager verwendet eine Kombination aus von Google verwalteten und vom Nutzer verwalteten Dienstkonten:

  • App Lifecycle Manager-Dienstkonto (von Google verwaltet): Dieses Konto wird automatisch erstellt, nachdem die erste SaaS-Angebotsressource erstellt wurde. Es wird von Google verwaltet. Es führt in Ihrem Namen Aktionen aus, z. B. die Interaktion mit anderen Google Cloud Diensten bei der Bereitstellung von Einheiten.

  • Dienstkonto zum Starten (vom Nutzer verwaltet): Sie erstellen und verwalten dieses Dienst konto. App Lifecycle Manager (über Infrastructure Manager) verwendet dieses Konto, um Ihre Terraform-Konfigurationen beim Bereitstellen oder Aktualisieren von Einheiten auszuführen. Dieses Konto dient als Identität zum Erstellen und Verwalten der in Ihrer Terraform-Konfiguration definierten Ressourcen. Die Berechtigungen des Dienstkontos zum Starten sind direkt mit den Ressourcen verknüpft, die von Ihrer Terraform-Konfiguration verwaltet werden.

    Sie können mehrere Dienstkonten zum Starten haben. Wir empfehlen, für jeden Mandanten ein Dienstkonto zum Starten zu verwenden.

  • Optional: Dienstkonto zum Erstellen von Artefakten (vom Nutzer verwaltet): Dieses Dienst konto wird zum Erstellen und Hochladen Ihrer in OCI Artefakte verpackten Terraform-Konfiguration verwendet. Dies ist häufig ein Cloud Build-Dienstkonto, kann aber auch ein beliebiges Dienstkonto mit den entsprechenden Berechtigungen für Ihr SaaS-Angebot sein.

App Lifecycle Manager-Dienstkonto (von Google verwaltet)

Das App Lifecycle Manager-Dienstkonto ist ein von Google verwalteter Dienst-Agent, der von App Lifecycle Manager verwendet wird, um Vorgänge in Ihrem Projekt auszuführen.

Dieses Dienstkonto wird automatisch bereitgestellt, wenn Sie Ihre erste App Lifecycle Manager-Ressource erstellen. Das App Lifecycle Manager-Dienstkonto wird in diesem Format erstellt:

  service-PROJECT_NUMBER@gcp-sa-saasservicemgmt.iam.gserviceaccount.com

Ersetzen Sie:

  • PROJECT_NUMBER: Ihre Projektnummer.

Dienstkonto zum Starten (vom Nutzer verwaltet)

Das Dienstkonto zum Starten ist ein vom Nutzer verwaltetes Dienstkonto, das Sie erstellen müssen. App Lifecycle Manager (über Infra Manager) verwendet dieses Dienstkonto, um Ihre Terraform-Konfigurationen auszuführen. Es ist die Identität, die die in Ihrer Terraform-Konfiguration definierten Ressourcen erstellt, ändert und löscht.

Sie sind dafür verantwortlich, dieses Dienstkonto in Ihrem Projekt oder in Ihrem Mandantenprojekt zu erstellen.

Eingabevariablen für das Dienstkonto zum Starten

Wenn Sie eine Einheit erstellen, müssen Sie das Dienstkonto zum Starten als Key-Value-Paar-Eingabevariable für die Terraform-Konfiguration angeben:

  • Name: actuation_sa
  • Variablentyp: String

  • Variablenwert: E-Mail-Adresse des Dienstkontos zum Starten:

    my-actuation-sa@my-identifier.iam.gserviceaccount.com

Erforderliche Berechtigungen

Das Dienstkonto zum Starten benötigt ausreichende Berechtigungen, um die in Ihrer Terraform-Konfiguration definierten Ressourcen zu verwalten. Mindestens erforderlich sind:

  • roles/iam.serviceAccountTokenCreator: Ermöglicht dem Dienstkonto, Tokens für die Authentifizierung zu generieren.
  • roles/config.admin: Gewährt die vollständige Kontrolle über Infra Manager-Ressourcen.
  • roles/storage.admin: Gewährt die vollständige Kontrolle über Cloud Storage.

Das Dienstkonto zum Starten benötigt außerdem Berechtigungen zum Erstellen und Verwalten der spezifischen Google Cloud Ressourcen, die von Ihrer Anwendung verwendet werden.

Beispiel:

  • Wenn Ihre Terraform-Konfiguration Google Kubernetes Engine-Cluster (GKE) erstellt, benötigt das Dienstkonto die entsprechenden GKE-Rollen (z. B. roles/container.admin).
  • Wenn Ihre Terraform-Konfiguration Compute Engine-Instanzen erstellt, benötigt das Dienstkonto die Rolle roles/compute.admin.
  • Wenn Ihre Terraform-Konfiguration Cloud SQL-Instanzen erstellt, benötigt das Dienstkonto die entsprechenden Cloud SQL-Rollen (z. B. roles/cloudsql.admin).

In der Dokumentation zu jeder Google Cloud Ressource, die Sie in Ihrer Terraform-Konfiguration verwenden, finden Sie die erforderlichen Berechtigungen. Erteilen Sie die geringste Berechtigung , die für die Funktion Ihrer Anwendung erforderlich ist.

Dienstkonto zum Erstellen von Artefakten (vom Nutzer verwaltet)

Das Dienstkonto zum Erstellen von Artefakten ist ein vom Nutzer verwaltetes Dienstkonto, das Sie erstellen, um ein Build-System (z. B. Cloud Build) zu verwenden, um Ihre Terraform-Artefakte zu packen und in Artifact Registry hochzuladen.

Dieses Dienstkonto ist von den Dienstkonten für App Lifecycle Manager und zum Starten getrennt. Es erstellt Ihren Terraform-Code und überträgt das resultierende Artefakt an Artifact Registry. Häufig ist dies das Cloud Build-Dienstkonto.

Manuelles Erstellen von Artefakten

Wenn Sie Ihre Terraform-Artefakte manuell erstellen und hochladen (z. B. direkt mit Docker build und Docker push), benötigen Sie kein separates Dienstkonto zum Erstellen von Artefakten.

Stattdessen sollten Sie sich mit Ihren eigenen Anmeldedaten oder einem Dienstkonto mit den erforderlichen Artifact Registry-Berechtigungen authentifizieren.

Erforderliche Berechtigungen

Wenn Sie Cloud Build verwenden, benötigt das Cloud Build-Dienstkonto in der Regel die folgenden Rollen:

  • roles/artifactregistry.writer: Zum Übertragen von Artefakten an Artifact Registry.
  • roles/artifactregistry.repoAdmin: Zum Verwalten des Artifact Registry-Repositorys.
  • roles/storage.admin: Zum Verwalten der Cloud Storage-Buckets.
  • roles/developerconnect.admin: Berechtigungen zur Verwendung von Developer Connect.
  • roles/developerconnect.readTokenAccessor: Berechtigungen zum Abrufen des Developer Connect -Lesetokens.
  • roles/logging.logWriter: Berechtigungen zum Schreiben von Logs.
  • Wenn Sie Ihre Terraform-Konfiguration mit Developer Connect bereitstellen: roles/cloudbuild.builds.builder: Zum Ausführen von Builds.
  • Alle anderen Berechtigungen, die für Ihren Build-Prozess erforderlich sind (z. B. Zugriff auf Quellcode-Repositories).

Roll‑out-Strategien

App Lifecycle Manager verwendet verschiedene Roll‑out-Strategien, um zu verwalten, wie Einheiten in Ihrem SaaS-Angebot aktualisiert werden. Diese Roll‑out-Strategien folgen Google Cloud's Ansatz für Änderungen, indem einheitliche Ansätze für die Bereitstellung von Änderungen in Ihrem SaaS-Angebot angewendet werden.

Mit Roll‑out-Strategien können Sie negative Auswirkungen auf Kunden minimieren und Probleme auf einzelne logische und physische Fehlerbereiche begrenzen. Definieren Sie Ihre Roll‑out-Strategien, indem Sie eine Roll‑out-Art erstellen und eine der folgenden Roll‑out-Strategien angeben:

  • Jeweils ein Standort (einfach): Es wird jeweils ein Standort eingeführt, ohne Wartezeit zwischen den Standorten. Einheiten werden willkürlich an einem Standort ausgewählt. Dabei werden maximal 20% der Einheiten des Standorts gleichzeitig aktualisiert.

    Diese Strategie wird für Entwicklungsumgebungen und Notfallszenarien empfohlen.

  • Alle auf einmal (einfach): Der Roll‑out beginnt gleichzeitig an allen Standorten.

    Diese Strategie wird für Entwicklungsumgebungen und Notfallszenarien empfohlen.

  • Progressiv (schrittweise): An jedem Standort werden Einheiten in statischen prozentualen Batches (z. B. 1%, 10%, 20%, 30%, ~40%) mit Übergangszeiten zwischen den Batches eingeführt. Standortübergreifend schreitet der Roll‑out mit einer exponentiellen Zunahme der Anzahl gleichzeitiger Standorte (z. B. ein Standort, dann zwei, dann vier) mit Übergangszeiten (z. B. 18 Stunden) zwischen den Wellen voran. Einheiten an einem Standort werden zufällig ausgewählt.

    Diese Strategie ist für sichere und vorhersehbare Roll‑outs an mehreren Standorten konzipiert. Sie beginnt in kleinem Umfang und wird mit steigender Zuversicht schrittweise erweitert. Diese Strategie wird in Produktionsumgebungen mit mehr als einem Standort empfohlen.

  • Progressiv (einzelner Standort): Einheiten werden in statischen prozentualen Batches (z. B. 1%, 10%, 20%, 30%, ~40%) mit längeren Übergangszeiten (z. B. 18 Stunden) zwischen den Batches aktualisiert, um ausreichend Zeit für die Erkennung von Problemen zu lassen und die negativen Auswirkungen von Roll‑out-Änderungen zu begrenzen.

    Diese Strategie ist auf SaaS-Angebote an einem einzigen Standort zugeschnitten, wobei Sicherheit und Vorsicht im Vordergrund stehen. Wir empfehlen diese Strategie in Produktionsumgebungen mit einem Standort.

Weitere Informationen zum Erstellen von Roll‑out-Arten finden Sie unter Roll‑out-Art erstellen.

Regionalisierung von App Lifecycle Manager

SaaS-Angebotsressourcen definieren, wo sich Ihre App Lifecycle Manager-Einheiten befinden können und wie Ihre Roll‑outs verwaltet werden. Wenn Sie ein SaaS-Angebot erstellen, dienen die ausgewählten Regionen als zentrale Informationsquelle für die unterstützten Regionen Ihres SaaS-Angebots. Die ausgewählten Regionen sind die verfügbaren Regionen , die Sie für Ihr SaaS-Angebot definiert haben.

Wenn Sie App Lifecycle Manager über die Google Cloud console verwenden, automatisiert App Lifecycle Manager die Replikation der Ressourcen, die Sie in Ihrem SaaS-Angebot definieren, in verschiedenen Regionen. So wird die Konsistenz und Verfügbarkeit Ihrer App Lifecycle Manager-Ressourcen in allen verfügbaren Regionen gewährleistet, die Sie in Ihrem SaaS-Angebot definiert haben.

Google Cloud

App Lifecycle Manager repliziert diese Ressourcen:

  • SaaS-Angebot (Saas)
  • Einheitentyp (UnitKind)
  • Release (Release)

global als Region verwenden

Es wird generell nicht empfohlen , global als Region in Ihr SaaS-Angebot aufzunehmen, wenn es sich um Bereitstellungsziele handelt. App Lifecycle Manager verwendet die Region global, um regionale Roll‑outs zu propagieren. Regionale Roll‑outs können nicht in der Region global ausgeführt werden.

Regionalisierung von Roll‑outs

Die unterstützten Standorte für Roll‑outs werden durch die Regionen der obersten Ebene bestimmt, die in den verfügbaren Regionen Ihres SaaS-Angebots definiert sind.

Roll‑outs lesen die Liste der verfügbaren Regionen aus dem zugehörigen SaaS-Angebot.

Ressourcenreplikation

App Lifecycle Manager übernimmt das Erstellen und Aktualisieren von Ressourcen für alle verfügbaren Regionen Ihres SaaS-Angebots.

Wenn Sie die verfügbaren Regionen Ihres SaaS-Angebots aktualisieren, übernimmt App Lifecycle Manager die Replikation:

  • Standorte hinzugefügt:Ressourcen werden an die neu hinzugefügten Standorte repliziert.
  • Standorte mit alten Kopien:Der Inhalt wird aktualisiert.

Artifact Registry- und Developer Connect-Standorte

Die Standorte Ihres Artifact Registry-Repositorys und Ihrer Developer Connect-Instanz müssen bestimmte Anforderungen erfüllen:

  • Die Region Ihres Artifact Registry-Repositorys und Ihrer Developer Connect Instanz kann jede gültige Google Cloud Region sein. Sie müssen nicht in den verfügbaren Regionen Ihres SaaS-Angebots enthalten sein.

  • Die Region Ihres Artifact Registry-Repositorys muss mit der Region Ihrer Developer Connect-Instanz übereinstimmen.

    Dies erfordert das Vorhandensein von Ressourcen für SaaS-Angebote, Releases und Einheitentypen in allen Regionen, die in Ihrem SaaS-Angebot definiert sind, auch wenn sich Artifact Registry und Developer Connect in einer einzigen (potenziell anderen) Region befinden.

  • Einheiten können nur in Regionen erstellt werden, die in Ihrem SaaS-Angebot angegeben sind.

Konfigurationsbeispiel für App Lifecycle Manager-Regionen

Wir haben dieses Beispiel bereitgestellt, um zu veranschaulichen, wie die Regionalisierung funktioniert, wenn Sie App Lifecycle Manager mit der verwalteten Ressourcenreplikation verwenden.

Wenn Sie beispielsweise Ihr SaaS-Angebot in us-central1 und europe-west4 bereitstellen und Ihr Artifact Registry-Repository und Ihre Developer Connect-Instanz in us-east1 hosten möchten, könnte Ihre App Lifecycle Manager-Regionsinfrastruktur so aussehen:

  • Verfügbare Regionen für SaaS-Angebote ['us-central1', 'europe-west4']
  • Region des Artifact Registry-Repositorys: us-east1
  • Region der Developer Connect-Instanz: us-east1
  • Ressourcen für Einheitentypen und Releases: App Lifecycle Manager verwaltet das Erstellen und Aktualisieren dieser Ressourcen in den Regionen global, us-central1 und europe-west4.
  • Einheiten:Einheiten können entweder in us-central1 oder europe-west4 erstellt werden.

Mit dieser Konfiguration können Sie Ihre Bereitstellungen in zwei Regionen verwalten, während Sie die Artefaktverwaltung in einer dritten, separaten Region mit automatisierter Ressourcenreplikation zentralisieren. Sie sollten Ihre Anforderungen an Latenz, Compliance und Datenstandort sorgfältig prüfen, wenn Sie Ihre Regionen auswählen.

Nächste Schritte