アップグレードを開始する前に次のメンテナンスタスクに従って、システムを準備し、問題が発生した場合にロールバックできるようにしておくことが重要です。
アップグレードを実行する場合は、コンテンツおよびコードのアップグレードアクティビティの他に、リポジトリの移行を実行する必要があります。この移行により、新しい Segment Tar 形式でリポジトリのコピーが作成されます。その結果、大容量になる可能性があるリポジトリの 2 つ目のバージョンを保持するのに十分なディスク領域が必要になります。
アップグレードを開始する前に、AEM を完全にバックアップする必要があります。リポジトリ、アプリケーションのインストール環境、データストアおよび Mongo インスタンスをバックアップします(該当する場合)。AEM インスタンスのバックアップおよび復元について詳しくは、バックアップと復元を参照してください。
アップグレードプロセスは、リポジトリの /apps
パスおよび /libs
パスの下にある既存のコンテンツおよび設定のメンテナンスやマージに役立ちます。Context Hub 設定など、/etc
パスに加えられた変更は、多くの場合、アップグレード後に再適用する必要があります。アップグレードにより、マージできない変更のバックアップコピーが /var
の下に作成されますが、アップグレードを開始する前にこれらの変更を手動でバックアップすることをお勧めします。
jar ファイルから AEM を起動すると、quickstart.properties
の下に crx-quickstart/conf
ファイルが生成されます。これまで AEM を起動スクリプトのみで起動していた場合、このファイルは存在せず、アップグレードは失敗します。このファイルが存在するかどうかを確認し、存在しない場合は jar ファイルから AEM を起動してください。
WorkflowPurgeTask
タスクおよび com.day.cq.audit.impl.AuditLogMaintenanceTask
タスクには個別の OSGi 設定が必要であり、この設定がない場合は機能しません。アップグレード前タスクの実行中にこれらのタスクが失敗した場合に最も考えられる原因は、設定がないことです。そのため、これらのタスク用の OSGi 設定を追加するか、これらのタスクを実行しない場合はアップグレード前の最適化タスクリストからこれらのタスクを削除する必要があります。ワークフローのパージタスクの設定については、ワークフローインスタンスの管理を参照し、監査ログのメンテナンスタスクの設定については、AEM 6 での監査ログのメンテナンスを参照してください。
CQ 5.6 でのワークフローおよび監査ログのパージと AEM 6.0 での監査ログのパージについては、ワークフローおよび監査ノードのパージを参照してください。
AEM で可能なカスタマイズのレベルにより、通常、アップグレードの実行方法は環境によって異なります。そのため、標準化されたアップグレード手順を作成することは簡単ではありません。
以前のバージョンでは、停止された AEM アップグレードまたは失敗した AEM アップグレードを安全に再開することも困難でした。そのため、完全なアップグレード手順を再度開始する必要があったり、不完全なアップグレードが警告なしでおこなわれたりしました。
これらの問題に対応するために、アドビは複数の拡張機能をアップグレードプロセスに追加して、アップグレードプロセスの回復性を高め、使いやすくしました。以前は手動で実行する必要があったアップグレード前のメンテナンスタスクを最適化および自動化する開発作業がおこなわれています。また、問題を簡単に見つけてプロセスを完全に調べられるように、アップグレード後のレポートが追加されました。
アップグレード前のメンテナンスタスクは、現在、一部または全部を手動で実行する様々なインターフェイスに分割されています。AEM 6.3 で導入されたアップグレード前のメンテナンス最適化では、統一された方法でこれらのタスクをトリガーして、その結果をオンデマンドで調査できます。
アップグレード前の最適化手順に含まれているすべてのタスクは、AEM 6.0 以降のすべてのバージョンと互換性があります。
AEM 6.3 以降では、アップグレード前のメンテナンス最適化タスクは quickstart jar に含まれています。AEM 6 の古いバージョンからアップグレードする場合、この最適化タスクは、パッケージマネージャーからダウンロードできる個別のパッケージを介して利用できます。
パッケージは以下の場所にあります。
PreUpgradeTasksMBean
OSGI コンポーネントは、アップグレード前のメンテナンスタスクのリストで事前設定されており、それらのすべてのタスクを一度に実行できます。以下の手順に従ってタスクを設定できます。
Web コンソールに移動するには、 https://serveraddress:serverport/system/console/configMgr
「preupgradetasks」を検索し、最初に一致したコンポーネントをクリックします。コンポーネントのフルネームは、com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl
です。
次に示すように、実行が必要なメンテナンスタスクのリストを変更します。
タスクリストは、インスタンスの開始に使用する実行モードによって異なります。各メンテナンスタスクの設計対象の実行モードの説明を次に示します。
タスク | 実行モード | メモ |
TarIndexMergeTask |
crx2 | |
DataStoreGarbageCollectionTask |
crx2 | マークアンドスイープを実行します。共有データストアの場合、この手順を削除して 手動で実行するか、実行前にインスタンスを適切に準備します。 |
ConsistencyCheckTask |
crx2 | |
WorkflowPurgeTask |
crx2/crx3 | 実行前に、Adobe Granite のワークフローのパージ設定 OSGi を設定する必要があります。 |
GenerateBundlesListFileTask |
crx2/crx3 | |
RevisionCleanupTask |
crx3 | AEM 6.0 から 6.2 の TarMK インスタンスについては、代わりに手動でオフラインでのリビジョンクリーンアップを実行します。 |
com.day.cq.audit.impl.AuditLogMaintenanceTask |
crx3 | 実行前に、監査ログのパージスケジューラー OSGi 設定を設定する必要があります。 |
DataStoreGarbageCollectionTask
を使用する場合、マークアンドスイープフェーズでデータストアガベージコレクション操作を呼び出します。共有データストアを使用するデプロイメントでは、別のインスタンスによって参照される項目が削除されないように、再設定するかインスタンスを適切に準備します。そのためには、このアップグレード前のタスクをトリガーする前に、すべてのインスタンスに対してマークフェーズを手動で実行する必要がある場合があります。
PreUpgradeTasksMBeanImpl
OSGI コンポーネントは、runAllPreUpgradeHealthChecks
メソッドが呼び出されたときに実行されるアップグレード前のヘルスチェックタグのリストで事前設定されています。
system - Granite のメンテナンスヘルスチェックで使用するタグです。
pre-upgrade - アップグレード前に実行するように設定できるすべてのヘルスチェックに追加できるカスタムタグです。
このリストは編集できます。タグの横のプラス(+)ボタンとマイナス(-)ボタンを使用して、カスタムタグを追加したり、デフォルトのタグを削除したりすることができます。
MBean メソッド
マネージド Bean 機能には、JMX コンソールを使用してアクセスできます。
以下の手順で MBean にアクセスできます。
JMX コンソール(https://serveraddress:serverport/system/console/jmx)に移動
「PreUpgradeTasks」を検索し、結果をクリックします。
「操作」セクションからメソッドを選択し、次のウィンドウで「呼び出し」を選択します。
PreUpgradeTasksMBeanImpl
によって公開されている使用可能なすべてのメソッドのリストを以下に示します。
メソッド名 | タイプ | 説明 |
getAvailablePreUpgradeTasksNames() |
INFO | 使用可能なアップグレード前のメンテナンスタスク名のリストを表示します。 |
getAvailablePreUpgradeHealthChecksTagNames() |
情報 | アップグレード前のヘルスチェックのタグ名のリストを表示します。 |
runAllPreUpgradeTasks() |
アクション | リスト内のすべてのアップグレード前のメンテナンスタスクを実行します。 |
runPreUpgradeTask(preUpgradeTaskName) |
アクション | パラメーターで指定された名前を持つアップグレード前のメンテナンスタスクを実行します。 |
isRunAllPreUpgradeTaskRunning() |
ACTION_INFO | runAllPreUpgradeTasksmaintenance タスクが現在実行されているかどうかを確認します。 |
getAnyPreUpgradeTaskRunning() |
ACTION_INFO | アップグレード前のメンテナンスタスクが現在実行されているかどうかをチェックし、 現在実行されているタスクの名前を含む配列を返します。 |
getPreUpgradeTaskLastRunTime(preUpgradeTaskName) |
アクション | パラメーターで指定された名前を持つアップグレード前のメンテナンスタスクの正確な実行時間を表示します。 |
getPreUpgradeTaskLastRunState(preUpgradeTaskName) |
アクション | パラメーターで指定された名前を持つアップグレード前のメンテナンスタスクの最終実行状態を表示します。 |
runAllPreUpgradeHealthChecks(shutDownOnSuccess) |
アクション | すべてのアップグレード前のヘルスチェックを実行して、sling ホームパスにある properties ファイルは今後のアップグレードの前提条件として使用され、 |
detectUsageOfUnavailableAPI(aemVersion) |
アクション | 指定された AEM バージョンにアップグレードしたときに適合しない すべての読み込み済みパッケージをリストします。ターゲットの AEM バージョンは、 パラメーターとして指定する必要があります。 |
MBean メソッドは、以下から呼び出すことができます。
この手順は、AEM 5 バージョンからアップグレードする場合にのみ必要です。以前の AEM 6 バージョンからのアップグレードの場合は、完全にスキップできます。
カスタム LoginModules
がリポジトリレベルで認証設定される方法は、Apache Oak で根本的に変更されました。
CRX2 を使用していた旧バージョンの AEM では、repository.xml
ファイルで設定をおこないましたが、AEM 6 以降では、web コンソールを使用して、Apache Felix JAAS Configuration Factory サービスで設定をおこないます。
そのため、既存の設定を無効にして、アップグレード後、Apache Oak 用に再作成する必要があります。
repository.xml
の JAAS 設定で定義したカスタムモジュールを無効にするには、次の例のようにデフォルトの LoginModule
を利用するように設定を変更する必要があります。
<Security >
....
<!--
Use LoginModule authenticating against repository itself
-->
<LoginModule class = "com.day.crx.core.CRXLoginModule" >
<param name = "anonymousId" value = "anonymous" />
<param name = "adminId" value ="admin" />
<param name = "disableNTLMAuth" value = "true" />
<param name = "tokenExpiration" value = "43200000" />
<!-- param name="trust_credentials_attribute" value="d5b9167e95dad6e7d3b5d6fa8df48af8"/
-->
</LoginModule >
</ Security>
詳しくは、外部ログインモジュールによる認証を参照してください。
AEM 6 での LoginModule
設定例については、AEM 6 での LDAP の設定を参照してください。
パッケージは、AEM インスタンスをシャットダウンした後にのみ crx-quickstart/install ディレクトリから削除します。これは、インプレースアップグレード手順を開始する前の最後の手順の 1 つです。
ローカルファイルシステムの crx-quickstart/install
ディレクトリを介してデプロイされたサービスパック、機能パックまたはホットフィックスを削除します。これにより、更新が完了した後に、新しい AEM バージョンに古いホットフィックスおよびサービスパックが誤ってインストールされることが防止されます。
TarMK コールドスタンバイを使用している場合は、すべてのコールドスタンバイインスタンスを停止します。これをおこなうことにより、アップグレードで問題が発生した場合に、オンラインに効率よく戻ることができます。アップグレードが正常に完了したら、アップグレードされたプライマリインスタンスからコールドスタンバイインスタンスを再構築する必要があります。
アプリケーションコードに含まれている OSGi スケジュール済みジョブを無効にします。
この手順は、TarMK インストール環境でのみ必要となります。
TarMK を使用している場合は、アップグレードの前にオフラインでのリビジョンクリーンアップを実行してください。これにより、リポジトリの移行ステップが作成され、後続のアップグレードタスクがより迅速に実行されます。また、アップグレード完了後に、オンラインでのリビジョンクリーンアップが正常に実行されるようになります。オフラインでのリビジョンクリーンアップの実行について詳しくは、オフラインでのリビジョンクリーンアップの実行を参照してください。
この手順は、crx3 を実行するインスタンスにのみ必要です。
CRX3 インスタンスでリビジョンクリーンアップを実行した後は、データストアのガベージコレクションを実行して、データストア内の参照されていない blob を削除する必要があります。手順については、データストアのガベージコレクションに関するドキュメントを参照してください。
このアップグレード前のメンテナンスタスクは、次の場合にのみ必要です。
サービスユーザーが以前の AEM バージョンで、通常のユーザーとして適切にタグ付けされていない場合があります。
この場合、アップグレードは失敗し、次のようなメッセージが表示されます。
ERROR [Apache Sling Repository Startup Thread] com.adobe.granite.repository.impl.SlingRepositoryManager Exception in a SlingRepositoryInitializer, SlingRepository service registration aborted
java.lang.RuntimeException: Unable to create service user [communities-utility-reader]:java.lang.RuntimeException: Existing user communities-utility-reader is not a service user.
この問題を回避するには、必ず次の手順を実行してください。
この問題を回避するには、必ず次の手順を実行してください。
通常、AEM が永続化に使用する基になる Apache Oak スタックは、 必要に応じてデータベーススキーマのアップグレードに対処します。
ただし、スキーマを自動的にアップグレードできない場合が考えられます。これらは、ほとんどの場合、権限が非常に限られたユーザーでデータベースが実行されている高いセキュリティ環境です。 この場合、AEM は引き続き古いスキーマを使用します。
この問題が発生しないようにするには、次の手順に従ってスキーマをアップグレードする必要があります。
アップグレードする必要がある AEM インスタンスをシャットダウンします。
データベーススキーマをアップグレードします。これを実現するために必要なツールを確認するには、データベースのタイプに関するドキュメントを参照してください。
Oak でのスキーマのアップグレードの処理方法について詳しくは、Apache Web サイトでこのページを参照してください。
AEM のアップグレードを続行します。
アップグレードを開始する前に、現在のログファイルをアーカイブすることをお勧めします。これにより、アップグレード中やアップグレード後にログファイルを監視およびスキャンし、問題が発生した場合に問題を特定して解決することが容易になります。