AEM as a Cloud Service へのデプロイ deploying-to-aem-as-a-cloud-service

最終更新日： 2026年9月22日

適用対象：
Experience Manager as a Cloud Service

トピック：
Deploying

作成対象：

Admin

はじめに introduction

AEM as a Cloud Service におけるコード開発の基本は、AEM オンプレミス環境や Managed Services ソリューションの場合と同様です。開発者はコードを作成しローカルでテストします。コードはその後、AEM as a Cloud Service のリモート環境にプッシュされます。 Cloud Manager（Managed Services のオプションのコンテンツ配信ツール）が必要です。この配信ツールは、AEM as a Cloud Service 開発、ステージ、および本番環境にコードをデプロイするための唯一のメカニズムになりました。前述の環境をデプロイする前に、機能の検証とデバッグを迅速に行うために、コードをローカル環境から高速開発環境に同期できます。

AEM バージョンのアップデートは、常に、カスタムコードのプッシュとは別のデプロイメントイベントになります。また、カスタムコードリリースは、デプロイ先が実稼動環境にあるAEM バージョンと比較してテストする必要があります。その後に行われるAEMのバージョン更新（頻繁に行われ、自動的に適用されます）は、既にデプロイされているカスタマーコードとの下位互換性を保つことを目的としています。

このドキュメントの残りの部分では、開発者がAEM as a Cloud Serviceのバージョン更新と顧客の更新の両方を使用して作業する方法を適応させる方法について説明します。

顧客リリース customer-releases

適切な AEM バージョンに照らしたコーディング coding-against-the-right-aem-version

以前のAEM ソリューションでは、AEMのバージョンが頻繁に変更され、お客様はAPI Jarを参照して実稼動インスタンスを最新のクイックスタートに更新しました。しかし、AEM as a Cloud Service 上のアプリケーションは、より頻繁に最新バージョンの AEM に自動更新されるので、内部リリースのカスタムコードは、最新の AEM バージョンに対応するように作成する必要があります。

クラウド以外の既存のAEM バージョンと同様に、特定のクイックスタートに基づくローカルのオフライン開発がサポートされており、通常はデバッグの主要なツールであると予想されます。

NOTE

ローカルマシンでのアプリケーションの動作とAdobe クラウドインフラストラクチャの動作には、微妙な運用上の違いがあります。このようなアーキテクチャの違いは、ローカル開発時に考慮する必要があり、クラウドインフラストラクチャにデプロイする際の動作も異なります。このような違いがあるため、実稼動環境に新しいカスタムコードを導入する前に、開発環境とステージ環境で徹底的なテストを実行することが重要です。

内部リリースのカスタムコードを開発するには、AEM as a Cloud Service SDK の関連バージョンをダウンロードし、インストールする必要があります。 AEM as a Cloud Service Dispatcher ツールを使用する方法について詳しくは、クラウド内の Dispatcher を参照してください。

次のビデオでは、AEM as a Cloud Service にコードをデプロイする方法の概要を説明します。

https://video.tv.adobe.com/v/34668?captions=jpn&quality=9&learn=on

Cloud ManagerとPackage Managerによるコンテンツパッケージのデプロイ deploying-content-packages-via-cloud-manager-and-package-manager

Cloud Managerを介したデプロイメント deployments-via-cloud-manager

お客様は、Cloud Manager を使用してカスタムコードをクラウド環境にデプロイします。 Cloud Managerは、ローカルでアセンブリされたコンテンツパッケージを、Sling機能モデルに準拠したアーティファクトに変換します。このモデルは、クラウド環境で実行中のAEM as a Cloud Service上のアプリケーションについて説明します。その結果、クラウド環境のパッケージマネージャーでパッケージを調べると、名前に「cp2fm」が含まれており、変換後のパッケージではすべてのメタデータが削除されています。これらを操作することはできません。つまり、ダウンロードしたり、複製したり、開いたりすることはできません。コンバーターに関するドキュメントについて詳しくは、GitHub の sling-org-apache-sling-feature-cpconverter を参照してください。

AEM as a Cloud Serviceのコンテンツパッケージでは、不変コンテンツと可変コンテンツを分離する必要があります。 Cloud Managerは可変コンテンツのみをインストールし、次のようなメッセージを出力します。

