Verwenden von Config Pipelines config-pipelines

Erfahren Sie, wie Sie Konfigurationspipelines verwenden können, um verschiedene Konfigurationen wie Einstellungen für die Protokollweiterleitung, Bereinigungsaufgaben und verschiedene CDN-Konfigurationen bereitzustellen.

Überblick overview

Eine Cloud Manager-Konfigurationspipeline stellt Konfigurationsdateien (die im YAML-Format erstellt wurden) in einer Zielumgebung bereit. Eine Reihe von Funktionen in AEM as a Cloud Service können auf diese Weise konfiguriert werden, darunter die Protokollweiterleitung, Bereinigungsaufgaben sowie verschiedene CDN-Funktionen.

Config Pipelines können über Cloud Manager für Entwicklungs-, Staging- und Produktionsumgebungstypen in Produktionsprogrammen (ohne Sandbox) bereitgestellt werden. RDE werden nicht unterstützt.

In den folgenden Abschnitten dieses Dokuments erhalten Sie einen Überblick über wichtige Informationen dazu, wie Config Pipelines verwendet werden können und wie Konfigurationen für sie strukturiert sein sollten. Es werden allgemeine Konzepte beschrieben, die für alle oder eine Untergruppe 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 Config Pipelines creating-and-managing

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

Stellen Sie beim Erstellen einer Config Pipeline in Cloud Manager sicher, dass Sie beim Konfigurieren der Pipeline eine "Targeted Deployment" anstelle von "Full Stack Code"auswählen.

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 ein ähnliches sollte sich oben im Baum befinden, wobei sich eine weitere YAML-Datei in einem Baum darunter befindet.

Zum Beispiel:

/config
  cdn.yaml

oder

/config
  /dev
    cdn.yaml

Die Ordnernamen 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 sieht wie folgt aus:

/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"

Separate Datei pro Umgebungstyp file-per-env

Die Dateistruktur sieht wie folgt aus:

/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. In den Dateien würde erwartet, dass der envTypes -Array-Wert 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.

Ordner pro Umgebung folder-per-env

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

Dieser Ansatz ist besonders nützlich, wenn Sie über mehrere Entwicklungsumgebungen verfügen, in denen jede über eindeutige Eigenschaftswerte verfügt.

Die Dateistruktur sieht wie folgt aus:

/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 einen separaten Zweig zu verwalten.

Geheime Umgebungsvariablen secret-env-vars

Damit vertrauliche Informationen nicht in der Quell-Code-Verwaltung 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"

Weitere Informationen zur Verwendung von Umgebungsvariablen finden Sie im Dokument Cloud Manager-Umgebungsvariablen .