LoginSignup
176
224

More than 3 years have passed since last update.

@zembutsu(Masahito Zembutsu)inさくらインターネット株式会社

Docker Desktop for Windows （参考訳）

Last updated at Posted at 2020-02-27

Docker Desktop for Windows

原文 、ウェブ版原文
2020年6月4日現在の情報です。

Windows 10 Pro で Docker Desktop をセットアップする手順については、別途記事をまとめ ています。

目次

Windows に Docker Desktop をインストール

Docker Desktop for Windows は、Microsoft Windows用の Docker コミュニティ 版です。Docker Desktop for Windows は Docker Hub からダウンロードできます。

このページは、Docker Desktop を Windows 10 Pro、Enterprise、Education にインストールするための情報です。Docker Desktop を Windows 10 Home にインストールする情報をお探しであれば、 Windows Home に Docker Desktop をインストール をご覧ください。

Docker Desktop のダウンロード中に、 Docker Software End User License Agreement と Docker Data Processing Agreement に同意ください。

インストール前に知っておくこと

システム要件

  • Windows 10 64 ビット：Pro、Enterprise、Education（ビルド 15063 以上）
  • Hyper-V と Windows コンテナ機能の有効化が必要
  • 以下は、Windows 10 以上で Hyper-V クライアントを問題なく実行するために必要なハードウェア要件

メモ : Docker による Windows 用 Docker Desktop のサポートは、Microsoft の Windows 10 オペレーティングシステムに対するサポート・ライフサイクルに基づきます。詳細な情報は Windows ライフサイクル・ファクトシート を御覧ください。

インストーラに含まれるもの

Docker Desktop のインストールに含まれるのは、 Docker Engine 、 Docker CLI クライアント、 Docker Compose 、 Notary 、 Kubernetes 、Credential Helper です。

Docker Desktop で作成したコンテナやイメージは、インストールしたマシン上の全ユーザ間で共有です。これは、すべての Windows アカウントが同じ仮想マシンでコンテナを構築・実行するからです。ただし、Docker Desktop WSL2 バックエンドを使用する場合は、ユーザ間でコンテナやイメージの共有ができないのでご注意ください。

VMware や Parralles インスタンス上で Docker Desktop を実行するような、ネストした仮想化でも動くでしょうが、無保証です。詳しい情報は ネスト対応の仮想化シナリオ を御覧ください。

メモ : Windows サーバに関する全ての Docker 互換性比較は、 Docker 互換表 を御覧ください。

Windows コンテナについて

Windows コンテナの情報をお探しですか？

  • Windows と Linux コンテナの切り替え では、Docker Desktop での Linux と Windows コンテナ間の切り替え方を説明し、上の方でチュートリアルに言及しています。
  • Getting Started with Windows Containers (Lab) では、セットアップと Windows コンテナを実行するためのチュートリアルを提供しています。対象は Windows 10、Windows Server 2016、Windows Server 2019 です。そちらでは Windows コンテナで MusicStore アプリケーションを扱う方法を説明します。
  • Windows 用 Docker コンテナ・プラットフォームについては、 Docker ウェブサイト上の 記事やブログ投稿 を御覧ください。

Windows に Docker Desktop をインストール

1.　「 Docker Desktop Installer.exe 」をダブルクリックし、インストーラを起動します。もしもまだインストーラ（ Docker Desktop Installer.exe ）をダウンロードしていなければ、 Docker Hub から取得できます。ダウンロードは通常「ダウンロード」フォルダ内か、ウェブブラウザ上のダウンロード・バーに表示される最近ダウンロードした場所です。
2.　確認画面が出たら、 Enable Hyper-V Windows Features ** （Hyper V の Windows 機能を有効にする）のオプションが、設定ページで選択されているかどうかを確認します。
3.　インストール・ウィザードの指示に従い、利用規約（ライセンス）を承諾し、インストーラに権限を与えてインストールを進めます。
4.　インストールに成功したら、 **Close （閉じる）をクリックしてインストールを終了します。
5. 　管理者（admin）アカウントと使用中のアカウントが異なる場合、 docker-users グループにユーザを追加する必要があります。（Windows の） コンピュータの管理 を管理者として起動し、 ローカル ユーザーとグループ > グループ > docker-users を右クリックし、対象ユーザをグループに追加します。ログアウト後に戻ってくると、設定が有効になっています。

Docker Desktop を始める

インストール後の Docker Desktop は、自動的に起動できません。Docker Desktop を開始するには Docker を検索し、検索結果にある「 Docker Desktop 」を選択します。

＜図＞

ステータス・バーに鯨のアイコンが出続けたら、 Docker Desktop は起動・実行中であり、あらゆる端末ウインドウからアクセスできます。

＜図＞

もしも鯨アイコンが通知エリアから隠れている場合は、タスクバーで「上」を向いた矢印をクリックして表示します。詳しく知るには [Docker 設定] を御覧ください。

初期化が完了すると、Docker Desktop は開始チュートリアルを起動します。チュートリアルには Docker イメージを構築、実行し、Docker Hub にイメージを送信するまでの例を含みます。

＜図＞

おめでとうございます！ Windows 版 Docker Desktop の実行に成功しました。

チュートリアルに戻りたければ、 Docker Desktop のメニューから Learn （学ぶ）をクリックします。

Docker Desktop のアンインストール

Windows マシンから Docker Desktop をアンインストールするには、

  1. Windows の スタート メニューから、 設定 > アプリ > アプリと機能 を選びます。
  2. アプリと機能 の一覧から Docker Desktop を選択し、 アンインストール をクリックします。
  3. 選択したのを確認の後、 アンインストール をクリックします。

メモ : Docker Desktop のアンインストールは、ローカルのマシンにある Docker コンテナのイメージを破棄し、アプリケーションによって作成された全てのファイルも破棄します。

Stable と Edge バージョンの切り替え

Docker Desktop は、自分で Stable （安定版）リリースと Edge （最新）リリースを切り替え可能です。しかしながら、 Docker Desktop を一度にインストールできるのは、1つのバージョンのみ です。Stable と Edge 版のリリース切り替えるは、開発環境の安定性を損なう可能性があります。特に、新しい（Edge）チャンネルを古い（Stable）チャンネルに切り替える場合です。

例えば、 Docker Desktop の新しい Edge バージョンでコンテナを作成する場合、Stable に切り戻すと動作しなくなる可能性があります。これは、Edge の機能を使って作成したコンテナには、まだ Stable には反映されていない機能が用いられている場合があるからです。Edge コンテナで作成したり作業したりする場合には、留意し続けてください。

Edge と Stable バージョン間を安全に切り替えるには、必要に応じてイメージの保存（save）やコンテナの出力（export）を確実に行い、他のバージョンをインストールする前に、既存のバージョンをアンインストールします。詳しい情報については、以下にあるデータの保存と修復を御覧ください。

データの保存と修復

以下の手順を用いて、イメージとコンテナのデータを保存・修復できます。例えば、Edge と Stable を切り替えたいときや、仮想マシンのディスクをリセットしたいときに用います。

  1. docker save -o images.tar image1 [image2 ....] を使い、保持したい全てのイメージを保存します。Docker Engine コマンドライン・リファレンスの save セクションを御覧ください。
  2. docker export -o myContainer1.tar container を使い、保持したい全てのコンテナをエクスポート（出力）します。Docker Engine コマンドライン・リファレンスの export セクションを御覧ください。
  3. 現在のバージョンの Docker Desktop をアンインストールし、異なるバージョン（Stable 又は Edge）をインストールし、仮想マシン・ディスクをリセットします。
  4. docker load -i images.tar を使い、以前に保存したイメージを再読み込みします。Docker Engine の load を御覧ください。
  5. docker import -i myContainer1.tar を使い、以前にエクスポートしたコンテナに対応するファイルシステム・イメージを作成します。Docker Engine の import を御覧ください。

データ・ボリュームのバックアップと修復の仕方に関する情報は、 Backup, restore, or migrate data volumes を御覧ください。

Window Home に Docker Desktop をインストール

Windows Home マシンで WSL2 バックエンドを使うと、Docker Desktop をインストールできます。Docker Desktop on Windows Home は、Linux コンテナ開発用の Docker Desktop の完全なバージョンです。

このページは、Docker Desktop を Windows 10 Home にインストールするための情報です。Docker Desktop を Windows 10 Pro、Enterprise、Education にインストールする情報をお探しであれば、 Windows に Docker Desktop をインストール をご覧ください。

Docker Desktop on Windows Home を使えば、以下の利点があります：

  • Windows Home マシン上で、最新版の Docker が使える
  • Windows Home 上で、1回クリックするだけで Kubernetes をインストールする
  • 統合 UI によって、実行中コンテナの表示・管理
  • 10 秒もかからず Docker Desktop を起動
  • Linux ワークスペースの使用
  • リソースとメモリの動的な割り当て
  • ネットワーク・スタックにより、http プロキ設定や信頼できる CA 同期のサポート

WSL 2 に関する詳細は、Docker Desktop WSL 2 バックエンドをご覧ください。

インストール前に知っておくこと

システム要件

Windows 10 Home マシンで Docker Desktop を実行するには、以下の要件が必要です。

メモ : Docker による Windows 用 Docker Desktop のサポートは、Microsoft の Windows 10 オペレーティングシステムに対するサポート・ライフサイクルに基づきます。詳細な情報は Windows ライフサイクル・ファクトシート を御覧ください。

インストーラに含まれるもの

Docker Desktop のインストールに含まれるのは、 Docker Engine 、 Docker CLI クライアント、 Docker Compose 、 Notary 、 Kubernetes 、Credential Helper です。

Docker Desktop で作成したコンテナやイメージは、インストールしたマシン上の全ユーザ間で共有です。これは、すべての Windows アカウントが同じ仮想マシンでコンテナを構築・実行するからです。ただし、Docker Desktop WSL2 バックエンドを使用する場合は、ユーザ間でコンテナやイメージの共有ができないのでご注意ください。

