App Lifecycle Manager – Übersicht

Mit App Lifecycle Manager (ehemals SaaS Runtime) 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
  • Finanzvorgänge

App Lifecycle Manager bietet folgende Vorteile:

  • Vereinfachen Sie die Dienstverwaltung 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, indem Sie Ihre Updates und Releases für konfigurierbare Einheiten optimieren, um Ihr App-Angebot im großen Maßstab präzise zu verwalten.
  • Sorgen Sie für Konsistenz in Ihrem Google Cloud Ökosystem, indem Sie Dienste für verschiedene Google Cloud Produkte verwalten, darunter Google Cloud, Google Distributed Cloud, Cloud Billing, Beobachtbarkeit und Resource Manager.
  • Verwenden Sie eine flexible und vorlagenbasierte Architektur, die einheitenbasierte Gruppenupdates und -bereitstellungen für mehr Effizienz und Wiederverwendbarkeit fördert.

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 enthalten. Dies erfolgt über einen konfigurierbaren Roll‑out-Prozess.

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 beim Planen Ihres App-Angebots Arten von Einheiten für jede Gruppierung Ihres App-Angebots.

Sobald Sie die ideale Struktur für Ihre Arbeitslast in App Lifecycle Manager festgelegt haben, können Sie Ihr App-Angebot und die Arten von Einheiten 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.

Zusammengesetzte Vorlagen mit App Lifecycle Manager verwenden

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

Sobald Sie eine zusammengesetzte Vorlage an Ihr App-Angebot angehängt haben, 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 zu zusammengesetzten Vorlagen. Weitere Informationen zum Anhängen zusammengesetzter Vorlagen an App Lifecycle Manager-Angebote finden Sie unter Einheiten für die Bereitstellung modellieren und verpacken.

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 App-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 fungiert 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 Dienstkonto wird verwendet, um Ihre in OCI Artefakte verpackte Terraform-Konfiguration zu erstellen und hochzuladen. Häufig ist dies ein Cloud Build-Dienstkonto, es 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, 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 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.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 vollständige Kontrolle über Infra Manager-Ressourcen.
  • roles/storage.admin: Gewährt 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 den einzelnen Google Cloud Ressourcen, die Sie in Ihrer Terraform-Konfiguration verwenden, finden Sie die erforderlichen Berechtigungen. Gewähren Sie nur die geringsten Berechtigungen, die für die Funktion Ihrer Anwendung erforderlich sind.

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 verpacken und in Artifact Registry hochzuladen.

Dieses Dienstkonto ist von den App Lifecycle Manager- und Dienstkonten 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.

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 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 App-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 App-Angebot angewendet werden.

Verwenden Sie Roll‑out-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 und eine der folgenden Roll‑out-Strategien angeben:

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

    Diese Strategie wird für Entwicklungsumgebungen und Notfallszenarien empfohlen.

  • Alle auf einmal (einfach): Die Bereitstellung 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 bereitgestellt (z. B. 1%, 10%, 20%, 30%, ~40%) mit Übergangszeiten zwischen den Batches. Standortübergreifend schreitet der Roll‑out mit einer exponentiellen Zunahme der Anzahl gleichzeitiger Standorte voran (z. B. ein Standort, dann zwei, dann vier) mit Übergangszeiten (z. B. 18 Stunden) zwischen den Wellen. Einheiten an einem Standort werden zufällig ausgewählt.

    Diese Strategie ist für sichere und vorhersehbare Roll‑outs an mehreren Standorten konzipiert. Es wird in kleinem Umfang begonnen und 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 aktualisiert (z. B. 1%, 10%, 20%, 30%, ~40%) mit längeren Übergangszeiten (z. B. 18 Stunden) zwischen den Batches, um ausreichend Zeit für die Erkennung von Problemen zu haben und die negativen Auswirkungen von Roll‑out-Änderungen zu begrenzen.

    Diese Strategie ist auf App-Angebote zugeschnitten, die an einem einzigen Standort betrieben werden, 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 ausgewählten Regionen als einzige verlässliche Quelle für die unterstützten Regionen Ihres App-Angebots. Die 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, 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 App-Angebot definiert haben.

App Lifecycle Manager repliziert diese Ressourcen:

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

global als Region verwenden

global als Region in Ihr App-Angebot aufzunehmen, wird für Bereitstellungsziele im Allgemeinen nicht empfohlen. 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 App-Angebots definiert sind.

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

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 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 App-Angebots enthalten sein.

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

    Dies erfordert das Vorhandensein von App-Angebot-, Release- und Arten von Einheiten-Ressourcen in allen Regionen, die in Ihrem App-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 App-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 Ihr App-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, könnte Ihre App Lifecycle Manager-Regionsinfrastruktur so aussehen:

  • Verfügbare Regionen für das App-Angebot ['us-central1', 'europe-west4']
  • Region des Artifact Registry-Repositorys: us-east1
  • Region der Developer Connect-Instanz: us-east1
  • Arten von Einheiten 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, während Sie Ihre 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