Variablen und Variablenzuordnung mit der SaaS-Laufzeit

In diesem Dokument wird erläutert, wie Variablen, Variablenzuordnung und Abhängigkeiten in der SaaS-Laufzeit funktionieren.

Mit der SaaS-Laufzeit können Sie komplexe SaaS-Anwendungen bereitstellen und verwalten, indem Sie sie in modulare Einheiten unterteilen. Diese Einheiten, die durch Terraform Konfigurationen in Blueprints definiert werden, können über Abhängigkeiten miteinander verbunden werden, was eine ausgefeilte Orchestrierung und automatisierte Bereitstellung ermöglicht. Ein wichtiger Aspekt der Verwaltung dieser Einheiten und ihrer Interaktionen ist die Verwendung von Variablen und Variablenzuordnung.

Sie können komplexe, modulare und skalierbare Bereitstellungen mit automatisierter Bereitstellung, Kommunikation zwischen Einheiten und flexiblen Konfigurationsoptionen erstellen. Berücksichtigen Sie sorgfältig Ihre Variablenhierarchie, Abhängigkeitsbeziehungen und Variablenzuordnungen, um Ihre SaaS-Architektur und Verwaltungsabläufe in der SaaS-Laufzeit zu optimieren.

Einheiten und Variablen

Das Herzstück der SaaS-Laufzeit sind Einheiten. Einheiten verwenden Variablen, um ihre Bereitstellung und ihr Verhalten anzupassen. Diese Variablen sind im Wesentlichen Terraform-Variablen, die Sie in der Datei variables.tf Ihres Blueprints definieren können. Sie ermöglichen es Ihnen, Ihre Terraform-Konfigurationen zu parametrisieren, sodass sie in verschiedenen Umgebungen und Bereitstellungen wiederverwendet und angepasst werden können.

Erforderliche Variablen für die Bereitstellung von Einheiten

Sie können zwar benutzerdefinierte Variablen für Ihre Einheiten definieren, die SaaS-Laufzeit verwendet aber auch eine Reihe von erforderlichen Variablen. Diese Variablen werden von der SaaS-Laufzeit automatisch erkannt und verarbeitet, auch wenn sie nicht explizit in Ihrer Terraform-Konfiguration definiert sind.

Die erforderlichen Variablen sind:

  • project_id und project_number oder tenant_project_id und tenant_project_id: Diese Variable gibt die Google Cloud Projekt-ID an, in der die Ressourcen Ihrer Einheit bereitgestellt werden. Sie können entweder project_id und project_number oder tenant_id und tenant_project_id verwenden. Dieses Feld ist für die Ressourcenerstellung und ‑verwaltung im richtigen Google Cloud Projekt erforderlich.

    Sie finden Ihre Projekt-ID in der the Google Cloud console auf der Seite „Dashboard“. Suchen Sie im Bereich Cloud-Übersicht auf der Karte Projektinformationen nach dem Feld Projekt-ID.

  • project_number oder tenant_project_number: Ähnlich wie project_id, stellt diese Variable die Google Cloud Projekt nummer dar. Sie können project_number oder tenant_project_number austauschbar verwenden.

    Sie finden Ihre Projektnummer neben Ihrer Projekt-ID im Bereich Cloud-Übersicht auf der Karte Projektinformationen der Seite „Dashboard“ der Google Cloud console.

  • actuation_sa: Diese Variable stellt die E-Mail-Adresse des Aktivierungsdienstkontos dar. Dieses Dienstkonto ist ein vom Nutzer verwaltetes Dienstkonto, das von der SaaS-Laufzeit (über Infrastructure Manager) verwendet wird, um Ihre Terraform-Konfigurationen auszuführen, wenn Einheiten bereitgestellt, aktualisiert oder deren Bereitstellung aufgehoben wird.

    Wir empfehlen, für jeden Mandanten (oder jede Einheit) ein eigenes Aktivierungsdienstkonto zu verwenden, um das Prinzip der geringsten Berechtigung zu implementieren. Dadurch werden die potenziellen Auswirkungen von Sicherheitsverletzungen begrenzt und eine bessere Isolation zwischen Ihren Bereitstellungen erreicht.

    Weitere Informationen zum Konfigurieren und Gewähren von Berechtigungen für Aktivierungs dienstkonten finden Sie unter Produktübersicht.

Hierarchie der Variablen für Einheiten

Variablen für Einheiten können an mehreren Stellen definiert und abgerufen werden. Wenn Sie die SaaS-Laufzeit verwenden, ist es wichtig, die Hierarchie der Variablenwerte zu verstehen, die bei Einheitsvorgängen verwendet werden.

Die Reihenfolge ist wie folgt (von der niedrigsten zur höchsten Priorität):