Generated content-package <PACKAGE_ID> located in file <PATH> is of MIXED type

このセクションの残りの部分では、不変パッケージと可変パッケージの構成と関係について説明します。

不変コンテンツパッケージ immutabe-content-packages

不変リポジトリに保存されるコンテンツとコードはすべて、Git にチェックインし、Cloud Manager を通じてデプロイする必要があります。つまり、現在の AEM ソリューションとは異なり、コードは実行中の AEM インスタンスには直接デプロイされません。このワークフローにより、任意のクラウド環境で特定のリリースに対して同一のコードが実行されるようになり、意図しないコード変更が本番環境で発生するリスクをなくすことができます。例えば、OSGi 設定は、AEM web コンソールの設定マネージャーを使用して実行時に管理されるのではなく、ソース管理にコミットする必要があります。

スイッチは、デプロイメントパターンによるアプリケーションの変更を有効にするため、サービスユーザー、ACL、ノードタイプ、インデックス定義の変更を除き、可変リポジトリの変更に依存することはできません。

既存のコードベースをお持ちのお客様は、AEM ドキュメントに記載されているリポジトリ再構築の手順に従って、以前 /etc の配下にあったコンテンツが適切な場所に確実に移動されるようにすることが重要です。

これらのコードパッケージには、いくつかの追加の制限が適用されます。例えば、インストールフックはサポートされません。

OSGI設定 osgi-configuration

前述のように、OSGi 設定は web コンソールを通じて管理するのではなく、ソース管理にコミットする必要があります。そのための手法は次のとおりです。

AEM web コンソールの設定マネージャーを使用して開発者のローカル AEM 環境に必要な変更を加えた後、その結果をローカルファイルシステム上の AEM プロジェクトに書き出す。
ローカルファイルシステムのAEM プロジェクトでOSGI設定を手動で作成し、AEM コンソールの設定マネージャーを参照してプロパティ名を指定します。

OSGI の設定について詳しくは、AEM as a Cloud Service の OSGi の設定を参照してください。

可変コンテンツ mutable-content

場合によっては、ソース管理でコンテンツの変更を準備して、環境が更新されるたびにCloud Managerがデプロイするように設定すると便利です。例えば、特定のルートフォルダー構造にシードを設定することは合理的です。アプリケーションのデプロイメントが更新するポリシーコンポーネントを有効にするには、編集可能なテンプレートで変更を調整します。

Cloud Managerでは、可変コンテンツパッケージとrepoinit ステートメントの2つの戦略を使用して、コンテンツを可変リポジトリにデプロイします。

可変コンテンツパッケージ mutable-content-packages

フォルダーのパス階層、サービスユーザー、アクセス制御（ACL）などのコンテンツは、通常、Maven アーキタイプベースの AEM プロジェクトにコミットされます。使用される手法には、AEM からの書き出し、または XML 形式での直接書き込みがあります。ビルドおよびデプロイメントプロセス中に、Cloud Manager は、生成された可変コンテンツパッケージをパッケージ化します。可変コンテンツは、パイプラインのデプロイフェーズで次の 3 回の異なるタイミングでインストールされます。

新しいバージョンのアプリケーションの起動前：

インデックス定義（追加、変更、削除）

新しいバージョンのアプリケーションの起動中（切り替えの前）：

サービスユーザー（追加）
サービスユーザー ACL（追加）
ノードタイプ（追加）

新しいバージョンのアプリケーションへの切り替え後：

Jackrabbit Vault を使用して定義可能なその他のすべてのコンテンツ。例：
- フォルダー（追加、変更、削除）
- 編集可能なテンプレート（追加、変更、削除）
- コンテキスト対応の設定（/conf 配下のあらゆるもの）（追加、変更、削除）
- スクリプト（パッケージは、インストールフックをトリガーできます。 Jackrabbit filevault ドキュメントを参照してください。

/apps 配下の install.author フォルダーまたは install.publish フォルダーにパッケージを埋め込むことで、可変コンテンツのインストールをオーサーまたはパブリッシュのみに制限することができます。この分離を反映する再構築は AEM 6.5 で行われました。推奨されるプロジェクト再構築について詳しくは、AEM 6.5 のドキュメントを参照してください。

