ログとトラブルシューティング

目次

このページに含む情報は、どのようにして原因を追及し、問題を解決し、ログを送信し、Docker Desktop のチームとやりとりし、フォーラムやナレッジ・ハブで使ったり、GitHub 上で問題を見たり記録したり、既知の問題に対する回避策を発見する方法です。

トラブルシュート

メニューバーにある Docker のアイコン > Troubleshoot を選択し、トラブルシュートのオプションを表示します。

トラブルシュートのページには、以下のオプションを含みます。

  • Restart Docker Desktop （Docker Desktop の再起動）: 選択すると、Docker Desktop を再起動します。
  • Reset Kubernetes cluster （Kubernetes クラスタのリセット）: このオプションを選択すると、全てのスタックと Kubernetes リソースを削除します。詳しい情報は Kubernetes を御覧ください。
  • Reset disk image （ディスク・イメージのリセット）：設定などを初期値のデフォルトに戻さず、全ての Docker データをリセットします。このオプションを選択した結果、既存の設定は消滅します。
  • Reset to factory defaults （初期値のデフォルトにリセット）: このオプションを選択すると、Docker Desktop の全てのオプションを初期値にリセットし、Docker Desktop が始めてインストールされたのと同じ状態にします。

問題の診断、フィードバック送信、GitHub issues の作成

アプリ内診断

発生した問題が、このページ内のドキュメントで解決できない場合は、 GitHub の Docker Desktop や Docker Desktop for Windows forum で、ログデータのトラブルシュートに役立つ可能性があります。

Docker アイコン > Troubleshoot > Run Diagnostics を選択します。

Diagnose & Feedback ウインドウが開始されたら、診断情報の収集が始まります。診断情報が取得可能であれば、アップロードするときに必要となる Diagnostic ID を得られます。これは Docker チームとやりとりするときに必須です。私たちの個人データ取り扱いポリシーに関する情報は win-how-is-personal-data-handled-in-docker-desktop を御覧ください。

Report an issue （問題を報告）をクリックすると GitHub 上の Docker Desktop for Windows issues をウェブブラウザで開き、送信前に必要な一式が揃った "New issue" テンプレートが適用されます。その際に Diagnostic ID （診断 ID）の添付を忘れないでください。

ターミナルから診断

例えば Docker Desktop for Windows が開始できないなど、場合によっては自分での診断実行が役立つ場合もあります。

まず com.docker.diagnose を探します。大抵は C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe にあるでしょう。

診断の作成とアップロードをするには、次のコマンドを実行します：

PS C:\> & "C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe" gather -upload

診断が終了したら、以下のように診断 ID を含む出力になります。

Diagnostics Bundle: C:\Users\User\AppData\Local\Temp\CD6CF862-9CBD-4007-9C2F-5FBE0572BBC2\20180720152545.zip
Diagnostics ID:     CD6CF862-9CBD-4007-9C2F-5FBE0572BBC2/20180720152545 (uploaded)

トラブルシューティング

証明書の正しいセットアップを確実にする

Docker Desktop は安全ではないレジストリ（insecure registry）上にある証明書を無視します。また、そちらに対してクライアント証明書も送りません。 docker run のようなコマンドでは、レジストリからの取得（pull）を試みても、次のようなコマンドライン上のエラーメッセージを表示します。

Error response from daemon: Get http://192.168.203.139:5858/v2/: malformed HTTP response "\x15\x03\x01\x00\x02\x02"

レジストリ側でも同様にエラーが出ます。こちらが例です。

2019/06/20 18:15:30 http: TLS handshake error from 192.168.203.139:52882: tls: client didn't provide a certificate
2019/06/20 18:15:30 http: TLS handshake error from 192.168.203.139:52883: tls: first record does not look like a TLS handshake

クライアントとサーバ側証明書の使用に関しては、導入ガイドのトピックにある どのようにしてカスタム CA 証明書を追加できますか？ と win-add-client-certificates: を御覧ください。

ボリューム

共有ボリュームにおける、データ・ディレクトリ上の権限（permission）エラー