VMware や Parralles インスタンス上で Docker Desktop を実行するような、ネストした仮想化でも動くでしょうが、無保証です。詳しい情報は ネスト対応の仮想化シナリオ を御覧ください。

メモ : Windows サーバに関する全ての Docker 互換性比較は、 Docker 互換表 を御覧ください。

Windows 10 Home に Docker Desktop をインストール

1.　「 Docker Desktop Installer.exe 」をダブルクリックし、インストーラを起動します。もしもまだインストーラ（ Docker Desktop Installer.exe ）をダウンロードしていなければ、 Docker Hub から取得できます。ダウンロードは通常「ダウンロード」フォルダ内か、ウェブブラウザ上のダウンロード・バーに表示される最近ダウンロードした場所です。
2.　確認画面が出たら、 Enable Hyper-V Windows Features ** （Hyper V の Windows 機能を有効にする）のオプションが、設定ページで選択されているかどうかを確認します。
3.　インストール・ウィザードの指示に従い、利用規約（ライセンス）を承諾し、インストーラに権限を与えてインストールを進めます。
4.　インストールに成功したら、 **Close （閉じる）をクリックしてインストールを終了します。

Docker Desktop を始める

インストール後の Docker Desktop は、自動的に起動できません。Docker Desktop を開始するには Docker を検索し、検索結果にある「 Docker Desktop 」を選択します。

＜図＞

ステータス・バーに鯨のアイコンが出続けたら、 Docker Desktop は起動・実行中であり、あらゆる端末ウインドウからアクセスできます。

＜図＞

もしも鯨アイコンが通知エリアから隠れている場合は、タスクバーで「上」を向いた矢印をクリックして表示します。詳しく知るには [Docker 設定] を御覧ください。

初期化が完了すると、Docker Desktop は開始チュートリアルを起動します。チュートリアルには Docker イメージを構築、実行し、Docker Hub にイメージを送信するまでの例を含みます。

＜図＞

おめでとうございます！ Windows 版 Docker Desktop の実行に成功しました。

チュートリアルに戻りたければ、 Docker Desktop のメニューから Learn （学ぶ）をクリックします。

Docker Desktop のアンインストール

Windows マシンから Docker Desktop をアンインストールするには、

  1. Windows の スタート メニューから、 設定 > アプリ > アプリと機能 を選びます。
  2. アプリと機能 の一覧から Docker Desktop を選択し、 アンインストール をクリックします。
  3. 選択したのを確認の後、 アンインストール をクリックします。

メモ : Docker Desktop のアンインストールは、ローカルのマシンにある Docker コンテナのイメージを破棄し、アプリケーションによって作成された全てのファイルも破棄します。

Stable と Edge バージョンの切り替え

Docker Desktop は、自分で Stable （安定版）リリースと Edge （最新）リリースを切り替え可能です。しかしながら、 Docker Desktop を一度にインストールできるのは、1つのバージョンのみ です。Stable と Edge 版のリリース切り替えるは、開発環境の安定性を損なう可能性があります。特に、新しい（Edge）チャンネルを古い（Stable）チャンネルに切り替える場合です。

例えば、 Docker Desktop の新しい Edge バージョンでコンテナを作成する場合、Stable に切り戻すと動作しなくなる可能性があります。これは、Edge の機能を使って作成したコンテナには、まだ Stable には反映されていない機能が用いられている場合があるからです。Edge コンテナで作成したり作業したりする場合には、留意し続けてください。

Edge と Stable バージョン間を安全に切り替えるには、必要に応じてイメージの保存（save）やコンテナの出力（export）を確実に行い、他のバージョンをインストールする前に、既存のバージョンをアンインストールします。詳しい情報については、以下にあるデータの保存と修復を御覧ください。

データの保存と修復

以下の手順を用いて、イメージとコンテナのデータを保存・修復できます。例えば、Edge と Stable を切り替えたいときや、仮想マシンのディスクをリセットしたいときに用います。

  1. docker save -o images.tar image1 [image2 ....] を使い、保持したい全てのイメージを保存します。Docker Engine コマンドライン・リファレンスの save セクションを御覧ください。
  2. docker export -o myContainer1.tar container を使い、保持したい全てのコンテナをエクスポート（出力）します。Docker Engine コマンドライン・リファレンスの export セクションを御覧ください。
  3. 現在のバージョンの Docker Desktop をアンインストールし、異なるバージョン（Stable 又は Edge）をインストールし、仮想マシン・ディスクをリセットします。
  4. docker load -i images.tar を使い、以前に保存したイメージを再読み込みします。Docker Engine の load を御覧ください。
  5. docker import -i myContainer1.tar を使い、以前にエクスポートしたコンテナに対応するファイルシステム・イメージを作成します。Docker Engine の import を御覧ください。

データ・ボリュームのバックアップと修復の仕方に関する情報は、 Backup, restore, or migrate data volumes を御覧ください。

Docker for Windows を始めよう

Docker Desktop へようこそ！

Docker Desktop for Windows のセクションは、Docker Desktop コミュニティ安定版リリース（Community Stable release）に関する情報を扱います。エッジリリース（Edge release）に関する情報は、 エッジリリースノートを御覧ください。Docker デスクトップ・エンタープライズ（DDE）リリースに関する情報は Docker Desktop Enterprise を御覧ください。

Docker とは、コンテナ化したアプリケーションを構築・実行・共有するための、全てが揃った開発プラットフォームです。Windows 上で Docker を使い始めるためには、Docker Desktop が最も良い方法です。

ダウンロード情報、システム要件、インストール手順については、 Docker Desktop のインストール を御覧ください。

インストールの確認

  1. ターミナルウインドウを開きます（コマンドプロンプトか PowerShell ですが、PowerShell ISE は除く）。
  2. docker --version を実行し、サポート対象の Docker かどうかを確認します。
> docker --version

Docker version 19.03.1

3.　hello-world イメージ を Docker Hub から取得し、コンテナとして実行します。

> docker run hello-world

docker : Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
1b930d010525: Pull complete
Digest: sha256:c3b4ada4687bbaa170745b3e4dd8ac3f194ca95b2d0518b417fb47e5879d9b5f
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.
...

4.　Docker Hub からダウンロードした hello-world イメージを、一覧から確認します。

> docker image ls

5.　hello-world コンテナを一覧に表示します（"Hello from Docker!" を表示した後、終了 exited しています）。

> docker container ls --all

6.　いくつかのヘルプ命令を実行し、Docker ヘルプページを見て回ります。

> docker --help
> docker container --help
> docker container ls --help
> docker run --help

アプリケーションの探索

このセクションでは、OS やウェブサーバといった複雑なアプリケーションを実行し、Docker 化アプリケーションの簡易さと威力をお見せします。

  1. Ubuntu OS のイメージを取得し、作成したコンテナ内で、双方向（インタラクティブ）のターミナルを実行します。
> docker run --interactive --tty ubuntu bash

docker : Unable to find image 'ubuntu:latest' locally
latest: Pulling from library/ubuntu
22e816666fd6: Pull complete
079b6d2a1e53: Pull complete
11048ebae908: Pull complete
c58094023a2e: Pull complete
Digest: sha256:a7b8b7b33e44b123d7f997bd4d3d0a59fafc63e203d17efedf09ff3f6f516152
Status: Downloaded newer image for ubuntu:latest

**PowerShell ISE を使用しないでください* 双方向ターミナルは PowerShell ISE では動作しません（PowerShell では動作します）。詳細は docker/for-win/issues/223 を御覧ください

2.　コンテナの中にいます。ルート # プロンプト上で、コンテナの hostname （ホスト名）を確認します。

root@8aea0acb7423:/# hostname
8aea0acb7423

ホスト名には、コンテナ ID が割り当てられているのに注目します（プロンプトでもホスト名にコンテナ ID が用いられています）。

3.　exit コマンドでシェルを終了します（また、コンテナも停止します）。

root@8aea0acb7423:/# exit
>

4.　--all オプションを付けて、コンテナ一覧を表示します（実行中のコンテナが存在しないからです）。

hello-world コンテナ（ランダムに relaxed_sammet と名前付け）は、自身のメッセージを表示した後、停止しました（stopped）。 ubuntu コンテナ（ランダムに laughing_kowalevski と名前付け）は、コンテナから抜け出た（exit）ので停止しました（stopped）。

> docker container ls --all

CONTAINER ID    IMAGE          COMMAND     CREATED          STATUS                      PORTS    NAMES
8aea0acb7423    ubuntu         "bash"      2 minutes ago    Exited (0) 2 minutes ago             laughing_kowalevski
45f77eb48e78    hello-world    "/hello"    3 minutes ago    Exited (0) 3 minutes ago             relaxed_sammet

5.　Docker 化した nginx （エンジンエックス）ウェブ・サーバを取得・実行し、 webserver と名付けます。

> docker run --detach --publish 80:80 --name webserver nginx

Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx

fdd5d7827f33: Pull complete
a3ed95caeb02: Pull complete
16f7a5f3082: Pull complete
7b10f03a0309: Pull complete
Digest: sha256:f6a001272d5d324c4c9f3f183e1b69e9e0ff12debeb7a092730d638c33e0de3e
Status: Downloaded newer image for nginx:latest
dfe13c68b3b86f01951af617df02be4897184cbf7a8b4d5caf1c3c5bd3fc267f

6.　ウェブ・ブラウザで http://localhost を指定し、nginx のスタートページを開きます（ :80 を追加する必要はありません。 docker コマンドで標準の HTTP ポートを指定したからです）。

＜図＞

7.　実行中（ running ）のコンテナのみを一覧表示します。

> docker container ls

CONTAINER ID    IMAGE    COMMAND                   CREATED          STATUS          PORTS                 NAMES
0e788d8e4dfd    nginx    "nginx -g 'daemon of…"    2 minutes ago    Up 2 minutes    0.0.0.0:80->80/tcp    webserver