NOTE

コンテンツパッケージは、すべての環境タイプ（開発、ステージ、実稼動）にデプロイされます。デプロイメントを特定の環境に限定することはできません。この制限があるのは、自動実行のテスト実行オプションが確実に適用されるようにするためです。環境に固有のコンテンツは、パッケージマネージャーを使用して手動でインストールする必要があります。

また、可変コンテンツパッケージの変更を適用した後にロールバックするメカニズムはありません。問題を検出した場合は、次回のコードリリースで修正するか、最後の手段としてシステム全体をデプロイメント前の時点に復元するかを選択できます。

含まれているサードパーティ製パッケージは、AEM as a Cloud Serviceと互換性があるかどうかを検証する必要があります。それ以外の場合、そのパッケージを含めるとデプロイメントエラーが発生します。

前述のように、既存のコードベースを持つお客様は、AEM 6.5 ドキュメントに記載されている6.5 リポジトリの変更で必要とされるリポジトリの再構築に従います。

repoinit repoinit

次の場合は、OSGI ファクトリ設定で明示的なコンテンツ作成repoinit ステートメントを手動でコーディングする方法を採用することをお勧めします。

サービスユーザーの作成／削除／無効化
グループの作成／削除
ユーザーの作成／削除

ACL の追加

note
NOTE
ACL の定義では、ノード構造が既に存在する必要があります。したがって、前のcreate path ステートメントは必要です。

パスの追加（例えば、ルートフォルダー構造用）
CND の追加（ノードタイプ定義）

次の利点があるので、サポートされているこれらのコンテンツ変更のユースケースには、repoinit の使用をお勧めします。

Repoinit では、起動時にリソースを作成して、それらのリソースの存在を前提としたロジックが可能になるようにします。可変コンテンツパッケージアプローチでは、起動後にリソースが作成されるため、リソースに依存するアプリケーションコードが失敗します。
実行されるアクションを明示的に制御するので、Repoinit は比較的安全な命令セットです。また、ユーザー、サービスユーザー、グループの削除が可能なセキュリティ関連のいくつかの場合を除き、追加的な操作のみサポートされています。これに対して、可変コンテンツパッケージのアプローチでは、何かの削除は明示的な操作になります。つまり、フィルターを定義すると、フィルターの適用対象となるすべてのものが削除されます。しかし、どのようなコンテンツでも、新しいコンテンツの存在でアプリケーションの動作が変わる可能性があるシナリオが考えられるので、やはり注意が必要です。
Repoinit は高速かつアトミックな操作を実行します。これに対して、可変コンテンツパッケージでは、フィルターの適用対象となる構造によってパフォーマンスが大きく左右される場合があります。 1つのノードを更新しても、大きなツリーのスナップショットが作成されます。
repoinit ステートメントは OSGi 設定が登録されると実行されるので、ローカル開発環境で実行時に repoinit ステートメントを検証できます。
Repoinit ステートメントはアトミックかつ明示的で、状態が既に一致している場合はスキップされます。

Cloud Manager がアプリケーションをデプロイすると、コンテンツパッケージのインストールとは無関係に、これらのステートメントが実行されます。

repoinit ステートメントを作成するには：

ファクトリ PID の OSGi 設定 org.apache.sling.jcr.repoinit.RepositoryInitializer をプロジェクトの設定フォルダーに追加します。設定には、org.apache.sling.jcr.repoint.RepositoryInitializer～initstructure など、わかりやすい名前を付けます。
設定のスクリプトプロパティに repoinit ステートメントを追加します。構文とオプションについては、 Sling のドキュメントを参照してください。親フォルダーを子フォルダーの前に明示的に作成します。例えば、/content を明示的に作成してから /content/myfolder を作成し、その後に /content/myfolder/mysubfolder を作成します。 ACL を下位レベルの構造に設定する場合は、ACL を上位レベルに設定し、rep:glob 制限を適用することをお勧めします。例：(allow jcr:read on /apps restriction(rep:glob,/msm/wcm/rolloutconfigs))
実行時にローカル開発環境で検証します。

WARNING

/appsまたは/libsの下のノードに定義されたACLの場合、repoinitの実行は空のリポジトリから開始されます。 repoinit の実行後にパッケージがインストールされるので、ステートメントでは、パッケージ内で定義されたものを使用できませんが、親構造などの前提条件を定義する必要があります。

