Docker Desktop for Mac（参考訳）

Docker Desktop for Mac

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

注記

こちらのページの内容を修正し、ページ間でリンクを張り直した情報は、こちらをご覧ください。

• Docker for Mac を始めよう — Docker-docs-ja 19.03 ドキュメント
  • http://docs.docker.jp/docker-for-mac/

目次

• Mac に Docker Desktop をインストール
• Docker for Mac を始めよう
• Kubernetes 上にデプロイ
• Docker Desktop for Mac 対 Docker Toolbox
• マルチ CPU アーキテクチャのサポートを活用
• ネットワーク構築機能
• ファイルシステム共有
• ボリューム・マウント（共有ファイルシステム）のパフォーマンス・チューニング
• ディスク使用量
• ログとトラブルシューティング
• FAQ

Mac に Docker Desktop をインストール

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

• Docker Hub からダウンロード

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

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

注意： Docker Toolbox と Docker Machine ユーザは一番初めにお読みください
既にマシン上で Docker を実行中の場合は、最初に Docker Desktop for Mac 対 Docker Toolbox のドキュメントをご覧ください。こちらには、既存の環境にセットアップする時の影響、Docker Desktop on Mac をどのようにセットアップするか、両者を共存する方法があります。

Docker Machine への影響 ： Docker desktop を Mac にインストールしても、既に作成している Docker Machine には影響を与えません。オプションで、ローカルの default （という名称の） Docker Machine （存在している場合）から、コンテナをイメージを Docker Desktop HyperKit VM にコピーできます。Docker Desktop を起動したら、Docker Machine ノードをローカルで（あるいは、どこでも）実行する必要はありません。Docker Desktop があれば、VirtualBox システムを置き換えるので、新しいネイティブな仮想化システム（HyperKit）を実行します。詳細を学ぶには、 Docker Desktop for Mac 対 Docker Toolbox をご覧ください。

システム要件

Docker Desktop を正しくインストールするには、Mac が以下の要件を満たす必要があります。

• Mac ハードウェアは 2010 年モデルか、それ以降の必要があります 。ハードウェアには、インテルのメモリ管理ユニット（MMU）仮想化のハードウェアサポート、EPT（Extended Page Tables）、Unrestricted モードを含みます。マシンがこれらをサポートしチエルかどうか調べたいときは、ターミナル上で以下のコマンドを実行して確認できます：sysctl kern.hv_support 。もしも Mac がハイパーバイザ・フレームワークをサポートしていれば、コマンドの実行結果に kern.hv_support: 1 が表示されます。
• macOS は 10.13 または、それ以降の必要があります 。つまり Catalina、Mojave、High Sierra です。私たちは macOS の最新版へのアップグレードを推奨します。macOS をバージョン 10.05 にアップグレードして何らかの問題が出るようであれば、その macOS のバージョンと互換性がある最新の Docker Desktop のインストールが必要です。 メモ： Docker がサポートしている Docker Desktop は、最新バージョンの macOS です。言い換えれば、現在リリースされている macOS と、直前の2つのリリースです。Docker Desktop が現在サポートするのは、 macOS Catalina、macOS Mojave、macOS High Sierra です。macOS の新しいメジャーバージョンが利用可能になれば、 Docker は最も古いバージョンのサポートを終了し、最も新しいバージョンの macOS （と、直近の2つのリリース）をサポートします。
• 最小 4GB の RAM
• VirtualBox バージョン 4.3.3 以前は、Docker Desktop と互換性がないのでインストールしてはいけません。

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

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

Mac に Docker Desktop をインストールして動かす

1.　Docker.dmg をダブルクリックし、インストーラを起動します。もしもまだインストーラ（ Docker Desktop Installer.exe ）をダウンロードしていなければ、 Docker Hub から取得できます。ダウンロードは通常「ダウンロード」フォルダ内か、ウェブブラウザ上のダウンロード・バーに表示される最近ダウンロードした場所です。

＜図＞

2.　アプリケーション・フォルダ内にある Docker.app をダブルクリックし、 Docker を起動します（下図では、アプリケーション・フォルダは「グリッド」表示モードです）。

＜図＞

トップステータスバーにある Docker メニューで、Docker Desktop が実行中で、ターミナルからアクセスできるのが分かります。

＜図＞

アプリのインストールが完了したら、Docker Desktop はオンボーディング（導入）・チュートリアルを開始します。チュートリアルには Docker イメージを構築、実行し、Docker Hub にイメージを送信するまでの例を含みます。

＜図＞

3.　Docker メニュー（鯨のアイコン）をクリックし、 Preferences （設定）と他のオプションをご覧ください。
4.　About Docker （Docker について）を選択し、最新バージョンであることを確認します。

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

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

Docker Desktop のアンインストール

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

1. Docker メニューから Troubleshoot （トラブルシュート）を選択し、 Uninstall （アンインストール）を選択します。
2. 確認画面で、Uninstall をクリックします。

メモ : 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 Mac を始めよう

Docker Desktop へようこそ！

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

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

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

バージョンの確認

docker と docker-compose が更新され、 Docker.app と互換性があるバージョンかどうか確認しましょう。異なるバージョンを実行していれば、以下のような表示とは異なるでしょう。

$ docker --version
Docker version 19.03, build c97c6d6

アプリケーションの探索

1.　コマンドライン・ターミナルを開き、シンプルな Docker イメージ hello-world を実行し、インストールが正常に終わったかどうかを確認します。

$ docker run hello-world

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
ca4f61b1923c: Pull complete
Digest: sha256:ca0eeb6fb05351dfc8759c20733c91def84cb8007aa89a5bf606bc8b315b9fc7
Status: Downloaded newer image for hello-world:latest

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

2.　Docker 化したウェブサーバを開始します。先ほどの hello-worldイメージのように、もしもイメージがローカルで見つからなければ、Docker は Docker Hub から取得します。

$ docker run --detach --publish=80:80 --name=webserver nginx

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

＜図＞

初期のベータ・リリースでは docker をビルドした URL のホストとして利用できました。現在では、ポートは仮想マシンのプライベートな IP アドレス上に公開され、 localhost に対して転送されるもので、その他のホスト名は使いません。

4.　詳細を確認（ docker container ls または docker ps ）すると、ウェブサーバが実行中（ running ）と分かります。

$ docker container ls
CONTAINER ID   IMAGE   COMMAND                  CREATED              STATUS              PORTS                         NAMES
56f433965490   nginx   "nginx -g 'daemon off"   About a minute ago   Up About a minute   0.0.0.0:80->80/tcp, 443/tcp   webserver

5.　以下のコマンドを実行し、コンテナの停止とイメージを削除します。停止したコンテナを確認するには、 "all" （すべて）フラグ（ --all または -a）を使います。

$ docker container ls
$ docker container stop webserver
$ docker container ls -a
$ docker container rm webserver
$ docker image ls
$ docker image rm nginx

Preferences （設定）

メニューバーの Docker メニュー（鯨アイコン） > Preference （設定）を選択すると、以下で説明している実行時のオプションを調整できます。

＜図＞

General（一般的な設定）

<図＞

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