8.　実行中の nginx コンテナを停止するために、割り当てた webserver の名前を使います。

> docker container stop webserver

9.　3つのコンテナ全てを、名前で削除します。後ろにある２つの名前は、おそらく皆さんの環境とは異なるでしょう。

> docker container rm webserver laughing_kowalevski relaxed_sammet

Docker 設定画面（ダイアログ）

Docker Desktop のメニュー から、インストール、アップデート、バージョンチャンネル、Docker Hub へのログインなど、Docker の設定ができます。

このセクションでは、 Settings （設定）画面から設定できるオプションについて説明します。

1.　Docker Desktop のメニューを開くには、通知エリア（又はシステムトレイ）にある Docker アイコンをクリックします。

＜図＞

2.　設定画面から Settings （設定）を選びます。

＜図＞

General（一般的な設定）

設定画面の General タブでは、Docker の起動と更新を設定できます。

＜図＞

  • Start Docker when you log in - Windows システムへのログイン時、自動的に Docker Desktop を起動します。
  • Automatically check for updates - デフォルトでは、Docker Desktop は自動的に更新を確認し、更新版が利用可能な場合は通知します。承諾して更新版をインストールするには OK をクリックします（あるいは、現在のバージョンを維持する場合は、キャンセルします）。メインの Docker メニューから Check for Updates （更新を確認）で、手動での更新ができます。
  • Expose daemon on tcp://localhost:2357 without TLS - レガシー（古い）クライアントが Docker デーモンに接続できるようにするには、このオプションを有効化します。このオプションを使う場合は注意が必要です。TLS なしでデーモンを公開する場合は、リモートからのコード実行攻撃をもたらす可能性があるためです。
  • Send usage statics - デフォルトでは、Docker Desktop は診断情報・クラッシュ報告・利用データを送信します。この情報は、 Docker の改善やアプリケーションの問題解決に役立ちます。止めるにはチェックボックスを空にします。Docker は定期的に更なる情報を訊ねるかもしれません。

Resources（リソース）

Resources タブは、CPU、メモリ、ディスク、プロキシ、ネットワーク、その他のリソースを設定できます。

＜図＞

ADVANCED（高度な設定）

Advanced タブでは、 Docker が利用できるリソースに制限をかけます。

  • CPUs （CPU）: デフォルトでは、 ホスト・マシン上で利用可能なプロセッサ数の半分を、Docker Desktop が使います。総理能力を向上するには、この値を高くします。減らすには、数値を低くします。
  • Memory （メモリ）: デフォルトでは、 マシン上で利用可能な全メモリから 2 GB の実行メモリを使用する設定です。RAM を増やすには、この値を高くします。減らすには、値を低くします。
  • Swap （スワップ）: 必要になるスワップ・ファイル容量を設定します。デフォルトは 1 GB です。
  • Disk image size （ディスク・イメージ容量）: ディスク・イメージの容量を指定します。
  • Disk image location （ディスク・イメージの場所）: Linux ボリュームの場所を指定します。ここにコンテナとイメージを置きます。

また、ディスク・イメージは別の場所に移動できます。ディスク・イメージの指定先に既にイメージがある場合は、既存のイメージを使うか置き換えるか訊ねる画面を表示します。

FILE SHARING（ファイル共有）

Linux コンテナと共有したいローカルのディレクトリを選択します。ファイル共有は Linux コンテナ内でボリュームをマウントするために必要であり、Windows コンテナ用ではありません。Linux コンテナでは、Dockerfile とボリュームを保管するための場所として、ドライブの共有が必要です。指定がなければ、実行時に file not found （ファイルが見つかりません）や cannot start service （サービスを開始できません）のエラーが出ます。詳しくは「Linux コンテナのボリューム・マウントには共有ドライブが必要」を御覧ください。

ファイル共有権限は、ここで指定した場所に認証情報（credential）の設定を試みます。この場所に対しては、設定済みの異なるユーザ名で docker コマンドを実行しても、コンテナはマウントされたボリュームに対してアクセスできません。

コンテナに共有したいローカル・ドライブを指定したら、 Docker Desktop は Windows システム（ドメイン）のユーザ名とパスワードの入力を求めます。認証情報を入力の後、 Apply & Restart （適用と再起動）をクリックします。

共有ドライブ、権限、ボリューム・マウントに役立つ情報
- 可能であれば、Windows ホストからボリューム・マウントするのではなく、その代わりに Linux VM 上をマウントします。あるいはデータ・ボリューム（名前付きボリューム）やデータ・コンテナを使います。ホストをマウントするボリュームや、データベース・ファイルにネットワーク・パスを用いる場合、多数の問題があります。詳細は「ホスト・パスでボリュームのマウントでは、データベース・ロックを上書きする nobrl オプションを使う」を御覧ください。
- Docker Desktop はユーザ、グループ、その他に対する読み込み／書き込み／実行権限を 0777 あるいは a+rwx に設定します。これは調整できません。詳細は「共有ボリュームにおけるデータ・ディレクトリ上の権限エラー」を御覧ください。
- ドメイン・ユーザは共有ドライブにアクセスできるようにしてください。詳細な情報は「ドメイン・ユーザは共有ドライブに対する権限があるかどうか確認」を御覧ください。
- コンテナに対してはローカル・ドライブを共有可能ですが、Docker Machine ノードに対してではありません。詳細は FAQ の「Docker Machine 用仮想マシンでローカル・ドライブとファイルシステムを共有できますか？」を御覧ください。

FIREWALL RULES FOR SHARED DRIVES（共有ドライブのファイアウォール・ルール）

ホストマシンと Linux コンテナを実行する仮想マシン間では、ドライブの共有にポート 445 のオープンが必要です。共有ドライブの追加ときに、Docker でポート 445 が閉じられているのを検出したら、以下のメッセージを表示します。

＜図＞

ドライブを共有するには、Windows ファイアウォールやサードパーティ製のファイアウォール・ソフトウェアで、Windows ホストマシンと仮想マシン間での通信を可能にします。ポート 445 以外のネットワークは、一切開く必要がありません。

デフォルトでは、 10.0.75.2 （仮想マシン）から 10.0.75.1 上のポート 445（Windows ホスト）へと通信します。もしもファイアウォールのルールが正しければ、Hyper-V 仮想ネットワーク・カード上のファイルと印刷共有サービスの切り替え又は再インストールが必要になるかもしれません。

SHARED DRIVES ON DEMAND（オンデマンド共有ドライブ）

個々のマウントが必要な場合、初回に "オンデマンド" でドライブを共有できます。

シェルでボリューム・マウント（以下に例があります）する Docker コマンドの実行時や、Compose ファイルで立ち上げ時にボリューム・マウントがあれば、特定のドライブを共有するかどうか訊ねるポップアップが現れます。

Share it （共有する）を選択でき、Docker Desktop の「共有ドライブ一覧」にあるいずれかを、コンテナで利用可能になります。あるいは、共有したくない場合には Cancel （中止）を選べます。

＜図＞

PROXIES（プロキシ）

Docker Desktop は、HTTP/HTTPS プロキシ設定を調整し、自動的に Docker とコンテナに対して情報を伝達（propagate）します。例えば、 http://proxy.example.com に対してプロキシ設定をすると、Docker はコンテナの取得時にこのプロキシを使います。

コンテナが実行中であれば、コンテナ内にプロキシ設定が伝わっているかどうか確認できます。例：

> docker run alpine env

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=b7edf988b2b5
TERM=xterm
HOME=/root
HTTP_PROXY=http://proxy.example.com:3128
http_proxy=http://proxy.example.com:3128
no_proxy=*.local, 169.254/16

こちらの結果では、 HTTP_PROXY 、 http_proxy 、 no_proxy 環境変数が設定されているのが分かります。プロキシ設定を変更した場合は、新しい設定を適用するために、Docker は自動的に再起動します。再起動後もコンテナを実行し続けたい場合には、「再起動ポリシー」の利用を検討すべきでしょう。

NETWORK （ネットワーク）

Docker Desktop のネットワーク機能を、仮想プライベート・ネットワーク（VPN）でも機能するように設定できます。インターネットとの疎通を有効にするには、ネットワーク・アドレス変換（NAT）プリフィックスとサブネットマスクを設定します。

DNS Server （DNS サーバ） : DNS サーバには、動的 IP アドレスか固定 IP アドレスを設定できます。

メモ : 何人かの利用者から、 Docker Desktop の安定バージョンで Docker Hub との通信問題が報告されています。これは docker コマンドの実行を試みるとき、Docker Hub からイメージを未ダウンロードであれば、エラーが確実に発生します。例えば、 docker run hello-world の初回実行時です。このような現象になれば、DNS サーバをリセットし、Google DNS の固定アドレス 8.8.8.8 を指定します。詳しい情報は「ネットワーク機能の問題」にあるトラブルシューティングを御覧ください。

以上の情報の更新するには、設定の変更と Linux VM の再起動が必要です。

Docker Engine （Docker エンジン）

Docker Engine のページでは、Docker デーモンの設定や、どのようにしてコンテナを実行するかを決められます。

デーモンの設定をするには、テキストボックス内に JSON 形式の設定ファイルとして入力します。オプションの一覧については、 Docker Engine dockerd コマンドライン・リファレンス を御覧ください。

Apply & Restart （適用と再起動）をクリックし、設定を保存して Docker Desktop を再起動します。

Command Line （コマンドライン）

コマンドラインのページでは、experimental features（実験的機能）を有効にするかどうかを指定できます。

Docker Desktop Edge と Stable リリースのいずれでも、実験的機能の有効化と無効化を切り替えできます。実験的機能を無効化すると、Docker Desktop は現時点の Docker エンジン安定版リリースを使います。

実験的機能（Experimental Features）