Die SaaS-Laufzeit löst Variablenwerte in dieser Reihenfolge auf:

  1. Vorhandene Eingabevariablen für die Einheit: Wenn eine Variable bereits für die Einheitsressource selbst definiert ist (z. B. aus einem vorherigen Vorgang oder einer vorherigen Konfiguration), hat dieser Wert die niedrigste Priorität. Wenn ein Variablenwert direkt für die Einheit festgelegt ist, wird er überschrieben, wenn Werte aus Quellen mit höherer Priorität in der Hierarchie gefunden werden.

  2. Standardwerte für Releases: Standardwerte für Releases werden angewendet, wenn eine Variable noch nicht für die Einheit festgelegt ist. Sie überschreiben jedoch vorhandene Variablen für Einheiten.

  3. Einheitsvorgänge: Wenn Sie einen Einheitsvorgang wie provision oder upgrade ausführen, können Sie Eingabevariablen explizit als Teil der Vorgangsanfrage angeben. Variablen, die in einem Einheitsvorgang angegeben werden, überschreiben Standardwerte für Releases und vorhandene Variablen für Einheiten.

  4. Zuordnungen von Eingabevariablen für Abhängigkeiten: Wenn eine Einheit von anderen Einheiten abhängig ist, können Variablenzuordnungen, die in der Art der Einheit definiert sind, Variablen werte aus den Ausgabevariablen der Abhängigkeitseinheiten abrufen. Dies ist die Quelle mit der höchsten Priorität. Variablen, die über Abhängigkeitszuordnungen abgerufen werden, überschreiben Werte aus Einheitsvorgängen, Standardwerte für Releases und vorhandene Variablen für Einheiten.

Dieser hierarchische Ansatz bietet Flexibilität und Kontrolle über die Variablenverwaltung. Sie können persistente Konfigurationen direkt für die Einheit festlegen (niedrigste Priorität), Standardwerte mit Releases definieren, Anpassungen für bestimmte Vorgänge vornehmen und die wichtigsten und überschreibenden Werte dynamisch aus Abhängigkeiten von Einheiten abrufen (höchste Priorität).

Abhängigkeiten der Einheit

Mit der SaaS-Laufzeit können Sie Abhängigkeiten zwischen Einheiten definieren. Dies ist wichtig für die Entwicklung komplexer SaaS-Anwendungen, bei denen verschiedene Komponenten voneinander abhängig sind. Abhängigkeiten sorgen dafür, dass verknüpfte Einheiten koordiniert bereitgestellt und verwaltet werden.

Sie definieren Abhängigkeiten innerhalb einer Art von Einheit. Wenn Sie eine Einheit einer bestimmten Art erstellen, verwaltet die SaaS-Laufzeit automatisch ihre Abhängigkeiten.

Abhängigkeitsdefinition in der Art der Einheit

In der Definition von UnitKind geben Sie eine Liste von Abhängigkeiten an, die jeweils auf eine andere UnitKind verweisen und ihr einen Alias zuweisen. Dieser Alias wird verwendet, um in Variablenzuordnungen auf die Abhängigkeit zu verweisen:

  message UnitKind {
    // ... other fields ...

    // List of other unit kinds that this release will depend on.
    repeated Dependency dependencies = 4
        [(.google.api.field_behavior) = OPTIONAL];
    // ...
  }

  message Dependency {
    // The unit kind of the dependency.
    string unit_kind = 1 [
      (.google.api.field_behavior) = REQUIRED,
      (.google.api.field_behavior) = IMMUTABLE,
      (.google.api.resource_reference) = {
        type: "saasservicemgmt.googleapis.com/UnitKind"
      }
    ];

    // An alias for the dependency. Used for input variable mapping.
    string alias = 2 [(.google.api.field_behavior) = REQUIRED];
  }

Automatische Bereitstellung von Abhängigkeiten

Wenn Sie die Bereitstellung einer Einheit anfordern, für die in ihrer UnitKind Abhängigkeiten definiert sind, prüft die SaaS-Laufzeit automatisch, ob diese Abhängigkeitseinheiten vorhanden sind.

Wenn eine Abhängigkeitseinheit nicht gefunden wird, stellt die SaaS-Laufzeit sie automatisch bereit, bevor die abhängige Einheit bereitgestellt wird.

Die SaaS-Laufzeit sorgt dafür, dass Abhängigkeitseinheiten vor ihren abhängigen Einheiten bereitgestellt werden, um die richtige Reihenfolge der Vorgänge einzuhalten.

Variablenzuordnung

Die Variablenzuordnung ist der Mechanismus zum Übergeben von Daten (Variablenwerten) zwischen abhängigen Einheiten und ihren Abhängigkeiten. Dies ist wichtig, um abhängige Einheiten basierend auf Ausgaben aus ihren Abhängigkeiten zu konfigurieren.

Die Variablenzuordnung wird innerhalb der Art der abhängigen Einheit definiert und verwendet FromMapping und ToMapping:

  • FromMapping: FromMapping wird verwendet, um Ausgabevariablen aus einer Abhängigkeitseinheit abzurufen und sie den Eingabevariablen der abhängigen Einheit zuzuordnen. So kann eine abhängige Einheit Informationen von ihren Abhängigkeiten abrufen, z. B. Verbindungsendpunkte oder Ressourcen-IDs.

    message VariableMapping {
  // ...
  oneof mapping_type {
    // Output variables which will get their values from dependencies
    FromMapping from = 2 [(.google.api.field_behavior) = OPTIONAL];
    // ...
  }
}

