Verwenden von Konfigurations-Pipelines config-pipelines

Erfahren Sie, wie Sie Konfigurations-Pipelines verwenden können, um in AEM as a Cloud Service verschiedene Konfigurationen wie Einstellungen für die Protokollweiterleitung, Bereinigungsaufgaben und verschiedene CDN-Konfigurationen bereitzustellen.

Überblick overview

Eine Cloud Manager-Konfigurations-Pipeline stellt Konfigurationsdateien (die im YAML-Format erstellt wurden) in einer Zielumgebung bereit. Auf diese Weise kann eine Reihe von Funktionen in AEM as a Cloud Service konfiguriert werden, darunter die Protokollweiterleitung, Bereinigungsaufgaben sowie verschiedene CDN-Funktionen.

Konfigurations-Pipelines können über Cloud Manager für Entwicklungs-, Staging- und Produktionsumgebungstypen in Produktionsprogrammen (ohne Sandbox) bereitgestellt werden. Die Konfigurationsdateien können mit dem Befehlszeilen-Tool in schnellen Entwicklungsumgebungen (Rapid Development Environments, RDEs) bereitgestellt werden.

In den folgenden Abschnitten dieses Dokuments erhalten Sie einen Überblick über wichtige Informationen dazu, wie Konfigurationspipelines verwendet werden können und wie Konfigurationen für sie strukturiert sein sollten. Es werden allgemeine Konzepte beschrieben, die für alle oder eine Teilmenge der von Konfigurations-Pipelines unterstützten Funktionen freigegeben werden.

Unterstützte Konfigurationen configurations

Die folgende Tabelle enthält eine umfassende Liste solcher Konfigurationen mit Links zur entsprechenden Dokumentation, die die jeweilige Konfigurationssyntax und andere Informationen beschreibt.

Erstellen und Verwalten von Konfigurations-Pipelines creating-and-managing

Informationen zum Erstellen und Konfigurieren von Pipelines finden Sie im Dokument CI/CD-Pipelines.

Wählen Sie beim Erstellen einer Konfigurations-Pipeline in Cloud Manager beim Konfigurieren der Pipeline eine Zielgerichtete Bereitstellung anstelle von Vollständiger Stack-Code aus.

Wie bereits erwähnt, wird die Konfiguration für RDEs mit dem Befehlszeilen-Tool und nicht mit einer Pipeline bereitgestellt.

Allgemeine Syntax common-syntax

Jede Konfigurationsdatei beginnt mit Eigenschaften, die dem folgenden Beispielausschnitt ähneln:

  kind: "LogForwarding"
  version: "1"
  metadata:
    envTypes: ["dev"]

Sie können das Dienstprogramm yq verwenden, um die YAML-Formatierung Ihrer Konfigurationsdatei lokal zu überprüfen (z. B. yq cdn.yaml).

Ordnerstruktur folder-structure

Ein Ordner mit dem Namen /config oder einem ähnlichen Namen sollte sich ganz oben in der Struktur befinden, wobei sich eine weitere YAML-Datei in einer Struktur darunter befindet.

Zum Beispiel:

/config
  cdn.yaml

oder

/config
  /dev
    cdn.yaml

Die Ordner- und Dateinamen unter /config sind beliebig. Die YAML-Datei muss jedoch einen gültigen kind-Eigenschaftswert enthalten.

In der Regel werden Konfigurationen für alle Umgebungen bereitgestellt. Wenn alle Eigenschaftswerte für jede Umgebung identisch sind, reicht eine einzelne YAML-Datei aus. Es ist jedoch üblich, dass sich Eigenschaftswerte zwischen Umgebungen unterscheiden, z. B. beim Testen einer niedrigeren Umgebung.

Die folgenden Abschnitte zeigen einige Strategien zur Strukturierung Ihrer Dateien.

Eine einzelne Konfigurationsdatei für alle Umgebungen single-file

Die Dateistruktur ähnelt dem Folgenden:

/config
  cdn.yaml
  logForwarding.yaml

Verwenden Sie diese Struktur, wenn dieselbe Konfiguration für alle Umgebungen und für alle Konfigurationstypen (CDN, Protokollweiterleitung usw.) ausreicht. In diesem Szenario würde die envTypes-Array-Eigenschaft alle Umgebungstypen enthalten.

   kind: "cdn"
   version: "1"
   metadata:
     envTypes: ["dev", "stage", "prod"]

Mithilfe von Umgebungsvariablen mit geheimen Typen können die geheimen Eigenschaften pro Umgebung variieren, wie durch die ${{SPLUNK_TOKEN}}-Referenz veranschaulicht wird

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  splunk:
    default:
      enabled: true
      host: "splunk-host.example.com"
      token: "${{SPLUNK_TOKEN}}"
      index: "AEMaaCS"

Eine separate Datei pro Umgebungstyp file-per-env

Die Dateistruktur ähnelt dem Folgenden:

/config
  cdn-dev.yaml
  cdn-stage.yaml
  cdn-prod.yaml
  logForwarding-dev.yaml
  logForwarding-stage.yaml
  logForwarding-prod.yaml

Verwenden Sie diese Struktur, wenn es Unterschiede bei Eigenschaftswerten geben kann. Es wäre zu erwarten, dass der envTypes-Array-Wert in den Dateien dem Suffix entspricht, beispielsweise
cdn-dev.yaml und logForwarding-dev.yaml mit dem Wert ["dev"], cdn-stage.yaml und logForwarding-stage.yaml mit dem Wert ["stage"] usw.

Ein Ordner pro Umgebung folder-per-env

Bei dieser Strategie gibt es einen separaten config-Ordner pro Umgebung, wobei für jede Umgebung eine separate Pipeline in Cloud Manager deklariert wird.

Dieser Ansatz ist besonders dann nützlich, wenn Sie über mehrere Entwicklungsumgebungen mit jeweils eindeutigen Eigenschaftswerten verfügen.

Die Dateistruktur ähnelt dem Folgenden:

/config/dev1
  cdn.yaml
  logForwarding.yaml
/config/dev2
  cdn.yaml
  logForwarding.yaml
/config/prod
  cdn.yaml
  logForwarding.yaml

Eine Variante dieses Ansatzes besteht darin, für jede Umgebung eine separate Verzweigung zu führen.

Geheime Umgebungsvariablen secret-env-vars

Damit vertrauliche Informationen nicht in der Verwaltung der Quelle gespeichert werden müssen, unterstützen Konfigurationsdateien Cloud Manager-Umgebungsvariablen vom Typ secret. Bei einigen Konfigurationen, einschließlich der Protokollweiterleitung, sind geheime Umgebungsvariablen für bestimmte Eigenschaften obligatorisch.

Der folgende Ausschnitt zeigt, wie die geheime Umgebungsvariable ${{SPLUNK_TOKEN}} in der Konfiguration verwendet wird.

kind: "LogForwarding"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  splunk:
    default:
      enabled: true
      host: "splunk-host.example.com"
      token: "${{SPLUNK_TOKEN}}"
      index: "AEMaaCS"

Bitte lesen Sie das Dokument Cloud Manager-Umgebungsvariablen, um zu erfahren, wie Sie Umgebungsvariablen verwenden können.