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

ログを確認します。 丸太は最初に見る場所です。問題に応じて、コンテナのログまたはエンジンのログを確認します。コンテナ ログへのアクセスについては、Sitecore Dockerチート シートを参照してください。ログは、Docker Desktop (ダッシュボード)や上記の他のツールで表示することもできます。

Sitecore CMおよびCDイメージの場合、デフォルトではすべての組み込みSitecoreログ ファイルがストリーミングされるわけではありません。それらをLogMonitor設定 (c:\LogMonitor\LogMonitorConfig.json) に追加できますが、出力が過剰になる可能性があります。Docker Examplesリポジトリに示されているように、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)、マウントされたフォルダー内のファイルを手動で、またはクリーンなスクリプトを使用して削除します (Docker Examplesリポジトリのclean.ps1例を参照)。

Prune Docker リソース:最近まだ行っていない場合は、未使用のDockerリソースをクリーンアップします。これは、少なくともディスクスペースを解放するために、毎日の習慣として適しています。

docker system prune

詳細については、Sitecore Dockerチート シート を参照してください。

PCを再起動します。 システムを再起動すると、いくつかの問題を解決できます。

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

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

XP1ではなくXM1またはXP0トポロジを実行します。

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

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

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

SITECORE_VERSION=10.0.0-1909
ISOLATION=process

個々のコンテナの メモリ制限 を設定します。Dockerはデフォルトで1GBを使用しますが、特定のサービスでは1GBを削減できます。ただし、mssqlやsolrサービスでは行わないでください。

不要なコンテナのサービスを無効にします。たとえば、XP1トポロジで、マーケティング オートメーション エンジンを使用しない場合は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_SA_PASSWORDのSQLパスワードを、既定のSQL Serverポリシーに合わせて変更します。.envファイルのパスワードを変更した後、docker-compose downを実行した後、マウントされたSQLデータフォルダをクリアしてください。その内容を手動で削除することも、クリーンなスクリプトを使用することもできます (Docker Examplesリポジトリのclean.ps1例を参照)。