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

目次

このページに含む情報は、どのようにして原因を追及し、問題を解決し、ログを送信し、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 が始めてインストールされたのと同じ状態にします。
  • Uninstall （アンインストール）：このオプションを選択すると、システム上から Docker Desktop を削除します。

注釈

コマンドラインから Docker Desktop のアンインストール

ターミナルから Docker Desktop をアンインストールするには、 <DockerforMacのパス> --uninstall を実行します。実態がデフォルトの場所へインストールしている場合は、このコマンドの実行によってクリーンにアンインストールできます。

$ /Applications/Docker.app/Contents/MacOS/Docker --uninstall
 Docker is running, exiting...
 Docker uninstalled successfully. You can move the Docker application to the trash.

コマンドラインでアンインストールを試みようとする時は、先の例とは異なり、アプリを機能的に見つけられないため、メニュー上からはアンインストールできません。

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

アプリ内診断

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

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

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

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

ターミナルから診断

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

まず com.docker.diagnose を探します。大抵は /Applications/Docker.app/Contents/MacOS/com.docker.diagnose にあるでしょう。

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

$ /Applications/Docker.app/Contents/MacOS/com.docker.diagnose gather -upload

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

Diagnostics Bundle: /tmp/B8CF8400-47B3-4068-ADA4-3BBDCE3985D9/20190726143610.zip
Diagnostics ID:     B8CF8400-47B3-4068-ADA4-3BBDCE3985D9/20190726143610 (uploaded)
Diagnostics Bundle: /tmp/BE9AFAAF-F68B-41D0-9D12-84760E6B8740/20190905152051.zip
Diagnostics ID:     BE9AFAAF-F68B-41D0-9D12-84760E6B8740/20190905152051 (uploaded)

診断 ID （ここでは BE9AFAAF-F68B-41D0-9D12-84760E6B8740/20190905152051）にはユーザ ID （BE9AFAAF-F68B-41D0-9D12-84760E6B8740）とタイムスタンプ（20190905152051）が合わさっています。診断 ID 全体を見て、ユーザ ID のみではないことを確認します。

診断ファイルの内容を表示するには、次のように実行します。

$ open /tmp/BE9AFAAF-F68B-41D0-9D12-84760E6B8740/20190905152051.zip

ログの確認

診断とフィードバックオプションによるログ送信だけでなく、自分自身でログを確認できます。以下のドキュメントは macOS 10.12 移行のものです。もしも古いバージョンであれば 古いドキュメント をご覧ください。

ターミナル上で

コマンドライン上で Docker Desktop ログのライブフロー（live flow）を表示するには、任意のシェルで以下のスクリプトを実行します。

$ pred='process matches ".*(ocker|vpnkit).*"
  || (process in {"taskgated-helper", "launchservicesd", "kernel"} && eventMessage contains[c] "docker")'
$ /usr/bin/log stream --style syslog --level=debug --color=always --predicate "$pred"

あるいは、直近1日のログ（ 1d ） をファイルに集めるには、次の様に実行します。

$ /usr/bin/log show --debug --info --style syslog --last 1d --predicate "$pred" >/tmp/logs.txt

アプリケーション上で

Mac には "Console" という内蔵ログビュアーがあります。これを使って Docker のログを確認できます。

Console は /Applications/Utilities にあります。これはスポットライト検索で見つけられます。

Docker アプリのログ・メッセージを読むには、 Console ウインドウの検索バーで docker と入力し、エンターを押します。それから ANY を選択肢、ドロップダウンリストを展開し、その横にある docker と検索語を入力し、 Press を押します。

Console ログクエリを使ってログを検索でき、様々な方法で結果をフィルだしたり、レポートを作成したりできます。

トラブルシューティング

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

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

クライアントとサーバ側証明書の使用に関しては、導入ガイドのトピックにある TLS 証明書の追加 を御覧ください。

アプリをインストール後、Mac ユーザアカウントとホームフォルダの名称を変更したら、 Docker Desktop が起動しません

FAQ にある do-i-need-to-reinstall-docker-for-mac-if-i-change-the-name-of-my-macos-account をご覧ください。

/Users 以外のプロジェクト・ディレクトリをファイル共有するため、ボリュームのマウントが必要な場合

