App Lifecycle Manager – Übersicht

Mit App Lifecycle Manager (früher SaaS Runtime) können Sie SaaS-Anwendungen (Software as a Service) in 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 Beteiligten in der SaaS-Pipeline auf vielfältige Weise verwendet werden. Wenn Sie eine dieser Rollen innehaben, könnte App Lifecycle Manager für Sie interessant sein:

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

App Lifecycle Manager bietet folgende Vorteile:

  • Vereinfachen Sie die Dienstverwaltung in großem Umfang, indem Sie Dienstverwaltungsaufgaben wie Bereitstellung, Roll-outs und die Verwaltung von Funktions-Flags für Ihre SaaS-Mandanten automatisieren.
  • Sie können die Beobachtbarkeit und Kontrolle verbessern, indem Sie Ihre Updates und Releases in konfigurierbaren Einheiten optimieren, um Ihr App-Angebot präzise und in großem Umfang 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 einheitenbasierte Gruppenaktualisierungen und -bereitstellungen fördert, um die Effizienz und Wiederverwendbarkeit zu verbessern.

Wie funktioniert App Lifecycle Manager?

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

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

Arbeitslast für App Lifecycle Manager vorbereiten

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

Organisieren Sie Teile Ihres App-Angebots, die zusammen aktualisiert oder geändert werden sollen, in separaten Terraform-Konfigurationen. Verwenden Sie bei der Planung Ihres App-Angebots Einheitsarten für jede Gruppierung Ihres App-Angebots.

Nachdem Sie die ideale Struktur für Ihre Arbeitslast in App Lifecycle Manager ausgearbeitet haben, können Sie Ihr App-Angebot und Ihre Einheitentypen erstellen und dann Ihre Einheiten mithilfe eines Roll-outs 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 im Application Design Center verwenden, um die Infrastruktur Ihrer App Lifecycle Manager-Anwendungsangebote zu definieren.

Sobald Sie eine zusammengesetzte Vorlage an Ihr App-Angebot anhängen, füllt App Lifecycle Manager die in Ihrer Vorlage definierten Arten von Einheiten aus. 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-App-Angeboten sehen.

Weitere Informationen zu zusammengesetzten Vorlagen finden Sie in der Dokumentation Zusammengesetzte Vorlagen entwerfen. Weitere Informationen zum Anhängen zusammengesetzter Vorlagen an App Lifecycle Manager-Angebote finden Sie unter Modell- und Paketeinheiten für die Bereitstellung.

App Lifecycle Manager-Dienstkonten

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

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

  • Betätigungsdienstkonto (nutzerverwaltet): Sie erstellen und verwalten dieses Dienstkonto. App Lifecycle Manager (über Infrastructure Manager) verwendet dieses Konto, um Ihre Terraform-Konfigurationen beim Bereitstellen oder Aktualisieren von Einheiten auszuführen. Dieses Konto fungiert als Identität zum Erstellen und Verwalten der in Terraform definierten Ressourcen. Die Berechtigungen des Betätigungsdienstkontos 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 eigenes Dienstkonto für die Betätigung zu verwenden.

  • Optional: Dienstkonto für die Artefakterstellung (nutzerverwaltet): Dieses Dienstkonto wird zum Erstellen und Hochladen Ihrer Terraform-Pakete in OCI-Artefakte verwendet. Dies ist häufig ein Cloud Build-Dienstkonto, kann aber auch ein beliebiges Dienstkonto mit den entsprechenden Berechtigungen für Ihr App-Angebot sein.

App Lifecycle Manager-Dienstkonto (von Google verwaltet)

Das App Lifecycle Manager-Dienstkonto ist ein von Google verwalteter Dienst-Agent, mit dem App Lifecycle Manager Vorgänge in Ihrem Projekt ausführt.

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.

Ersetzen Sie:

  • PROJECT_NUMBER: Ihre Projektnummer.

Dienstkonto zum Starten (nutzerverwaltet)

Das Betätigungsdienstkonto 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. Dies ist die Identität, die die in Terraform 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 für die Betätigung als Schlüssel/Wert-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.

Erforderliche Berechtigungen

Das Betätigungsdienstkonto 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 vollständige Kontrolle über Infra Manager-Ressourcen.
  • roles/storage.admin: Gewährt vollständige Kontrolle über Cloud Storage.

Das Dienstkonto für die Betätigung benötigt außerdem Berechtigungen zum Erstellen und Verwalten der spezifischen Google Cloud -Ressourcen, die von Ihrer Anwendung verwendet werden.

Beispiel:

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

Lesen Sie die Dokumentation zu jeder Google Cloud Ressource, die Sie in Terraform verwenden, um die erforderlichen Berechtigungen zu ermitteln. Gewähren Sie die geringsten Berechtigungen, die für die Funktion Ihrer Anwendung erforderlich sind.

Dienstkonto für die Artefakterstellung (nutzerverwaltet)

Das Dienstkonto für die Artefakterstellung ist ein von Ihnen erstelltes nutzerverwaltetes Dienstkonto, mit dem Sie ein Build-System (z. B. Cloud Build) verwenden, um Ihre Terraform-Artefakte zu verpacken und in Artifact Registry hochzuladen.

