アップグレード前のメンテナンスタスク pre-upgrade-maintenance-tasks

アップグレードの開始前に、次のメンテナンスタスクに従って、システムの準備が完了し、問題が発生した場合にロールバックができる状態にしておくことが重要です。

十分なディスク領域の確保 ensure-sufficient-disk-space

アップグレードを実行する際には、コンテンツとコードのアップグレードアクティビティに加えて、リポジトリの移行を実行する必要があります。この移行により、新しいセグメント Tar 形式でリポジトリのコピーが作成されます。その結果、大容量になり得るリポジトリの 2 番目のバージョンを保持するために十分なディスク領域が必要になります。

AEM の完全なバックアップ fully-back-up-aem

アップグレードの開始前に、AEM を完全にバックアップする必要があります。該当する場合は、リポジトリ、アプリケーションのインストール、データストア、Mongo インスタンスを必ずバックアップします。AEM インスタンスのバックアップと復元についての詳細情報は、バックアップと復元を参照してください。

/etc に対する変更のバックアップ backup-changes-etc

アップグレードプロセスは、リポジトリの /apps パスおよび /libs パスの下にある既存のコンテンツおよび設定のメンテナンスやマージに役立ちます。Context Hub 設定などの /etc パスに加えられた変更は、多くの場合、アップグレード後に再適用する必要があります。アップグレードにより、マージできない変更のバックアップコピーが /var の下に作成されますが、アップグレードの開始前にこれらの変更を手動でバックアップすることをお勧めします。

quickstart.properties ファイルの生成 generate-quickstart-properties

jar ファイルから AEM を起動すると、crx-quickstart/conf の下に quickstart.properties ファイルが生成されます。これまで AEM を起動スクリプトでのみ起動していた場合、このファイルは存在せず、アップグレードは失敗します。このファイルが存在するかどうかを確認し、存在しない場合は jar ファイルから AEM を再起動します。

ワークフローおよび監査ログのパージの設定 configure-wf-audit-purging

WorkflowPurgeTask タスクと com.day.cq.audit.impl.AuditLogMaintenanceTask タスクには個別の OSGi 設定が必要であり、この設定がない場合は機能しません。アップグレード前のタスクの実行中にこれらのタスクが失敗した場合、最も考えられる原因は、タスクに設定がないことです。したがって、これらのタスクに OSGi 設定を追加するか、タスクを実行しない場合はアップグレード前の最適化タスクリストから完全に削除してください。ワークフローのパージタスクの設定に関するドキュメントはワークフローインスタンスの管理で、監査ログのメンテナンスタスクの設定に関するドキュメントは AEM 6 の監査ログのメンテナンスで参照できます。

CQ 5.6 でのワークフローと監査ログのパージ、AEM 6.0 での監査ログのパージについては、ワークフローと監査ノードのパージを参照してください。

アップグレード前のタスクのインストール、設定および実行 install-configure-run-pre-upgrade-tasks

AEM で可能なカスタマイズのレベルにより、通常、アップグレードの実行方法は環境によって異なります。そのため、標準化されたアップグレード手順の作成は簡単ではありません。

以前のバージョンでは、停止または失敗した AEM アップグレードを安全に再開することも困難でした。この問題により、完全なアップグレード手順の再開が必要になったり、警告が表示されずに不完全なアップグレードが実行されたりすることがありました。

これらの問題に対処するために、アドビはアップグレードプロセスにいくつかの拡張機能を追加し、より柔軟で使いやすくしました。以前は手動で実行する必要があった、アップグレード前のメンテナンスタスクの最適化と自動化が進められています。また、アップグレード後のレポートを追加して、プロセスを完全に調べて問題を見つけやすくしました。

現在、アップグレード前のメンテナンスタスクは、部分的または完全に手動で実行される様々なインターフェイスに分散されています。AEM 6.3 で導入されたアップグレード前のメンテナンスの最適化により、共通の方法でこれらのタスクをトリガーし、その結果をオンデマンドで調べることができます。

アップグレード前の最適化手順に含まれるすべてのタスクは、AEM 6.0 以降のすべてのバージョンと互換性があります。

設定方法 how-to-set-it-up

AEM 6.3 以降では、アップグレード前のメンテナンス最適化タスクが quickstart jar に含まれています。

