Linux に Docker Desktop をインストール¶
注釈
Docker Desktop 利用条件
大企業（従業員が 251 人以上、または、年間収入が 1,000 万米ドル以上 ）における Docker Desktop の商用利用には、有料サブスクリプション契約が必要です。
このページには、 Docker Desktop for Mac のシステム要件、ダウンロード URL 、Docker Desktop for Linux のインストールと更新の手順の情報を含みます。
システム要件¶
Docker Desktop を正しくインストールするには、Linux ホストが以下の要件を満たす必要があります。
仮想化のために、 64-bit カーネルと CPU のサポート
KVM 仮想化のサポート。KVM カーネルモジュールのサポート有効化を確認する方法と、kvm デバイスにアクセスする方法は、以下の KVM 仮想化サポート手順 を参照
QEMU はバージョン 5.2 以上が必須 。最新バージョンへのアップグレードを推奨
systemd init システム
Gnome または KDE デスクトップ環境
多くの Linux ディストリビューションでは、Gnome 環境でトレイアイコンをサポートしていない。トレイアイコンをサポートするには、Gnome 拡張をインストールする必要がある。例： AppIndicator
最小 4GB の メモリ RAM
ユーザ名前空間で ID マッピングの設定を有効化。 ファイル共有 を参照
Docker Desktop for Linux は仮想マシン（VM）を実行します。なぜ実行するかの詳しい情報は、 どうして Docker Desktop for Linux は仮想マシンを実行するのか をご覧ください。
注釈
サポート対象のプラットフォーム¶
以下の Linux ディストリビューションとアーキテクチャに対し、Docker は .deb と .rpm パッケージを提供します。
プラットフォーム |
x86_64 / amd64 |
|---|---|
|
|
|
|
|
|
|
注釈
Arch をベースとしたディストリビューションに対する実験的なパッケージが利用可能です。Docker はテストしておらず、インストールも未検証です。
Docker がサポートする Docker Desktop は、前述したディストリビューションの現在の LTS リリースと、最も新しいバージョンです。新しいバージョンが利用可能になれば、Docker は古いバージョンのサポートを停止し、新しいバージョンをサポートします。
KVM 仮想化のサポート¶
Docker Desktop は仮想マシンを実行しますが、 KVM のサポート が必要です。
ホストが仮想化をサポートしている場合、 kvm モジュールは自動的に読み込まれます。モジュールを手動で読み込むには、次のように実行します。
$ modprobe kvm
ホストマシンのプロセッサによって、適切なモジュールを読み込む必要があります。
$ modprobe kvm_intel # Intel プロセッサ
$ modprobe kvm_amd # AMD プロセッサ
先のコマンドに失敗する場合、調査結果を表示するには、次のように実行します。
$ kvm-ok
KVM モジュールが有効化されているかどうかを確認するには、次のように実行します。
$ lsmod | grep kvm
kvm_amd 167936 0
ccp 126976 1 kvm_amd
kvm 1089536 1 kvm_amd
irqbypass 16384 1 kvm
KVM デバイスのユーザ権限をセットアップ¶
/dev/kvm の所有者を確認するには、次のように実行します。
$ ls -al /dev/kvm
kvm デバイスに対してアクセスするには、ユーザを kvm グループに追加します。
$ sudo usermod -aG kvm $USER
ログアウトしてログインしなおすと、所属しているグループのメンバー情報が再読み込みされます。
一般的なインストール手順¶
自分の Linux ディストリビューション向けに適切なパッケージをダウンロードし、適切なパッケージマネージャを使い、そのパッケージをインストールします。
Gnome/KDE デスクトップの Applications を開き、 Docker Desktop を探します。
Docker Desktop を選択し、 Docker を起動します。
Docker メニュー（
）は Docker サブスクリプション サービス使用許諾 ウインドウを表示します。
Accept をクリックすると続きます。使用許諾を承諾した後、 Docker Desktop は起動します。
重要
使用許諾に同意しなければ、 Docker Desktop アプリケーションは終了し、以後マシン上で Docker Dekstop を起動しないようようにします。後日、 Docker Desktop を開いた時、使用許諾を承諾するかどうか選択できます。
詳しい情報は、 `Docker Desktop Subscription Service Agreement（ Docker Desktop サブスクリプション サービス 使用許諾）`_ をご覧ください。また、 FAQ を読むのもお勧めします。
Docker Desktop for Linux と Docker Engine との違い¶
Docker Desktop for Linux と Docker Engine は、同じマシン上で並列にインストールできます。Docker Desktop for Linux は、コンテナとイメージを 仮想マシン内の 分け隔てられた保管場所に保存し、 リソースを制限するよう制御 します。Docker Desktop 用（のコンテナやイメージ）は専用の場所に保存するため、同じマシン上にインストールした Docker Engine との干渉を防げます。
Docker Desktop と Docker Engine の両方を同時に実行可能なため、同時に実行すると何らかの問題を引き起こす可能性があります。たとえば、コンテナに対してネットワーク ポート（ -p / --publish ）を割り当てると、Docker Desktop と Docker Engine の両方が、同じマシン上のポート確保を試みるため、衝突を引き起こします（「port already in use」＝ポートが既に使用されています）。
私たちは、Docker Engine がリソースを消費の消費を避けたり、前述のような衝突を避けるため、 Docker Desktop の利用時は Docker Desktop を停止するのを一般的に推奨します。
以下のコマンドで Docker Engine サービスを停止します：
$ sudo systemctl stop docker docker.socket containerd
インストール状況によって、 Docker Engine はマシン起動時に自動的にサービスとして起動するよう設定されています。以下のコマンドを実行し、Docker Engine サービスが自動的に起動するのを防ぎます：
$ sudo systemctl disable docker docker.socket containerd
Docker Desktop と Docker Engine 間の切り替え¶
Docker CLI は複数の Docker Engine と相互接続できます。たとえば、同じ Docker CLI を使い、ローカルの Docker Engine とクラウド上で実行しているリモートの Docker Engine インスタンス（訳者注：Docker Engine 実行している"実体"そのものを指す抽象的な表現）を制御できます。 Docker Contests により、Docker Engine インスタンス（実体）間の切り替えができます。
Docker Desktop をインストールするとき、専用の「desktop-linux」コンテクストが Docker Desktop とやりとりするため作成されます。起動時、 Docker Desktop は現在のコンテクストを、自動的に自身のコンテクスト（ desktop-linux ）へと設定します。つまり、以降の Docker CLI コマンドは Docker Desktop が対象になります。シャットダウン時、Docker Desktop は現在のコンテクストを default コンテクストにリセットします。
docker context ls コマンドを使うと、自分のマシン上で何のコンテクストが利用できるか表示します。現在のコンテクストは、アスタリスク記号（ * ） で示されます。
$ docker context ls
NAME DESCRIPTION DOCKER ENDPOINT ...
default * Current DOCKER_HOST based configuration unix:///var/run/docker.sock ...
desktop-linux unix:///home/<user>/.docker/desktop/docker.sock ...
同じマシン上に Docker Desktop と Docker Engine の両方をインストールしている場合は、 docker context use コマンドを使い、Docker Desktop と Docker Engine コンテクスト間を切り替え可能です。たとえば、「default」コンテクストを使い Docker Engine とやりとりするには、次のようにします：
$ docker context use default
default
Current context is now "default"
それから、 desktop-linux コンテクストを使い、 Docker Desktop とやりとりします：
$ docker context use desktop-linux
desktop-linux
Current context is now "desktop-linux"
詳細は Docker Context のドキュメント をご覧ください。
更新（アップデート）¶
新しいバージョンの Docker Desktop がリリースされると、 Docker UI に通知が表示されます。更新をしたい場合は、新しいパッケージを都度手動でダウンロードする必要があります。
インストール済みの Docker Desktop を更新するには、まずローカルで実行しているあらゆる Docker Desktop を停止し、既存のバージョンの上に、新しいバージョンを通常のインストール手順に従ってインストールします。
Docker Desktop のアンインストール¶
Docker Desktop は Linux ホストが使うパッケージマネージャで削除できます。
Docker Desktop を削除したら、ユーザは ~/.docker/config.json から credsStore と currentContext プロパティの削除が必要です。
注釈
Docker Desktop のアンインストールは、ローカルのマシンにある Docker コンテナ、イメージ、ボリューム、 Docker 関連のデータ破棄し、アプリケーションによって作成された全てのファイルも破棄します。アンインストール前に重要なデータを保持する方法については、 バックアップと修復 を参照ください。
どうして Docker Desktop for Linux は仮想マシンとして実行するのか¶
Docker Desktop for Linux は、以下の理由のため仮想マシン（VM）として実行します：
プラットフォーム間を横断しても、Docker Desktop が一貫した体験の提供を保証するためです。
調査により、ユーザが Docker Desktop for Linux (DD4L) に最も多く求められている理由は、多くの主なオペレーティングシステム上で Docker Desktop 体験の一貫性を保証することでした。VM の使用により、Linux ユーザの Docker Desktop 体験は、 Windows と macOS に近くなります。
すべての主要な OS で一貫した経験を提供する必要が、ますます重要になってきているため、私たちは Docker Desktop に対して Docker Extensions のような心躍る新機能を追加し、全ての層のユーザに対して利便をもたらします。これらの詳細は DockerCon22 で説明予定です。こちらに注目ください。
新しいカーネル機能を使用するため。
時々、新しいオペレーティングシステム機能を利用したい場合があります。私たちはカーネルと VM 内の OS を制御しているため、全てのユーザに対し各機能をただちに提供できます。たとえ、マシン OS の LTS バージョンを固定しようとしているユーザに対してもです。
セキュリティを拡張します。
コンテナ イメージの脆弱性は、ホスト環境に対してセキュリティの危険性をもたらします。数多くの非公式イメージは、既知の脆弱性に対する対応が保証されていません。悪意のあるユーザは公開レジストリにイメージを送信でき、異なる手法でユーザがイメージをダウンロードして実行するよう企みます。VM のアプローチにより、VM からはホストにアクセスできない環境のため、 root 特権の取得を試みるあらゆるマルウェアによる脅威を抑制します。
どうして rootless Docker を実行しないのでしょうか？ これは root ユーザに対するアクセスを表面的に制限する利点があり、何より最も安全に見えますが、権限のないユーザが自身のユーザ名前空間内で
CAP_SYS_ADMINを得ると、特権のないユーザにより予期しないカーネル API にアクセスされ、結果として 脆弱性 になります。
性能上の影響を最小限にしながら、同等性の機能と、強化されたセキュリティという利点を提供するためです。
DD4L が使われる VM は
virtiofsを使います。これは、共有ファイルシステムであり、仮想マシンがホスト上にあるディレクトリツリーに直接アクセスできるようにします。私たちの内部ベンチマークが示すのは、VM へ正しいリソースを割り当てると、 virtiofs ファイルシステムはネイティブに近い性能を発揮します。それで、 DD4L では VM に割り当て可能なデフォルトのメモリを調整しました。この設定を調整するには、 Docker Desktop の Settings > Resources タブのなかにある Memory スライダを使います。
ファイル共有¶
Docker Desktop for Linux は、ホストと Docker Desktop VM 間でファイル共有をできるようにするため、デフォルト（かつ現時点では唯一）の手法として virtiofs を使います。共有ファイルの操作に不要な制限を加えることなく、特権への昇格を不要とするために、Docker Desktop はユーザ名前空間内に（ user_namespaces(7) 参照）ファイル共有サービス（ virtiofsd ）を実行し、 UID と GID の割り当てを調整可能にします。結果として Docker Desktop は、現在のユーザが /etc/subuid （ subuid(5) 参照）と /etc/subgid （ subgid(5) 参照）の存在が必要です。Docker Desktop はファイルを経由した下位 ID 委任のみサポートします。Docker Desktop は現在のユーザ ID と GID をコンテナ内では 0 に割り当て（マップ）します。 /etc/subuid と /etc/subgid の現在のユーザに対応する1つめのエントリを使い、コンテナ内で先ほどの 0 を適切な ID に割り当てます。
コンテナ内の ID |
ホスト上の ID |
|---|---|
0 (root) |
Docker Desktop を実行ｓているユーザの ID （例： 1000 ） |
1 |
0 + |
2 |
1 + |
3 |
2 + |
… |
… |
もしも /etc/subuid と /etc/subgid が無ければ、作成の必要があります。どちらも <username>:<start of id range>:<id range size> の形式でのエントリを含む必要があります。たとえば、現在のユーザに対して 100000 から 165535 までの使用を許可するには：
$ grep "$USER" /etc/subuid >> /dev/null 2&>1 || (echo "$USER:100000:65536" | sudo tee -a /etc/subuid)
$ grep "$USER" /etc/subgid >> /dev/null 2&>1 || (echo "$USER:100000:65536" | sudo tee -a /etc/subgid)
設定により、正しく作成されているかどうかを確認するには、それぞれのコンテナを調べます：
$ echo $USER
exampleuser
$ cat /etc/subuid
exampleuser:100000:65536
$ cat /etc/subgid
exampleuser:100000:65536
たとえば、 Docker Desktop コンテナ内で、UID が 1000 のユーザが所有するよう chown された共有ファイルは、ホスト上では UID が 100999 のユーザによって所有されているように表示されます。このため、ホスト上でこのようなファイルに簡単にアクセスできないという、残念な副作用があります。この問題を解決するには、新しい GID でグループを作成し、そこに私たちのユーザを追加するか、Docker Desktop VM で共有しているフォルダに再帰的 ACL（ setfacl(1)`` ）を設定します。
次はどこへ行きますか¶
トラブルシューティング は一般的な問題、回避方法、統計情報の送信方法、問題報告の仕方があります。
FAQs は、よく見受けられる質問と回答があります。
リリースノート は Docker Desktop リリースに関連する更新コンポーネント、新機能、改良の一覧があります。
Docker の始め方 は一般的な Docker チュートリアルです。
バックアップと修復 は Docker 関連データのバックアップと修復手順です。
参考
- Install Docker Desktop on Linux