ログとトラブルシューティング¶
このページに含む情報は、どのようにして原因を追及し、問題を解決し、Docker Desktop のサポート要求、ログを送信し、Docker Desktop のチームとやりとりし、フォーラムやナレッジ・ハブで使ったり、GitHub 上で問題を見たり記録したり、既知の問題に対する回避策を発見する方法です。
トラブルシュート¶
メニューバーにある Docker のアイコン > Troubleshoot を選択し、トラブルシュートのオプションを表示します。
トラブルシュートのページには、以下のオプションを含みます。
Restart Docker Desktop (Docker Desktop の再起動):選択すると、Docker Desktop を再起動します。
Support :有償 Docker サブスクリプション利用者は、このオプションを使ってサポートリクエストを送信できます。他の利用者がこのオプションを使うと、Docker Desktop 上のあらゆる問題を診断します。診断に関する詳細情報は、 mac-diagnose-and-feedback をご覧ください。
Reset Kubernetes cluster (Kubernetes クラスタのリセット):このオプションを選択すると、全てのスタックと Kubernetes リソースを削除します。詳しい情報は Kubernetes をご覧ください。
Clean / Purge data (データ除去 / 削除):設定などを初期値のデフォルトに戻さず、全ての 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 の Docker Desktop や Docker Desktop for Mac forum で、ログデータのトラブルシュートに役立つ可能性があります。issue を報告する前に、いくつかの一般的に知られた問題を修正するため、このページが提供する情報を読むのをお勧めします。
注釈
Docker Desktop は有償 Docker サブスクリプションの利用者にサポートを提供しています。Docker Desktop を使っていて何らかの問題が発生したら、以下のセクションの手順に従って、Docker サポートにサポートリクエストを送信してください。
はじめる前に、Docker Desktop アプリケーションに自分の Docker Hub アカウントでサインインしておくのを推奨します。
オプション: Docker Desktop にサインイン。加えて、自分の Docker アカウント で入っているのを確認します。
診断情報の収集が終われば、 Upload to get a Diagnostic ID をクリックします。
診断情報のアップロードが完了すると、 Docker Desktop は Diagnostic ID(診断 ID)を表示します。この ID をコピーします。
有償 Docker サブスクリプションを持っている場合は、 Contact Support をクリック。これは Docker Desktop サポート フォームを開きます。必要な情報を入力し、Diagnostics ID フィールドには先ほどコピーした ID を入れます。Docker Desktop サポートをリクエストするには Submit をクリックします。
注釈
サポートフォームにアクセスするには、Docker Desktop に Pro、Team、Business いずれかの認証賞情報でサインインしている必要があります。Docker Desktop サポートで扱う情報については、 サポート をご覧ください。
有償 Docker サブスクリプションが無い場合、既存のアカウントをアップグレードするために Upgrade to benefit from Docker Support がクリック出来ます。あるいは、 Report a Bug をクリックし、GitHub に新しい Docker Desktop の issue を開きます。これは、GitHub 上の Docker Desktop for Mac をブラウザで開き、「New issue」テンプレートを使います。必要情報を入力し、先ほどコピーした診断 ID を追加します。新しい issue を作成するには submit new issue をクリックします。
ターミナルから診断¶
例えば 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
有償 Docker サブスクリプションを持っている場合は、 Contact Support をクリック。これは Docker Desktop サポート フォームを開きます。必要な情報を入力し、Diagnostics ID フィールドには先ほどコピーした ID を入れます。Docker Desktop サポートをリクエストするには Submit をクリックします。
自己診断ツール ¶
Docker Desktop には、共通する問題を確認するのに役立つ自己診断ツールが入っています。自己診断ツールを実行する前に、 com.docker.diagnose
を探します。アプリケーションのディレクトリ内に Docker Desktop をインストールしている場合は、自己診断ツールの場所は /Applications/Docker.app/Contents/MacOS/com.docker.diagnose
です。
自己診断ツールを実行するには、次のように実行します。
$ /Applications/Docker.app/Contents/MacOS/com.docker.diagnose check
ツールはチェックの一式を実行し、それぞれのチェックごとに PASS か FAIL を表示します。何らかのエラーがあれば、レポートの最後で最も関連する情報をハイライトで表示します。
ログの確認¶
診断とフィードバックオプションによるログ送信だけでなく、自分自身でログを確認できます。
ターミナル上で¶
コマンドライン上で 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 証明書の追加 をご覧ください。
/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
環境変数と関連する変数をアンセットします。 bash を使用中であれば、次のコマンドを実行します:
unset ${!DOCKER_*}
それ以外のシェルでは、各環境変数を Docker Desktop for Mac と Docker Toolbox の比較 の Docker Desktop on Mac を動かすためのセットアップ に書いてある手順に従い、個々にアンセットします。
- もし
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 アプリケーションが他のポートを使うようにします。
既知の問題¶
virtualization.framework
実験的機能を使用時、以下の問題が見受けられます。いくつかの VPN クライアントは、ホスト上から VM で動作している Docker への通信を阻止できるため、 Docker Desktop を正しい起動を妨げます。 docker/for-mac#5208 をご覧ください。
これは
vmnet.framework
(virtualization.fremework
によって使われます)と VPN クライアント間の相互干渉によるものです。いくつかのコンテナのディスク I/O が予想よりも遅くなります。 docker/for-mac#5389 をご覧ください。特にディスクの
フラッシュ は遅くなります。これは、ホスト上の安定したストレージ上に、データを確実に書き込む必要があるためです。他にも分かっているのは、 Intel チップ上の MacOS Monterery でvirtualization.fremework
利用時に、パフォーマンス上の問題があります。これは新しい
virtualization.fremework
技術による副作用です。Linux Kernel が時々クラッシュする可能性があります。Docker は現在この問題を検出でき、利用者に対して素早く Linux を再起動できるようにエラーダイアログ画面をポップアップします。
現在もデータを収集中であり、代替 kernel のバージョンを試験中です。
IPv6 は(まだ) Docker Desktop 上ではサポートされていません。
Apple silicon 上のネイティブな
arm64
コンテナで、debian:buster
やubuntu:20.04``や ``centos:8
のように、libssl
の古いバージョンを使っている場合は、curl https://dl.yarnpkg.com
のように、いくつかのTLS サーバへの接続を試みるとセグメンテーション違反になります。このバグは、debian:bullseye
・ubuntu:21.04
・fedora:35
に含まれるlibssl
の新しいバージョンで修正済みです。
Docker Desktop で
docker-compose up
の実行時にエラーが出るかもしれません(ValueError: Extra Data
)。この現象が発生するのは、関連するデータのイベントが1つ1つ処理されるのではなく、一度にすべて処理されるためです。そのため、2つ以上のオブジェクトが連続して戻るようなデータがあれば、まれにエラーを引き起こします。
Docker.app
の実行後、.dmg
を強制イジェクトすると、鯨のアイコンが反応しなくなります。また、アクティビティモニタでは、いくつかのプロセスが CPU リソースの大部分を消費してしまい、Docker が無反応なように見えます。この問題を解決するには、リブートして 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
osxfs
ではディレクトリのバインド・マウントによる性能上の問題がいくつかあります。とくに、小さなブロックへの書き込みと、大きなディレクトリの再帰的な表示です。さらに、大きなディレクトリ階層を繰り返しスキャンするような、コンテナが非常に多いディレクトリの操作をすると、乏しいパフォーマンスに陥る可能性があります。このような挙動となりうるアプリケーションには:rake
ember build
Symfony
Magento
Zend Framework
PHP アプリケーションのうち、 Composer で
vendor
フォルダに依存関係をインストールする場合
この挙動を回避するには、ベンダーまたはサードパーティ ライブラリ Docker ボリュームの中に入れ、 osxfs マウントの外で一時的にファイルシステム処理を行うようにします。そして、 Unison や
rsync
のようなサードパーティ製ツールを使い、コンテナのディレクトリとバインド マウントしたディレクトリ間を同期します。私たちは数々の技術を用いながら性能改善にアクティブに取り組んでいます。詳細を学ぶには、 ロードマップ上のトピック をご覧ください。
サポート¶
このセクションでは、サポートを得る手順と、 Docker Desktop のサポート範囲を扱います。
注釈
この機能は有償 Docker サブスクリプションが必要です
Docker Desktop は Pro、Team、Business を契約している開発者向けにサポートを提供します。Docker サポートの利点を得るには、いますぐアップグレードしましょう。
Docker Desktop のサポートを得るには¶
有償 Docker サブスクリプションがあれば、 Docker Desktop support を通してチケットを上げてください。
Docker Community 利用者は、 Github リポジトリ for-win と for-mac を通してサポートを得られますが、対応は基本的にベストエフォートです。
何のサポートを得られるのか¶
有償 Docker サブスクリプションを持っていれば、以下の種類の問題に対するサポートを要求できます。
Desktop アップグレードの問題
Desktop インストールの問題
インストールのクラッシュ
Docker Desktop 初回実行時のエラー
利用に関係する問題
クラッシュによってソフトウェアが閉じる
Docker Desktop が期待通りの挙動をしない
設定に関する問題
基本的なプロダクトの「使い方」の質問
何がサポートされないか¶
Docker Desktop のサポートから、以下の種類の問題は対象外です。
ドキュメントで対象としていないハードウェアやソフトウェアに関連する使い方
サポートしていないオペレーティングシステム上での実行で、オペレーティングシステムのベータもしくはプレビューバージョンも含む
エミュレーションを使用し、異なるアーキテクチャのコンテナを実行
Docker Engine、 Docker CLI 、あるいは他に同梱されている Linux コンポーネントに対するサポート
Kubernetes サポート
実験的と表記されている機能
システムやサーバ管理の取り組み
本番環境での Desktop 実行に関するサポート
Desktop をスケールするデプロイや複数マシンへのインストール
定期的なプロダクトのメンテナンス(データバックアップ、ディスク容量をあけたり、ログローテーションの設定)
Docker によって知恵教されていないサードパーティ製アプリケーション
Docker ソフトウェアの改変や編集
ハードウェア故障、不正利用、不適切な利用による Docker ソフトウェアの不具合
最新バージョンではない、あらゆる古いバージョンの Docker ソフトウェア
Docker が提供していないサードパーティ製サービスに対する補償や費用請求
Docker サポートから、トレーニング、カスタマイズ、インテグレーションは除外
どのバージョンがサポート対象ですか?¶
現在サポートを提供しているのは、 Docker Desktop の最新バージョンのみです。古いバージョンを実行している場合は、私たちに調査のサポートリクエストを送る前に、最新バージョンへのアップグレードを確認ください。
Docker Desktop のサポートを何台まで受けられますか?¶
Pro の利用者であれば、1台のマシン上の Docker Desktop にサポートを得られます。Team であれば、プランの一部として、契約数と同等の数の Docker Desktop のサポートが得られます。
どの OS がサポートされますか?¶
Docker Desktop は Mac と Windows 上で利用できます。サポート対象のバージョン情報は、以下のページで確認できます。