--- title: "Dockerのトラブルシューティング" slug: "troubleshooting-docker" abstract: "SitecoreやDockerを使う際に使えるトラブルシューティングの方法を示しています。" --- # Dockerのトラブルシューティング このトピックでは、Windows Docker DesktopおよびDockerベースのSitecore開発に関するトラブルシューティングのアドバイスが掲載されています。 [Dockerツールやリソース](https://doc.sitecore.com/xp/ja/developers/103/developer-tools/docker-tools-and-resources.html "Docker tools and resources") には、トラブルシューティングの議論が見られる複数のリソースやコミュニティサイトへのリンクがあります。 ## 一般的なトラブルシューティング手順 - **ログを確認する:** ログが最初に確認すべき場所です。問題に応じて、コンテナのログやエンジンログを確認してください。コンテナログへのアクセスについては、[Sitecore Dockerチートシート](https://doc.sitecore.com/xp/ja/developers/103/developer-tools/sitecore-docker-cheat-sheet.html "Sitecore Docker cheat sheet")をご覧ください。また、**Docker Desktop** (ダッシュボード)や上記の他のツールでログを見ることもできます。 Sitecore CMやCDイメージの場合、すべての組み込みSitecoreログファイルがデフォルトでストリーミングされるわけではありません。LogMonitorの設定(c:\\LogMonitor\\LogMonitorConfig.json)に追加することは可能ですが、これにより過剰な出力が発生する可能性があります。[Docker例リポジトリ](https://github.com/Sitecore/docker-examples)で見られるように、Sitecoreログフォルダを[バインドマウント](https://docs.docker.com/storage/bind-mounts/)するのが役立ちます。 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例](https://github.com/Sitecore/docker-examples)リポジトリのclean.ps1例を参照)。 - **Dockerリソースの剪定:** 最近やっていなければ、使っていないDockerリソースを整理しましょう。これは最低でもディスク容量を空けるための良い毎日の習慣です: docker system prune 詳細は[Sitecore Dockerチートシート](https://doc.sitecore.com/xp/ja/developers/103/developer-tools/sitecore-docker-cheat-sheet.html "Sitecore Docker cheat sheet") をご覧ください。 - **PCの再起動:** システムの再起動でいくつかの問題が解決します。 - **Windows の最新Docker Desktopへのアップグレード:**Dockerはバグ修正や改善を含むDocker Desktop for Windowsの新バージョンを継続的にリリースしています。アップデートはWindowsシステムトレイのDocker項目(クジラアイコン)で確認できます。 - **Docker Desktopを工場出荷時の状態にリセットする:** これにより、Docker Desktopのすべてのオプションがインストール当初と同じ状態にリセットDocker Desktop。これはWindowsシステムトレイのDocker項目(ホエールアイコン)のトラブルシューティングオプションから行えます。 ## コンテナ環境のメモリ使用量 Sitecoreは、開発者用ワークステーションでSitecoreコンテナを扱う場合、最大16GBを推奨しています。システムメモリ不足によるエラーやパフォーマンス問題が発生した場合、以下の手法で環境のメモリ使用量を削減することができます。 - 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 - Windows 10またはWindows 11のバージョンで1909コンテナでプロセス分離が可能な場合は、1909ベースのSitecoreコンテナに切り替え、SITECORE\_VERSIONおよびISOLATION環境変数によるプロセス分離を行ってください。 SITECORE\_VERSION=10.0.0-1909 ISOLATION=process - 個々のコンテナごとに [メモリ制限](https://docs.docker.com/compose/compose-file/compose-file-v2/#cpu-and-other-resources) を設定してください。Dockerデフォルトで1GBを使用しますが、特定のサービスではそれを減らすことができます。ただし、mssqlやsolrサービスではやらないでください。 - 不要なコンテナのサービスを無効にしてください。例えばXP1トポロジーでは、マーケティング自動化エンジンを使わない場合は*xdbautomation*、*xdbautomationrpt*、*xdbautomationworker*を無効にし、Cortexを使わない場合は*cortexprocessing*、*cortexreporting*、*cortexprocessingworker*を無効にします。サービスはサービスをscale: 0に設定し、depends\_on条件をすべて削除することで行います。 ## ウイルス対策ソフトをインストールするとDocker Desktop起動しません ウイルス対策ソフトのスキャンからDockerデータディレクトリ(%ProgramData%\\docker)を除外してみてください。詳細は[https://docs.docker.com/engine/security/antivirus/](https://docs.docker.com/engine/security/antivirus/) をご覧ください。 ## Windowsコンテナはインターネットにアクセスできません これは、例えばNuGetの復元操作における接続エラーとして様々な形で現れることがあります。 [https://github.com/docker/for-win/issues/2760#issuecomment-430889666](https://github.com/docker/for-win/issues/2760#issuecomment-430889666)より: これはホスト上に複数のネットワークアダプター(イーサネット、Wi-Fi)が存在する場合によく起こります。Windowsネットワークスタックが正しくゲートウェイルートを選択するためには、これらのアダプターの優先順位を正しく設定する必要があります。これを解決するには、プライマリのインターネット接続ネットワークアダプターの最低InterfaceMetric値を設定できます: Get-NetIPInterface -AddressFamily IPv4 | Sort-Object -Property InterfaceMetric -Descending このコマンドを使って変更を行います(この例ではプライマリアダプターのInterfaceAliasが 'Wi-Fi'を前提としています): Set-NetIPInterface -InterfaceAlias 'Wi-Fi' -InterfaceMetric 3 もしホストのプライマリネットワークアダプターがブリッジされているなら、Hyper-Vに外部仮想スイッチを設定している場合、外部仮想スイッチのInterfaceMetric値を最も低いものに設定してください。 ルーティングテーブルの検証は以下のコマンドで確認できます(最後の行にはプライマリアダプターのゲートウェイアドレスとそのifMetric値が表示されます): Get-NetRoute -AddressFamily IPv4 ## 使用中のポート/「プロセスはファイルにアクセスできません」 Sitecore環境を起動しようとすると、次のようなエラーが出るかもしれません: ERROR: for myproject\_traefik\_1 Cannot start service traefik: failed to create endpoint myproject\_traefik\_1 on network myproject\_default: failed during hnsCallRawResponse: hnsCall failed in Win32: The process cannot access the file because it is being used by another process. (0x20) このエラーは、必要なポートを使用するIISや他のプロセスを停止する必要があることを示しています。必要なポートの完全なリストについては、「 [最初のSitecoreインスタンスを実行する](https://doc.sitecore.com/xp/ja/developers/103/developer-tools/run-your-first-sitecore-instance.html "Run your first Sitecore instance")」をご覧ください。 ## 無効なSQL Server管理者パスワードによるエラー SQL\_SA\_PASSWORD値はSQL Server指定された[強力なパスワード要件](https://docs.microsoft.com/en-us/sql/relational-databases/security/strong-passwords?view=sql-server-2017)を満たしなければなりません。これらの要件を満たさないパスワードは、以下のようなエラーを示します。 - 環境内の不健康なコンテナ状態(XConnect、CMなど)、および以下のような起動エラーがあります: ERROR: for traefik Container 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リポジトリ](https://github.com/Sitecore/docker-examples)のclean.ps1例を参照)。 ## コンテナは「作成済み」ステータスで固定されています このエラーは通常、docker-compose upを使った後に表示されます。特定のサービスが実行できず、docker ps -aで確認すると*Created*状態が報告されることがあります。 この問題を解決するために、Docker Composeファイル内の問題のあるコンテナのメモリ制限を増やしてみてください。Dockerデフォルトは1GBですが、サービスによってはそれが少なすぎる場合もあります。例えば、mssqlサービスやsolrサービスのコンテナは2GBを必要とすることがあります: mssql: ... mem\_limit: 2GB solr: ... mem\_limit: 2GB ## 管理者としてSitecoreにログインできません これは、永続的なSQLデータストレージが有効になっている(Docker Compose設定のマウントボリュームを通じて)し、.envファイルのSitecore管理者パスワード(SITECORE\_ADMIN\_PASSWORD変数)を変更した場合に起こります。パスワードはデータベースファイルの最初の作成時に設定されるため、パスワード変更前にインスタンスが実行されていた(つまりdocker-compose up)場合は古いものになります。 デフォルトのSitecore設定ではこれが有効で、ボリュームはmssql-dataフォルダにマウントされています: mssql: ... volumes: - type: bind source: .\\mssql-data target: c:\\data 解決するには、インスタンスがダウンしている(つまりdocker-compose down)ことを確認し、マウントフォルダ内のファイルを削除してください。手動で削除するか、クリーンスクリプトを使うこともできます([Docker Examplesリポジトリ](https://github.com/Sitecore/docker-examples)のclean.ps1例を参照)。 ## 誤った機能エラー コンテナやイメージ構築を開始する際に、以下のエラーが出ることがあります: hcsshim::PrepareLayer - failed failed in win32 : Incorrect function. (0x1) これはBox、Dropbox、OneDriveなどのツールのドライバーの互換性が悪いことが原因であることが多いです。回避策や解決策については[GitHubのWindows Docker Desktop問題](https://github.com/docker/for-win/issues/3884) の議論をご覧ください。 ## コンテナのシャットダウン失敗エラー コンテナを起動したり、ビルドイメージを起動したりすると、次のようなエラーが出ることがあります。 failed to shutdown container: container 45917373d49ed4130f7c7ac16f19f59379c1c98d0c429cc806a6f292d6792286 encountered an error during hcsshim::System::Shutdown: failure in a Windows system call: The connection with the virtual machine or container was closed. (0xc037010a): subsequent terminate failed container 45917373d49ed4130f7c7ac16f19f59379c1c98d0c429cc806a6f292d6792286 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The connection with the virtual machine or container was closed. (0xc037010a) Docker Desktopを再起動すればほとんどの場合この問題は解決しますが、マシンの再起動が必要になるかもしれません。 この[Docker Desktop for Windows号の](https://github.com/docker/for-win/issues/7523)進捗はGitHubでフォローしてください。 ## ファイアウォールとプロセス分離の競合 特定のファイアウォール構成は、プロセス隔離を利用するコンテナ同士の通信を妨げます。症状としては、ログを検査した際にコンテナ間の不健康なコンテナやネットワーク通信エラーが発生します。 特定のファイアウォールの競合を見つけるのは難しい場合があります。回避策として、影響を受けた個々のコンテナをデフォルトの隔離に設定できます(例えばあなたのdocker-compose.override.yml): solr: ... isolation: default