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

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

概要 overview

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

Config パイプラインは、Cloud Managerを介して、実稼動（サンドボックス以外）プログラムの開発環境、ステージング環境および実稼動環境タイプにデプロイできます。 RDE はサポートされていません。

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

サポートされる設定 configurations

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

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

パイプラインの作成および設定方法について詳しくは、CI/CD パイプラインドキュメントを参照してください。

Cloud Managerで Config パイプラインを作成する場合は、パイプラインの設定時に フルスタックコード ではなく ターゲットデプロイメント を選択してください。

共通の構文 common-syntax

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

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

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

フォルダー構造 folder-structure

/config または同様の名前のフォルダーがツリーの上部に表示され、ツリー内のどこかにもう 1 つの YAML ファイルが存在する必要があります。

次に例を示します。

/config
  cdn.yaml

または

/config
  /dev
    cdn.yaml

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

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

以下の節では、ファイルを構造化するための戦略をいくつか説明します。

すべての環境に対して 1 つの設定ファイル 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 の配列値がサフィックスに対応していることを想定します。例えば、次のようになります
値が ["dev"] の cdn-dev.yaml および logForwarding-dev.yaml、値が ["stage"] の cdn-stage.yaml および logForwarding-stage.yaml など。

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

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

この方法は、開発環境が複数あり、それぞれに一意のプロパティ値がある場合に特に便利です。

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

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

このアプローチのバリエーションは、環境ごとに個別のブランチを維持することです。

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

ソース管理に機密情報を保存する必要がないように、設定ファイルでは secret タイプのCloud Manager環境変数をサポートしています。 ログ転送などの一部の設定では、特定のプロパティに対してシークレットの環境変数が必須です。

以下のスニペットは、シークレット環境変数 ${{SPLUNK_TOKEN}} が設定でどのように使用されるかを示しています。

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

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