Variablen und Variablenzuordnung mit App Lifecycle Manager

In diesem Dokument wird beschrieben, wie Variablen, Variablenzuordnung und Abhängigkeiten in App Lifecycle Manager funktionieren.

Mit App Lifecycle Manager 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, Abhängigkeitsbeziehungen und Variablenausrichtungen, um Ihre SaaS-Architektur und Verwaltungs-Workflows in App Lifecycle Manager zu optimieren.

Einheiten und Variablen

Einheiten sind das Herzstück von App Lifecycle Manager. 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, App Lifecycle Manager verwendet aber auch eine Reihe von Pflichtvariablen. Diese Variablen werden von App Lifecycle Manager 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_number): Mit dieser Variablen wird die Google Cloud Projekt-ID angegeben, in der die Ressourcen Ihrer Einheit bereitgestellt werden. Sie können entweder project_id und project_number oder tenant_id und tenant_project_number verwenden. Dieses Feld ist für die Erstellung und Verwaltung 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 der Dashboard-Seite der Google Cloud Console auf der Karte Projektinformationen.

  • 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 App Lifecycle Manager (ü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 App Lifecycle Manager verwenden, ist es wichtig, die Hierarchie der Variablenwerte zu verstehen, die bei Einheitenvorgängen verwendet werden.

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

App Lifecycle Manager 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-Standardeinstellungen 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 abrufen. 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) festlegen, 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 App Lifecycle Manager können Sie Abhängigkeiten zwischen Einheiten definieren. Das ist wichtig, wenn Sie komplexe SaaS-Anwendungen entwickeln, bei denen verschiedene Komponenten voneinander abhängig sind. Abhängigkeiten sorgen dafür, dass zugehörige Einheiten koordiniert bereitgestellt und verwaltet werden.

Sie definieren Abhängigkeiten innerhalb einer Art von Einheit. Wenn Sie eine Einheit eines bestimmten Einheitentyps erstellen, verwaltet App Lifecycle Manager automatisch die zugehörigen 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 App Lifecycle Manager automatisch, ob diese abhängigen Einheiten vorhanden sind.

Wenn eine Abhängigkeitseinheit nicht gefunden wird, stellt App Lifecycle Manager sie automatisch bereit, bevor die abhängige Einheit bereitgestellt wird.

App Lifecycle Manager sorgt dafür, dass Abhängigkeitseinheiten vor den zugehörigen 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 App Lifecycle Manager 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 Option auf true festgelegt 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. Das 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 Clustereinheitstyp 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 gesetzt oder vermeiden Sie ToMapping-Lookup-Variablen ganz. Jede Anwendungseinheit würde dann die Bereitstellung eines neuen, isolierten Kubernetes-Clusters auslösen.

Secrets verwalten

App Lifecycle Manager-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 verfügbar gemacht werden, was das Risiko eines unbefugten Zugriffs erhöht.

Für die sichere Verwaltung von Secrets in Ihren App Lifecycle Manager-Anwendungen empfehlen wir dringend die Verwendung von Secret Manager.

Nächste Schritte