• Start Docker when you log in - セッションの開始時、自動的に Docker Desktop を起動します。
• Automatically check for updates - デフォルトでは、Docker Desktop は自動的に更新を確認し、更新版が利用可能な場合は通知します。承諾して更新版をインストールするには OK をクリックします（あるいは、現在のバージョンを維持する場合は、キャンセルします）。メインの Docker メニューから Check for Updates （更新を確認）で、手動での更新ができます。
• Include VM in Time Machine backups （タイムマシン・バックアップに仮想マシンを含める） - このオプションを選択すると、Docker Desktop 仮想マシンをバックアップします。このオプションは、デフォルトでは無効です。
• Securely store Docker logins in macOS keychain （macOS キーチェーンに Docker ログイン情報を安全に保管） - Docker Desktop は、Docker login 認証情報を macOS キーチェーンにデフォルトで保存します。
• Send usage statics - デフォルトでは、Docker Desktop は診断情報・クラッシュ報告・利用データを送信します。この情報は、 Docker の改善やアプリケーションの問題解決に役立ちます。止めるにはチェックボックスを空にします。Docker は定期的に更なる情報を訊ねるかもしれません。

Switch to the Edge version （Edge バージョンの切り替え）をクリックすると、Docker Desktop Edge リリースに関する情報を学べます。

Resources（リソース）

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

ADVANCED（高度な設定）

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

＜図＞

Advanced 設定とは、

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

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

FILE SHARING（ファイル共有）

Linux コンテナと共有したいローカルのディレクトリを選択します。これはホスト上の IDE を用い、コンテナ内でコードの実行やテストをしている場合、ソースコードの編集に特に役立ちます。デフォルトでは /Users 、 /Volume 、/private 、 /tmp 、/var/folders ディレクトリが共有されます。プロジェクトがこのディレクトリ外であれば、必ずこのリストに追加する必要があります。そうしなければ、 Mounts denied （マウント拒否）や cannot start serice （サービスを開始できない）エラーが実行時に出るでしょう。

ファイル共有を設定するには：

• ディレクトリの追加 : + をクリックし、追加したいディレクトリを選択します。
• Apply & Restart （適用と再起動）によって、対象ディレクトリが Docker のバインド・マウント（ -v ）機能で利用できるようになります。

共有可能なディレクトリ上では、いくつかの制限があります：

• ディレクトリは Docker の内部に存在していてはいけません。

詳しい情報は、こちらをご覧ください。

• osxfs file system sharing の [Namespaces] のトピック内
• Volume mounting requires file sharing for any project directories outside of /Users .

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）プリフィックスとサブネットマスクを設定します。

Docker Engine （Docker エンジン）

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

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

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

Command Line （コマンドライン）

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

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

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

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

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

実験的機能が有効かどうかを確認するには、 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 は Mac ホスト上で実行できますので、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 上にデプロイ を御覧ください。

リセット

リセットと再起動オプション
Docker Desktop Mac では、 Troubleshoot （トラブルシュート）のメニュー上から、 Restart Docker Desktop （Dockerデスクトップの再起動）と Reset to factory defaults （初期値にリセットする）オプションを利用できます。

詳しい情報は [ログとトラブルシューティング]を御覧ください。

ダッシュボード

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

TLS 証明書の追加

Docker デーモンが、レジストリ・サーバ証明書と クライアント証明書 の検証用に、信頼できる 認証局(CA; Certificate Authorities) を追加してレジストリを認証できます。

カスタム CA 証明書の追加（サーバ側）

全ての信頼できうる（ルート及び中間）証明局（CA）をサポートしています。Docker Desktop は Mac キーチェーン上にある全ての信頼できうる証明局の情報に基づき、全てのユーザが信頼する CAの証明書バンドルを作成します。また、Moby の信頼できる証明書にも適用します。そのため、エンタープライズ SSL 証明書がホスト上のユーザによって信頼されている場合は、Docker Desktop からも信頼されます。

任意の、自己証明した証明書を主導で追加するには、macOS キーチェン上に証明書を追加し、Docker Desktop が扱えるようにします。以下は例です：

$ sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ca.crt

あるいは、（全てのユーザに対してではなく）自身のローカルキーチェーンのみ追加したい場合は、代わりにこちらのコマンドを実行します。

$ security add-trusted-cert -d -r trustRoot -k ~/Library/Keychains/login.keychain ca.crt

あるいはまた、 Directory structures for certificates をご覧ください。

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

以上の設定方法に関する完全な説明は Adding Self-signed Registry Certs to Docker & Docker Desktop for Mac のブログ投稿をご覧ください。

クライアント証明書の追加

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

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

• キーチェーンに対する何らかの変更をするか、 ~/.docker/certs.d ディレクトリ内の変更を有効にするには、 Docker Desktop の再起動が必要です。
• レジストリは insecure （安全ではない）レジストリとして表示されません（ Docker デーモン（英語） を御覧ください ）。Docker Desktop は安全ではないレジストリにある証明書を無視します。そして、クライアント証明書も送信しません。 docker run のようなレジストリから取得するコマンドは、コマンドライン上でもレジストリでもエラーになるメッセージが出ます。

認証情報のディレクトリ構造

次のディレクトリ構造の場合、Mac OS システムログインのため、CA 証明書を手動で追加する必要はありません。

/Users/<user>/.docker/certs.d/
└── <MyRegistry>:<Port>
   ├── ca.crt
   ├── client.cert
   └── client.key

以下は、カスタム証明書を設定例と説明を追加したものです：

/etc/docker/certs.d/        <-- 証明書のディレクトリ
└── localhost:5000          <-- ホスト名:ポート番号
   ├── client.cert          <-- クライアント証明書
   ├── client.key           <-- クライアント鍵
   └── ca.crt               <-- 証明機関によって署名されたレジストリ証明書

あるいは、CA 証明書が自分のキーチェンにあれば、次のようなディレクトリ構造にもできます。

/Users/<user>/.docker/certs.d/
└── <MyRegistry>:<Port>
    ├── client.cert
    └── client.key

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

シェル補完のインストール

Docker Desktop には、 docker と docker-compose のコマンド補完を有効化するスクリプトがあります。補完スクリプトは Docker.app 内の Contents/Resources/etc ディレクトリ内にあり、 Bash と Zsh の両方にインストールできます。

Bash

Bash は 補完のサポートを内蔵 しています。Docker コマンドの補完をできるようにするには、 bash_completion.d/ ディレクトリ内に各ファイルをコピーしたり symlink を作成必要があります。たとえば、 Homebrew 経由で bash をインストール。

etc=/Applications/Docker.app/Contents/Resources/etc
ln -s $etc/docker.bash-completion $(brew --prefix)/etc/bash_completion.d/docker
ln -s $etc/docker-compose.bash-completion $(brew --prefix)/etc/bash_completion.d/docker-compose

以下を自分の ~/.bash_profile に追加します：

[ -f /usr/local/etc/bash_completion ] && . /usr/local/etc/bash_completion

または

if [ -f $(brew --prefix)/etc/bash_completion ]; then
. $(brew --prefix)/etc/bash_completion
fi

Zsh

Zsh では、 補完システム の管理が必要です。Docker コマンドに対する補完を有効化するには、自分の Zsh site-functions/ ディレクトリに各ファイルをコピーするか symlink する必要があります。以下は Homebrew を経由して Zsh をインストールします：