message FromMapping {
  // Alias of the dependency that the outputVariable will pass its value to
  string dependency = 1 [(.google.api.field_behavior) = REQUIRED];

  // Name of the outputVariable on the dependency
  string output_variable = 2 [(.google.api.field_behavior) = REQUIRED];
}

    Im bereitgestellten Codelab-Beispiel hat App UnitKind eine FromMapping, um die Ausgabevariable cluster_endpoint aus der Abhängigkeit Cluster UnitKind abzurufen. So kann die Anwendung eine Verbindung zum neu bereitgestellten Kubernetes-Cluster herstellen.

  • ToMapping: ToMapping wird verwendet, um Eingabevariablen von der abhängigen Einheit an die Eingabevariablen einer Abhängigkeitseinheit zu übergeben. So können Sie Abhängigkeitseinheiten basierend auf Parametern konfigurieren, die für die abhängige Einheit angegeben wurden.

    message VariableMapping {
  // ...
  oneof mapping_type {
    // ...
    // Input variables whose values will be passed on to dependencies.
    ToMapping to = 3 [(.google.api.field_behavior) = OPTIONAL];
  }
}

message ToMapping {
  // Alias of the dependency that the inputVariable will pass its value to
  string dependency = 1 [(.google.api.field_behavior) = REQUIRED];

  // Name of the inputVariable on the dependency
  string input_variable = 2 [(.google.api.field_behavior) = REQUIRED];

  // Tells EasySaaS if this mapping should be used during lookup or not
  bool ignore_for_lookup = 3 [(.google.api.field_behavior) = OPTIONAL];
}

    Im Codelab verwendet App UnitKind ToMapping, um die Eingabevariablen tenant_project_id und tenant_project_number an die Abhängigkeit Cluster UnitKind zu übergeben. So wird sichergestellt, dass der Kubernetes-Cluster im richtigen Projekt erstellt wird.

  • ignore_for_lookup in ToMapping: Das Feld ignore_for_lookup in ToMapping steuert das Verhalten bei der Suche nach Abhängigkeiten. Es ist ein boolescher Wert:

    • false (oder nicht angegeben): Wenn der Wert auf false gesetzt ist, verwendet die SaaS-Laufzeit die in ToMapping angegebenen Eingabevariablen als Suchschlüssel , um eine vorhandene Abhängigkeitseinheit zu finden. Wenn eine Einheit mit übereinstimmenden Eingabevariablen gefunden wird, wird sie als Abhängigkeit wiederverwendet. Wenn keine übereinstimmende Einheit gefunden wird, wird eine neue Abhängigkeitseinheit bereitgestellt. Dies ist nützlich, um freigegebene Ressourcen wie Cluster wiederzuverwenden.
    • true: Wenn der Wert auf true gesetzt ist, wird die Eingabevariable in ToMapping nicht für die Suche nach Abhängigkeiten verwendet. Das bedeutet, dass immer eine neue Abhängigkeitseinheit bereitgestellt wird, auch wenn bereits Einheiten mit denselben Eingabevariablen vorhanden sind. Dies ist nützlich, wenn Sie für jede abhängige Einheit eigene, nicht freigegebene Abhängigkeiten benötigen.

Beispiel: Freigegebener Kubernetes-Cluster

Wenn Sie einen Kubernetes-Cluster für mehrere Anwendungseinheiten im selben Projekt wiederverwenden möchten, verwenden Sie ToMapping mit ignore_for_lookup auf false gesetzt und ordnen Sie Variablen wie tenant_project_id und region der Art der Clustereinheit zu. Einheiten im selben Projekt und in derselben Region verwenden dann denselben Cluster.

Beispiel: Eigener Kubernetes-Cluster pro Anwendung

Wenn Sie für jede Anwendungseinheit einen eigenen Kubernetes-Cluster benötigen, setzen Sie ignore_for_lookup in ToMapping auf true oder verzichten Sie ganz auf Suchvariablen in ToMapping. Jede Anwendungseinheit löst dann die Bereitstellung eines neuen, isolierten Kubernetes-Clusters aus.

Secrets verwalten

Variablen der SaaS-Laufzeit sind nicht zum Speichern vertraulicher Informationen wie Passwörter, API-Schlüssel oder Zertifikate vorgesehen. Das direkte Speichern von Secrets in Variablen birgt Sicherheitsrisiken. Variablenwerte können protokolliert und möglicherweise über Systemausgaben offengelegt werden, was die Wahrscheinlichkeit eines unbefugten Zugriffs erhöht.

Für die sichere Verwaltung von Secrets in Ihren SaaS-Laufzeitanwendungen, empfehlen wir dringend die Verwendung von Secret Manager.

Nächste Schritte