TIP

ACLの場合、深層構造の作成は複雑です。したがって、ACL をより高いレベルで定義し、rep:glob 制限によって動作する場所を制限する方が合理的です。

repoinit について詳しくは、Sling のドキュメントを参照してください

可変コンテンツパッケージのパッケージマネージャー「one offs」 package-manager-oneoffs-for-mutable-content-packages

コンテンツパッケージを「1回限り」インストールとしてインストールする必要があるユースケースがあります。例えば、実稼動環境での問題をデバッグするために、実稼動環境からステージング環境に特定のコンテンツを読み込む場合などです。これらのシナリオでは、AEM as a Cloud Service 環境でパッケージマネージャーを使用できます。

パッケージマネージャーはランタイムの概念です。不変リポジトリにコンテンツまたはコードをインストールすることはできず、これらのコンテンツパッケージは可変コンテンツ（主に/contentまたは/conf）で構成されます。コンテンツパッケージに混在コンテンツ（可変コンテンツと不変コンテンツの両方）が含まれている場合、可変コンテンツのみインストールされます。

IMPORTANT

パッケージのインストールに10分以上かかる場合、パッケージマネージャーユーザーインターフェイスは 未定義 のエラーメッセージを返します。

この時間は、インストールのエラーではなく、すべての要求に対して Cloud Service が持つタイムアウトによるものです。

このようなエラーが表示された場合は、インストールを再試行しないでください。インストールはバックグラウンドで正しく進行しています。インストールを再起動すると、複数の同時読み込みプロセスで競合が発生します。

Cloud Managerがインストールするコンテンツパッケージ（可変および不変）は、AEM パッケージマネージャーユーザーインターフェイスでフリーズしたようになります。これらのパッケージは、再インストール、再ビルド、またはダウンロードすることもできず、サフィックスが "cp2fm" と表示され、Cloud Managerがインストールを実行したことを示します。

サードパーティーパッケージを含む including-third-party

顧客が、アドビの翻訳パートナーなどのソフトウェアベンダーといったサードパーティから提供される事前構築済みパッケージを組み込むことは一般的です。これらのパッケージをリモートリポジトリでホストし、それらを pom.xml で参照することをお勧めします。このメソッドは、パブリックリポジトリと、パスワード保護 Maven リポジトリで説明されているパスワード保護を持つプライベートリポジトリに対しても可能です。

パッケージをリモートリポジトリに格納できない場合、顧客はファイルシステムベースのローカルの Maven リポジトリにパッケージを保存できます。このリポジトリは、プロジェクトの一環として SCM にコミットされます。依存するものは何でも、それを参照します。このリポジトリは、プロジェクトの POM で次の例のように宣言されます。

<repository>
    <id>project.local</id>
    <name>project</name>
    <url>file:${maven.multiModuleProjectDirectory}/repository</url>
</repository>

含まれているサードパーティパッケージは、この記事に記載されているAEM as a Cloud Serviceのコーディングおよびパッケージガイドラインに準拠している必要があります。そうしないと、デプロイメントの失敗につながります。

Maven プラグイン設定 filevault-package-maven-plugin を使用してサードパーティパッケージをプロジェクトの「コンテナ」パッケージ（通常は、「all」）に埋め込む方法を、次の Maven POM.xml スニペットで示します。

...
<plugin>
  <groupId>org.apache.jackrabbit</groupId>
  <artifactId>filevault-package-maven-plugin</artifactId>
  <extensions>true</extensions>
  <configuration>
      ...
      <embeddeds>

          ...

          <!-- Include any other extra packages  -->
          <embedded>
              <groupId>com.vendor.x</groupId>
              <artifactId>vendor.plug-in.all</artifactId>
              <type>zip</type>
              <target>/apps/vendor-packages/container/install</target>
          </embedded>
      <embeddeds>
  </configuration>
</plugin>
...

ローリングデプロイメントの仕組み how-rolling-deployments-work

AEM のアップデートと同様に、お客様向けリリースも、適切な状況下でのオーサークラスターのダウンタイムをなくすために、ローリングデプロイメント戦略を使用してデプロイされます。イベントの一般的なシーケンスを以下で説明します。ここでは、顧客コードの古いバージョンと新しいバージョンの両方を持つノードで同じバージョンの AEM コードが実行されます。