Docker Desktop Edge リリースは、デフォルトで Docker エンジンの実験的なバージョンが有効です。詳細は Git Hub 上の Docker 実験的機能 README（英語） を御覧ください。

実験的機能は、今後提供する機能を先行利用できます。各機能は、テストやフィードバックを意図した、参考程度のものです。そのため、リリース時までに警告が出たり、今後のリリースでは削除されたりする場合があります。本番向けの環境では、実験的機能を決して使わないでください。Docker は実験的機能に対するサポートを提供していません。

Tips: Docker コマンドラインツールで実験的機能を有効にするには、 config.json ファイルを編集し、 experimental を有効化するよう指定します。
Docker Desktop のメニューから実験的機能を有効にするには、 Settings （設定） → Command Line （コマンドライン）をクリックし、 Enable experimental features （実験的機能の有効化）ボタンを押します。 Apply & Restart （適用と再起動）をクリックします。

実験的機能が有効かどうかを確認するには、 docker version を実行します。実験的モードは Server データ下の一覧に状態があります。もしも以下のように Experimental （実験的）が true （真）であれば、Docker は実験的モードで動作しています。

> docker version

Client: Docker Engine - Community
 Version:           19.03.1
 API version:       1.40
 Go version:        go1.12.5
 Git commit:        74b1e89
 Built:             Thu Jul 25 21:17:08 2019
 OS/Arch:           windows/amd64
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          19.03.1
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.5
  Git commit:       74b1e89
  Built:            Thu Jul 25 21:17:52 2019
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          v1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Kubernetes

Docker Desktop には単独の Kubernetes サーバを含みます。Kubernetes は Windows ホスト上で実行できますので、Kubernetes 上に Docker ワークロードを試験的にデプロイできます。

＜図＞

Kubernetes クライアント・コマンドの kubectl が組み込まれており、ローカルの Kubernetes サーバに接続するよう設定済みです。もしも既に kubectl をインストール済みで、 minikube や GKE クラスタのような他の環境を向いている場合は、 kubectl が docker-for-desktop を指し示すように切り替わっているかどうか確認します。

> kubectl config get-contexts
> kubectl config use-context docker-for-desktop

Kubernetes サポートを有効化し、Kubernetes の独立したインスタンスを Docker コンテナとしてインストールするには、 Enable Kubernetes （Kubernetes 有効化）をクリックします。

Kubernetes を デフォルトのオーケストレータ として設定するには、 Deploy Docker Stacks to Kubernetes by default （Docker Stack のデプロイをデフォルトで Kubernetes にする）を選びます。

デフォルトで、Kubernetes コンテナは docker service ls のようなコマンドで非表示です。この理由は、手動での（Kubernetes）管理がサポートされていないからです。これらを表示するには Show system containers (advances) （システムコンテナの表示〔高度〕）を選びます。多くの利用者には不要なオプションです。

Apply & Restart （適用と再起動）をクリックし、設定を保存します。 Kubernetes サーバをコンテナとして実行するために必要なイメージが実体化（インスタンス化）され、 kubectl.exe コマンドがパス上にインストールされます。

  • Kubernetes を有効化して実行している場合は、Docker Desktop 設定ダイアログの右横に、ステータス・バーの追加アイテムを表示します。Docker メニューの Kubernetes のステータスは、作業対象を docker-desktop と表示します。
  • Enable Kubernetes （Kubernetes 有効化）のチェックボックスをクリアしたら、Kubernetes サポートはいつでも無効にできます。無効により、この Kubernetes コンテナを停止及び削除し、 /usr/local/bin/kubectl コマンドも削除します。
  • 全てのスタックと Kubernetes リソースを削除するには、 Reset Kubernetes Cluster （Kubernetes クラスタのリセット）を選びます。
  • 他の方法で kubectl をインストールした場合は、競合が発生し、削除されます。

Docker Desktop で Kubernetes 統合機能を使う詳しい情報は、 Kubernetes 上にデプロイ を御覧ください。

リセット

Troubleshoot （トラブルシュート）のメニュー上から、 Restart Docker Desktop （Dockerデスクトップの再起動）と Reset to factory defaults （初期値にリセットする）オプションを利用できます。詳しい情報は ログとトラブルシューティング を御覧ください。

トラブルシュート

詳細は ログとトラブルシューティング ガイドを御覧ください。

Docker Desktop for Windows フォーラム（英語） にログオンしたら、コミュニティからの手助けを得たり、利用者のトピックを参照したり、議論に参加できます。

GitHub 上の Docker Desktop for Windows issues（英語） にログオンし、バグや問題の報告や、コミュニティに報告された問題を参照できます。

ドキュメントに対するフィードバックの仕方や自分で更新するには ドキュメント貢献（英語） を御覧ください。

Windows と Linux コンテナとの切り替え

Docker Desktop のメニューから、Docker CLI が通信するデーモン（Linux か Windows）を切り替えできます。 Switch to Windows containers （Windows コンテナへ切り替え）を選ぶと Windows コンテナを使います。又は、 Switch to Linux containers （Linux コンテナへ切り替え）を選ぶと Linux コンテナを使います（こちらがデフォルト）。

Windows コンテナに関する詳しい情報は、以下のドキュメントを参照ください（※リンク先はいずれも英語）。

ダッシュボード

Docker Desktop ダッシュボードを通して、マシン上にあるコンテナとアプリケーションを用いる、アプリケーションのライフサイクルと管理をやりとりできます。ダッシュボードの UI を通して見えるのは、全ての実行中、停止中、開始中のコンテナと状態です。直感的なインターフェースを通して、コンテナや Docker Compose アプリケーションに対する調査と管理といった共通動作が行えます。より詳しい情報は、 Docker Desktop Dashboard をご覧ください。

Docker Hub

自分の Docker Hub アカウントにアクセスするには、Docker Desktop のメニューから「Sing in/Create Docker ID」（サインイン/Docker ID 作成）を選びます。一度ログインしておけば、Docker Desktop のメニューから Docker Hub リポジトリに直接アクセス可能になります。

詳しい情報は、以下の Docker Hub 記事（英語） を御覧ください。

二要素認証

Docker Desktop では、Docker Hub へのログインに二要素認証（Two-factor authentication）を有効化できます。二要素認証は Docker Hub アカウントにアクセスするとき、追加のセキュリティ段階を提供します。

Docker Hub での二要素認証を有効化する前に、Docker Desktop を通して Docker Hub アカウントにサインインする必要があります。手順は Docker Hub で二要素認証を有効にする（英語） を御覧ください。

二要素認証を有効化した後、

  1. Docker Desktop のメニューから「 Sign in / Create Docker ID 」を選択。
  2. Docker ID とパスワードを入力し、 Sign in （サインイン）をクリック。
  3. サインインに成功した後、 Docker Desktop で認証コード（authentication code）の入力を求める画面が開きます。電話に届いた6桁のコードを入力し、 Verify （確認）をクリックします。

＜図＞

認証に成功したら、Docker Desktop のメニューから organization やリポジトリにアクセス可能になります。

TLS 証明書の追加

Docker デーモンが、レジストリ・サーバ証明書と クライアント証明書 の検証用に、信頼できる 認証局(CA; Certificate Authorities) を追加してレジストリを認証できます。詳しい情報は FAQ にある 任意の CA 証明書を追加できますか？ と クライアント証明書の追加はどのように行いますか？ を御覧ください。

どのようにしてカスタム CA 証明書を追加できますか？

Docker Desktop は全ての信頼できうる（ルート及び中間）証明局（CA）をサポートしています。証明書が信頼できるルート認証局や中間認証局の配下にあるかどうか、Docker は識別します。

Docker Desktop は Windows 証明局ストアに基づき、全てのユーザが信頼する CAの証明書バンドルを作成します。また、Moby の信頼できる証明書にも適用します。そのため、エンタープライズ SSL 証明書がホスト上のユーザによって信頼されている場合は、Docker Desktop からも信頼されます。

レジストリに対する CA ルート証明書のインストール方法について学ぶには、Docker エンジン記事の 証明書でリポジトリ・クライアントを認証する（英語） を御覧ください。

どのようにしてクライアント証明書を追加しますか？

自分のクライアント証明書を ~/.docker/certs.d/<MyRegistry>:<Port>/client.cert と ~/.docker/certs.d/<MyRegistry>:<Port>/client.key に追加できます。自分の証明書を git コマンドで送信する必要はありません。

Docker Desktop ・アプリケーションの開始時に、 Windows システム上の ~/.docker/certs.d フォルダを Moby 上（Hyper-V 上で稼働する Docker Desktop 仮想マシン）の /etc/docker/certs.d ディレクトリにコピーします。

キーチェーンに対する何らかの変更をするか、 ~/.docker/certs.d ディレクトリ内の変更を有効にするには、 Docker Desktop の再起動が必要です。

レジストリは insecure （安全ではない）レジストリとして表示されません（ Docker デーモン（英語） を御覧ください ）。Docker Desktop は安全ではないレジストリにある証明書を無視します。そして、クライアント証明書も送信しません。 docker run のようなレジストリから取得するコマンドは、コマンドライン上でもレジストリでもエラーになるメッセージが出ます。

認証用にクライアント TLS 証明書を設定する方法を学ぶには、Docker エンジン記事の 証明書でリポジトリ・クライアントを確認する（英語） を御覧ください。

Docker Desktop ・ダッシュボード

Docker Desktop のダッシュボードは、コンテナやアプリケーションの操作や、マシン上のアプリケーションのライフサイクルを直接管理するための、シンプルなインターフェースを提供します。ダッシュボードのユーザ・インターフェースで、実行中や停止中の前コンテナの稼働状態や、実行中であればその状態を表示します。直感的なインターフェースを通して、コンテナを含む Docker オブジェクトと Docker Compose ベースのアプリケーションに対し、調査、アクション、管理するために共通する処理を行います

