App Lifecycle Manager – Übersicht

Mit App Lifecycle Manager können Sie SaaS-Anwendungen (Software as a Service) 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 Sie eine der folgenden Rollen haben, ist App Lifecycle Manager möglicherweise für Sie interessant:

  • Plattformadministrator
  • Symbol: Anwendungsentwickler
  • Architekt
  • Compliance-Administrator
  • Plattformentwickler
  • Finanzvorgänge

App Lifecycle Manager bietet folgende Vorteile:

  • Vereinfachen Sie die Verwaltung Ihrer Dienste im großen Maßstab, indem Sie Aufgaben zur Dienstverwaltung (z. B. Bereitstellung, Roll-outs und Verwaltung von Funktions-Flags) für Ihre SaaS-Mandanten automatisieren.
  • Erweitern Sie Ihre Beobachtbarkeit und Kontrolle durch Feinabstimmung Ihrer Updates und Releases über konfigurierbare Einheiten hinweg, um Ihr SaaS-Angebot präzise und skalierbar 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, Abrechnung, Observability und Resource Manager.
  • Verwenden Sie eine flexible und vorlagenbasierte Architektur, die einheitliche Gruppenaktualisierungen und ‑bereitstellungen ermöglicht, um die Effizienz und Wiederverwendbarkeit zu verbessern.

Wie funktioniert App Lifecycle Manager?

App Lifecycle Manager stellt Artefakte bereit, die Ihr SaaS-Angebot definieren. Für diese Artefakte muss eine Terraform-Konfiguration vorhanden sein. Die Bereitstellung ist in separate Einheiten unterteilt, die über einen konfigurierbaren Roll-out-Prozess mit Releases aktualisiert werden können, die Änderungen an Ihrem Angebot enthalten.

Weitere Informationen zur App Lifecycle Manager-Nomenklatur 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 Arten von Einheiten für jede Gruppierung Ihres SaaS-Angebots.

Sobald Sie die ideale Struktur für Ihre Arbeitslast in App Lifecycle Manager ermittelt haben, können Sie Ihr SaaS-Angebot und Ihre Einheitenarten erstellen und dann Ihre Einheiten über einen Roll-out bereitstellen.

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

Zusammengesetzte Vorlagen mit App Lifecycle Manager verwenden

Sie können zusammengesetzte Vorlagen über das App Design Center verwenden, um die Infrastruktur Ihrer App Lifecycle Manager-Angebote zu definieren.

Sobald Sie Ihrem SaaS-Angebot eine zusammengesetzte Vorlage zuweisen, werden die in der Vorlage definierten Einheitenarten in App Lifecycle Manager eingefügt. So können Sie Einheiten basierend auf der Struktur und den Ressourcen bereitstellen, die in Ihrer zusammengesetzten Vorlage definiert sind.

Sie können Ihre zusammengesetzten Vorlagen im App Design Center bearbeiten und die Änderungen in Ihren App Lifecycle Manager-SaaS-Angeboten sehen.

Weitere Informationen zu zusammengesetzten Vorlagen finden Sie in der Dokumentation unter Zusammengesetzte Vorlagen entwerfen. Weitere Informationen zum Anhängen zusammengesetzter Vorlagen an App Lifecycle Manager-Angebote finden Sie unter Bereitstellungseinheiten modellieren und verpacken.

