設定パイプラインの使用 config-pipelines
設定パイプラインを使用して、ログ転送の設定、パージ関連のメンテナンスタスク、様々な CDN 設定など、様々な設定の AEM as a Cloud Service をデプロイする方法について説明します。
概要 overview
Cloud Manager 設定パイプラインでは、設定ファイル(YAML 形式で作成)をターゲット環境にデプロイします。この方法では、ログ転送、パージ関連のメンテナンスタスク、いくつかの CDN 機能など、AEM as a Cloud Service の多くの機能を設定できます。
設定パイプラインは、Cloud Manager を通じて、実稼動(サンドボックス以外の)プログラムで、開発環境、ステージ環境および実稼動環境のタイプにデプロイできます。設定ファイルは、コマンドラインツールを使用して迅速な開発環境(RDE)にデプロイできます。
このドキュメントの以降の節では、設定パイプラインの使用方法と、それらの設定を構造化する方法に関する重要な情報の概要を示します。設定パイプラインでサポートされる機能のすべてまたはサブセットで共有される一般的な概念について説明します。
- サポートされる設定 - 設定パイプラインでデプロイできる設定のリスト
- 設定パイプラインの作成と管理 - 設定パイプラインの作成方法。
- 共通の構文 - 設定間で共有される構文
- フォルダー構造 - 設定に必要な構造の設定パイプラインについて説明します。
- 秘密鍵の環境変数 - 環境変数を使用して、設定の秘密鍵を開示しない例
サポートされる設定 configurations
次の表に、このような設定の包括的なリストと、その個別の設定構文やその他の情報を説明する専用ドキュメントへのリンクを示します。
kind
値LogForwarding
設定パイプラインの作成と管理 creating-and-managing
パイプラインの作成および設定方法について詳しくは、CI/CD パイプラインドキュメントを参照してください。
Cloud Manager で設定パイプラインを作成する場合は、パイプラインを設定する際に、フルスタックコード ではなく ターゲットデプロイメント を選択します。
前述のように、RDE の設定は、パイプラインではなくコマンドラインツールを使用してデプロイされます。
共通の構文 common-syntax
各設定ファイルは、次の例のスニペットに類似したプロパティで始まります。
kind: "LogForwarding"
version: "1"
metadata:
envTypes: ["dev"]
kind
version
envTypes
metadata
ノードの子プロパティです。可能な値は、dev、stage、prod または任意の組み合わせで、設定を処理する環境タイプを決定します。例えば、配列に 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
配列の値がサフィックスに対応することが想定されます。例: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
このアプローチのバリエーションとして、環境ごとに個別のブランチを維持する方法があります。
秘密鍵の環境変数 secret-env-vars
ソースコントロールに機密情報を保存する必要がないように、設定ファイルでは 秘密鍵 タイプの 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 環境変数ドキュメントを参照してください。