設定パイプラインの使用 config-pipelines

設定パイプラインを使用して、ログ転送の設定、パージ関連のメンテナンスタスク、様々な CDN 設定など、様々な設定の AEM as a Cloud Service をデプロイする方法について説明します。

概要 overview

Cloud Manager 設定パイプラインでは、設定ファイル（YAML 形式で作成）をターゲット環境にデプロイします。 この方法では、ログ転送、パージ関連のメンテナンスタスク、いくつかの CDN 機能など、AEM as a Cloud Service の多くの機能を設定できます。

Publish Delivery プロジェクトの場合、設定パイプラインをCloud Managerを介してデプロイし、デベロッパー、ステージ、実稼動環境のタイプを指定できます。 設定ファイルは、コマンドラインツールを使用して高速開発環境（RDE）にデプロイできます。 パブリッシュ配信環境に接続されたドメインのトラフィックを設定する必要がある場合は、ターゲットのデプロイメント パブリッシュ配信パイプライン （実稼動または実稼動以外）を使用します。

構成パイプラインは、Edge Delivery プロジェクト用にCloud Managerを通じてデプロイすることもできます。 ドメインが​ Edge Delivery サイト ​にアタッチされている場合は、Edge Delivery パイプライン​を使用します。

このドキュメントの以降の節では、設定パイプラインの使用方法と、それらの設定を構造化する方法に関する重要な情報の概要を示します。 設定パイプラインでサポートされる機能のすべてまたはサブセットで共有される一般的な概念について説明します。

サポートされる設定 configurations

次の表に、このような設定の包括的なリストと、その個別の設定構文やその他の情報を説明する専用ドキュメントへのリンクを示します。

CDNに関連する設定については、表のリンクされた記事に加えて、CDN Configuration Snippets for Common Scenariosの記事も参照してください。

設定パイプラインの作成と管理 creating-and-managing

パブリッシュ配信​設定パイプラインを作成および設定する方法について詳しくは、CI/CD パイプライン ​を参照してください。 Cloud Managerで設定パイプラインを作成する場合は、パイプラインの設定時に​ フルスタックコード ​ではなく​ ターゲットデプロイメント ​を選択してください。 前述のように、RDE の設定は、パイプラインではなくコマンドラインツールを使用してデプロイされます。

Edge Delivery​設定パイプラインを作成および設定する方法について詳しくは、Edge Delivery パイプラインを追加の記事を参照してください。

共通の構文 common-syntax

各設定ファイルは、次の例のスニペットに類似したプロパティで始まります。

   kind: "CDN"
   version: "1"
   metadata: ...
   data: ...

yq ユーティリティを使用すると、設定ファイル（例：yq cdn.yaml）の YAML 形式をローカルで検証できます。

公開配信 yamls-for-aem

パブリッシュ配信​設定がターゲット環境にデプロイされます。 複数の環境をターゲットにする場合、異なる方法で異なるファイルを整理できます。 例えば、配列にdevのみが含まれている場合、設定がそこにデプロイされていても、ステージング環境または実稼動環境には設定が読み込まれません。

   kind: "CDN"
   version: "1"
   metadata:
    envType: ["dev"]

フォルダー構造 folder-structure

/config または類似の名前のフォルダーをツリーの最上部に存在させ、その下のツリー内にもう 1 つの YAML ファイルを存在させる必要があります。

次に例を示します。

/config
  cdn.yaml

または

/config
  /dev
    cdn.yaml

/config の下のフォルダー名とファイル名は任意です。 ただし、YAML ファイルには有効な kind プロパティ値を含める必要があります。

通常、設定はすべての環境にデプロイされます。 すべてのプロパティ値が各環境で同じ場合は、1つのYAML ファイルで十分です。 ただし、下位環境のテスト時など、環境間でプロパティ値が異なることは一般的です。

次の節では、ファイルを構造化するいくつかの戦略について説明します。

すべての環境に対する単一の設定ファイル single-file

ファイル構造は次のようになります。

/config
  cdn.yaml
  logForwarding.yaml

この構造は、すべての環境とすべての設定のタイプ（CDN、ログ転送など）に対して同じ設定で十分な場合に使用します。 このシナリオでは、envTypes 配列プロパティにすべての環境タイプが含まれます。

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

シークレット タイプの環境（またはパイプライン）変数を使用すると、次の${{SPLUNK_TOKEN}}参照に示すように、​ シークレット プロパティ ​が環境ごとに異なる可能性があります。

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

環境タイプごとに個別のファイル file-per-env

ファイル構造は次のようになります。

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

プロパティ値に違いがある可能性がある場合は、この構造を使用します。 ファイルでは、envTypes配列値が接尾辞に対応することが期待されます。 例えば、cdn-dev.yamlとlogForwarding-dev.yamlの値が["dev"]、cdn-stage.yamlとlogForwarding-stage.yamlの値が["stage"]であるなど。

環境ごとのフォルダー folder-per-env

この戦略では、環境ごとに個別の config フォルダーがあり、それぞれに対して Cloud Manager で個別のパイプラインが宣言されます。

このアプローチは、それぞれに一意のプロパティ値を持つ複数の開発環境がある場合に特に便利です。

ファイル構造は次のようになります。

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

このアプローチのバリエーションとして、環境ごとに個別のブランチを維持する方法があります。

Edge Delivery Services yamls-for-eds

Edge Delivery設定パイプラインには、開発環境、ステージング環境および実稼動環境が分離されていません。 パブリッシュ配信環境では、変更は開発、ステージ、実稼動階層を通じて進行します。 対照的に、Edge Delivery設定パイプラインでは、Edge Delivery サイト用にCloud Managerに登録されているすべてのドメインマッピングに直接設定が適用されます。

したがって、次のような単純なファイル構造をデプロイします。

/config
  cdn.yaml
  logForwarding.yaml

Edge Delivery サイトごとにルールを変更する必要がある場合は、構文​ when ​を使用してルールを区別します。 例えば、ドメインが以下のスニペットのdev.example.comと一致し、ドメイン www.example.comと区別できることに注意してください。

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

envTypes メタデータフィールドを含める場合は、値​ prod ​のみを使用します（envTypes メタデータフィールドを省略しても問題ありません）。 tier reqPropertyでは、値​ publish ​のみを使用する必要があります。

設定シークレット secret-in-configuration

機密情報をソース管理に保存する必要がないように、設定ファイルでは、Config パイプライン変数または環境変数からシークレットを参照できます。 ログ転送を含む一部の設定では、特定のプロパティにシークレット変数が必須です。 CDN設定でのシークレットの使用について詳しくは、CDN認証情報と認証の設定を参照してください。

次のスニペットは、秘密変数${{SPLUNK_TOKEN}}が設定でどのように使用されるかを示す例です。

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

シークレットパイプライン変数 secret-pipeline-vars

好みの方法​では、Cloud Manager パイプライン変数タイプ secret​を使用するので、機密情報をソースコントロールに保存する必要はありません。 手順が適用されました​選択ボックスでは、デプロイ オプションを使用する必要があります。

パイプライン変数の使用方法について詳しくは、Cloud Managerのパイプライン変数を参照してください。

シークレット環境変数 secret-env-vars

シークレット環境変数は、環境ごとに異なるシークレット値を設定する場合に使用します。

環境変数の使用方法について詳しくは、Cloud Manager環境変数を参照してください。