Docker Desktop ・ダッシュボードは、以下の利点を提供します。

  • GUI は CLI がもたらすコアな情報を抽象化します
  • コンテナの挙動を検索・調査をするために、UI を通してコンテナのログに直接アクセスします
  • Compose アプリケーションを理解するために、 UI を通して連結された Compose ログにアクセスします
  • コンテナによって使用しているポートを、素早く見えるようにします
  • コンテナのリソース使用状況を監視します

加えて、ダッシュボード UI を使って、以下のことを可能にします。

Docker Desktop のダッシュボードにアクセスするには、Docker メニューから Dashboard （ダッシュボード）を選択します。ダッシュボードは、全てのコンテナとアプリケーションの一覧を提供します。

＜図＞

実行中のコンテナとアプリケーションの探索

Docker メニューから、 Dashboard を選択します。ここでは実行中のコンテナとアプリケーションの全リストを表示します。Docker Desktop ・ダッシュボード上に表示されているのは、実行中のコンテナとアプリケーションのみなので御注意ください。

Redis コンテナの開始

Redis コンテナを開始するには、任意の CLI を開き、以下のコマンドを実行します。

docker run -dt redis

これは、新しい Redis コンテナを作成します。Docker メニューから Dashboard を選択し、新しい Redis コンテナを表示します。

＜図＞

サンプル・アプリケションの開始

それでは、サンプル・アプリケーションを実行しましょう。Docker サンプル・ページから サンプル投票アプリ をダウンロードできます。サンプル投票アプリは、複数の Docker コンテナを横断する分散アプリケーションです。

＜図＞

サンプル投票アプリケーションの含むもの：

  • Python か ASP.NET Core によるフロントエンド・ウェブ・アプリケーションを通して、2つの選択肢から投票できます
  • Redis 又は NATS キューは、新しい投票を集めます
  • .NET Core 、 Java 、 .NET Core 2.1 ワーカーは、投票を取り込み保存します
  • Docker ボリューム上の、Postgres か TiDB データベース
  • Node.js や ASP.NET Core SignalR ウェブアプリは、投票結果をリアルタイムで表示します。

アプリケーションを開始するには、CLI でサンプル投票アプリケーションを含むディレクトリに移動し、 docker-compose up --build を実行します。

$ docker-compose up --build
Creating network "example-voting-app-master_front-tier" with the default driver
Creating network "example-voting-app-master_back-tier" with the default driver
Creating volume "example-voting-app-master_db-data" with default driver
Building vote
Step 1/7 : FROM python:2.7-alpine
2.7-alpine: Pulling from library/python
Digest: sha256:d2cc8451e799d4a75819661329ea6e0d3e13b3dadd56420e25fcb8601ff6ba49
Status: Downloaded newer image for python:2.7-alpine
 ---> 1bf48bb21060
Step 2/7 : WORKDIR /app
 ---> Running in 7a6a0c9d8b61
Removing intermediate container 7a6a0c9d8b61
 ---> b1242f3c6d0c
Step 3/7 : ADD requirements.txt /app/requirements.txt
 ---> 0f5d69b65243
Step 4/7 : RUN pip install -r requirements.txt
 ---> Running in 92788dc9d682

...
Successfully built 69da1319c6ce
Successfully tagged example-voting-app-master_worker:latest
Creating example-voting-app-master_vote_1   ... done
Creating example-voting-app-master_result_1 ... done
Creating db                                 ... done
Creating redis                              ... done
Creating example-voting-app-master_worker_1 ... done
Attaching to db, redis, example-voting-app-master_result_1, example-voting-app-master_vote_1, example-voting-app-master_worker_1
...

アプリケーションの実行に成功したら、 Docker メニューから Dashboard を選択し、サンプル投票アプリケーションを見ましょう。アプリケーションを展開し、アプリケーション内で実行中のコンテナを見ます。

＜図＞

これで、ダッシュボード上で実行中のコンテナとアプリケーションの一覧が見られます。それでは、何ができるか見ていきましょう。

  • Port をクリックし、コンテナによって公開されているポートをブラウザで開きます
  • CLI をクリックし、コンテナ上にターミナルを開き、コマンドを実行します
  • Stop 、 Start 、 Restart 、 Delete をクリックし、コンテナのライフサイクルを処理します

Search オプションを使い、特定のオブジェクトを検索します。また、様々なオプションでコンテナやアプリケーションを並び替えできます。 Sort by ドロップ・ダウンで、利用可能なオプションの一覧を表示します。

コンテナやアプリケーションの操作

Docker Desktop ・ダッシュボードから、先ほど起動したサンプル投票アプリケーションを選択します。

application view 一覧から、実行している全アプリケーションのコンテナ一覧と、詳細なログ表示を行います。また、アプリケーションの起動、停止、削除も行えます。

コンテナ名の上にマウスを移動すると、主要な操作可能な機能を表示します。特定のイベントに対するアプリケーションのログを検索するには、下の方にある Search オプションを使います。あるいは、クリップボードにログをコピーするには Copy を選択します。

＜図＞

特定のコンテナに対する詳細情報を指定するには、クリックします。 container view には Logs 、 Inspect 、 Stats タブが表示され、ボタンのクリックで様々なアクションを処理できます。

＜図＞

  • Logs を選択し、コンテナからのログを表示します。また、任意のイベントをログから検索したり、クリップボードにログをコピーしたりできます。
  • Inspect を選択し、コンテナに対するローレベルな情報を表示します。また、ローカルのパスや、イメージのバージョン番号、 SHA-256 、ポート割り当て（マッピング）、その他詳細を確認できます。
  • Stats をクリックし、コンテナのリソース使用率に関する情報を表示します。コンテナによって、たくさんの CPU 、ディスクI/O 、メモリ、ネットワーク I/O が使われているのが見えます。

また、トップバー上にある quick action（クイック・アクション）ボタンを使っても、CLI を開いてコンテナ内でコマンドを実行するような共通操作を行えます。また、コンテナに対する停止、起動、再起動、削除のようなライフサイクルの操作も行えます。

Port をクリックし、コンテナが公開（露出）しているポートをブラウザで開きます。

＜図＞

フィードバック

新しいダッシュボードのユーザーインターフェースについて、皆さんから伺いたいです。あなたのフィードバックをお知らせいただくには、 docker/for-win GitHub リポジトリで issue を作成ください。

Kubernetes 上にデプロイ

Docker デスクチップはスタンドアロン Kubernetes サーバとクライアントを含むだけでなく、Docker コマンドライン・インターフェースと統合しています。 Kubernetes サーバはローカルの Docker インスタンス内で実行します。設定の変更はできず、単一ノードのクラスタです。

ローカルシステム上の Docker コンテナ内で Kubernetes サーバが稼働します。また、用途はローカルでのテストのみです。Kubernetes サポートを有効化したら、Kubernetes 、 Swarm 、そしてスタンドアロン・コンテナを、それぞれ並列にワークロードをデプロイ可能となります。

Kubernetes を有効化し、 Kubernetes 上にワークロードをデプロイするテストを開始するには、 Docker Desktop for Windows > Getting started を御覧ください。

Docker コマンドを使う

docker stack deploy に docker-compose.yml ファイルとスタック名を使い、Kubernetes 上にスタックをデプロイ可能です。

docker stack deploy --compose-file /path/to/docker-compose.yml mystack
docker stack services mystack

デプロイしたサービスは kubectl get services コマンドで表示できます。

namespace（名前空間）の指定

デフォルトでは default namespace （名前空間）が使われます。名前空間は --namespace フラグで指定します。

docker stack deploy --namespace my-app --compose-file /path/to/docker-compose.yml mystack

kubectl get services -n my-app の実行は、 my-app 名前空間にデプロイしているサービスのみ表示します。

デフォルトのオーケストレータを上書き

Kubernetes でテストをしながら、複数のワークロードを swarm モードにデプロイしたい場合があるでしょう。 DOCKER_STACK_ORCHESTRATOR 環境変数を使い、操作中のターミナル・セッションや単一の Docker コマンドで、デフォルトのオーケストレータを上書きします。この環境変数は 設定されていない （デフォルト、この場合はオーケストレータが Kubernetes）か、 swarm 又は kubernetes をセットします。以下はコマンドを実行する前に環境変数を設定し、単一デプロイメント用のオーケストレータを上書きするコマンドです。

set DOCKER_STACK_ORCHESTRATOR=swarm
docker stack deploy --compose-file /path/to/docker-compose.yml mystack

あるいは、デプロイメント向けのデフォルト・オーケストレータをデプロイ時に上書きする場合は、 --orchestrator フラグでも設定できます。

docker stack deploy --orchestrator swarm --compose-file /path/to/docker-compose.yml mystack

メモ : Kubernetes と swarm モードで同じアプリをデプロイすると、ポートやサービス名に競合を引き起こす場合があります。

kubectl コマンドを使う

Windows Kubernetes 統合機能により、Kubernetes CLI コマンドが C:\>Program Files\Docker\Docker\Resources\bin\kubectl.exe に提供されています。この場所はシェルの PATH 変数に入っていない場合があるため、コマンドはフルパスで実行するか、 PATH に追加する必要があります。 kubectl に関する情報は、 公式 kubectl ドキュメント を御覧ください。コマンドのテストは、利用可能なノード一覧の表示で行えます。

kubectl get nodes

NAME                 STATUS    ROLES     AGE       VERSION
docker-for-desktop   Ready     master    3h        v1.8.2

サンプル・アプリケーション

Docker は以下のデモ用アプリケーションを作成しました。 docker stack deploy コマンドを使って swarm モードや Kubernetes にデプロイできます。

version: '3.3'

services:
  web:
    image: dockersamples/k8s-wordsmith-web
    ports:
     - "80:80"

  words:
    image: dockersamples/k8s-wordsmith-api
    deploy:
      replicas: 5
      endpoint_mode: dnsrr
      resources:
        limits:
          memory: 50M
        reservations:
          memory: 50M

  db:
    image: dockersamples/k8s-wordsmith-db

