トラブルシュートのトピック¶
全プラットフォーム対象のトピック¶
証明書を適切にセットアップしているか確認¶
Docker Desktop は docker run のようなコマンドでは、レジストリからの取得（pull）を試みても、次のようなコマンドライン上のエラーメッセージを表示します。
Error response from daemon: Get http://192.168.203.139:5858/v2/: malformed HTTP response "\x15\x03\x01\x00\x02\x02"
レジストリ側でも同様にエラーが出ます。こちらが例です。
2017/06/20 18:15:30 http: TLS handshake error from 192.168.203.139:52882: tls: client didn't provide a certificate
2017/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
Linux と Mac 版のトピック¶
$HOME 以外のプロジェクト ディレクトリをファイル共有するため、ボリュームのマウントが必要な場合¶
Docker Compose 等を使う場合、もしもマウント ボリュームを使用していて、実行時にアプリケーション ファイルが見つからない、ボリューム マウントへのアクセスが拒否、サービスが起動できないなどのエラーが出る時は、 ファイル共有 を有効化する必要があるかもしれません。
/home/<user> ディレクトリの外をボリューム マウントするには、プロジェクトに対する共有ドライブが必要です。 Settings から Resources を選び、 File sharing をクリックします。Dockerfile とボリュームを含むドライブを共有します。
Mac 版のトピック¶
互換性がない 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 システム要件 をご覧ください。
Windows 版のトピック¶
ボリューム¶
共有ボリュームにおける、データ ディレクトリ上の権限（permission）エラー¶
Docker Desktop は 共有ボリューム 上の権限（パーミッション）をデフォルトで 0777 （ ユーザ 及び グループ に対して、 読み込み ・ 書き込み ・ 実行 の権限）に設定します。
共有ボリューム上におけるデフォルトの権限は、変更できません。もしも、アプリケーションの動作上、デフォルトの共有ボリューム上でコンテナ実行時に異なる権限が必要となる場合は、ホストをマウントしないボリュームを使用するか、アプリケーション側が初期設定の権限で動作する設定を見つける必要があります。
また、 can-i-change-permissions-on-shared-volumes-for-container-specific-deployment-requirements もご覧ください。
共有ドライブ上へのボリューム マウントが Linux コンテナに必要です¶
マウント ボリュームを使用中に、アプリケーション ファイルが見つからないというランタイム エラーが表示される場合は、ボリューム マウントに対するアクセスが拒否されているか、あるいは、 :doc:` Docker Compose </compose/gettingstarted>` などを使っていてサービスが開始できない場合には、 共有フォルダ の有効化が必要でしょう。
Hyper-V バックエンドで、Windows から Linux コンテナにボリュームをマウントするには、共有フォルダが必要です。Docker アイコンをクリックし、それから Settings > Shared Folders を選び、Dockerfile と ボリュームを置くためのフォルダを共有します。
シンボリックリンク（symlinks）のサポート¶
シンボリックリンクはコンテナ間および横断して機能します。詳しく学ぶには、 FAQ の how-do-symlinks-work-on-windows をご覧ください。
予期しない構文エラー（unexpected syntax error）を避けるため、コンテナ内でファイルの行末を unix 風にする¶
コンテナ内で実行するあらゆるファイルは、 Unix 風の行末 n を使う必要があります。これをファイルに含むのは、ビルド用のコマンドラインや Dockerfile における RUN 命令で参照するからです。
Docker コンテナと docker build の実行は Unix 環境のため、コンテナ内のファイルは Unix 風の行末 n を使うのが必須です。 Window 風の rn ではありません。シェルスクリプトのようなファイルを作成するときは、Windows ツールを使うとデフォルトで Windows 風の行末になるので、気に留めておいてください。各コマンドは、最終的には Unix をベースするコンテナ内の Unix コマンドに渡されます（例えば、シェルスクリプトは /bin/sh に渡されます）。もしも Windows 風の行末が用いられると、 docker run は構文エラーになり失敗します。
この問題と解決方法の例は、GitHub 上の issue を御覧ください： Docker RUN でシェルスクリプトの実行に失敗する（英語）
Windows 上でのパス変換¶
Linux 上では、マウントしているパスを、他のパスへと管理しています。たとえば、Linux 上で以下のコマンドを実行するとします。
$ docker run --rm -ti -v /home/user/work:/work alpine
これは対象のコンテナに /work ディレクトリを追加し、指定したパスの内容をミラーします。
しかしながら、Windows 上では、元のパス（ソース パス）を変更する必要があります。たとえば、レガシーの Windows シェル（ cmd.exe ）を使っている場合、以下のコマンドが使えます。
$ docker run --rm -ti -v C:\Users\user\work:/work alpine
これはコンテナを起動し、ボリュームを利用可能な状態にします。Docker Desktop は Windows 形式のパスを見つけると、ディレクトリをマウントするため、適切に変換する場合があります。
Docker Desktop でも適切な形式で Unix 風のパスを指定できます。例：
$ docker run --rm -ti -v /c/Users/user/work:/work alpine ls /work
Git Bash で動かす¶
$ docker run --rm -ti -v C:\Users\user\work:/work alpine
docker: Error response from daemon: mkdir C:UsersUserwork: Access is denied.
エラーになるのは、 Git Bush では \ 記号が特別な意味を持つためです。Bit Bash を使う場合は、無効化する \\ を使う必要があります。
$ docker run --rm -ti -v C:\\Users\\user\\work:/work alpine
また、スクリプト内で pwd コマンドを使う場合は、ファイルシステムの場所をハードコーディングしないように使われます。出力は Unix 風のパスです。
$ pwd
/c/Users/user/work
$() 構文を組み合わせる場合、 Linux では以下のコマンドは動作しますが、 Git Bash では失敗します。
$ docker run --rm -ti -v $(pwd):/work alpine
docker: Error response from daemon: OCI runtime create failed: invalid mount {Destination:\Program Files\Git\work Type:bind Source:/run/desktop/mnt/host/c/Users/user/work;C Options:[rbind rprivate]}: mount destination \Program Files\Git\work not absolute: unknown.
この問題に対応するには、追加の / を使います。
$ docker run --rm -ti -v /$(pwd):/work alpine
Linux は複数の / を１つの入力として扱うため、スクリプトの互換性には影響ありません。１行でパスを扱う場合は、無効化する必要があります。
$ docker run --rm -ti -v /$(pwd):/work alpine ls /work
ls: C:/Program Files/Git/work: No such file or directory
この例では、 / が先にあるため、 $(pwd) は変換されません。ですが、２つめの /work は Docker Desktop で処理する前に、 POSIX レイヤーによって変換されます。これを正しく動作するには、 / を追加します。
$ docker run --rm -ti -v /$(pwd):/work alpine ls //work
スクリプトや他のソースでエラーが発生する場合、どこか原因かを確認するには、環境変数が使えます。例：
$ MSYS_NO_PATHCONV=1 docker run --rm -ti -v $(pwd):/work alpine ls /work
ここでは、環境変数そのものを想定しています。（環境変数の）値は関係ありません。
場合によっては、 MSYS もコロンをセミコロンに変換します。 ~ を使う時、 POSIX レイヤーが DOS のパスに変更する時に発生する状況と似ています。この場合、 MSYS_NO_PATHCONV も動作します。
仮想化¶
Docker Desktop を正しく機能するには、マシンには以下の機能が必要です。
WSL 2 と Windows Home¶
仮想マシン プラットフォーム
Windows 起動時にハイパーバイザーを有効化
Hyper-V¶
Windows 10 Pro や Enterprise では、以下の機能を有効にして Hyper-V も使えます。
Hyper-V をインストールして、動作させる
Windows 起動時にハイパーバイザーを有効化
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 をインストールする を御覧ください。インストール後は再起動が必要です。Hyper-V をインストールしても再起動をしないと、 Docker Desktop は正しく動作しません。
スタートメニューから、 Windows 機能の有効化又は無効化 を入力し、エンターを押します。以下の画面のようになっていると、Hyper-V は有効です。
仮想化の有効化が必須¶
Hyper-V や WSL 2 を追加するには、仮想化の有効化が必要です。タスクマネージャー上のパフォーマンス タブをクリックします。
もしも Hyper-V を手動でアンインストールするか、仮想化を無効にしたら、Docker Desktop は起動できません。 [Windows 10 Enterprise では Docker for Windows を実行できません（英語）](https://github.com/docker/for-win/issues/74) を御覧ください。
Windows のスタートアップでハイパーバイザを有効化¶
前述の手順を全て実施しても Docker Desktop の起動に問題が出ている場合は、ハイパーバイザーはインストールされているものの、Windows のスタートアップ（起動処理）中に起動できていない可能性があります。同様のツール（Virtual Box の古いバージョン）やビデオゲームのインストーラが、起動時にハイパーバイザーを無効化します。再度、有効化するには、次の手順をします。
管理者としてコマンドプロンプトを開く。
bcdedit /set hypervisorlaunchtype autoを実行Windows 再起動
また、 Microsoft TechNet の記事 にある Code flow guard (CFG) 設定もご覧ください。
Windows コンテナーと Windows Server¶
Windows Server 上での Docker Desktop はサポート外です。Windows 10 上で Windows コンテナの実行に関する疑問があれば、 switch-between-windows-and-linux-containers を御覧ください。
docker/labs の Getting Started with Windows Container に全てのチュートリアルがあります。 .. .. You can install a native Windows binary which allows you to develop and run Windows containers without Docker Desktop. However, if you install Docker this way, you cannot develop or run Linux containers. If you try to run a Linux container on the native Docker daemon, an error occurs:
ネイティブな 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'.