TIP

標準的なローリングデプロイメントの代わりに、カナリアデプロイメントを使用して、ライブトラフィックを運用インフラストラクチャにルーティングする前に、実稼動インフラストラクチャ上で新しいビルドを検証することができます。「Canary デプロイメントを使用してコードを検証する」を参照してください。

古いバージョンを持つノードがアクティブになり、新しいバージョンのリリース候補が構築されて使用可能になります。
新しいまたは更新されたインデックス定義がある場合は、対応するインデックスが処理されます。古いバージョンのノードでは常に古いインデックスを使用し、新しいバージョンのノードでは常に新しいインデックスを使用します。
新しいバージョンのノードは起動しますが、古いバージョンは引き続きトラフィックを提供します。
古いバージョンのノードは実行中であり、処理を続行します。一方、新しいバージョンのノードは、ヘルスチェックを通じて準備状況を確認します。
準備が整った新しいバージョンのノードがトラフィックを受け入れ、古いバージョンのノードを置き換えます。古いバージョンのノードは停止されます。
時間の経過とともに、新しいバージョンを持つノードは、新しいバージョンを持つノードのみが残るまで、ノードを古いバージョンに置き換え、デプロイメントを完了します。
新しいまたは変更された可変コンテンツがデプロイされます。

インデックス indexes

新しいまたは変更されたインデックスがあると、追加のインデックス作成または再作成の手順が行われてから、新しいバージョンでトラフィックを引き受けることができるようになります。 AEM as a Cloud Service でのインデックス管理について詳しくは、コンテンツの検索とインデックス作成を参照してください。 Cloud Manager でビルドページのインデックス作成ステータスを確認し、新しいバージョンでトラフィックを引き受ける準備ができたら通知を受け取ることができます。

NOTE

ローリングデプロイメントに必要な時間は、インデックスのサイズによって異なります。その理由は、新しいバージョンは、新しいインデックスが生成されるまでトラフィックを受け入れることができないためです。

現時点では、AEM as a Cloud Service はインデックス管理ツール（ACS AEM Commons の Ensure Oak Index ツールなど）とは連携して動作しません。

レプリケーション replication

公開メカニズムは、AEM レプリケーション Java API と後方互換性があります。

クラウド対応のAEM クイックスタートを使用してレプリケーションを開発およびテストするには、オーサー/パブリッシュ設定でクラシックレプリケーション機能を使用します。クラウドで AEM オーサーのユーザーインターフェイスエントリポイントが削除された場合、ユーザーは設定のために http://localhost:4502/etc/replication に移動します。

ローリングデプロイメント用の後方互換性のあるコード backwards-compatible-code-for-rolling-deployments

前述のように、AEM as a Cloud Serviceのローリングデプロイメント戦略では、古いバージョンと新しいバージョンの両方が同時に動作することを意味します。そのため、古いAEM バージョンと後方互換性のないコードの変更は、まだ動作していることに注意してください。

また、ロールバック時には、可変コンテンツが削除されないので、新しいリリースで適用された新しい可変コンテンツ構造との互換性が古いリリースにあるかどうかをテストする必要があります。

サービスユーザーとACLの変更 service-users-and-acl-changes

サービスユーザー（コンテンツまたはコードにアクセスするACL）を変更すると、古いAEM バージョンでエラーが発生し、そのコンテンツまたはコードに古いサービスユーザーがアクセスできるようになります。この動作に対処するには、少なくとも 2 つのリリースに分散して変更を行い、最初のリリースをリンクとして機能させてから、後続のリリースでクリーンアップを行うことをお勧めします。

索引の変更 index-changes

インデックスに変更を加えた場合、古いバージョンは終了するまで現在のインデックスを引き続き使用するのに対して、新しいバージョンは自分自身の変更済みのインデックスセットを使用します。開発者は、コンテンツ検索とインデックス作成で説明されているインデックス管理手法に従います。

ロールバックの保守的なコーディング conservative-coding-for-rollbacks