Docker Compose 等を使う場合、もしもマウント・ボリュームを使用していて、実行時にアプリケーション・ファイルが見つからない、ボリューム・マウントへのアクセスが拒否、サービスが起動できないなどのエラーが出る時は、 ファイル共有 を有効化する必要があるかもしれません。

/Users ディレクトリの外をボリュームマウントするには、プロジェクトに対してドライブ共有する必要があります。 鯨アイコン > Preferences > Resources > File sharing に移動し、Dockerfile とボリュームを含むドライブを共有します。

互換性がない CPU の検出

Docker Desktop が必要なのは、仮想化をサポートしているプロセッサ（CPU）と、とりわけ Apple Hypervisor framework です。 Docker Desktop が適合するのは、このハイパーバイザ・フレームワークをサポートしている CPU を搭載する Mac システムのみです。多くの Mac は 2010 年以降、最近まで製造されたものであり、サポートしています。詳細は Apple Hypervisor Framework ドキュメントにサポートしているハードウェアの情報があります。

一般的に、Intel VT-x 機能ががセットされたマシンには、Extended Page Table (EPT) と Unrestricted モードがサポートされています。

自分の Mac が Hypervisor frametowk をサポートしているかどうか確認するには、ターミナルウインドウ上で以下のコマンドを実行します。

sysctl kern.hv_support

もしも Mac がハイパーバイザ・フレームワークをサポートしていたら、コマンドの結果は kern.hv_support: 1 です。

もしサポートしていなければ、コマンドの結果は kern.hv_support: 0 です。

また、Apple のドキュメント Hypervisor Framework Reference と Docker Desktop Mac システム要件 をご覧ください。

共通する問題の回避策

  • Mac で Docker Desktop のインストールに失敗するか、適切に起動しない：
    • アプリケーションの新しいバージョンをインストールする前に、Docker Desktop を確実に終了しておきます（鯨アイコン > Quit Docker Desktop ）。そうしなければ、新しいアプリケーションを .dmg から /Applications にコピーしようとしても、 "アプリケーションが使用中です" とエラーが出ます。
    • 以前にインストールしたバージョンが動作していたデーモンの停止と、その痕跡を無くすために、 Mac の再起動をします。
    • メニューからアンインストールのコマンドを実行します。
  • もし docker コマンドが適切または期待通りに動作しない場合は、シェルまたはコマンド画面で古い Docker Machine 環境を使用していないことを確認し、いくつかの環境変数を削除する必要があるかもしれません。 DOCKER_HOST 環境変数と関連する変数をアンセットします。
  • macOS ファイアウォールを「外部からの接続を全てブロック」（Block all incoming connections）に設定している場合、ネットワーク通信に失敗します。ファイアウォールは有効化できますが、仮想マシンが IP アドレスを取得できるようにするため、 bootpd に対して外部からの接続（incoming connections）を許可する必要があります。
  • hello-world-nginx を例に挙げると、 Docker Desktop は http://localhost/ 上のウェブサーバに到達する必要があります。メニューバーに Docker アイコンが表示されているのを確認し、それからシェル上で Docker コマンドを実行し、Docker Desktop Engine に接続しているかどうかを確認します（Toolbox 上の Engine ではありません）。そうでなければ、ウェブサーバ用コンテナの起動はできますが、 localhost に移動しても「ウェブページが表示できません」とエラーが出るでしょう。2つの環境間の区別に関する情報は Docker Desktop for Mac と Docker Toolbox の比較 をご覧ください。
  • Bind for 0.0.0.0:8080 failed: port is already allocated （ポートが既に割り当て済みです）や listen tcp tcp:0.0.0.0:8080: bind: address is already in use のようなエラーが出る場合は：
    • Mac 上の他のソフトウェアによって対象ポートが既に利用されているため、エラーが起こる場合があります。
    • lsof -i tcp:8080 を実行し、他のプロセスの名前と pid を確認し、他のプロセスを停止するかどうかを決めます。あるいは、docker アプリケーションが他のポートを使うようにします。

