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

アップグレードを開始する前に、次のメンテナンスタスクに従って、問題が発生した場合にシステムの準備が整い、ロールバックが可能であることを確認することが重要です。

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

アップグレードを実行する際には、コンテンツおよびコードのアップグレードアクティビティに加えて、リポジトリの移行を実行する必要があります。 移行すると、新しい Segment 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 を起動すると、quickstart.properties の下に crx-quickstart/conf ファイルが生成されます。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のアップグレードや、安全に再開できなかったのアップグレードも困難でした。 その結果、完全なアップグレード手順を再開する必要があった場合や、警告を発生させずに不良なアップグレードが実行された場合がありました。

これらの問題に対処するため、Adobeはアップグレードプロセスにいくつかの機能強化を加え、より柔軟でユーザーにとって使いやすいものにしました。 アップグレード前のメンテナンスタスクを手動で実行する必要があった場合は、最適化と自動化が行われています。 また、アップグレード後のレポートが追加され、問題がより簡単に見つかることを期待してプロセスを完全に詳細に調べることができます。

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

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

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

AEM 6.3 以降では、アップグレード前のメンテナンス最適化タスクが quickstart jar に含まれています。 古いバージョンのAEM 6 からアップグレードする場合は、別のパッケージを通じて使用可能になり、パッケージマネージャーからダウンロードできます。

パッケージは次の場所にあります。

使用方法 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 をすべて削除する必要があります。 手順については、 データストアのガベージコレクション.

アップグレードの妨げになる可能性のあるユーザーの削除 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.

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

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

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

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

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

この問題が発生しないようにするには、次の手順に従ってスキーマをアップグレードする必要があります。

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

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