既に Kubernetes YAML ファイルがある場合は、 kubectl コマンドを使ってデプロイできます。

Docker Desktop for Windows のネットワーク構築機能

Docker Desktop は、簡単に利用できるようにする複数のネットワーキング機能を提供します。

機能

VPN パススルー

Docker Desktop のネットワーク構築は、VPN 接続時も動作します。そのためには、あたかも Docker アプリケーションが発信しているかのように、Docker Desktop がコンテナからのトラフィックを取り込み、Windows へ投入します。

ポートマッピング

コンテナに -p 引数を付けて実行します。こちらが実行例です。

$ docker run -p 80:80 -d nginx

Docker Desktop はコンテナ内のポート 80 で実行しているものが何であろうと（この例では nginx ）、 localhost のポート 80 上で利用可能にします。ホスト側で異なるポートを指定するにはどうしたら良いでしょうか。例えば、ホストマシン側でポート 80 上で実行中の何かがある場合、コンテナに対しては別のポートで接続できます。

$ docker run -p 8000:80 -d nginx

これで localhost:8000 への接続が、コンテナ内のポート 80 へ送られます。 -p の構文は ホスト側ポート:クライアント側ポート です。

HTTP/HTTPS プロキシ・セットアップ

プロキシ を御覧ください。

既知の制限、利用例、回避方法

以下で扱うのは、 Docker Desktop for Windows 上のネットワーク構築スタックにおける、現時点での制限の要約と、回避策に対する考え方です。

Windows には docker0 ブリッジがありません

ネットワーク構築機能の実装が、Docker Desktop for Windows 用のため、ホスト側では docker0 インターフェースは見えません。このインターフェースは、実際には仮想マシン内にあります。

コンテナに ping できません

Docker Desktop for Windows は Linux コンテナに対してトラフィックを経路付け（ルーティング）できません。一方で、Windows コンテナに対しては ping ができます。

コンテナごとに IP アドレスを割り当てられません

docker (Linux) ブリッジ・ネットワークは Windows ホストから到達できません。一方で、Windows コンテナでは動作します。

利用例と回避方法

前述の制限に対応する、2つのシナリオがあります。

コンテナからホスト上のサービスに対して接続したい

ホストの IP アドレスは変動します（あるいは、ネットワークへの接続がありません）。18.03 よりも前は、特定の DNS 名 host.docker.internal での接続を推奨していました。これはホスト上で内部の IP アドレスで名前解決します。これは開発用途であり、Docker Desktop for Windows 外の本番環境では動作しません。

また、ゲートウェイに対しては gateway.docker.internal で到達可能です。

Windows からコンテナに対して接続したい

localhost に対するポート転送（port forwarding）が動作します。つまり、 --publish 、 -p 、 -P が全て機能します。Linux からのポート公開（露出）は、ホスト側に転送されます。

現時点で推奨するのは、ポートの公開か、他のコンテナからの接続です。これは Linux 上でも同様ですが、ブリッジ・ネットワークではなくオーバレイ・ネットワーク上にコンテナがある場合、到達（経路付け）できません。

始めましょう で用いた例にある nginx ウェブサーバを表示するには、次のコマンドを使います。

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

構文を明確にしましょう。以下の2つのコマンドは、いずれも同じコンテナのポート 80 をホスト側のポート 8080 に公開するものです。

$ docker run --publish 8000:80 --name webserver nginx

$ docker run -p 8000:80 --name webserver nginx

全ポートを公開するには -P フラグを使います。例えば、以下のコマンドはコンテナを起動し（デタッチド・モードで）、 -P フラグはコンテナが公開する全てのポートを、ホスト側ランダムなポートに対して割り当てます。

$ docker run -d -P --name webserver nginx

docker run で公開するオプションに関する詳細は run コマンドを御覧ください。

Docker Toolbox の移行

このページで説明するのは、Docker Toolbox ディスクイメージや既にあるイメージを Docker Desktop for Windows に移行する方法です。

Docker Toolbox ディスクイメージを Docker Desktop への移行方法

警告 : Docker Toolbox からのディスクイメージ移行は、既存の Docker イメージを上書きします。移行手順では、以前の Docker Toolbox データ全体を含む仮想マシン全体を置き換えます。

  1. qemu をインストールします。 https://cloudbase.it/downloads/qemu-img-win-x64-2_3_0.zip
  2. Docker Desktop for Windows をインストールします。
  3. もしも Docker が起動中であれば停止します。
  4. 現在の Docker 仮想マシン・ディスクを安全な場所の移動します。
mv 'C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks\MobyLinuxVM.vhdx' C:/<any directory>

5.　Toolbox ディスク・イメージを変換します。

qemu-img.exe convert 'C:\Users\<username>\.docker\machine\machines\default\disk.vmdk' -O vhdx -o subformat=dynamic -p 'C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks\MobyLinuxVM.vhdx'

6.　Docker Desktop を（変換したディスクを用いて）再起動します。

Docker Toolbox をアンインストールする方法

Docker Toolbox イメージを移行するかどうかに関わらず、アンインストールを決めるべきでしょう。Toolbox をクリーン・アンインストールする詳細は、 How to uninstall Toolbox を御覧ください。

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

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

トラブルシュート

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

＜図＞

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

  • Restart Docker Desktop （Docker Desktop の再起動）: 選択すると、Docker Desktop を再起動します。
  • Run Diagnostics （診断の開始）: このオプションを選択すると、Docker Desktop 上のあらゆる問題を診断します。診断に関する詳細情報は、 問題の診断、フィードバック送信、GitHub issue の作成 を御覧ください。
  • Reset Kubernetes cluster （Kubernetes クラスタのリセット）: このオプションを選択すると、全てのスタックと Kubernetes リソースを削除します。詳しい情報は [Kubernetes] を御覧ください。
  • Reset to factory defaults （初期値のデフォルトにリセット）: このオプションを選択すると、Docker Desktop の全てのオプションを初期値にリセットし、Docker Desktop が始めてインストールされたのと同じ状態にします。

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

アプリ内診断

発生した問題が、このページ内のドキュメントで解決できない場合は、 GitHub の Docker Desktop for Windows issues や Docker Desktop for Windows forum で、ログデータのトラブルシュートを手助けできるかもしれません。

メニューの Docker アイコン > Troubleshoot を選択します。

＜図＞

Diagnose & Feedback ウインドウが開始されたら、診断情報の収集が始まります。診断情報が取得可能であれば、アップロードするときに必要となる Diagnostic ID を得られます。これは Docker チームとやりとりするときに必須です。私たちの個人データ取り扱いポリシーに関する情報は 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
にあるでしょう。

Powershell で診断の作成とアップロードをするには、次のように実行します。

 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"

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

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

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

ボリューム

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

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

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

現時点における Docker Desktop の実装では、ホストをマウントするボリュームは マイクロソフト SMB プロトコル をベースにしているため、権限を制御する chmod のようなキメ細かなサポートはありません。

また、 FAQ の コンテナのデプロイごとに、必要に応じて共有ボリューム上の権限を変更できますか をご覧いただき、詳しい情報は 御覧 issue の Controlling を御覧ください。

共有ドライブ上で inotify が動作しません

現時点では、 inotify は Docker Desktop 上で動作しません。これが明らかになる例は、アプリケーションがコンテナがマウントしたドライブに対する読み書きが必要な場合です。ファイルシステム上の inotify に頼らず、私たちが推奨するのはフレームワークやプログラミング言語にあるポーリング（polling）機能の使用です。

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

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

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

共有ドライブ（ボリューム）に対してドメインのユーザが権限を持っているかどうか確認

Tip : 共有ドライブが必要になるのは [Linux コンテナ]のボリューム・マウントであり、Windows コンテナでは必要ありません。

共有ドライブに対するアクセス権限は、セットアップをした共有ドライブを使っているユーザ名とパスワードで試みます。もしも共有ドライブをセットアップしたユーザ名と異なるユーザ名で docker コマンドを実行しようとしても、マウントしたボリュームに対するアクセス権限はありません。ボリュームは空になって見えます。

この解決方法は、ドメインのユーザ・アカウントを切り替え、共有ドライブ上の資格情報（クレデンシャル）をリセットします。

以下はこの問題に対処するデバッグ例です。 c ドライブをドメインユーザではなくローカルユーザで共有した場合を考えましょう。ローカルユーザは samstevens 、ドメインユーザは merlin と仮定します。

  1. Windows ドメインユーザ（この例では merlin ）でログインしているかどうかを確認します。
  2. net share c を実行し、 <ホスト名>\<ユーザ名>, FULL でユーザ権限を見ます。
> net share c

Share name        C
Path              C:\
Remark
Maximum users     No limit
Users             SAMSTEVENS
Caching           Caching disabled
Permission        windowsbox\samstevens, FULL

3.　共有を解除するため、以下のコマンドを実行します。

> net share c /delete

4.　共有ドライブのダイアログ を通して、ドライブを再共有し、Windows ドメインユーザ・アカウントの資格情報（クレデンシャル）を与えます。
5. net share c を再度実行します。

> net share c

Share name        C
Path              C:\
Remark
Maximum users     No limit
Users             MERLIN
Caching           Caching disabled
Permission        windowsbox\merlin, FULL

関連項目として、GitHub 上の issue に マウントしたボリュームが、コンテナから空になった（英語） があります。

nobrl オプションを使うホスト上のパスをボリューム・マウントすると、データベースのロックを上書きする

