Konfigurieren von 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.

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

Konfigurations-Pipelines können auch über Cloud Manager für Edge Delivery-Projekte werden.

In den folgenden Abschnitten dieses Dokuments erhalten Sie einen Überblick über wichtige Informationen dazu, wie Konfigurations-Pipelines verwendet werden können und wie Konfigurationen für diese 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, wo die jeweilige Konfigurationssyntax und andere Informationen beschrieben werden.

Konfigurieren von Pipelines creating-and-managing

Informationen zum Erstellen und Konfigurieren von Veröffentlichungs-Bereitstellung Konfigurations-Pipelines finden Sie unter CI/CD-Pipelines. Achten Sie beim Erstellen einer Konfigurations-Pipeline in Cloud Manager darauf, beim Konfigurieren Pipeline „Zielgerichtete Bereitstellung und nicht Full-Stack-" auszuwählen. Wie bereits erwähnt, wird die Konfiguration für RDEs mit dem Befehlszeilen-Tool und nicht mit einer Pipeline bereitgestellt.

Informationen zum Erstellen und Konfigurieren von Edge Delivery-Konfigurations-Pipelines finden Sie im Artikel Hinzufügen einer Edge Delivery-Pipeline .

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 einzige Konfigurationsdatei für alle Umgebungen single-file

Die Dateistruktur sieht ähnlich der folgenden 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"]

Bei Verwendung von Umgebungsvariablen vom Typ „Geheime Daten“ (oder Pipeline​ können die "" je nach Umgebung variieren, wie in der folgenden ${{SPLUNK_TOKEN}}-Referenz veranschaulicht.

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 sieht ähnlich der folgenden 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 man erwarten, dass der envTypes Array-Wert mit dem Suffix übereinstimmt. Beispiel: 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 sieht ähnlich der folgenden 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 eine separate Verzweigung zu führen.

Edge Delivery Services yamls-for-eds

Edge Delivery-Konfigurations-Pipelines verfügen über keine separaten Entwicklungs-, Staging- und Produktionsumgebungen. In Veröffentlichungs-Bereitstellungsumgebungen schreiten Änderungen durch die Entwicklungs-, Staging- und Produktebenen voran. Eine Edge Delivery-Konfigurations-Pipeline wendet die Konfiguration dagegen direkt auf alle Domain-Zuordnungen an, die in Cloud Manager für eine Edge Delivery-Site registriert sind.

Stellen Sie daher eine einfache Dateistruktur wie die folgende bereit:

/config
  cdn.yaml
  logForwarding.yaml

Wenn eine Regel pro Edge Delivery-Site unterschiedlich sein muss, verwenden Sie die Syntax wenn, um die Regeln voneinander zu unterscheiden. Beachten Sie beispielsweise, dass die Domain im folgenden Ausschnitt mit dev.example.com übereinstimmt, was von der Domain www.example.com unterschieden werden kann.

kind: "CDN"
version: "1"
data:
  trafficFilters:
    rules:
    # Block simple path
    - name: block-path
      when:
        allOf:
          - reqProperty: domain
            equals: "dev.example.com"
          - reqProperty: path
            equals: '/block/me'
      action: block

Wenn Sie das Metadatenfeld envTypes einschließen, sollte nur der Wert prod verwendet werden (das Auslassen des Metadatenfelds envTypes ist ebenfalls in Ordnung). Für die tier reqProperty sollte nur der Wert publish verwendet werden.

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.

Beachten Sie, dass geheime Umgebungsvariablen für Veröffentlichungs-Bereitstellungsprojekte verwendet werden. Weitere Informationen finden Sie im Abschnitt Geheime Pipeline-Variablen für Edge Delivery Services-Projekte.

Das folgende Snippet ist ein Beispiel dafür, 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 unter Cloud Manager-Umgebungsvariablen.

Geheime Pipeline-Variablen secret-pipeline-vars

Verwenden Sie für Edge Delivery Services-Projekte Cloud Manager-Pipeline-Variablen vom Typ secret sodass vertrauliche Informationen nicht in der Quell-Code-Verwaltung gespeichert werden müssen. Das Auswahlfeld Schritt angewendet sollte die Option Bereitstellen verwenden.

Die Syntax ist identisch mit dem im vorherigen Abschnitt gezeigten Snippet.

Weitere Informationen zur Verwendung von Pipeline-Variablen finden Sie unter Pipeline-Variablen in Cloud Manager.