デプロイメント後に失敗が報告または検出された場合は、古いバージョンへのロールバックが必要になる可能性があります。新しい構造（可変コンテンツ）はロールバックされないので、新しいコードが、その新しいバージョンで作成された新しい構造と互換性があることを確認します。古いコードに互換性がない場合は、それ以降のお客様向けリリースで修正を適用する必要があります。

高速開発環境（RDE） rde

迅速な開発環境（またはRDE）を使用すると、開発者は変更を迅速にデプロイしてレビューできます。これにより、ローカル開発環境で動作することが既に証明されている機能のテストに必要な時間を最小限に抑えることができます。

Cloud Manager パイプラインを使用してコードをデプロイする通常の開発環境とは異なり、デベロッパーはコマンドラインツールを使用してローカル開発環境から RDE にコードを同期できます。変更が RDE で正常にテストされたら、Cloud Manager パイプラインを通じて通常のクラウド開発環境にデプロイします。これにより、コードが適切な品質ゲートを経由します。

実行モード runmodes

既存のAEM ソリューションでは、任意の実行モードでインスタンスを実行し、OSGI設定を適用するか、それらの特定のインスタンスにOSGI バンドルをインストールするというオプションがあります。定義されている実行モードには、通常、サービス（author および publish）と環境（rde、dev、stage、prod）があります。

一方、AEM as a Cloud Service は、使用可能な実行モードと、それらへの OSGi バンドルおよび OSGi 設定のマッピング方法について、より保守的です。

OSGi 設定の実行モードでは、環境については RDE、開発、ステージング、本番のいずれかを、サービスについてはオーサーまたはパブリッシュを参照する必要があります。これらの環境をこの特定の順序で使用する必要がある場合は、<service>.<environment_type>の組み合わせがサポートされています（例：author.devまたはpublish.prod）。 OSGi トークンは、実行時に環境タイプを含まなくなったgetRunModes メソッドを使用するのではなく、コード内で直接参照する必要があります。詳しくは、AEM as a Cloud Service の OSGi の設定を参照してください。
OSGi バンドルの実行モードは、サービス（author、publish）のみに制限されます。実行モードごとに、OSGi バンドルを install.author または install.publish の配下のコンテンツパッケージにインストールする必要があります。

AEM as a Cloud Service では、実行モードを使用して特定の環境やサービスのコンテンツをインストールすることはできません。開発環境で、ステージング環境または本番環境にないデータや HTML を使用して開発環境をシードする必要がある場合は、パッケージマネージャーを使用できます。

サポートされている実行モード設定は次のとおりです。

config（デフォルト。すべての AEM サービスに適用）
config.author（すべての AEM オーサーサービスに適用）
config.author.dev（開発環境の AEM オーサーサービスに適用）
config.author.rde（AEM RDE オーサーサービスに適用）
config.author.stage（ステージング環境の AEM オーサーサービスに適用）
config.author.prod（実稼動環境の AEM オーサーサービスに適用）
config.publish（AEM パブリッシュサービスに適用）
config.publish.dev（開発環境の AEM パブリッシュサービスに適用）
config.publish.rde（AEM RDE パブリッシュサービスに適用）
config.publish.stage（ステージング環境の AEM パブリッシュサービスに適用）
config.publish.prod（実稼動環境の AEM パブリッシュサービスに適用）
config.dev（開発環境の AEM サービスに適用）
config.rde（RDE サービスに適用）
config.stage（ステージング環境の AEM サービスに適用）
config.prod（実稼動環境の AEM サービスに適用）

最も一致する実行モードを持つ OSGi 設定が使用されます。

ローカルで開発する場合、実行モードの起動パラメーター -r を使用して、実行モードの OSGI 設定を指定します。

$ java -jar aem-sdk-quickstart-xxxx.x.xxx.xxxx-xxxx.jar -r publish,dev

ソース管理でのメンテナンスタスク設定 maintenance-tasks-configuration-in-source-control

ツール／操作画面はクラウド環境では使用できないので、メンテナンスタスク設定をソース管理下に置く必要があります。このメリットにより、変更が場当たり的に適用されて忘れられてしまうのではなく、意図的に保存されるようになります。詳しくは、AEM as a Cloud Service のメンテナンスタスクを参照してください。

recommendation-more-help

experience-manager-cloud-service-help-main-toc