ホスト上のボリューム・マウントを使用すると、データベース・ソフトウェアやオプションの有効化によっては、思いがけない問題に遭遇しがちです。Docker Desktop for Windows はホスト上のパスをマウントするのに SMB/CIFS プロトコル（英語） を使用し、そこを nobrl オプションでマウントしますが、データベース・サーバがロック要求を送信するのを阻害します（docker/for-win#11 、docker/for-win#694 ）。これが確実に発生するのは、ホスト上で共有されているデータベースファイルにコンテナがアクセスするときです。たとえ、ネットワーク越しのデータベース接続問題が解決したとしても、この「アンロック」されていない側面が、データベースの機能性を妨げます（例えば、SQLite の WAL については docker/for-win#1886 に記述）。

可能であれば、ホスト上のネットワーク・パスを共有ドライブとしてボリューム・マウントするのを避け、そのかわりに MobyVM 上をマウントするか、 データ・ボリューム（英語）（名前付きボリューム）か データ・コンテナ（英語） を作成します。
また、Compose ファイル・ドキュメントの service 設定かの volume キー（英語） と ボリューム設定リファレンス（英語） も御覧ください。

ローカルセキュリティポリシーが共有ドライブをブロックし、ログインエラーを発生させます

Docker Desktop for Windows 共有ドライブ が用いる共有ドライブのマウントには、権限が必要です

もしもローカルポリシーが妨げる場合、Docker 上で共有ドライブを有効化しようとしてもエラーになるでしょう。これは Docker 側では解決できないため、この機能を使うための権限が必要です。

こちらはエラーメッセージ例を切り取ったものです。

Logon failure: the user has not been granted the requested logon type at
this computer.

[19:53:26.900][SambaShare     ][Error  ] Unable to mount C drive: mount
error(5): I/O error Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount: mounting //10.0.75.1/C on /c failed: Invalid argument

Docker for Windows issue #98（英語） も御覧ください。

symlinks の制限を理解する

コンテナ間で symlinks は動作します。しかし、コンテナの外で作成した symlinks （例えばホスト上）は動作しません。詳しく学ぶには、 FAQ の symlinks をサポートしますか？ を御覧ください。

予期しない構文エラー（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 をインストールする を御覧ください。インストール後は再起動が必用です。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 を追加するには、仮想化の有効化が必要です。タスクマネージャー上のパフォーマンス・タブをクリックします。

＜図＞

もしも Hyper-V を手動でアンインストールするか、仮想化を無効にしたら、Docker Desktop は起動できません。 Windows 10 Enterprise では Docker for Windows を実行できません（英語） を御覧ください。

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

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

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

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

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

Windows コンテナと Windows サーバー

Windows サーバー上での 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 を確認します。
関連する問題。

GitHub の議論スレッドは Docker for Windows issue 267 です。

ネットワーク機能の課題

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 （設定）メニューからプリフィックスを変更可能です。 設定 以下の ネットワーク 記事を御覧ください。

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

現時点で inotify が Docker Desktop では機能しません

もしも Node.js で nodemon を使っているのであれば、こちらで説明しているフォールバック・プーリング・モードを試すのが、一時的な回避策です： nodemon が node アプリケーションを再起動しません（英語） 。また、GitHub issue の 共有ドライブの inotify が動作しません（英語） も御覧ください。

再起動

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 フォーラム上での他の回避策をお探しください。

FAQ（よくある質問と回答）

Stable と Edge リリース

Docker Desktop の Stable か Edge 版を入手するには、どうしたら良いでしょうか？

Docker Desktop の Stable 又は Edge 版は Docker Hub からダウンロードできます。

インストール手順は Windows に Docker Desktop をインストール を御覧ください。

Docker Desktop の Stable 版と Edge 版の違いは何ですか？

Docker Desktop のコミュニティ版では、2つのダウンロード・チャンネルがあります。

Stable チャンネル は、完全に固められ、テスト済みであり、信頼できるアプリケーションとして、一般的に利用可能な準備が調っているリリースのインストーラを提供します。リリース時期は Docker エンジンのリリースとパッチ（修正版）リリースに同期しています。Stable チャンネルでは、利用状況統計や他のデータを送信するかどうか選択できます。

Edge チャンネル は、開発中の新機能を含むインストーラを提供しますが、必要なテストを十分に行っていません。Docker エンジンの実験的なバージョンを含みます。そのため、Edge バージョンの利用時には、バグ、クラッシュなど問題が発生する可能性があります。しかし、新機能のお試しや経験を得られるチャンスとなり、Docker Desktop の進化に対するフィードバックを提供します。一般的に、Edge リリースは Stable に比べ頻繁にリリースがあります。おおよそ、一ヶ月か一ヶ月おきのリリースです。デフォルトで利用統計情報やクラッシュ報告が送信されます。Edge チャンネルでは、これを無効化するオプションはありません。

Docker Desktop の Stable と Edge 版を切り替えできますか？

はい、Stable と Edge 版を切り替え可能です。Edge リリースで何が新しくなったか試してみた後、Stable に戻って他のことができます。しかしながら、 一度に Docker Desktop をインストールできるバージョンは、１つのみ です。詳しい情報は Stable 及び Edge バージョン間の切り替え を御覧ください。

Docker Desktop のシステム動作条件は何ですか？

システム動作条件に関する情報は、 Docker Desktop Windows システム動作条件 を御覧ください。

実験的機能（experimental features）とは何ですか？

実験的機能とは、今後のプロダクト機能を早期に利用できます。各機能のテストやフィードバックのみを目的としており、今後のリリースでは予告のない変更や、将来的なリリースでは機能全体が削除される場合があります。実験的機能はプロダクション環境で利用すべきではありません。実験的機能に対し、Docker はサポートを提供しません。

Docker CLI で実験的機能を有効にするには、config.json ファイルを編集し、 experimental を enabled（有効）にしてください ** 。
Docker Desktop のメニューから実験的機能を有効にするには、 **Settings （macOS は Preferences ）> Command Line をクリックし、それから Enable experimental features トグルを有効に切り替えます。 Apply & Restart （適用と再起動）をクリックします。

どうしたらいいでしょうか？

リモートの Docker Engine API に接続するには？

Docker クライアントと開発ツール用のために、 Engine API の場所を指定する必要があるでしょう。

Docker Desktop では、Docker Engine は、 名前付きパイプ npipe:////./pipe/docker_engine や TCP ソケット tcp://localhost:2375 では接続できません。

DOCKER_HOST と DOCKER_CERT_PATH 環境変数のセットを指定します（名前付きパイプ、あるいは TCP ソケットを使ういずれの場合でもです）．

Docker Engine API と Docker Desktop for Windows フォーラムのトピック リモート API をどのようにして見つけられますか（英語） も御覧ください。

ホスト上のサービスにコンテナから接続するには？

Windows は変動 IP アドレスを持ちます（あるいは、ネットワーク接続がなければ存在しません）。私たちが推奨するのは host.docker.internal という特別な DNS 名での接続です。これはホストによって使われる内部の IP アドレスを名前解決します。これは開発用途であり、Docker Desktop for Windows 以外のプロダクション環境では動作しません。

また、ゲートウェイには gateway.docker.internal で到達できます。

Docker Desktop for Windows のネットワーク機能についての情報は ネットワーク機能 を御覧ください。

Windows からコンテナに接続するには？

私たちが推奨するのはポートの公開か、他のコンテナからの接続です。コンテナがオーバレイ・ネットワークを使う場合は、Linux と同じような手法が使えますが、ブリッジ・ネットワークの場合は経路付け（ルーティング）されず使えません。

詳細な情報と例は、 ネットワーク機能 の記事にある Windowsからコンテナに接続したい を御覧ください。

ボリューム

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

いいえ、現時点では、Docker Desktop はデプロイしたコンテナで 共有ボリューム 上で Unix 風の権限を制御（ chmod ）できません。それどころか、権限をデフォルトで 0777 の値（ user と group に対する「読み込み」「書き込み」「実行」の権限 ）に設定し、変更不可能です。

回避策を学ぶには 共有ボリュームのデータ・ディレクトリ上における権限エラー を御覧ください。

symlink をサポートしますか？

Docker Desktop はコンテナ内で作成したシンボリック・リンク ( symlinks ) をサポートします。 シンボリック・リンクはコンテナ間でも動作します。ただし、Docker の外で作成したシンボリック・リンクは動作しません。

この制限の理由に関する情報を知るには、以下の議論を御覧ください。

証明書

任意の CA 証明書を追加可能ですか？

Docker Desktop は全ての信頼できる（ルート及び中間の）認証局（CA）をサポートしています。Docker は信頼できるルート認証局や中間認証局以下に保管されている証明書を認識します。

サーバとクライアント側証明書の追加に関する情報は、めましょうの記事にある TLS 証明書の追加 を御覧ください。

クライアント証明書の追加はどのように行いますか？

クライアント証明書の追加に関する情報は、始めましょうの記事にある TLS証明書の追加 を御覧ください

コンテナに USB デバイスをパス・スルーできますか？

残念ながら、コンテナに対する USB デバイスのパス・スルーはできません。これは、ハイパーバイザ段階でのサポートが必要だからです。

ネストした仮想化環境で Docker Desktop を実行できますか？

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

VirtualBox と Docker Desktop を併用できますか？

残念ながら、Windows では Hyper-V を有効化しますと、VirtualBox を（及び VMware のような他のハイパーバイザでも）実行できません。

Windows 動作条件

Windows Server 上の Docker Desktop で Windows コンテナを実行できますか？

Windows Server 上で Windows コンテナを実行するためのチュートリアルが、 Windows コンテナを始めましょう にあります。

どうして Windows 10 Home はサポート外なのですか？

Docker Desktop は Hyper-V 機能が必要であり、これは Windows Home ディションでは利用できません。

どうして Windows 10 が必要なのですか？

Docker Desktop は Windows Hyper-V 機能を使います。Windows の古いバージョンでも Hyper-V はありますが、それらの Hyper-V には Docker Desktop を動作するために必要な機能が欠如しています。

アンチウィルス・ソフトウェアをインストールしていると、Docker Desktop の起動に失敗するのはなぜでしょうか？

