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 bei 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 die Variablenhierarchie, die Abhängigkeitsbeziehungen und die Variablenausrichtungen, um Ihre SaaS-Architektur und Management-Workflows in der SaaS-Laufzeit zu optimieren.

Einheiten und Variablen

Im Zentrum der SaaS-Laufzeit stehen Einheiten. Einheiten verwenden Variablen, um ihre Bereitstellung und ihr Verhalten anzupassen. Diese Variablen sind im Grunde Terraform-Variablen, die Sie in der variables.tf-Datei Ihres Blueprints definieren können. Damit können Sie Ihre Terraform-Konfigurationen 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 obligatorischen 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 das Erstellen und Verwalten von Ressourcen im richtigen Google Cloud Projekt erforderlich.

    Sie finden Ihre Projekt-ID in der Google Cloud Console auf der Seite Dashboard. Suchen Sie im Abschnitt Cloud-Übersicht auf der Karte Projektinformationen nach dem Feld Projekt-ID.

  • project_number oder tenant_project_number: Ähnlich wie bei project_id steht diese Variable für die Google Cloud Projektnummer. Sie können project_number und tenant_project_number austauschbar verwenden.

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

  • actuation_sa: Diese Variable steht für die E-Mail-Adresse des Dienstkontos für die Ausführung. Dieses Dienstkonto ist ein nutzerverwaltetes Dienstkonto, das von der SaaS-Laufzeit (über Infrastructure Manager) verwendet wird, um Ihre Terraform-Konfigurationen beim Bereitstellen, Aktualisieren oder Aufheben der Bereitstellung von Einheiten auszuführen.

    Wir empfehlen, pro Mandant (oder Einheit) ein eigenes Dienstkonto für die Ausführung zu verwenden, um das Prinzip der geringsten Berechtigung zu implementieren. Dadurch werden die potenziellen Auswirkungen von Sicherheitslücken begrenzt und die Isolation zwischen Ihren Bereitstellungen verbessert.

    Weitere Informationen zum Konfigurieren und Zuweisen von Berechtigungen für Dienstkonten für die Ausführung finden Sie in der Produktübersicht.

Hierarchie der Einheitsvariablen

Einheitliche Variablen 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 während der Einheitsvorgänge 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 Einheitenressource 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 ein Wert aus Quellen mit höherer Priorität in der Hierarchie gefunden wird.

  2. Standardwerte für die Veröffentlichung: Standardwerte für die Veröffentlichung werden angewendet, wenn eine Variable noch nicht für die Einheit festgelegt ist. Sie überschreiben jedoch vorhandene Einheitsvariablen.

  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 Release-Standardwerte und vorhandene Einheitsvariablen.

  4. Variablenzuordnungen für Eingabevariablen von Abhängigkeiten: Wenn eine Einheit von anderen Einheiten abhängt, können Variablenzuordnungen, die in der Einheitentyp definiert sind, Variablenwerte aus den Ausgabevariablen von Abhängigkeitseinheiten beziehen. Dies ist die Quelle mit der höchsten Priorität. Variablen, die über Abhängigkeitszuordnungen abgerufen werden, überschreiben Werte aus Einheitsvorgängen, Release-Standardwerten und vorhandenen Einheitsvariablen.

Dieser hierarchische Ansatz bietet Flexibilität und Kontrolle bei der Verwaltung von Variablen. Sie können persistente Konfigurationen direkt auf der Einheit (niedrigste Priorität) einrichten, Baseline-Standardwerte mithilfe von Releases definieren, Anpassungen für bestimmte Vorgänge vornehmen und die wichtigsten und überschreibenden Werte dynamisch aus Einheitenabhängigkeiten abrufen (höchste Priorität).

Abhängigkeiten der Einheit

Mit der SaaS-Laufzeit können Sie Abhängigkeiten zwischen Einheiten definieren. Das ist wichtig für die Entwicklung komplexer SaaS-Anwendungen, bei denen verschiedene Komponenten voneinander abhängen. Durch Abhängigkeiten wird sichergestellt, dass zugehörige 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 UnitKind-Definition 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 der UnitKind Abhängigkeiten definiert sind, prüft die SaaS-Laufzeit automatisch, ob diese Abhängigkeitseinheiten vorhanden sind.

Wenn eine abhängige Einheit nicht gefunden wird, wird sie von der SaaS-Laufzeit automatisch bereitgestellt, 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 beizubehalten.

Variablenzuordnung

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 ihrer Abhängigkeiten zu konfigurieren.

Die Variablenausrichtung wird innerhalb des abhängigen Einheitentyps 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 Cluster UnitKind-Abhängigkeit abzurufen. Dadurch 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 bereitgestellt werden.

    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 wird App UnitKind verwendet, um die Eingabevariablen tenant_project_id und tenant_project_number an die Cluster UnitKind-Abhängigkeit zu übergeben.ToMapping 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 diese Option auf false festgelegt ist, verwendet die SaaS-Laufzeit die in ToMapping angegebenen Eingabevariablen als Suchschlüssel, um eine vorhandene abhängige Einheit zu finden. Wenn eine Einheit mit übereinstimmenden Eingabevariablen gefunden wird, wird sie als Abhängigkeit wiederverwendet. Wenn keine passende Einheit gefunden wird, wird eine neue Abhängigkeitseinheit bereitgestellt. Dies ist nützlich, um freigegebene Ressourcen wie Cluster wiederzuverwenden.
    • true: Wenn diese Variable 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 dedizierte, nicht freigegebene Abhängigkeiten benötigen.

Beispiel: Gemeinsam genutzter Kubernetes-Cluster

Wenn Sie einen Kubernetes-Cluster für mehrere Anwendungseinheiten innerhalb desselben Projekts wiederverwenden möchten, verwenden Sie ToMapping mit ignore_for_lookup auf false und ordnen Sie Variablen wie tenant_project_id und region dem Clustertyp zu. Einheiten im selben Projekt und in derselben Region würden dann denselben Cluster verwenden.

Beispiel: Dedizierter Kubernetes-Cluster pro Anwendung

Wenn Sie für jede Anwendungseinheit einen dedizierten Kubernetes-Cluster benötigen, verwenden Sie ToMapping mit ignore_for_lookup auf true oder vermeiden Sie ToMapping-Lookup-Variablen ganz. Jede Anwendungseinheit würde dann die Bereitstellung eines neuen, isolierten Kubernetes-Clusters auslösen.

Secrets verwalten

SaaS Runtime-Variablen sind nicht zum Speichern vertraulicher Informationen wie Passwörter, API-Schlüssel oder Zertifikate vorgesehen. Das Speichern von Secrets direkt 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