App Lifecycle Manager-Dienstkonten

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

  • App Lifecycle Manager-Dienstkonto (von Google verwaltet): Dieses Konto wird automatisch erstellt, nachdem Sie die erste SaaS-Angebotressource erstellt haben. Sie wird von Google verwaltet. Es führt Aktionen in Ihrem Namen aus, z. B. die Interaktion mit anderen Google Cloud Diensten während der Gerätebereitstellung.

  • Aktivierungsdienstkonto (vom Nutzer verwaltet): Sie erstellen und verwalten dieses Dienstkonto. App Lifecycle Manager (über Infrastructure Manager) verwendet dieses Konto, um Ihre Terraform-Konfigurationen auszuführen, wenn Einheiten bereitgestellt oder aktualisiert werden. Dieses Konto fungiert als Identität zum Erstellen und Verwalten der in Ihrem Terraform definierten Ressourcen. Die Berechtigungen des Dienstkontos für die Ausführung sind direkt an die Ressourcen gebunden, die von Ihrer Terraform-Konfiguration verwaltet werden.

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

  • Optional: Dienstkonto für die Artefakterstellung (nutzerverwaltet): Dieses Dienstkonto 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 (nutzerverwaltet)

Das Ausführungsservicekonto 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. Mit dieser Identität werden die in Ihrem Terraform definierten Ressourcen erstellt, geändert und gelö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 für die Ausführung als Schlüssel-Wert-Paar-Eingabevariable für die Terraform-Konfiguration angeben:

  • Name: actuation_sa
  • Variablentyp: String

  • Variablenwert: E-Mail-Adresse des Dienstkontos für die Ausführung:

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

Erforderliche Berechtigungen

Das Actuation-Dienstkonto benötigt ausreichende Berechtigungen, um die in Ihrer Terraform-Konfiguration definierten Ressourcen zu verwalten. Dafür benötigen Sie mindestens:

  • roles/iam.serviceAccountTokenCreator: Ermöglicht dem Dienstkonto, Tokens zur 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 für die Ausführung benötigt außerdem Berechtigungen zum Erstellen und Verwalten der spezifischen Google Cloud -Ressourcen, die von Ihrer Anwendung verwendet werden.

Beispiel:

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

In der Dokumentation für jede Google Cloud -Ressource, die Sie in Ihrem Terraform-Code verwenden, finden Sie die erforderlichen Berechtigungen. Gewähren Sie die geringste Berechtigung, die für die Funktion Ihrer Anwendung erforderlich ist.

Dienstkonto für die Artefakterstellung (vom Nutzer verwaltet)

Das Dienstkonto für die Artefakterstellung ist ein nutzerverwaltetes Dienstkonto, das Sie erstellen, um ein Build-System (z. B. Cloud Build) zum Verpacken und Hochladen Ihrer Terraform-Artefakte in Artifact Registry zu verwenden.

Dieses Dienstkonto ist unabhängig von den Dienstkonten für App Lifecycle Manager und die Ausführung. Es erstellt Ihren Terraform-Code und überträgt das resultierende Artefakt in Artifact Registry. Häufig ist dies das Cloud Build-Dienstkonto.

Artefakte manuell erstellen

Wenn Sie Ihre Terraform-Artefakte manuell erstellen und hochladen (z. B. mit „docker build“ und „docker push“), benötigen Sie kein separates Dienstkonto für die Artefakterstellung.

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: Artefakte in Artifact Registry übertragen.
  • 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 Einführungsstrategien folgen dem Google Cloud-Ansatz für Änderungen, indem einheitliche Ansätze für die Bereitstellung von Änderungen in Ihrem SaaS-Angebot angewendet werden.