etc=/Applications/Docker.app/Contents/Resources/etc
ln -s $etc/docker.zsh-completion /usr/local/share/zsh/site-functions/_docker
ln -s $etc/docker-compose.zsh-completion /usr/local/share/zsh/site-functions/_docker-compose

Fish-Shell

Fish-shell もまた、タブ補完による 補完システム をサポートしています。Docker コマンドに対する補完を有効化するには、各ファイルを自分の Fish-shell の completions ディレクトリにコピーするか symlink する必要があります。

completions ディレクトリを作成します：

mkdir -p ~/.config/fish/completions

次に docker から fish completions を追加します。

ln -shi /Applications/Docker.app/Contents/Resources/etc/docker.fish-completion ~/.config/fish/completions/docker.fish
ln -shi /Applications/Docker.app/Contents/Resources/etc/docker-compose.fish-completion ~/.config/fish/completions/docker-compose.fish

フィードバックやヘルプを得るには

コミュニティからのヘルプを得たり、現在のユーザートピックを見たり、ディスカッションに参加・開始するには Docker Desktop for Mac forum にログオンください。

バグや問題の報告をするには、 GitHub の Mac issues にログオンし、そこでコミュニティに報告された報告を見たり、新しい課題を追加できます。詳細は [ログとトラブルシューティング] をご覧ください。

Docker Hub

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

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

• Organizations and Teams in Docker Hub
• Builds and Images

二要素認証

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 やリポジトリにアクセス可能になります。

Kubernetes 上にデプロイ

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

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