Dieses Dienstkonto ist vom App Lifecycle Manager- und dem Betätigungsdienstkonto getrennt. Es erstellt Ihren Terraform-Code und überträgt das resultierende Artefakt an Artifact Registry. Häufig ist dies das Cloud Build-Dienstkonto.

Manuelle Artefakterstellung

Wenn Sie Ihre Terraform-Artefakte manuell erstellen und hochladen (z. B. direkt 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: Zum Übertragen von Artefakten in 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 mehrere Roll-out-Strategien, um die Aktualisierung von Einheiten in Ihrem App-Angebot zu verwalten. Diese Roll-out-Strategien folgen dem Ansatz vonGoogle Cloudfür Änderungen, indem sie konsistente Ansätze für die Bereitstellung von Änderungen in Ihrem App-Angebot anwenden.

Verwenden Sie Roll-out-Strategien, um negative Auswirkungen auf Kunden zu minimieren und Probleme auf einzelne logische und physische Fehlerdomains zu beschränken. Definieren Sie Ihre Roll-out-Strategien, indem Sie eine Roll-out-Art erstellen, die eine der folgenden Roll-out-Strategien angibt:

  • Jeweils ein Standort (einfach): Es wird jeweils ein Standort aktualisiert, ohne dass zwischen den Standorten gewartet wird. Die Einheiten werden an einem Standort zufällig ausgewählt. Maximal 5% der Einheiten des Standorts werden gleichzeitig aktualisiert.

    Diese Strategie wird für Entwicklungsumgebungen und Notfallszenarien empfohlen.

  • Alle auf einmal (einfach): Alle Standorte werden gleichzeitig aktualisiert.

    Diese Strategie wird für Entwicklungsumgebungen und Notfallszenarien empfohlen.

  • Progressiv (schrittweise): Innerhalb jedes Standorts werden die Einheiten in statischen, prozentualen Batches (z. B. 1%, 10%, 20%, 30%, ~40%) mit Übergangszeiten zwischen den Batches aktualisiert. An den verschiedenen Standorten wird das 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 fortgesetzt. Einheiten innerhalb eines Standorts 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): 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, um genügend Zeit für die Problemerkennung zu haben und die negativen Auswirkungen von Rollout-Änderungen zu begrenzen.

    Diese Strategie ist auf App-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

App-Angebotsressourcen definieren, wo sich Ihre App Lifecycle Manager-Einheiten befinden können und wie Ihre Roll-outs verwaltet werden. Wenn Sie ein App-Angebot erstellen, dienen die von Ihnen ausgewählten Regionen als zentrale Informationsquelle für die unterstützten Regionen Ihres App-Angebots. Die von Ihnen ausgewählten Regionen sind die verfügbaren Regionen, die Sie für Ihr App-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 App-Angebot definieren, über Regionen hinweg. So werden die Konsistenz und Verfügbarkeit Ihrer App Lifecycle Manager-Ressourcen in allen verfügbaren Regionen gewährleistet, die Sie in Ihrem App-Angebot definiert haben.

Der App Lifecycle Manager repliziert die folgenden Ressourcen:

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

global als Region verwenden

Die Aufnahme von global als Region in Ihr App-Angebot wird im Allgemeinen nicht für Bereitstellungsziele empfohlen. App Lifecycle Manager verwendet die Region global, um regionale Roll-outs zu verteilen. 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 auf oberster Ebene bestimmt, die in den verfügbaren Regionen Ihres App-Angebots definiert sind.

Bei Roll-outs wird die Liste der verfügbaren Regionen aus dem zugehörigen App-Angebot gelesen.

Ressourcenreplikation

App Lifecycle Manager übernimmt die Erstellung und Aktualisierung von Ressourcen in allen verfügbaren Regionen Ihres App-Angebots.

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

  • Standorte hinzugefügt: Ressourcen werden an die neu hinzugefügten Standorte repliziert.
  • Speicherorte 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 App-Angebots enthalten sein.

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

    Dazu müssen Ressourcen für App-Angebote, Releases und Einheiten in allen Regionen vorhanden sein, die in Ihrem App-Angebot definiert sind, obwohl sich Artifact Registry und Developer Connect in einer einzigen (möglicherweise anderen) Region befinden.

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

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

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

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

  • Regionen, in denen die App verfügbar ist: ['us-central1', 'europe-west4']
  • Artifact Registry-Repository-Region: us-east1
  • Developer Connect-Instanzregion: us-east1
  • Einheitsart- und Release-Ressourcen: 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 automatisierter Ressourcenreplikation zentralisieren. Bei der Auswahl der Regionen sollten Sie Ihre Anforderungen an Latenz, Compliance und Datenstandort sorgfältig berücksichtigen.

Nächste Schritte

  • In der Kurzanleitung erfahren Sie, wie Sie eine VM mit App Lifecycle Manager bereitstellen.
  • Beginnen Sie mit App-Angebot erstellen, um mit App Lifecycle Manager loszulegen.