Verwenden Sie Rollout-Strategien, um negative Auswirkungen auf Kunden zu minimieren und Probleme auf einzelne logische und physische Fehlerbereiche zu begrenzen. Definieren Sie Ihre Roll-out-Strategien, indem Sie eine Roll-out-Art erstellen, in der Sie eine der folgenden Roll-out-Strategien angeben:

  • Jeweils ein Standort (einfach): Die Standorte werden nacheinander eingeführt, ohne Wartezeit zwischen den Standorten. Die Einheiten werden innerhalb eines Standorts willkürlich ausgewählt. Es werden jeweils maximal 5% der Einheiten des Standorts aktualisiert.

    Diese Strategie wird für Entwicklungsumgebungen und Notfallszenarien empfohlen.

  • Gleichzeitig (einfach): Die Einführung beginnt an allen Standorten gleichzeitig.

    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%, ca. 40%) mit Wartezeiten zwischen den Batches eingeführt. Der Roll-out schreitet an den Standorten mit einer exponentiellen Zunahme der Anzahl der gleichzeitigen Standorte voran (z. B. ein Standort, dann zwei, dann vier) mit Soak-Zeiten (z. B. 18 Stunden) zwischen den Wellen. Einheiten innerhalb eines Standorts werden zufällig ausgewählt.

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

  • Progressiv (einzelner Standort): Die 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, damit genügend Zeit für die Erkennung von Problemen bleibt und die negativen Auswirkungen von Roll-out-Änderungen begrenzt werden.

    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 Rollout-Arten finden Sie unter Rollout-Art erstellen.

Regionalisierung von App Lifecycle Manager

Mit SaaS-Angebot-Ressourcen wird definiert, 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 von Ihnen ausgewählten Regionen als zentrale Informationsquelle für die unterstützten Regionen Ihres SaaS-Angebots. Die von Ihnen 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 -Konsole verwenden, wird die Replikation der Ressourcen, die Sie in Ihrem SaaS-Angebot definieren, regionsübergreifend automatisiert. So wird die Konsistenz und Verfügbarkeit Ihrer App Lifecycle Manager-Ressourcen in allen verfügbaren Regionen sichergestellt, die Sie in Ihrem SaaS-Angebot definiert haben.

App Lifecycle Manager repliziert diese Ressourcen:

  • SaaS-Angebot (Saas)
  • Art der Einheit (UnitKind)
  • Release (Release)

global als Region verwenden

global als Region in Ihr SaaS-Angebot aufzunehmen, wird für Bereitstellungsziele im Allgemeinen nicht empfohlen. App Lifecycle Manager verwendet die Region global, um regionale Roll-outs zu übertragen. Regionale Roll-outs können nicht in der Region global ausgeführt werden.

Regionalisierung des 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.

Bei der Einführung wird die Liste der verfügbaren Regionen aus dem zugehörigen SaaS-Angebot gelesen.

Ressourcenreplikation

App Lifecycle Manager übernimmt die Erstellung und Aktualisierung 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:

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

Artifact Registry- und Developer Connect-Standorte

Für die Standorte Ihres Artifact Registry-Repositorys und Ihrer Developer Connect-Instanz gelten bestimmte Anforderungen:

  • Die Region Ihres Artifact Registry-Repositorys und Ihrer Developer Connect-Instanz kann eine beliebige 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.

    Dazu müssen SaaS-Angebot, Release und Ressourcentyp in allen Regionen vorhanden sein, 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.

Beispiel für die Konfiguration von App Lifecycle Manager-Regionen

Dieses Beispiel soll veranschaulichen, wie die Regionalisierung funktioniert, wenn Sie App Lifecycle Manager mit der Replikation verwalteter Ressourcen verwenden.

Wenn Sie Ihr SaaS-Angebot beispielsweise in us-central1 und europe-west4 bereitstellen und Ihr Artifact Registry-Repository und Ihre Developer Connect-Instanz in us-east1 hosten möchten, würde die Infrastruktur der App Lifecycle Manager-Regionen so aussehen:

  • Verfügbare Regionen für SaaS-Angebot:['us-central1', 'europe-west4']
  • Region des Artifact Registry-Repositorys: us-east1
  • Region der Developer Connect-Instanz: us-east1
  • Einheitstyp und Release: App Lifecycle Manager verwaltet die Erstellung und Aktualisierung 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 und gleichzeitig die Artefaktverwaltung in einer dritten, separaten Region mit automatischer Ressourcenreplikation zentralisieren. Bei der Auswahl der Regionen sollten Sie Ihre Anforderungen an Latenz, Compliance und Datenstandort sorgfältig berücksichtigen.

Nächste Schritte