Kubernetes を有効化し、 Kubernetes 上にワークロードをデプロイするテストを開始するには、 [Docker Desktop for Mac > 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 Mac 対 Docker Toolbox

既に Docker Toolbox をインストール済みの場合は、最初にこのトピックを読み、Docker Desktop on Mac と Docker Toolbox の違いを学び、どのようにして共存するかを学びます。

Docker Toolbox 環境

Docker Toolbox は Mac 上の /usr/local/bin に、 docker 、 docker-compose 、 docker-machine をインストールします。また、 VirtualBox もインストールします。インストール時に、 Toolbox は docker-machine で default という名前の VirtualBox 仮想マシンをプロビジョン（自動構築）し、 boot2docker Linux ディストリビューション上で Docker Engine を実行し、Docker Engine が使う証明書を $HOME/.docker/machine/machines/default に置きます。

Mac 上で docker や docker-compose を使う前に、 eval $(docker-machine env default) のような典型的なコマンドを使い、 docker や docker-compose が VirtualBox 上で実行している Docker Engine と通信するために必要な環境変数を指定します。

セットアップすると下図のようになります。

＜図＞

Docker Desktop on Mac 環境

Docker Desktop on Mac は、 /Applications にインストールする Mac ネイティブのアプリケーションです。インストール時に /Applications/Docker.app/Contents/Resources/bin から /usr/local/bin へ docker と docker-compose 等のシンボリックリンクを作成し、様々なコマンドを実行できるようにします。

以下は、 Docker Desktop on Mac を使い始める前に知っておく重要なポイントです：

• Docker Desktop は VirtualBox の代わりに HyperKit を使います。Hyperkit は軽量な macOS 仮想化ソリューションであり、 macOS 10.10 Yosemite 以降の Hypervisor.framework 上で構築されています。
• Docker Desktop on Mac をインストールしても、Docker Machine で作成したマシンは影響を受けません。
• Docker Desktop は仮想マシンのプロビジョンに docker-machine を使いません。Docker Engine API は Mac ホスト上の /var/run/docker.sock に露出しているソケットで利用できます。これは Docker と Docker Compose クライアントが Docker デーモンと通信するためのデフォルトの場所です。つまり、 docker と docker-compose CLI コマンドが Mac 上で使えます。

セットアップすると下図のようになります。

＜図＞

Docker Desktop on Mac では、得られるのは1つの仮想マシン（通常必要なのは1つ）です。この仮想マシンは Docker Desktop によって管理されます。Docker Desktop は更新が利用出来るようになれば、自動的に Docker クライアントとデーモンを自動的に更新します。

また、Docker Desktop はコンテナに対するトラフィックは径路付け（route）できないので注意してください。つまり、ホストマシン上で実行しているコンテナが公開しているポートに、直接アクセスできません。

複数のノードの swarm のような、複数の仮想マシンが必要な場合は、Docker Machine を利用し続けられます。Docker Machine は Docker Desktop が操作する範囲外です。詳細は Docker Toolbox と Docker Desktop の共存をご覧ください。

Docker Deskto on Mac を動かすためのセットアップ

1.　どこで Toolbox の DOCKER 環境変数が指定されているか確認します。

$ env | grep DOCKER
DOCKER_HOST=tcp://192.168.99.100:2376
DOCKER_MACHINE_NAME=default
DOCKER_TLS_VERIFY=1
DOCKER_CERT_PATH=/Users/<your_username>/.docker/machine/machines/default

コマンドを実行しても出力が何もなければ、既に Docker Desktop を利用する準備が整っています。

もし（上の例のように）出力があれば、 DOCKER 環境園数を無効化し（次のステップ）、 Docker Desktop エンジンとクライアントが通信できるようにします。

2.　 シェル上で DOCKER 環境変数を無効化（unset）するために、以下の unset コマンドを実行します。

unset DOCKER_TLS_VERIFY
unset DOCKER_CERT_PATH
unset DOCKER_MACHINE_NAME
unset DOCKER_HOST

それから、次のコマンドを実行しても、何も出力がないのを確認します。

$ env | grep DOCKER

Bash シェルを使っている場合は、unset ${!DOCKER_*} を使い、全ての DOCKER 環境変数を一度で無効化できます。（これは zsh のような他のシェルでは動作しません。すなわち、環境変数を１つ１つ無効化する必要があります）

メモ ：コマンド画面を開くとき、自動でシェルスクリプトの profile ファイルの一部で各 DOCKER 環境変数を読み込んでいる場合、Docker Desktop を使いたい時には都度それぞれの環境変数を無効化する必要があります。

警告 ： Docker Toolbox がインストール済みのマシンに Docker Desktop をインストールすると...
Docker Desktop は /usr/local/bin にある docker と docker-compose コマンドラインのシンボリックリンクを、Docker Desktop のものへ書き換えます。

Docker Machine トピックにある Unset environment variables in the current shell もご覧ください。

Docker Toolbox と Docker Desktop の共存

同じマシン上で Docker Desktop と Docker Toolbox を一緒に利用できます。Docker Desktop を使いたい場合は、全ての DOCKER 環境変数を無効化します。これを bash でするには unset ${!DOCKER_*} です。 docker-machine で設定した VirtualBox 仮想マシンの１つを使いたい場合には、 eval $(docker-machine env default) を実行します（あるいは、対象となるマシン名を指定します）。現在操作しているコマンドのシェルで切り替えることにより、特定の Toolbox マシンと通信できるようになります。

セットアップした状態は、下図のように表せます。

＜図＞

異なるバージョンの Docker ツールを使う

Docker Desktop と Docker Machine を共存するセットアップをすると、 docker-machine でプロビジョンした VirtualBox 仮想マシンはそのまま残っています。もしも古いバージョンの Docker Engine が動作している仮想マシンを使う必要があれば、 Docker Version Manager のようなツールを使い、docker クライアントで複数のバージョンを管理できるようにします。

コンポーネントのバージョン確認

理想としては、 Docker CLI クライアントと Docker Engine のバージョンは同一であるべきです。クライアントとサーバまたはホストマシンでの不一致により、作成した Docker Machine が何らかの問題を引き起こす可能性があります（クライアントがサーバやホストマシンと通信できないなど）。

既に Docker Toolbox をインストールしていて、追加で Docker Desktop をインストールした場合、おそらく新しいバージョンの Docker クライアントを入手します。コマンド・シェル内で docker version を実行し、クライアントとサーバのバージョンを確認します。以下の例では、Docker Desktop でインストールしたクライアントのバージョンは Version: 19.03.1 で、サーバ（Docker Toolbox で先にインストールしていたもの）は Version: 19.03.2 です。

$ docker version
Client:
Version:      19.03.1
...

Server:
Version:      19.03.2
...

また、（Toolbox でインストールした）Docker Machine でマシンを作成していた場合は、アップグレードや Docker Desktop のインストールにより、異なるバージョンの Engine を実行することがあります。 docker-machine ls を実行し、作成したマシンのバージョン情報を表示します。 DOCKER 列で、各マシン上で異なるバージョンのサーバが動作しているのがわかります。

$ docker-machine ls
NAME             ACTIVE   DRIVER         STATE     URL                         SWARM   DOCKER    ERRORS
aws-sandbox      -        amazonec2      Running   tcp://52.90.113.128:2376            v19.03.1
default          *        virtualbox     Running   tcp://192.168.99.100:2376           v19.03.2
docker-sandbox   -        digitalocean   Running   tcp://104.131.43.236:2376           v19.03.1

Docker Universal Control Plane (UCP) を使っている場合であれば、似たような状況になるでしょう。

この問題への対処や古いマシンを使い続けるには、複数の方法があります。解決策の１つは、 DVM のようなバージョン管理ソフトを使う方法です。

Docker Toolbox から Docker Desktop on Mac への移行

Docker Desktop では、バージョン 18.01.0 以降のインストーラの一部として、 Toolbox イメージ移行を提案しなくなりました。既存の Docker Toolbox イメージの移行は、以下のスクリプトで行えます（この移行方法では、 Docker と Toolbox の両方の統合はできません。なぜなら、あらゆる既存の Docker イメージは Toolbox のイメージに置き換えるからです）。

ターミナル内で以下のシェル・コマンドを実行します。動作には MacPorts と Brew 両方の qemu パッケージに含まれる qemu-img が必要です。

$ brew install qemu  # または sudo port install qemu

まず、自分の Toolbox ディスクイメージがどこか探します。おそらくこちらでしょう： ~/.docker/machine/machines/default/disk.vmd 。

$ vmdk=~/.docker/machine/machines/default/disk.vmdk
$ file "$vmdk"
/Users/akim/.docker/machine/machines/default/disk.vmdk: VMware4 disk image

次に、 Docker Desktop が使用しているディスク・イメージの場所とフォーマットを確認します。

$ settings=~/Library/Group\ Containers/group.com.docker/settings.json
$ dimg=$(sed -En 's/.*diskPath.*:.*"(.*)".*/\1/p' < "$settings")
$ echo "$dimg"
/Users/akim/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw

今回はフォーマットは raw です（ qcow2 の場合もあります） 。また、場所は ~/Library/Containers/com.docker.docker/Data/vms/0/ です。

それから

• フォーマットが qcow2 であれば、次の様に実行します。

$ qemu-img convert -p -f vmdk -O qcow2 -o lazy_refcounts=on "$vmdk" "$dimg"

• フォーマットが raw であれば、以下のコマンドを実行します。ディスク容量の空きが少なければ、おそらく失敗するでしょう。

$ qemu-img convert -p -f vmdk -O raw "$vmdk" "$dimg"

（オプション）最後に、Docker Toolbox を使い終えるのであれば、完全にアンインストールしたらよいでしょう。

Docker Toolbox をアンインストールするには

新しい Docker Desktop を手に入れ、Docker Toolbox が不要になれば、アンインストールを決意するでしょう。Mac 上の Toolbox を完全にアンインストールするための詳細は、Toolbox Mac トピックの How to uninstall Toolbox をご覧ください。

マルチ CPU アーキテクチャのサポートを活用

Docker イメージはマルチ・アーキテクチャ（multi-architecture）をサポートしています。つまり１つのイメージ内に、異なるアーキテクチャを含んでいたり、稀に Windows のような異なるオペレーティングシステムを含むことがあります。

マルチ・アーキテクチャをサポートしているイメージの実行時、 docker は自動的に OS とアーキテクチャに一致した、対応しているイメージを選択します。

Docker Hub 上の大部分の公式イメージには、 様々なアーキテクチャ があります。例えば、 busybox イメージがサポートするのは amd64 、 arm32v6 、 arm32v7 、arm64v8 、 i386 、ppc64le 、 s390x です。このイメージを x86_64 / amd64 マシン上で実行しようとすると、 x86_64 対応版を自動的に取得・実行します。

Doker Desktop は binfmt_misc マルチ・アーキテクチャをサポートします。つまり、 arm 、 mips 、 ppc64le のような異なる Linux アーキテクチャでコンテナを実行できるだけでなく、 x390x でさえもです。

Docker for Mac 仮想マシン が qemu-static を使うので、コンテナ内で特別な設定は不要です。これにより、 busybox イメージの arm32v7 や ppc64le に対応した ARM コンテナを実行可能です。

Buildx （実験的機能）

現在の Docker は、 Arm サーバやデバイス向けのコンテナ開発が、以前よりも簡単になりました。標準的な Docker ツールや手順を用いて、異なるコンピュータ・アーキテクチャ上のイメージの開発、送信、受信、実行がシームレスに行えます。なお、Arm 向けにビルド開始しようとするとき、Dockerfile やソースコードに一切変更を加える必要はありません。

Dockre には buildx という新しい CLI コマンドライン・ツールを導入しました。Docker Desktop for Mac と Windows では、この buildx コマンドを使うことで、複数のアーキテクチャに対応したイメージを構築し、マニフェスト・ファイルでそれらを一緒にし、コマンド１つでこれら全てを送信できます。エミュレーションを入れておけば、単にネイティブなイメージを作るよりも、透過的に構築できます。BUildx はこれらを行うため、 BuildKit をベースとする新しい構築インスタンスを追加しました。そして、Docker Desktop の技術スタックによって、ネイティブではないバイナリも実行します。

Buildx CLI コマンドに関する詳しい情報は Biuldx をご覧ください。

インストール

1.　Docker Desktop の最新バージョンをダウンロードします。
2.　画面の指示に従い、インストール手順を完了します。Docker Desktop のインストールに成功したら、タスクトレイ内に Docker のアイコンが見えます。
3.　Docker メニューから About Docker Desktop をクリックし、インストールした Docker Desktop のバージョンが 2.0.4.0 (33772) 以上かどうかを確認します。

＜図＞

マルチ・アーキテクチャ・イメージの構築と実行

docker buildx ls コマンドを実行し、既存のビルダーを一覧表示します。以下で表示しているのは、デフォルトのビルダーです。これは元々ある古いビルダーです。

$ docker buildx ls

NAME/NODE DRIVER/ENDPOINT STATUS  PLATFORMS
default * docker
  default default         running linux/amd64, linux/arm64, linux/arm/v7, linux/arm/v6

マルチ・アーキテクチャ機能を利用できる新しいビルダーを作成します。

$ docker buildx create --name mybuilder

mybuilder

あるいは、新しいビルダーを作成してコマンド１つで切り替えるには docker buildx create --name mybuilder --use を実行します。

新しいビルダーに切り替えて調べてみましょう。

$ docker buildx use mybuilder

$ docker buildx inspect --bootstrap

[+] Building 2.5s (1/1) FINISHED
 => [internal] booting buildkit                                                   2.5s
 => => pulling image moby/buildkit:master                                         1.3s
 => => creating container buildx_buildkit_mybuilder0                              1.2s
Name:   mybuilder
Driver: docker-container

Nodes:
Name:      mybuilder0
Endpoint:  unix:///var/run/docker.sock
Status:    running

Platforms: linux/amd64, linux/arm64, linux/arm/v7, linux/arm/v6

マルチ・アーキテクチャ・イメージの構築、送信、実行のワークフローが機能するかどうか調べます。簡単なサンプル Dockerfile を作成し、２つの派生イメージを作成し、それらを Docker Hub に送信します。

$ mkdir test && cd test && cat <<EOF > Dockerfile

FROM ubuntu
RUN apt-get update && apt-get install -y curl
WORKDIR /src
COPY . .
EOF

$ docker buildx build --platform linux/amd64,linux/arm64,linux/arm/v7 -t username/demo:latest --push .

[+] Building 6.9s (19/19) FINISHED
...
 => => pushing layers                                                             2.7s
 => => pushing manifest for docker.io/username/demo:latest              

username の場所には、有効な Docker ユーザ名を入れてます。

メモ：
* --platform フラグは、buildx に対して AMD64-bit 、 Arm 64-bit、Armv7 アーキテクチャに対応する Linux イメージを生成するように伝えます。
* --push フラグは、生成したマルチ・アーキテクチャ対応マニフェストを生成し、全てのイメージを Docker Hub に送信します。

イメージの調査には imagetools を使います。

$ docker buildx imagetools inspect username/demo:latest

Name:      docker.io/username/demo:latest
MediaType: application/vnd.docker.distribution.manifest.list.v2+json
Digest:    sha256:2a2769e4a50db6ac4fa39cf7fb300fa26680aba6ae30f241bb3b6225858eab76

Manifests:
  Name:      docker.io/username/demo:latest@sha256:8f77afbf7c1268aab1ee7f6ce169bb0d96b86f585587d259583a10d5cd56edca
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/amd64

  Name:      docker.io/username/demo:latest@sha256:2b77acdfea5dc5baa489ffab2a0b4a387666d1d526490e31845eb64e3e73ed20
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/arm64

  Name:      docker.io/username/demo:latest@sha256:723c22f366ae44e419d12706453a544ae92711ae52f510e226f6467d8228d191
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/arm/v7

このイメージは Docker Hub 上で username/demo:latest というタグで利用可能になりました。このイメージを使って、Intel ノート PC 上や、 Amazon EC2 A1 インスタンス上や、Raspberry Pis や、その他のアーキテクチャ上でコンテナを実行できます。Docker はイメージ取得時、各々のアーキテクチャに対応したものをダウンロードします。そのため、 Raspberry Pi では 32-bit Arm バージョンを実行し、EC2 A1 インスタンスでは 64-bit Arm を実行します。 SHA タグの識別は、イメージ派生ごとに保持します。また、Docker Desktop 上では異なるアーキテクチャとしてタグ付けされたイメージを実行可能です。

イメージの実行には SHA タグを使えますし、アーキテクチャの角煮もできます。例えば、以下のコマンドを macOS 上で実行します：

 $ docker run --rm docker.io/username/demo:latest@sha256:2b77acdfea5dc5baa489ffab2a0b4a387666d1d526490e31845eb64e3e73ed20 uname -m
aarch64

$ docker run --rm docker.io/username/demo:latest@sha256:723c22f366ae44e419d12706453a544ae92711ae52f510e226f6467d8228d191 uname -m
armv7l

この例では、 uname -a の実行結果が aarch64 と armv7l になっているだけでなく、各コマンドが macOS 開発マシン上でネイティブに実行しています。

ネットワーク構築機能

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

機能

VPN パススルー

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

ポートマッピング

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

$ docker run -p 80:80 -d nginx

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

$ docker run -p 8000:80 -d nginx

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

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

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

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

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

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

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

コンテナに ping できません

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

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

docker (Linux) ブリッジ・ネットワークは macOS ホストから到達できません。

利用例と回避方法

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

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

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

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

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

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 コマンドを御覧ください。

ファイルシステム共有 [osxfs]

osxfs は Docker Desktop for Mac 限定の、新しい共有ファイルシステムのソリューションです。 osxfs は macOS ファイルシステム・ツリーを Docker コンテナ内にバインド・マウントするにあたり、ネイティブに近いユーザ体験を提供します。この目的のため、 osxfs の機能には、古典的な Linux ファイルシステムとは異なる数々のユニークな機能があります。

大文字と小文字の区別（case sensitivity）

Docker Desktop for Mac では、コンテナ内のファイルシステム操作が、 macOS で操作するのと同じように行えます。macOS 上のファイルシステムが大文字小文字を区別するなら、その挙動は macOS からコンテナ内にバインド・マウントする場合も同じです。

macOS Sierra と以前では、デフォルトのファイルシステムは HFS+ です。 macOS Hight Sierra では、デフォルトのファイルシステムは APFS です。いずれもデフォルトで大文字小文字を区別しますが、バージョンによって大文字小文字を区別するものとしないものがあります。

大文字小文字の挙動がどうなるかは、バインド・マウントに用いるフォーマット形式が HFS+ か APFS かに依存します。 APFS FAQ をご覧ください。

同じ Mac 上のソフトウェアは大文字小文字の機能に依存していますので、root パーティションの再フォーマットは推奨しません。

アクセス制御（access control）

osxfs では、 Dockerはファイスシステムリソースに対してアクセス可能です。つまり、 Docker Desktop for Mac ユーザは osxfs にアクセスしますが、 root としては実行できません。もしも macOS ユーザが administrator であれば、 osxfs は administrator 権限を継承します。私たちはセキュリティと使いやすさのバランスをとるために、ファイルシステム処理から権限を落とせるように取り組んでいます。 osxfs の動作は、追加の権限チェックがなく、追加のアクセス制御もありません。コンテナ内の全てのプロセスは、コンテナを起動した Docker ユーザによって同じ方法で同じオブジェクトに対してアクセスできます。

名前空間（namespaces）

macOS ファイルシステムの大部分は、 -v バインド・マウント構文をコンテナで用いてユーザによってアクセス可能です。以下のコマンドを実行すると、 r-base という名称のイメージからコンテナを実行し、macOS ユーザの ~/Desktop/ ディレクトリをコンテナ内の /Desktop としてマウントします。

$ docker run -it -v ~/Desktop:/Desktop r-base bash

ユーザの ~/Desktop/ ディレクトリは、コンテナ内の / ディレクトリ以下に見えるようになります。

root@2h30fa0c600e:/# ls
Desktop boot    etc lib lib64   media   opt root    sbin    sys usr
bin dev home    lib32   libx32  mnt proc    run srv tmp var

デフォルトでは、 /Users/ 、 /private/ 、 /tmp ディレクトリにあるファイルを共有可能です。ディレクトリツリーの追加や削除を Docker に反映するには、 Docker の設定、鯨アイコン -> Preferences -> File sharing にある Fire sharing のタブを使います（設定のページをご覧ください）。

-v バインドマウントで使う他のすべてのパスは、Docker コンテナが稼働する Moby Linux 仮想マシンをソースとしますので、引数では -v /var/run/docker.sock:/var/run/docker.sock のような指定が動作します。もしも macOS のパスが共有されたおらず、仮想マシン上に存在しなければ、仮想マシンを生成せずにバインド・マウントは失敗します。パスは既に仮想マシン上に存在するものであり、含まれるファイルは Docker に予約済みであり、macOS 側には露出（export）できません。

Docker 17.04 CE Edge リリースで利用可能になった新しい設定オプションについて学ぶには Performance tuning for volume mounts (shared filesystems をご覧ください。

所有権（Ownership）

初期化時、あらゆるコンテナ化したプロセスは、自身のオブジェクトに対して uid と gid といったオブジェクトのメタデータ所有者をリクエストします。あらゆるコンテナ化したプロセスにおいて、 chown コマンドなどを用いて共有ファイルシステムオブジェクト上の所有権を変更すると、新しい所有者情報はオブジェクトの拡張属性 com.docker.owner内に存在します。所有者メタデータの変更に伴い、それに続く処理では以前にセットした値を返します。所有者を元にした権限（ownership-based permissions）は、macOS ファイルシステムレベル上のみ強制されるもので、Docker を実行しているユーザによるプロセスであればすべてアクセス可能です。もしもユーザがオブジェクトに対する拡張属性を読み込む権限が無ければ（オブジェクトのパーミッションが 0000 のような場合）、 osxfs はユーザが読み書きできるような拡張属性を得られるよう、アクセスコントロールリスト（ACL）のエントリを追加しようとします。割り当てに失敗すると、オブジェクトはプロセスの所有者のものとして表示され、拡張属性は再び読み込み可能なものとして表示します。

ファイルシステムイベント（File system events）

大部分の inotify イベントはバインド・マウントでサポートしています。また、 dnotify と fanotify （あまりよくテストされていません）もサポートしています。つまり、macOS からのファイルシステムイベントは、コンテナ内のプロセスに対しても送信され、あらゆるリッスンしているプロセスがトリガとなります。

以下は サポートしているファイルシステムイベントです ：

• 作成
• 変更
• 属性変更
• 削除
• ディレクトリ変更

以下は 一部サポートしているファイルシステムイベントです ：

• ソース上で IN_DELETE をトリガとする移動イベントによる名前変更と、名前変更先の IN_MODIFY

以下は サポートしていないファイルシステムイベントです：

• オープン
• アクセス
• クローズイベント
• アンマウント・イベント（マウントをご覧ください）

いくつかのイベントは何度も送られます。コンテナ間のイベントは反映しないという制約があります。各イベントは macOS を起点としているものだけです。

マウント（Mounts）

共有ボリューム上では macOS マウント構造は見えませんが、ボリュームの内容は見えます。ボリュームの中身として表示されるのは、共有ファイルシステム上の場所にあるものと同一のファイルシステムです。macOS ボリュームのマウントおよびアンアウントとは、コンテナの中に対するバインド・マウントでもあるので、コンテナ内においては予期しない挙動が発生する場合もあります。アンマウントイベントはサポートされていません。マウント・エクスポートのサポートは計画中ですが、まだ開発中です。

シンボリックリンク（Symlinks）

シンボリックリンクは共有され、変更できません。そのため、シンボリックリンクにパスを含む場合は、デフォルトの　ﾏcOS ファイルシステムはデフォルトで大文字小文字を区別するかどうかによって、問題を引き起こす可能性があります。

ファイルタイプ

シンボリックリンク、ハードリンク、ソケットファイル、名前付きパイプ、通常のファイル、ディレクトリをサポートしています。ソケットファイルと名前付きパイプは、コンテナと macOS プロセス間のみで送信（transmit）するだけです。つまりハイパーバイザを横断する送信は、まだサポートしていません。キャラクタおよびブロックデバイスファイルはサポート外です。

属性の拡張（Extended attributes）

属性の拡張はまだサポートしていません。

技術

osxfs は OSXUFSE を使いません。 osxfs は macOS ユーザー空間プロセスと macOS カーネル間で、あるいは、その配下、内部では動作しません。

SSH エージェント転送（SSH agent forwarding）

Docker Desktop for Mac はホスト側の SSH エージェントをコンテナ内で利用できます。そのためには、

1. SSH エージェントの助っ人をバインド・マウントするため、 docker run コマンドで以下のパラメータを追加： --mount type=bind,src=/run/host-services/ssh-auth.sock,target=/run/host-services/ssh-au
2. SSH_AUTH_SOCK 環境変数をコンテナに追加： -e SSH_AUTH_SOCK="/run/host-services/ssh-auth.sock"

Docker Compose で SSH エージェントを有効化するには、サービスに以下のフラグを追加します：

services:
  web:
    image: nginx:alpine
    volumes:
      - type: bind
        source: /run/host-services/ssh-auth.sock
        target: /run/host-services/ssh-auth.sock
    environment:
      - SSH_AUTH_SOCK=/run/host-services/ssh-auth.sock

パフォーマンス問題、ソリューション、ロードマップ

Docker 17.04 CE Edge リリースで利用可能になった新しい設定オプションについて学ぶには Performance tuning for volume mounts (shared filesystems をご覧ください。

(TBD、将来的に変更する可能性があるため。また、マニュアル本編とは直接関係がないため)

ボリューム・マウント（共有ファイルシステム）のためのパフォーマンス・チューニング

Docker 17.03 CE Edge は docker run -v 、 --volume オプションに、新しい２つのフラグ cached と delegated のサポートを追加しました。これは Docker Desktop for Mac がマウントしたボリュームに対し、アクセス性能を著しく改善する可能性があります。これらオプションは パフォーマンス問題、ソリューション、ロードマップ における課題の議論と同じくして始まったものです。

*Tip: * Docker CE Edge 17.04 のリリースノートは こちら です。それと、 docker run -v フラグの追加に関連するプルリクエストは こちら です。

以下のトピックで説明するのは、 osxfs 上のバインド・マウント・ボリュームの変更に対するものと、パフォーマンス最適化をもたらすオプションについてです。

こちらの Docker on Mac Performance ブログ投稿に、簡単な要約があります。

Compose ファイル中における各オプション調整に関する情報は、Docker Compose トピックにある Caching options for volume mounts をご覧ください。

ホストコンテナのファイルシステム一貫性とパフォーマンスの密接な関係

macOS や Windows を含む、数々のプラットフォーム上で Docker が利用できるようになり、コンテナ実行時にマウントに関連するワークロード（作業負荷）を最適化する必要性が一般化しました。

現時点で Linux 上のマウントに関する実装とは、コンテナ内にホスト側と一貫性したディレクトリツリーを提供するものです。つまり、読み書き処理とは、ホスト上だけでなくコンテナ内でも行われますので、他の環境の影響を直ちに受けます。また、ファイルシステムイベント（ inotify 、 FSEvents`` ）は、両方（ホスト上およびコンテナ）のディレクトリで直ちに反映します。

Linux 上ではホストとコンテナ間で VFS を基盤に共有しているので、オーバーヘッドのない反映を保証します。しかしながら、 macOS （および他の Linux 以外のプラットフォーム）では、完全な一貫性を保つために著しいオーバーヘッドがあります。これは message describing ファイルシステムが動作するために、ホストとコンテナ間を同期的に通過（passed synchronously）する必要があるためです。現時点の実装は多くのタスクに対して十分なものですが、ある種のワークロードでは完全な一貫性を確保するためにオーバーヘッドが発生し、ネイティブな環境（Docker 以外）でなければ、著しいパフォーマンス悪化をもたらします。たとえば、

• docker/docker ソースツリーに go list ./... をバインド・マウントして実行すると、約 26 秒かかる
• バインド・マウントしたディレクトリに、100MB を 1k ブロックで書き込むと、約 23 秒かかる
• 新しく作成した（空っぽの）アプリケーションで ember build を実行すると、コンテナとホスト間でリクエストと応答があるたびに、連続して 70000 syscall を引き起こす

スタックの遅延（latench）を減らすための最適化により、これらのワークロードを著しく改善しました。そして、さらにいくつかの最適化も施しています。しかしながら、それでも一貫性を維持するための制約によって、遅延は最小限あります。つまり、ある種の使い方によっては受け入れがたいワークロードの遅さがあるでしょう。

consistent、cached、delegated 設定のチューニング

幸いにも、ほパフォーマンス劣化は多くの場合において最も深刻な例であり、また、コンテナとホスト間における一貫性が完全である必要はありません 。特に多くのケースでは、コンテナ内に書き込んだファイルを、即時ホスト上に反映する必要がありません。たとえば、双方向（インタラクティブ）の開発を行っていると、コンテナ内でのファイルシステムイベントの発生が、ホスト上のバインド・マウントしたディレクトリに書き込む必要がある場合、コンテナ内で構築した成果物（build artifacts）を即座にホスト上のファイルシステムに反映する必要はありません。これら特徴的な２つのケースでは、著しいパフォーマンス改善が可能です。

ここでは必要となる一貫性のレベルに応じ、３つのシナリオを検討しました。各ケースは、いずれもコンテナ内にバインド・マウントしたディレクトリを持っていますが、２つのケースではコンテナとホスト間で一時的な矛盾の発生を許容しています。

• consistent ：完全な一貫性（常にホストとコンテナが完全に同じ表示）
• cached ：ホストの表示が信頼できる（ホスト上の更新がコンテナ上に反映するまで、遅延が発生するのを許容）
• delegated ：コンテナの表示が信頼できる（コンテナ上の更新がホスト上に反映するまで、遅延が発生するのを許容）

例

これら各設定（ consistent 、 cached 、 delegated ）は docker run の -v オプションで指定できます。たとえば、 /Users/yallop/project をコンテナ内の /project パス以下にバインド・マウントするとき、次のようなコマンドを実行します。

docker run -v /Users/yallop/project:/project:cached alpine command

キャッシュ設定はバインド・マウントごとに独立しているため、マウントするディレクトリごとに異なるモードでマウントできます。

docker run -v /Users/yallop/project:/project:cached \
 -v /host/another-path:/mount/another-point:consistent
 alpine command

挙動についての解説

以下にある各設定で説明が保証しているのは、ファイルシステム操作が効率的になるかどうかに関連しています。ここでは前提として、 host が指し示すのは、ユーザの Docker クライアント上にあるファイルシステムです。

delegated

delegated 設定では、一連の（一貫性に対する）保証が最も弱いものです。 delegated でディレクトリをマウントすると、コンテナのファイルシステム上の表示が信頼できるものとなり、コンテナ内での書き込み処理が、ホスト上のファイルシステムに即時反映しない場合があります。NFS非同期モードのような状況であれば、もしも delegated バインドマウントしたコンテナがクラッシュすると、書き込みが失われる可能性があります。

しかしながら、一貫性の放棄により、 delegated マウントは他の設定に比べて著しいパフォーマンスをもたらします。空っぽのスペースやビルド成果物のような、データの書き込みが一時的（ephemeral）または直ぐに再生成可能であれば、 delegated は正しい選択になるでしょう。

delegated マウントを担保するため、コンテナ実行中に以下の制約があります。

1. もしもファイルシステムイベントに通知する実装であれば、イベントが生成されたとき、関連するファイルシステム状態に関連するコンテナの変更がなければ、コンテナの状態に関連する特定のイベントは、ホストファイルシステム状態にその時点で反映する 必要があります 。
2. flush や sync 処理が行われると、関連するデータはホストファイルシステム上に反映（write back）する 必要があります 。flush から sync 処理をするまで、コンテナは データの書き込み、メタデータの変更、ディレクトリ階層の変更をキャッシュする 可能性があります 。
3. 同じランタイムによってホストされている全てのコンテナは、マウントしているキャッシュの一貫性を共有する 必要があります 。
4. delegated マウントで共有しているコンテナが終了すると、マウントに対する変更はホストファイルシステム上に反映する 必要があります 。反映が失敗すると、コンテナの処理が失敗 しなくてはならず 、終了コードや Docker event channel で通知します。
5. delegated マウントしている場所を cached や consistent マウントで共有すると、それぞれの場所は cached や consistent マウント指定に従う 必要があります 。これらの制約はありますが、 delegated 設定はコンテナ実行時に自由度をもたらします。
6. コンテナはファイルデータとメタデータ（ディレクトリ構造、ノードの存在、等）を無期限に保持する 可能性があり 、このキャッシュによってホスト上のファイルシステム状態と同期しない 可能性があり ます。ホストファイルシステムで変更が発生すると、開発者はキャッシュを無効化すべきですが、プラットフォームの制約による時間枠（timeframe）の保証は難しいでしょう。
7. もしもホストファイルシステム上でマウントしているソースディレクトリに変更を加えても、 delegated マウントしているホスト側ソース・ディレクトリの同期によって、それぞれの変更が失われる 可能性があります 。
8. 挙動 6～7 はソケット、パイプ、デバイスに対しては 適用外 です。

cached

cached 設定は delegated 設定の全てを保証し、コンテナ内で書き込み処理の見え方に関連し、追加の保証をします。 cached は読み込みが重たいワークロードの性能を著しく改善しますが、ホストとコンテナ間で一時的に一貫性を失う犠牲を伴います。

cached としてマウントしたディレクトリは、ホスト側ファイルシステムが信頼できます。つまり、コンテナでの書き込み処理は即時ホスト側でも見えるようになりますが、ホスト上での書き込み処理がコンテナ内で見えるようになるには遅延が発生しうるでしょう。

Tip: cached について更に学ぶには、 User-guided caching in Docker Desktop for Mac をご覧ください。

1. 実装は delegated 挙動の 1～5 に従う 必要があります 。
2. 実装がファイスシステムイベントの提供時、イベントが生成された時点で、コンテナ状態をホストファイルシステムの状態に反映する 必要があります 。
3. コンテナはホストファイルシステムのメタデータ変更、ディレクトリ階層の変更、データ書き込みの一貫性を処理する 必要があります が、データ書き込み、メタデータ変更、ディレクトリ階層の変更をキャッシュ する必要はありません 。
4. cached マウントが consistent マウントとして共有される場合、重複する場所は consistent マウントの挙動で上書きする 必要があります 。
5. 実装は delegated 挙動 6 を許容する 可能性があります 。

consistent

consistent 設定した場所は、コンテナ実行中に最も制約をうけます。コンテナとホストを consistent でマウントしたディレクトリは、常に同期します。つまり、コンテナ内での書き込み処理は即時ホスト上でも見えるようになり、ホスト上での書き込み処理は即時コンテナ内でも見えるようになります。

consistent 設定は最も Linux のバインド・マウントの挙動を反映しているものです。しかしながら、パフォーマンスの優先度が高く完全な一貫性の維持に対する優先度が低いような、いくつかの利用例にあたっては、強力な一貫性を確保するためにオーバーヘッドをもたらします。

1. 実装は cached 挙動 1～4 に従う 必要があります 。
2. コンテナのマウントは、ホストファイルシステム上のメタデータ変更、ディレクトリ階層の変更、データ書き込みを即時に反映する 必要があります 。

defaut

default 設定は、指定が無ければデフォルトで適用されるもので、 consistent 設定と同一です。重要なのは、重複したディレクトリを強化するのに必要な cached 挙動 4 と delegated 挙動 5 が、 default マウントには適用されません。もしも state フラグの指定が無ければ、これがデフォルト設定になります。

Docker for Mac におけるディスク使用量

Docker Desktop で Linux コンテナとイメージを保管するのは、Mac ファイルシステム内の単一の大きな「ディスク・イメージ」ファイルです。これは Linux 上の Docker が /var/lib/docker ディレクトリにコンテナとイメージを保管するのと異なります。

ディスクイメージファイルはどこに？

ディスクイメージファイルの場所をさがすには、 Docker アイコンから Preferences > Resources > Advanced を選択します。

＜図＞

Advanced タブでディスクイメージの場所を表示します。また、ディスクイメージの最大サイズと、ディスクイメージが消費している実際のディスクサイズの両方表示します。なお他のツールでは、ファイルサイズが最大化する観点から、実際に使用しているファイルサイズではなく、ファイルが確保するサイズを表示している場合もあります。

ファイルが大きすぎる場合

ディスクイメージファイルが大きすぎる場合、次の対処ができます：

• より大きなドライブに移動
• 不要なコンテナやイメージを削除、あるいは
• ファイルに割り当て可能な最大サイズを減らす

大きなドライブにファイルを移動

ディスクイメージファイルを別の場所に移動するには：

1. Preferences > Resources > Advanced を選択
2. Disk image locaition セクション内で、 Browse をクリックし、ディスクイメージの新しい場所を選択
3. 設定を反映するには Apply & Restart をクリックします。

（macOS の）Finder でファイルディレクトリを移動しないでください。移動しても、 Docker Desktop はファイルを追跡できません。

不要なコンテナやイメージを削除

不要なコンテナやイメージがないかどうか確認します。クライアントとデーモン API がバージョン 1.25 以降で動いていれば（クライアントで docker version コマンドを実行し、クライアントとデーモンの API バージョンを確認できます ）、次のコマンド実行によって詳細な容量の利用状況が分かります。

docker system df -v

あるいは、イメージ一覧を表示します。

$ docker image ls

そして、次にコンテナ一覧を表示します。

docker container ls -a

もしも不要なものが大量にあれば、次のコマンドを実行します。

$ docker system prune

このコマンドは停止済みコンテナ、使用していないネットワーク、派生イメージ、構築キャッシュをすべて削除します。

ホストに依存するディスクイメージファイル形式によっては、容量改善のために数分の時間がかかることもあります。

• ファイル名が Docker.raw ：ホスト上のスペース改善は数秒以内に終わります。
• ファイル名が Docker.qcow2 ：バックグラウンド処理が進行し、数分後に空き容量が増えます。

容量の解放は、イメージを削除した時のみです。実行中のコンテナ内でファイルを削除しても、自動的に空き容量は解放されません。任意のタイミングで容量を確保をしたければ、次のコマンドを実行します。

$ docker run --privileged --pid=host docker/desktop-reclaim-space

多くのツールでは、実際に使用しているファイルサイズではなく、ファイルが確保するサイズを表示する場合があるため、注意してください。ホスト上のファイルが実際に使用している容量を確認するには、ターミナル上で次のコマンドを実行します：

$ cd ~/Library/Containers/com.docker.docker/Data
$ cd vms/0/data
$ ls -klsh Docker.raw
2333548 -rw-r--r--@ 1 username  staff    64G Dec 13 17:42 Docker.raw

この例では、ディスクの実際のサイズは 2333548 KB ですが、最大のディスクサイズは 64 GB です。

ファイルに割り当て可能な最大サイズを減らす

ディスクイメージファイルの最大サイズを減らすには：

1. Docker アイコンから Preferences > Resoruces > Advanced を選択
2. Disk image size セクションで、スライダーを調整。この変更によって、ディスクイメージに割り当てる最大容量を変更できる。スライダーを下限にセット
3. Apply & Restart をクリック

最大容量を変更すると、使用中のディスクイメージファイルは削除されます。つまり、全てのコンテナとイメージは失われます。

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

このページに含む情報は、どのようにして原因を追及し、問題を解決し、ログを送信し、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 や Docker Desktop for Mac forum で、ログデータのトラブルシュートを手助けできるかもしれません。

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

＜図＞

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

診断が完了したら、次のように診断 ID を含む出力結果が得られます。
```

トラブルシューティング

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

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 を御覧ください。

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

Stable と Edge リリース

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

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

インストール手順は Mac に 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.app とは何ですか？

Docker.app は Mac 上の Docker Desktop です。Docker クライアントと Docker Engine が同梱されています。 Docker.app は macOS Hypervisor.framework でコンテナを実行します。つまり Docker Desktop の実行に、別途 VirtualBox をセットアップする必要がありません。

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

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

実験的機能（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 Mac フォーラムのトピック リモート API をどのようにして見つけられますか（英語） も御覧ください。

もしも Apache Maven のようなアプリケーションを動作中であれば、 DOCKER_HOST と DOCKER_CERT_PATH 環境変数の設定が必要でしょう。特にこれらで Docker にアクセスするためには Unix ソケットの指定が必要です。例：

export DOCKER_HOST=unix:///var/run/docker.sock

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

Mac は変動 IP アドレスを持ちます（あるいは、ネットワーク接続がなければ存在しません）。私たちが推奨するのは IP を使わず、Mac 上の lo0 インターフェースを使い、コンテナはこのアドレスで接続します。

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

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

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

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

フィードバック

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

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

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

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

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

Docker Desktop for Mac フォーラム には議論のスレッドがあります。そちらでも議論のトピックを作成できますが、私たちが推奨するのはフォーラムではなく 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 リリースノート

• Stable release note

Edge リリースノート

• Edge release note

原文

• GitHub
  • https://github.com/docker/docker.github.io/blob/master/docker-for-mac/index.md
• Get started with Docker for Mac | Docker Documentation
  • https://docs.docker.com/docker-for-mac/

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.