既知の問題

  • IPv6 は（まだ） Docker Desktop 上ではサポートされていません。
  • Docker Desktop で docker-compose up の実行時にエラーが出るかもしれません（ ValueError: Extra Data ）。この現象が発生するのは、関連するデータのイベントが１つ１つ処理されるのではなく、一度にすべて処理されるためです。そのため、２つ以上のオブジェクトが連続して戻るようなデータがあれば、まれにエラーを引き起こします。
  • Docker.app の実行後、 .dmg を強制イジェクトすると、鯨のアイコンが反応しなくなります。また、アクティビティモニタでは、いくつかのプロセスが CPU リソースの大部分を消費してしまい、Docker が無反応なように見えます。この問題を解決するには、リブートして Docker を再起動します。
  • Docker を鯨のアイコン > Preferences でログイン時に自動起動を設定しても、有効にならない場合があります。これは Docker ヘルパー、登録、バージョンに関連する一連の問題です。
  • macOS 10.10 Yosemite 以降では、Docker Desktop は HyperKit ハイパーバイザ（ https://github.com/docker/hyperkit ）を使います。Intel Hardware Accelerated Execution Manager (HAXM) のような HyperKit と競合するようなツールで開発を行っている場合、同時に両者を実行するための回避策は、現時点ではありません。一時的に Docker Desktop を終了して HyperKit を停止すると、 HAXM を利用できます。これにより HyperKit による干渉を防ぎながら、他のツールも利用し続けることができます。
  • Apache Maven のようなアプリケーションを使っている場合に、 DOCKER_HOST ` と :code:`DOCKER_CERT_PATH 環境変数をそれぞれ設定し、Docker に対して Unix ソケットを通して接続するように設定を試みる場合があります。その場合は、次のようにします。
export DOCKER_HOST=unix:///var/run/docker.sock
  • docker-compose 1.7.1 は localunixsocket.local という不要な DNS 名前解決を処理するため、同一ネットワーク上で 5 秒のタイムアウトを引き起こします。もしも docker-compose コマンドの処理が非常に遅く、ネットワークを無効化しても速度が向上しない場合は、ファイル /etc/hosts に 127.0.0.1 localunixsocket.local の追加を試みてください。別の方法として、 localhost:1234 を使うプレインテキストの TCP プロキシを作成することもできます。
docker run -d -v /var/run/docker.sock:/var/run/docker.sock -p 127.0.0.1:1234:1234 bobrik/socat TCP-LISTEN:1234,fork UNIX-CONNECT:/var/run/docker.sock

それから export DOCKER_HOST=tcp://localhost:1234. です。

  • osxfs ではディレクトリのバインド・マウントによる性能上の問題がいくつかあります。とくに、小さなブロックへの書き込みと、大きなディレクトリの再帰的な表示です。さらに、大きなディレクトリ階層を繰り返しスキャンするような、コンテナが非常に多いディレクトリの操作をすると、乏しいパフォーマンスに陥る可能性があります。このような挙動となりうるアプリケーションには：

    • rake
    • ember build
    • Symfony
    • Magento
    • Zend Framework
    • PHP アプリケーションのうち、 Composer で vendor フォルダに依存関係をインストールする場合

    この挙動を回避するには、ベンダーまたはサードパーティ・ライブラリ Docker ボリュームの中に入れ、 osxfs マウントの外で一時的にファイルシステム処理を行うようにします。そして、 Unison や rsync のようなサードパーティ製ツールを使い、コンテナのディレクトリとバインド・マウントしたディレクトリリ間を同期します。私たちは数々の技術を用いながら osxfs 性能改善にアクティブに取り組んでいます。詳細を学ぶには、 パフォーマンス問題、ソリューション、ロードマップ をご覧ください。

  • システムが NTP サーバにアクセスできなければ、Docker Desktop が一時休止後に見える時間の関係で、ホストとの同期が外れてしまう可能性があります。さらに同期のために用いる時間が少々ずれる可能性があります。一時休止後に手動でリセットするには、次のコマンドを実行します。
docker run --rm --privileged alpine hwclock -s

あるいは、両方の問題を解決するには、ホストをソースとするフォールバック NTP 時間を低プライオリティ（high stratum）のローカルクロックとして追加する方法があります。これのするには、ホスト側の /etc/ntp-restrict.conf に追加します。

server 127.127.1.1              # LCL, local clock
fudge  127.127.1.1 stratum 12   # increase stratum

それから、次のコマンドで NTP サービスを再起動します。

sudo launchctl unload /System/Library/LaunchDaemons/org.ntp.ntpd.plist
sudo launchctl load /System/Library/LaunchDaemons/org.ntp.ntpd.plist

参考

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