いくつかのアンチウィルス・ソフトウェアは、Hyper-V と Windows 10 ビルドと互換性がなく、Docker Desktop に影響があります。詳しい情報は トラブルシューティング の アンチウィルス・ソフトウェアをインストールしていると,
Docker Desktop の起動に失敗する を御覧ください。

フィードバック

どのような種類のフィードバックが求められていますか？

全てが対象です。私たちはダウンロード、インストール手順、起動、利用可能な機能、GUI、アプリケーションの使いやすさ、コマンドライン統合、などなど、皆さんの所感を求めています。問題があれば、何をしたいのか、どのような機能が欲しいのかを教えてください。

問題や質問がある場合は、どうしたら良いでしょうか？

診断やトラブルシューティングに関する共通課題の情報は、 ログとトラブルシューティング の記事にあります。

トラブルシューティングで解決策が見つからなければ、 GitHub の Docker Desktop for Windows の issue を見るか、新しい issue を作成してください。また、診断結果に基づいて新しい issue の作成もできます。詳細を学ぶには 問題の診断、フィードバック送信、GitHub issue の作成 を御覧ください。

Docker Desktop for Windows フォーラム には議論のスレッドがあります。そちらでも議論のトピックを作成できますが、私たちが推奨するのはフォーラムではなく GitHub issue を使う方が、追跡可能かつ反応も良いです。

私の利用統計データの送信を停止できますか？

利用統計データの送信を行いたくなければ、 Stable チャンネルを御利用ください。詳しい情報については、 Docker Desktop の Stable と Edge 版の違いは何ですか を御覧ください。

Docker Desktop での個人データの取り扱いはどのようになっていますか？

アップロードされた診断情報は、Docker の問題調査に役立ちますが、ユーザ名や IP アドレスなど個人情報がアップロードされる診断データに含まれる場合があります。診断データにアクセス可能なのは、Docker Desktop の問題を直接解析する Docker, Inc. の従業員のみです。

docker/for-mac や docker/for-win の issue トラッカーで、オープンになっていても参照の必要がなければ、Docker, Inc. はアップロードされた診断情報を通常 30 日で削除します。もし issue がクローズされれば、Docker, Inc. は参照された診断情報を 30 日以内に削除します。また、診断 ID かGitHub ID（診断 ID が GitHub issue で使われている場合は）のどちらかで、診断情報の削除要求が可能です。 Docker, Inc. は診断情報のデータを、特定のユーザに対する調査にのみ用いますが、そこから発生する頻度などハイレベル（個人に依存しない）なメトリクスを得る場合もあります。

オープンソース・ライセンス

Docker Desktop エディションはオープンソース・ソフトウェアを用いて構築されています。ライセンスに関する詳細は、 Docker の鯨アイコン → About Docker を選択し、アプリケーション内の Acknowledgements （謝辞）をクリックします。

Docker Desktop エディションは、 GNU General Public License 以下でライセンスされた複数のコンポーネントを配布します。各コンポーネントに関するソースは こちら からダウンロードできます。

qemu-img のソースは こちら から得られます。 qemu-img が必要とする gettext と glib ライブラリは Homebrew から得られ、 brew install --build-from-source gettext glib からも得られます。

Stable リリースノート

Edge リリースノート

Docker Desktop WSL 2 バックエンド

新しい Docker Desktop WSL 2 バックエンドは、Docker Desktop WSL 2 Tech Preview の後を継ぐものです。WSL2 バックエンド・アーキテクチャは Kubernetes 向けのサポートを導入し、更新版 Docker デーモンの提供、VPN と親和性のあるネットワーク機能や追加機能を提供します。WSL 2 は構造上の著しい変更をもたらします。Microsoft によってビルドされた完全な Linux カーネルによって、エミュレーションではなく、ネイティブに Linux コンテナを実行可能になります。WSL 2 上で Docker Desktop を実行しますと、利用者は Linux ワークスペースを活用できるようになり、また、ビルド用スクリプトは Windows 用と Linux 用との両方を準備する必要がなくなります。

また、Docker Desktop は WSL 2 で導入された動的メモリ割り当て機能も活用できるため、リソースの消費を著しく改善します。つまり、Docker Desktop は、コンテナのビルドのような CPU とメモリを大量に必要とするタスクでも、 CPU とメモリを必要量しか使わないため、より速く実行できます。

さらに、WSL 2 はDocker デーモンのコールド・スタート後は、起動に必要な時間が著しく早くなります。Docker デーモンの起動に、現在の Docker Desktop のバージョンでは数十秒かかるのと比べ、2秒以下です。

動作条件

Docker Desktop WSL 2 バックエンドをインストールする前に、以下の手順を完了している必要があります。

  1. Windows 10, version 2004 以上をインストール。
  2. Windows 上での WSL2 機能の有効化。詳細手順は マイクロソフトのドキュメント を参照ください。
  3. Linux カーネル更新パッケージ のダウンロードとインストール

ダウンロード

Docker Desktop stable 2.3.0.2 以上のリリースをダウンロード。

インストール

Docker Desktop Stable 2.3.0.2 リリースをインストールする 前に 、動作条件のセクションで説明した手順を必ず終えてください。

  1. 通常の Docker Desktop の手順に従って、Docker Desktop をインストールします。
  2. Windows スタート・メニューから Docker Desktop をスタートします。
  3. Docker メニューから、 Settings > General を選択します。 ＜図＞
  4. User WSL 2 based engine （WSL2 対応エンジンを使う） のチェックボックスを選択します。WSL 2 をサポートしているシステム上に Docker Desktop をインストールした場合は、デフォルトでこのオプションが有効化されています。
  5. **Apply & Restart* （適用と再起動）をクリックします。
  6. ディストリビューションが WSL2 モードで動作しているかどうかを確認します。WSL はディストリビューションの v1 と v2 モードのどちらでも動作します。

WSL モードの確認は、次のように実行します。

wsl -l -v

v2 にアップグレードするには、次のように実行します。

wsl --set-version <ディストリビューション名> 2

7.　Docker Desktop を再起動したら、 Settings > Resources > WSL Integration に移動し、Docker でアクセスしたい WSL 2 ディストリビューションを選択します。

WSL 統合によって、デフォルトの WSL ディストリビューションが有効化されます。このデフォルトの WSL ディストリビューションを変更するには wsl --set-default <ディストリビューション名> を実行します。

たとえば、デフォルト WSL ディストリビューションを Ubuntu に設定するには、 wsl --set-default ubuntu を実行します。

オプションの項目から、WSL 2 上で有効化したい追加ディストリビューションを選択できます。

＜図＞

8.　変更を有効にするには Apply & Restart をクリックします。

Docker と WSL 2 で開発

以下のセクションでは、Docker と WSL 2 を用いたアプリケーション開発のはじめかた説明します。私たちの推奨は、皆さんのデフォルト Linux ディストリビューションにコードを入れる方法が、Docker と WSL 2 バックエンドを用いた開発体験にベストです。Docker Desktop で WSL 2 を有効化した後は、Linux ディストリビューションの中でコードが動き始めるので、Windows 上でありながら理想的な IDE（統合開発環境）となるでしょう。VSCode を使えば、 このワークフローはより洗練されるでしょう。

1.　VSCode を開き、 Remote - WSL エクステンションをインストールします。この拡張機能によって、Windows 上にある Linux ディストリビューションをリモート・サーバとして動かすことができ、Windows 上の IDE クライアントになります。
2.　次に、VSCode をリモートで動作するようにします。そのためには、ターミナルを開き、次のように実行します。

wsl
code .

これにより新しい VSCode のリモート接続先が、スクリーン上で下の端でチェックしている、デフォルトの Linux ディストリビューションになります。
あるいは、スタートメニューからデフォルトの Linux ディストリビューション名を入力し、開き、 code を実行します。

3.　VSCode 内であれば、VSCode のターミナルを使って、Windows マシンからコードを取得し、ネイティヴに動かせられます。

ベストプラクティス

  • ファイルのマウント（bind-mount）時に最高のシステムパフォーマンスを得るために：
    • Linux コンテナ内にソースコードや他のデータを入れるには、Windows ファイルシステムよりも、Linux ファイルシステムでバインド・マウント（bind-mount）を使う（例、 docker run -v <ホスト側パス>:<コンテナ側パス>）。
    • オリジナルのファイルが Linux ファイルシステム内にあれば、Linux コンテナはファイル変更イベント（ "inotify events" ）のみ受け取る
    • Windows ホストからリモート操作するより、Linux ファイルシステム上でファイルをバインド・マウントするほうが、パフォーマンスがより優れる。つまり docker run -v /mnt/c/users:/users を避ける（ /mnt/c は Windows からマウントしている場所 ）。
    • そのかわりに、 コマンドラインで docker run -v ~/my-project:/sources <自分のイメージ> のようなコマンドをシェルで用いると、 ~ にあたる場所は Linux シェルによって $HOME に展開される。
  • docker-desktop-data VHDX の容量についての懸念や、変更の必要があれば、 [Windows に組み込まれた WSL ツール]　(https://docs.microsoft.com/ja-jp/windows/wsl/compare-versions#understanding-wsl-2-uses-a-vhd-and-what-to-do-if-you-reach-its-max-size) を参照
  • CPU やメモリ使用量に関する懸念があれば、 WSL 2 ユーティリティ VM に割り当て可能な メモリ、CPU 、スワップサイズにし慧玄を設ける
  • Docker Desktop 上の WSL 2 を用いることで、競合する可能性を避けるためには、Docker Desktop を通して Linux ディストリビューションを直接インストールする前に、古いバージョンの Docker Engine および CLI のアンインストールが必須

原文

Apache License 2.0
https://github.com/docker/docker.github.io/blob/master/LICENSE

Thanks to all Docker developers and contributors and Docker, inc., and you.

176
224
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
176
224