使用方法 how-to-use-it

PreUpgradeTasksMBean OSGI コンポーネントは、アップグレード前のメンテナンスタスクのリストで事前設定されており、それらのすべてのタスクを一度に実行できます。以下の手順に従ってタスクを設定できます。

タスクリストは、インスタンスの開始に使用する実行モードによって異なります。各メンテナンスタスクの設計対象となる実行モードの説明を次に示します。

アップグレード前のヘルスチェックのデフォルトの設定 default-configuration-of-the-pre-upgrade-health-checks

PreUpgradeTasksMBeanImpl OSGI コンポーネントは、runAllPreUpgradeHealthChecks メソッドが呼び出されたときに実行されるアップグレード前のヘルスチェックタグのリストで事前設定されています。

このリストは編集できます。タグの横のプラス​ （+） ​ボタンとマイナス​ （-） ​ボタンを使用して、カスタムタグを追加したり、デフォルトのタグを削除したりすることができます。

MBean メソッド

マネージド Bean 機能には、JMX コンソールを使用してアクセスできます。

以下の手順で MBean にアクセスできます。

PreUpgradeTasksMBeanImpl によって公開されている使用可能なすべてのメソッドのリストを以下に示します。

カスタムログインモジュールの無効化 disable-custom-login-modules

カスタム 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>

/install ディレクトリからの更新の削除 remove-updates-install-directory

ローカルファイルシステムの crx-quickstart/install ディレクトリを介してデプロイされたサービスパック、機能パックまたはホットフィックスを削除します。これにより、更新が完了した後に、新しい AEM バージョンに古いホットフィックスおよびサービスパックが誤ってインストールされることを防止できます。

すべてのコールドスタンバイインスタンスの停止 stop-tarmk-coldstandby-instance

TarMK コールドスタンバイを使用している場合は、すべてのコールドスタンバイインスタンスを停止します。これにより、アップグレードで問題が発生した場合でも、効率的にオンラインに戻すことができます。アップグレードが正常に完了したら、アップグレードされたプライマリインスタンスからコールドスタンバイインスタンスを再構築する必要があります。

カスタムのスケジュール済みジョブの無効化 disable-custom-scheduled-jobs

アプリケーションコードに含まれている OSGi スケジュール済みジョブを無効にします。

オフラインでのリビジョンクリーンアップの実行 execute-offline-revision-cleanup

TarMK を使用している場合は、アップグレードの前にオフラインでのリビジョンクリーンアップを実行してください。これにより、リポジトリの移行ステップが作成され、後続のアップグレードタスクがより迅速に実行されます。また、アップグレード完了後に、オンラインでのリビジョンクリーンアップが正常に実行されるようになります。オフラインでのリビジョンクリーンアップの実行について詳しくは、オフラインでのリビジョンクリーンアップの実行を参照してください。

データストアのガベージコレクションの実行 execute-datastore-garbage-collection

CRX3 インスタンスでリビジョンクリーンアップを実行した後は、データストアのガベージコレクションを実行して、データストア内の参照されていない BLOB を削除する必要があります。手順については、データストアのガベージコレクションに関するドキュメントを参照してください。

必要に応じてデータベーススキーマをアップグレード upgrade-the-database-schema-if-needed

通常、AEM が永続性の処理に使用する基礎的な Apache Oak スタックは、必要に応じてデータベーススキーマのアップグレードに対処します。

ただし、スキーマを自動的にアップグレードできない場合も考えられます。それは、ほとんどの場合、権限が限られているユーザーの下でデータベースが実行されている、セキュリティレベルの高い環境です。このような状況が発生した場合、AEM は引き続き古いスキーマを使用します。

このようなシナリオが発生しないようにするには、次の手順を実行してスキーマをアップグレードします。

アップグレードの妨げになる可能性のあるユーザーの削除 delete-users-that-might-hinder-the-upgrade

サービスユーザーが以前の 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.

この問題を回避するには、必ず次の手順を実行してください。

ログファイルのローテーション rotate-log-files

アップグレードを開始する前に、現在のログファイルをアーカイブすることをお勧めします。これにより、アップグレード中やアップグレード後にログファイルを監視およびスキャンして、発生する可能性のある問題を特定および解決することが容易になります。