Docker Desktop は 共有ボリューム 上の権限（パーミッション）をデフォルトで 0777 （ ユーザ 及び グループ に対して、 読み込み ・ 書き込み ・ 実行 の権限）に設定します。

共有ボリューム上におけるデフォルトの権限は、変更できません。もしも、アプリケーションの動作上、デフォルトの共有ボリューム上でコンテナ実行時に異なる権限が必要となる場合は、ホストをマウントしないボリュームを使用するか、アプリケーション側が初期設定の権限で動作する設定を見つける必要があります。

また、 コンテナ固有のデプロイに必要となる、共有ボリューム上の権限を変更できますか？ もご覧ください。

共有ドライブ上へのボリューム・マウントが Linux コンテナに必要です

マウント・ボリュームを使用中に、アプリケーション・ファイルが見つからないというランタイム・エラーが表示される場合は、ボリューム・マウントに対するアクセスが拒否されているか、あるいは、 :doc:` Docker Compose </compose/gettingstarted>` などを使っていてサービスが開始できない場合には、 共有ドライブ の有効化が必要でしょう。

Linux コンテナ（Windows コンテナではありません）でボリュームをマウントするには、共有ドライブが必要です。Docker アイコンをクリックし、それから Settings > Shared Drives を選び、Dockerfile と ボリュームを置くためのドライブを共有します。

予期しない構文エラー（unexpected syntax error）を避けるため、コンテナ内でファイルの行末を unix 風にする

コンテナ内で実行するあらゆるファイルは、 Unix 風の行末 \n を使う必要があります。これをファイルに含むのは、ビルド用のコマンドラインや Dockerfile における RUN 命令で参照するからです。

Docker コンテナと docker build の実行は Unix 環境のため、コンテナ内のファイルは Unix 風の行末 \n を使うのが必須です。 Window 風の \r\n ではありません。シェルスクリプトのようなファイルを作成するときは、Windows ツールを使うとデフォルトで Windows 風の行末になるので、気に留めておいてください。各コマンドは、最終的には Unix をベースするコンテナ内の Unix コマンドに渡されます（例えば、シェルスクリプトは /bin/sh に渡されます）。もしも Windows 風の行末が用いられると、 docker run は構文エラーになり失敗します。

この問題と解決方法の例は、GitHub 上の issue を御覧ください： Docker RUN でシェルスクリプトの実行に失敗する（英語）

仮想化

Docker Desktop を正しく機能するには、マシンには以下の機能が必要です。

  1. Hyper-V をインストールして、動作させる
  2. 仮想化の有効化

Hyper-V

Docker Desktop をインストールして有効化するには、 Hyper-V と同様に Windows Powershell 用 Hyper-V モジュールも必要です。Docker Desktop インストーラは、これらを有効化します。

また、Docker Desktop は Hyper-V を使うために2つの CPU 機能を使います。すなわち、仮想化と Rapid Virtualization Indexing (RVI) とも呼ばれる Second Level Address Translation (SLAT) です。同じシステムの BIOS 上で、Virtualization （仮想化）の有効化が必須です。必要な手順はベンダによって異なりますが、典型的な BIOS オプションは Virtualization Technology (VTx) と呼ばれるものか、似たようなものです。Hyper-V 機能が必要とする全てを確認するには、 systeminfo コマンドを実行します。詳細は Windows 10 Hyper-V のシステム要件 を御覧ください。

