Docker のトラブルシューティング

ログの確認: 最初にログを確認します。問題に応じて、コンテナーのログやエンジンのログを確認します。コンテナーのログへのアクセスについては、「Sitecore Docker クイック ガイド」を参照してください。また、Docker Desktop (ダッシュボード) や上記の他のツールでも、ログを確認できます。

Sitecore の CM イメージや CD イメージでは、Sitecore の組み込みのログ ファイルの一部はデフォルトではストリーミングされません。それらのログ ファイルは LogMonitor 設定 (c:\LogMonitor\LogMonitorConfig.json) に追加できますが、それにより出力が過剰になる可能性があります。Docker サンプル リポジトリにあるように、Sitecore のログ フォルダーをバインド マウントすると役立ちます。

cm:
 [...]
 volumes:
   - ${LOCAL_DATA_PATH}\cm:C:\inetpub\wwwroot\App_Data\logs

Docker エンジン (デーモン) のログは、C:\Users\%USERNAME%\AppData\Local\Docker にあります。

Docker Desktop を再起動します。Docker Desktop を再起動すると、問題が解決することがよくあります。Windows システム トレイの Docker アイテム (クジラのアイコン) から再起動できます。

マップ済みのボリューム データを消去します。コンテナーで、永続ストレージにマップされたボリュームを使用している場合は、これらのフォルダー内の古いデータが問題の原因である可能性があります。デフォルトの Sitecore 設定では、このような設定は、mssql および solr サービスで使用されています。インスタンスがダウン (docker-compose down) していることを確認してください。マウントされたフォルダー内のファイルを手動で、またはクリーン スクリプトを使用して削除します (clean.ps1 は、Docker Examples リポジトリの例です)。

Docker リソースを整理します。最近行っていなかった場合は、使用していない Docker リソースを消去します。ディスク領域を解放するために、最低でもこの作業を毎日行うことをお勧めします。

docker system prune

詳細については、Sitecore Docker クイック ガイドを参照してください。

コンピューターを再起動します。システムを再起動すると、問題が解決することがあります。

Windows 用の最新の Docker Desktop にアップグレードします。Docker では、バグ修正と改良を加えた新しいバージョンの Docker Desktop for Windows が継続的にリリースされています。Windows システム トレイの Docker アイテム (クジラのアイコン) から、更新を確認できます。

Docker Desktop を工場出荷時のデフォルトにリセットします。これにより、Docker Desktop のすべてのオプションは、Docker Desktop が最初にインストールされたときと同じ初期状態にリセットされます。これは、Windows システム トレイの Docker アイテム (クジラのアイコン) の [トラブルシューティング] オプションから実行できます。

XP1 の代わりに XM1 または XP0 トポロジを実行します。

XM0 で変更された XM1 トポロジを実行します (開発専用)。これは、redis および cd サービスを scale: 0 に設定し、Sitecore_AppSettings_role:define 環境変数を使って cm サービスをスタンドアロン モードに設定して行います。

redis:
  [...]
  scale: 0
cd:
  [...]
  scale: 0
cm:
  [...]
  environment:
      Sitecore_AppSettings_role:define: Standalone

1909 コンテナーでプロセス分離を実行できる Windows 10 バージョンを実行している場合は、SITECORE_VERSION および ISOLATION 環境変数を使って、1909 ベースの Sitecore コンテナーとプロセス分離に切り替えます。

SITECORE_VERSION=10.0.0-1909
ISOLATION=process

コンテナーごとにメモリ制限を設定します。Docker はデフォルトで 1 GB を使用しますが、mssql または solr サービス以外の特定のサービスではこの値以下に減らすことができます。

不要なコンテナーのサービスを無効にします。たとえば、XP1 トポロジで Marketing Automation Engine を使用しない場合は、xdbautomation、 xdbautomationrpt および xdbautomationworker を無効にします。あるいは、Cortex を使用しない場合は、cortexprocessing、cortexreporting および cortexprocessingworker を無効にします。これは、サービスを scale: 0 に設定し、depends_on 条件をすべて削除して行います。

使用している環境 (XConnect、CM など) のコンテナーの状態が異常な場合は、次のような起動エラーが表示されます。

ERROR: for traefik  Container <id> is unhealthy.
ERROR: Encountered errors while bringing up the project.

XConnect コンテナー ログのエラー:

Microsoft.Azure.SqlDatabase.ElasticScale.ShardManagement.ShardManagementException: Store Error: Login failed for user 'sa'.. The error occurred while attempting to perform the underlying storage operation during 'Microsoft.Azure.SqlDatabase.ElasticScale.ShardManagement.StoreException: Error occurred while performing store operation. See the inner SqlException for details. ---> System.Data.SqlClient.SqlException: Login failed for user 'sa'.

SQL Server コンテナー ログのエラー:

VERBOSE: Changing SA login credentials
Msg 15118, Level 16, State 1, Server 96FAC1ED734A, Line 1
Password validation failed. The password does not meet the operating system policy requirements because it is not complex enough.

デフォルトの SQL Server ポリシーに適合するよう、SQL_SA_PASSWORD の SQL パスワードを変更します。.env ファイルのパスワードを変更したら、docker-compose down の実行後に、マウント済み SQL データ フォルダーをクリアします。内容を手動で削除するか、クリーン アップ スクリプトを使用できます (Docker Examples リポジトリの clean.ps1 の例を参照)。