SaaS-Laufzeit – Übersicht

Vorschau

Dieses Produkt oder diese Funktion unterliegt den Bedingungen für Pre‑GA-Angebote im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und ‑Funktionen stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

Mit der SaaS-Laufzeit können Sie Software-as-a-Service-Anwendungen (SaaS) auf Google Cloudspeichern, hosten, verwalten und überwachen. SaaS Runtime 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.

Die SaaS-Laufzeit kann von verschiedenen Stakeholdern in der SaaS-Pipeline auf vielfältige Weise verwendet werden. Wenn Sie eine der folgenden Rollen haben, ist die SaaS-Laufzeit möglicherweise für Sie interessant:

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

Die SaaS-Laufzeit 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.
• Sie können Ihre Updates und Releases für konfigurierbare Einheiten optimieren, um die Sichtbarkeit und Kontrolle zu verbessern und Ihr SaaS-Angebot präzise zu verwalten.
• Sorgen Sie für Konsistenz in Ihrem Google Cloud Ökosystem, indem Sie Dienste in verschiedenen Google Cloud Produkten wie Google Cloud, Google Distributed Cloud, Billing, Observability und Resource Manager verwalten.
• Verwenden Sie eine flexible und auf Vorlagen basierende Architektur, die einheitliche Gruppenaktualisierungen und ‑bereitstellungen ermöglicht, um die Effizienz und Wiederverwendbarkeit zu verbessern.

Wie funktioniert die SaaS-Laufzeit?

Die SaaS-Laufzeit 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 Nomenklatur der SaaS-Laufzeit finden Sie im Glossar.

Arbeitslast für die SaaS-Laufzeit vorbereiten

Bevor Sie Ihr SaaS-Angebot bereitstellen, empfehlen wir, die ideale Anordnung Ihres SaaS-Angebots im SaaS-Laufzeit-Ökosystem zu ermitteln.

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

Sobald Sie die ideale Struktur für Ihre Arbeitslast in der SaaS-Laufzeit ermittelt haben, können Sie Ihr SaaS-Angebot und die Arten von Einheiten erstellen und dann Ihre Einheiten über einen Rollout bereitstellen.

Ein Beispiel für die Einrichtung der SaaS-Laufzeit finden Sie in der Kurzanleitung.

SaaS-Laufzeitdienstkonten

In der SaaS-Laufzeit werden sowohl von Google als auch von Nutzern verwaltete Dienstkonten verwendet:

• SaaS-Laufzeit-Dienstkonto (von Google verwaltet): Dieses Konto wird automatisch erstellt, nachdem die erste SaaS-Angebotressource erstellt wurde. 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. SaaS Runtime (ü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 Ihrem Terraform-Code 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.

Achtung: Die sorgfältige Verwaltung dieser Dienstkonten ist entscheidend für die Sicherheit und ordnungsgemäße Funktion Ihrer SaaS-Laufzeitbereitstellung. Sie sollten immer dem Grundsatz der geringsten Berechtigung folgen und jedem Dienstkonto nur die erforderlichen Berechtigungen erteilen.

SaaS Runtime-Dienstkonto (von Google verwaltet)

Das SaaS-Laufzeit-Dienstkonto ist ein von Google verwalteter Dienst-Agent, der von der SaaS-Laufzeit zum Ausführen von Vorgängen in Ihrem Projekt verwendet wird.

Dieses Dienstkonto wird automatisch bereitgestellt, wenn Sie Ihre erste SaaS Runtime-Ressource erstellen. Das SaaS-Laufzeit-Dienstkonto wird in diesem Format erstellt:

  [e-mail]

Ersetzen Sie:

• PROJECT_NUMBER: Ihre Projektnummer.

Hinweis :Die Projektnummer finden Sie in der Google Cloud Console auf der Seite Dashboard.

Dienstkonto zum Starten (nutzerverwaltet)

Das Ausführungsservicekonto ist ein vom Nutzer verwaltetes Dienstkonto, das Sie erstellen müssen. SaaS Runtime (über Infra Manager) verwendet dieses Dienstkonto, um Ihre Terraform-Konfigurationen auszuführen. Mit dieser Identität werden die in Ihrem Terraform-Code 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:

  [e-mail]
  

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 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 Mindestberechtigungen, die für die Funktion Ihrer Anwendung erforderlich sind.

Hinweis :Es empfiehlt sich, für jeden Mandanten (jede Einheit) ein separates Dienstkonto für die Ausführung zu erstellen, um potenzielle Probleme zu isolieren und zu begrenzen.

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 Packen und Hochladen Ihrer Terraform-Artefakte in Artifact Registry zu verwenden.

Dieses Dienstkonto ist unabhängig von den Dienstkonten für die SaaS-Laufzeit und zum Starten. 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

Die SaaS-Laufzeit 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 willkürlich innerhalb eines Standorts ausgewählt. Es werden maximal 20% der Einheiten eines Standorts gleichzeitig aktualisiert.

  Diese Strategie wird für Entwicklungsumgebungen und Notfallszenarien empfohlen.

• Alle auf einmal (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 erfolgt an allen Standorten mit einer exponentiellen Steigerung der Anzahl gleichzeitiger Standorte (z. B. ein Standort, dann zwei, dann vier) mit Soak-Zeiten (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 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.

Nächste Schritte

• In der Kurzanleitung erfahren Sie, wie Sie eine VM mit SaaS Runtime bereitstellen.
• Wenn Sie mit der SaaS-Laufzeit beginnen möchten, lesen Sie zuerst den Artikel SaaS-Angebot erstellen.