Hyper-V を手動でインストールするには、 `Windows 10 上に Hyper-V をインストールする <https://docs.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v?redirectedfrom=MSDN>_ を御覧ください。インストール後は再起動が必用です。Hyper-V をインストールしても再起動をしないと、 Docker Desktop は正しく動作しません。

スタートメニューから、 Windows 機能の有効化又は無効化 を入力し、エンターを押します。以下の画面のようになっていると、Hyper-V は有効です。

Docker Machine 用の Hyper-V ドライバ

Docker Desktop のインストールには、Docker Machine という以前のツールが使う古い boot2docker.iso と、ローカルで仮想マシンを作成するための Microsoft Hyper-V ドライバ を含みます。これらは Docker Desktop とはほとんど関係がありませんが、Docker Machine で複数のローカル仮想マシン（VM）を作成したいときや、リモートマシンをプロビジョン（自動構築）するために必要です。詳しくは Docker Machine の記事を御覧ください。こちらのドキュメントは Docker Machine on Windows について探している方向けのドキュメントであり、必要となる Hyper-V の有効化や、アクティブに切り替える外部ネットワークや、 前述の Docker Machine ドライバ例 にある docker-machine create コマンドのフラグも含むリファレンスです。

仮想化を必ず有効化

Hyper-V や WSL 2 を追加するには、仮想化の有効化が必要です。タスクマネージャー上のパフォーマンス・タブをクリックします。

もしも Hyper-V を手動でアンインストールするか、仮想化を無効にしたら、Docker Desktop は起動できません。 [Windows 10 Enterprise では Docker for Windows を実行できません（英語）](https://github.com/docker/for-win/issues/74) を御覧ください。

Docker Desktop for Windows インストール後のネットワーク機能と WiFi 問題

Docker Desktop のインストールと起動によって、何人かの利用者は、ネットワーク機能の問題が発生する可能性があります。例えば、インストールあるいは自動再起動の後、ネットワーク・アダプタと WiFi のどちらかか両方が無効化するものです。問題のいくつかの原因は、 VirtualBox を導入しているか、そのネットワーク・アダプタをインストールしている場合ですが、その他の原因によっても起こる可能性があります。GitHub issue Hyper-V 機能の有効化で wi-fi が切れる（英語） を御覧ください。

こちらは、もしも似たような問題が発生したときの対応手順です。

  1. 仮想化を必ず有効化 で前述した通り、 仮想化 の有効化を確認します。
  1. Hyper-V を必ず有効化 で前述した通り、Hyper-V のインストールと有効化を確認します。
  1. Hyper-V マネージャー の右側にある 操作 タブ上の 仮想スイッチマネージャー で DockerNAT の有効化を確認します。
  1. 外部ネットワークスイッチをセットアップします。 Docker Machine で複数のローカル VM のセットアップを検討中であれば、前述の Docker Machine 用 Hyper-V ドライバ にある作業はいずれ必要です。 DockerNAT はこのスイッチに置き換え可能です。
  1. 以上の手順でも問題解決できない場合は、次の クリーンアップ Readme にある手順を進めてください。

ちなみに

Windows クリーンアップスクリプトを実行する前に、必ずお読みください
クリーンアップ・コマンドには2つのフラグ -Cleanup と -ForceDeleteAllSwitches があります。スクリプトの実行前に各ページをお読みください。特に -ForceDeleteAllSwitches に書かれた警告をお読みください。

Windows コンテナと Windows Server

Windows Server 上での Docker Desktop はサポート外です。そのかわり、追加費用なしで Docker Enterprise Basic を利用可能です。Windows 10 上で Windows コンテナの実行に関する疑問があれば、 Windows と Linux コンテナとの切り替え を御覧ください。

docker/labs の Getting Started with Windows Container に全てのチュートリアルがあります。

ネイティブな Windows バイナリをインストールしたら、Windows Desktop がなくても Windows コンテナの開発と実行が可能です。しかし、この方法で Docker をインストールしたら、Linux コンテナの開発と実行ができません。もしもネイティブな Docker デーモンで Linux コンテナの実行を試みても、次のようなエラーが発生します。

C:\Program Files\Docker\docker.exe:
 image operating system "linux" cannot be used on this platform.
 See 'C:\Program Files\Docker\docker.exe run --help'.

localhost の Windows コンテナの制限と公開ポート

Docker Desktop for Windows は、Windows と Linux コンテナの切り替えオプションがあります。もし Windows コンテナを使っている場合は、現時点における Windows NAT (WinNAT) の実装により、ネットワーク機能に対する複数の制限があります。それぞれの制限は Windows コンテナ・プロジェクトの進化によって、いずれは解決する可能性があります。

Windows 10 1819 で使える Docker Desktop for Windows から、Windows コンテナはローカルホスト上でのポート公開が可能になりました。Windows Server 2019 / 1809 で Docker EE を使う場合も同様です。

もしも Windows 10 18.09 未満のバージョンを使う場合は、Windows コンテナの公開ポートがローカルホストにループバックされる問題があります。ホストからコンテナのエンドポイントに到達できる唯一の方法は、コンテナの IP とポートを使います。 Windows 10 18.09 では、コンテナはローカルホスト上にポートを公開可能です。

それでは、Docker を使ってイメージを取得してウェブサーバを実行するため、次のようなコマンド実行例を見ましょう。

> docker run -d -p 80:80 --name webserver nginx

curl http://localhost を使うか、ウェブ・ブラウザで http://localhost を表示しても、 nginx ウェブページは（Linux コンテナの場合とは違い）表示されません。

ローカルホストから Windows コンテナに到達するには、サービスを実行しているコンテナの IP アドレスとポートを指定する必要があります。

コンテナに割り当てられている IP アドレスを知るには、 docker inspect に複数の --format オプションと、コンテナの ID 又は名前を使います。先ほどの例では、コマンドを実行するときにコンテナ ID ではなくコンテナ名（ webserver ）を使います。

$ docker inspect \
  --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' \
  webserver

これにより、コンテナの IP アドレスを次のように表示します。

$ docker inspect \
  --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' \
  webserver

172.17.0.2

あとは、ウェブサーバに対して http://172.17.0.2:80 を使って接続できるようになります（あるいは、ポート 80 はデフォルトの HTTP ポートのため、シンプルに http://172.17.0.2 を使います）。

更に詳しい情報は、以下を御覧ください。

ネストした仮想化環境で Docker Desktop を実行

Paralles や VMware Fusion a Mac 上で動く Windows 10 仮想マシン内で、適切な設定をすると Docker Desktop を実行可能です。しかしながら、ハードウェア仮想化アプリの手法によって、問題や一時的な問題が発生する可能性があります。そのため、 Docker Desktop はネストした仮想化環境での実行をサポートしません 。動く場合もあれば、動かない場合もあります。

最良の結果を出すには、Windows システム上で Docker Desktop をネイティブに実行するのを推奨します（Windows コンテナも Linux コンテナも動作します）。また Mac では Linux コンテナのみ動作します。

それでもネスト化した仮想化環境を使いたい場合には

  • VMware や Paralles でネスト化した仮想化サポートが有効になっているかどうかを確認します。設定の Hardware > CPU & Memory > Advanced Options > Enable nested virtualization を確認します（展開するメニュー順番は、若干変わるかもしれません）。
  • 仮想マシンが最小 2 CPU と、ワークロードを実行するための十分なメモリを使うように設定します。
  • システムは多少のアイドル（余裕）があるようにします。
  • Windows OS を最新版へ確実に更新します。insider ビルドによっては、複数の問題があります。
  • 適切なプロセッサも必要です。例えば、Westmere ベースの Mac Pro は、Nehalem ベースの Mac Pro よりもハードウェア仮想化機能が追加されていますし、更に新しい世代のインテル・プロセッサもそうでしょう。

ネスト化した仮想化環境で起こる典型的な問題

  • Linux 仮想マシンのブート時に確認します。ログを見て、 Moby を先頭に含む行がないかどうか調べます。実在のハードウェアでは、Linux 仮想マシンのブートにかかる時間は 5 ～ 10 秒です。つまり、おおよその時間は、 Connected のログ記録から * Starting Docker ... [OK] ログ記録までです。もしも Windows 仮想マシン内で Linux 仮想マシンをブートするのであれば、この処理にかかる時間はより長くなります。タイムアウトは 60 秒以上です。もし VM が時間までに起動しなければ、リトライします。リトライに失敗したら、エラーを表示します。Windows 仮想マシンに対し、更にリソースを提供することで回避可能な場合があります。
  • ブート時、タイムスタンプ・カウンタ（TSC）の補正を Linux が行うとき、仮想マシンが落ちる場合があります。この処理はタイミングがセンシティブなため、仮想マシン内で仮想マシンを実行する場合に落ちるかもしれません。また、 CPU 使用率も高くなります。
  • Paralles on Mac では "PMU Virtualizatoin" が無効かどうかを確認します。 設定の Hardware > CPU & Memory > Advanced Settings > PMU Virtualization を確認します。

ネットワーク機能の課題

Docker Desktop は（まだ） IPv6 をサポートしていません。

Docker Desktop 安定版（stable）を使っているユーザ数名から、 Docker Hub への接続問題が報告されています。 GitHub issue [22567] を御覧ください）

以下はコマンドとエラーメッセージの例です。

> docker run hello-world

Unable to find image 'hello-world:latest' locally
Pulling repository docker.io/library/hello-world
C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error while pulling image: Get https://index.docker.io/v1/repositories/library/hello-world/images: dial tcp: lookup index.docker.io on 10.0.75.1:53: no such host.
See 'C:\Program Files\Docker\Docker\Resources\bin\docker.exe run --help'.

この問題を一時的に回避するには、 DNS サーバの設定をリセットし、 Google DNS の固定アドレス 8.8.8.8 を使います。この設定は Settings から行えます。

注釈

Network ダイアログについては、 [ネットワーク]() のトピックに詳細があります。この設定を適用したら、少し時間をおいた後、Docker は自動的に再起動します。

NAT/IP 設定

デフォルトでは、 Docker Desktop は 10.0.75.0/24 の内部ネットワーク・プリフィックスを使用します。通常のネットワークセットアップで衝突してしまう場合には、 Settings （設定）メニューからプリフィックスを変更可能です。 [設定]() 以下の [ネットワーク]() 記事を御覧ください。

回避策（ワークアラウンド）

再起動

PC を再起動し、以前にインストールしたバージョンで動いているデーモンの残骸を、停止・削除します。

DOCKER_HOST のリセット（unset）

DOCKER_HOST 環境変数の設定は不要です。 bash を使用する場合は、リセットのために unset ${!DOCKER_*} コマンドを使います。他のシェルの場合は、シェルのドキュメントをご確認ください。

ウェブサーバの例で Docker が動作しているのを確認

hello-world-nginx サンプルなどを使い、 Docker Desktop で https://localhost 上にウェブサーバを起動します。メニューバー上に Docker 鯨（のアイコン）があるのを確認し、シェル上の Docker コマンドが Docker Desktop エンジンに接続しているのを確認します（Toolbox のエンジンではありません）。そうしなければ、ウェブサーバ・コンテナは実行できるかもしれませんが、 docker は "web page not available"（ウェブページが表示できません）というエラーを返すでしょう。

'port already allocated' （ポートが既に割り当てられています） エラーを解決するには

Bind for 0.0.0.0:8080 failed: port is already allocated や listen tcp:0.0.0.0:8080: bind: address is already in use ... のようなエラーが出ることがあるでしょう。

これらのエラーは、Windows 上の他のソフトウェアが各ポートを使っている場合によく発生します。どのソフトウェアが使っているかを見つけるか、 resmon.exe の GUI を使い "Network" と "listening Ports" をクリックするか、 Powershell 上では netstat -aon | find /i "listening " を使って、対象ポートを現在使っているプロセスの PID を見つけます（PID の値は行の右端です）。他のプロセスの停止を決めるか、あるいは、docker アプリで別のポートを使うかを決めます。

アンチウィルス・ソフトウェアをインストールしていると、Docker Desktop の起動に失敗

いくつかのアンチウィルス・ソフトウェアは、Hyper-V と Microsoft Windows 10 ビルドによっては互換性がない場合があります。典型的に発生するのは Windows update 直後で、Docker デーモンからエラーの反応が表示され、Docker Desktop の起動に失敗します。

一時的な回避策としては、アンチウィルス・ソフトウェアをアンインストールするか、Docker Desktop フォーラム上での他の回避策をお探しください。

参考

Logs and troubleshooting
https://docs.docker.com/docker-for-windows/troubleshoot/