Docker

関連記事

• systemd-nspawn
• Linux Containers
• Vagrant
• Podman

Docker は軽量コンテナとしてあらゆるアプリケーションを詰めて運んで実行できるユーティリティです。

ノート: 訳注: この記事では、https://docs.docker.com のリンクとともに https://docs.docker.jp のリンクも合わせて表示していますが、一部の翻訳が古い場合があります。

インストール

Docker イメージを pull し Docker コンテナを実行するには、Docker Engine が必要です。Docker Engine には、コンテナを管理するデーモンや docker CLI フロントエンドが含まれています。docker パッケージをインストールしてください。開発版は docker-git^AUR パッケージをインストールしてください。次に、docker.service を開始/有効化して、動作することを確認してください:

# docker info

アクティブな vpn 接続がある場合、docker サービスの起動に失敗することがあることに注意してください。VPN と Docker のブリッジネットワークやオーバーレイネットワークの間で IP が競合するからです。このような場合、docker サービスの起動前に vpn を切断してみてください。その後すぐに vpn に再接続できます。ネットワークの衝突解除を試してみることも可能です (解決策については、 [1] や [2] をご覧ください)。

次に、コンテナが動作することを検証します。次のコマンドは、最新の Arch Linux イメージをダウンロードし、そのイメージを使ってコンテナの中で Hello World プログラムを実行します:

# docker run -it --rm archlinux bash -c "echo hello world"

docker CLI コマンドを非 root ユーザとして実行できるようにしたい場合は、ユーザーを docker グループに追加して、ログインし直し、docker.service を再起動してください。

警告: ユーザーを docker グループに追加することは、そのユーザーを root にするのと等価です。なぜなら、そのグループに属するユーザーは docker run --privileged コマンドを実行して、コンテナを root 権限で開始することができるからです。詳しくは こちら や こちら (日本語訳ページ) を参照してください。

Docker Compose

Docker Compose (日本語訳ページ) は Docker Engine の代替 CLI フロントエンドです。(例として) docker run のオプションを使うスクリプトではなく、docker-compose.yml YAML ファイルを使ってコンテナのプロパティを指定します。これは、しばしば使用されたり複雑な設定を持っていたりするサービスを何度も設定する際に便利です。Docker Compose を使うには、docker-compose をインストールしてください。

Docker Desktop

Docker Desktop は、Linux 仮想マシン内で Docker Engine を実行するプロプライエタリなデスクトップアプリケーションです。Kubernetes クラスタや脆弱性スキャナなどの追加の機能が含まれています。このアプリケーションは、macOS や Windows を使って Docker コンテナを開発するソフトウェア開発チームにとって便利です。このアプリケーションの Linux 移植は比較的新しく、Docker の CLI フロントエンドを補完します [3]。Arch 向けの実験的なパッケージは Docker によって直接提供されています; 詳細は マニュアル (日本語訳ページ) を見てください。残念ながら、そのパッケージには docker-compose パッケージと衝突するファイルが含まれているため、docker-compose がインストールされている場合はまずそれを削除する必要があります。

また、Docker Desktop を実行するには、Linux システム要件 (日本語訳ページ) を満たしている必要があります (要件には KVM による仮想化サポートが含まれています)。Gnome でのトレイアイコンを有効化するには、gnome-shell-extension-appindicator が必要です。

最後に、ファイル共有サポートは、ユーザとグループの id を /etc/subuid と /etc/subgid を通してマッピングする必要があります。詳細は Docker Desktop For Linux ファイル共有指示書 (日本語訳ページ) を見てください。

使用法

Docker は複数のパーツから成ります:

• Docker デーモン (Docker Engine とも呼ばれています)。docker.service として実行されるプロセスです。Docker API を提供し、Docker コンテナを管理します。
• docker CLI コマンド。ユーザがコマンドラインを通して Docker API と対話し、Docker デーモンを管理できるようにします。
• Docker コンテナ。Docker API を通して要求された通りに Docker デーモンが起動・管理する、名前空間で隔離されたプロセスです。

通常、ユーザは docker CLI コマンドを実行することで Docker を使用します。コマンドは Docker デーモンにアクションの実行を要求し、Docker コンテナを管理します。クライアント (docker)、サーバ (docker.service)、コンテナ間の関係を理解することは、Docker を正しく管理するために重要です。

Docker デーモンが停止/再起動した場合、現在実行中の Docker コンテナもすべて停止/再起動されることに注意してください。

Docker API にリクエストを送信して、docker CLI コマンドを使わずに Docker デーモンを制御することも可能です。詳細は Docker API 開発ドキュメントを見てください。

使用法に関するドキュメントは the Docker Getting Started guide (日本語訳ページ) を見てください。

設定

設定ファイル /etc/docker/daemon.json を使うか、docker.service systemd ユニットにコマンドラインフラグを追加することで、Docker デーモンを設定することができます。Docker 公式ドキュメント (日本語訳ページ) によると、設定ファイルによる方法が推奨されています。コマンドラインフラグの方を使いたい場合は、systemd のドロップインファイル を使って、docker.service の ExecStart ディレクティブを上書きしてください。

daemon.json のオプションに関する詳細は、dockerd のドキュメント (日本語訳ページ) を見てください。

ストレージドライバー

ストレージドライバー (日本語訳ページ) は、Docker ホスト上でイメージとコンテナをどのように格納し管理するかを制御します。デフォルトの overlay2 ドライバはパフォーマンスが良く、最近の Linux カーネルとファイルシステムすべてで良い選択肢です。古い Linux カーネルとの互換性のために devicemapper や aufs などのレガシーなドライバがありますが、Arch Linux の overlay2 ではなくこれらを使う利点はありません。

btrfs や ZFS のユーザは btrfs や zfs のドライバを使用できます。それぞれのドライバは、これらのファイルシステムのユニークな機能を活用します。詳細とステップ・バイ・ステップの説明は btrfs ドライバ (日本語訳ページ) と zfs ドライバ (日本語訳ページ) のドキュメントを見てください。

デーモンのソケット

デフォルトで、Docker デーモンは Unix ソケット /var/run/docker.sock を用いて Docker API を提供します。ほとんどの場合、この方法は適切です。

さらに TCP ソケットをリッスンするようにデーモンを設定できます。これにより、他のコンピュータからリモートで Docker API にアクセスできるようになります [4]。そうすることで、ホストマシン上の docker コマンドから Linux 仮想マシン (Windows や macOS システム上の Arch 仮想マシン) 上の Docker デーモンにアクセスできるようになり、便利です。

警告: デフォルトで Docker API は暗号化も認証もされません。TLS 暗号化や認証が有効化されていなかったり、認証 HTTP リバースプロキシや適切なDocker の追加設定 (日本語訳ページ) がなされていなかったりした場合、Docker デーモンへのリモート TCP アクセスは安全でない root アクセスと等価です。一般に、Docker API の TCP ソケットを有効化することは、セキュリティ上、高リスクであるとみなすべきです。

デフォルトの docker.service ファイルは -H フラグをデフォルトでセットします。そして、フラグと /etc/docker/daemon.json ファイルの両方にオプションが存在する場合、Docker は起動しません。なので、ソケットの設定を変更する最も単純な方法は、ドロップインファイルを使うことです。以下は、ポート 2376 上に TCP ソケットを追加します:

/etc/systemd/system/docker.service.d/execstart.conf

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2376

systemd デーモンをリロードし、docker.service を再起動して変更を適用してください。

HTTP プロキシ

HTTP プロキシを使うために設定すべきなのは、Docker デーモンと Docker コンテナです。

Docker デーモンのプロキシ設定

HTTP プロキシを設定するための systemd ドロップインユニットの設定に関する Docker ドキュメント (日本語訳ページ) を見てください。

Docker コンテナのプロキシ設定

docker CLI を使用して作成されたすべてのコンテナに対してプロキシを自動で設定する方法は プロキシ設定に関する Docker ドキュメント (日本語訳ページ) を見てください。

DNS の設定

Docker コンテナ内での DNS の動作に関するドキュメントや、DNS の設定のカスタマイズに関する情報は Docker の DNS に関するドキュメント (日本語訳ページ) を見てください。ほとんどの場合、ホストで設定されているリゾルバは、コンテナ内でも設定されています。

127.0.0.0/8 でホストされている DNS リゾルバのほとんどは、コンテナとホストのネットワーク名前空間の衝突により、サポートされていません。そのようなリゾルバは、コンテナの /etc/resolv.conf から削除されます。このせいで /etc/resolv.conf が空になる場合は、Google DNS が代わりに使用されます。

さらに、127.0.0.53 が、設定されている唯一のネームサーバである場合は、特殊なケースとして処理されます。この場合、Docker はリゾルバが systemd-resolved であると仮定し、/run/systemd/resolve/resolv.conf にある 上流の DNS リゾルバを使用します。

If you are using a service such as dnsmasq to provide a local resolver, consider adding a virtual interface with a link local IP address in the 169.254.0.0/16 block for dnsmasq to bind to instead of 127.0.0.1 to avoid the network namespace conflict.

イメージの置き場所

デフォルトでは、docker のイメージは /var/lib/docker に保存されます。置き場所は別のパーティションに移動することが可能です (例えば、イメージ用の専用のパーティションかディスクを使いたい場合)。ここでは、例として /mnt/docker にイメージを移動することにします。

まず、docker.service を停止してください。すると、現在実行中のコンテナがすべて停止され、実行中のイメージはすべてアンマウントされます。これで、イメージを /var/lib/docker から目的の場所へ移動できるようになります (例: cp -r /var/lib/docker /mnt/docker)。

/etc/docker/daemon.json 内の data-root を設定してください:

/etc/docker/daemon.json

{
  "data-root": "/mnt/docker"
}

変更を適用するために、docker.service を再起動してください。

安全ではないレジストリ

プライベートレジストリに自己署名証明書を使うことにした場合、あなたが信頼すると宣言するまで Docker はその使用を拒否します。例えば、myregistry.example.com:8443 でホストされているレジストリのイメージを許可するには、/etc/docker/daemon.json ファイル内の insecure-registries を設定してください:

/etc/docker/daemon.json

{
  "insecure-registries": [
    "my.registry.example.com:8443"
  ]
}

変更を適用するために docker.service を再起動してください。

IPv6

In order to enable IPv6 support in Docker, you will need to do a few things. See [5] and [6] for details.

Firstly, enable the ipv6 setting in /etc/docker/daemon.json and set a specific IPv6 subnet. In this case, we will use the private fd00::/80 subnet. Make sure to use a subnet at least 80 bits as this allows a container's IPv6 to end with the container's MAC address which allows you to mitigate NDP neighbor cache invalidation issues.

/etc/docker/daemon.json

{
  "ipv6": true,
  "fixed-cidr-v6": "fd00::/80"
}

Restart docker.service to apply changes.

Finally, to let containers access the host network, you need to resolve routing issues arising from the usage of a private IPv6 subnet. Add the IPv6 NAT in order to actually get some traffic:

# ip6tables -t nat -A POSTROUTING -s fd00::/80 ! -o docker0 -j MASQUERADE

Now Docker should be properly IPv6 enabled. To test it, you can run:

# docker run curlimages/curl curl -v -6 archlinux.org

If you use firewalld, you can add the rule like this:

# firewall-cmd --zone=public --add-rich-rule='rule family="ipv6" destination not address="fd00::1/80" source address="fd00::/80" masquerade'

If you use ufw, you need to first enable ipv6 forwarding following Uncomplicated Firewall#Forward policy. Next you need to edit /etc/default/ufw and uncomment the following lines

/etc/ufw/sysctl.conf

net/ipv6/conf/default/forwarding=1
net/ipv6/conf/all/forwarding=1

Then you can add the iptables rule:

# ip6tables -t nat -A POSTROUTING -s fd00::/80 ! -o docker0 -j MASQUERADE

It should be noted that, for docker containers created with docker-compose, you may need to set enable_ipv6: true in the networks part for the corresponding network. Besides, you may need to configure the IPv6 subnet. See [7] for details.

ユーザ名前空間の隔離

By default, processes in Docker containers run within the same user namespace as the main dockerd daemon, i.e. containers are not isolated by the user_namespaces(7) feature. This allows the process within the container to access configured resources on the host according to Users and groups#Permissions and ownership. This maximizes compatibility, but poses a security risk if a container privilege escalation or breakout vulnerability is discovered that allows the container to access unintended resources on the host. (One such vulnerability was published and patched in February 2019.)

The impact of such a vulnerability can be reduced by enabling user namespace isolation. This runs each container in a separate user namespace and maps the UIDs and GIDs inside that user namespace to a different (typically unprivileged) UID/GID range on the host.

ノート:

• The main dockerd daemon still runs as root on the host. Running Docker in rootless mode is a different feature.
• Processes in the container are started as the user defined in the USER directive in the Dockerfile used to build the image of the container.
• All containers are mapped into the same UID/GID range. This preserves the ability to share volumes between containers.
• Enabling user namespace isolation has several limitations. Also, Kubernetes currently does not work with this feature.
• Enabling user namespace isolation effectively masks existing image and container layers, as well as other Docker objects in /var/lib/docker/, because Docker needs to adjust the ownership of these resources. The upstream documentation recommends to enable this feature on a new Docker installation rather than an existing one.

Configure userns-remap in /etc/docker/daemon.json. default is a special value that will automatically create a user and group named dockremap for use with remapping.

/etc/docker/daemon.json

{
  "userns-remap": "default"
}

Configure /etc/subuid and /etc/subgid with a username/group name, starting UID/GID and UID/GID range size to allocate to the remap user and group. This example allocates a range of 65536 UIDs and GIDs starting at 165536 to the dockremap user and group.

/etc/subuid

dockremap:165536:65536

/etc/subgid

dockremap:165536:65536

Restart docker.service to apply changes.

After applying this change, all containers will run in an isolated user namespace by default. The remapping may be partially disabled on specific containers passing the --userns=host flag to the docker command. See [8] for details.

Rootless Docker デーモン

警告: Docker rootless は非特権ユーザの名前空間の利用 (CONFIG_USER_NS_UNPRIVILEGED) に依存しており、これはセキュリティ上、重要な意味を持ちます。詳細については、セキュリティ#アプリケーションのサンドボックス化 をご覧ください

Docker デーモン自体を通常ユーザとして実行するには、docker-rootless-extras^AUR パッケージをインストールしてください。

/etc/subuid と /etc/subgid に ユーザ名/グループ名、開始 UID/GID、そして UID/GID 範囲を設定し、再割り当てユーザ/グループに割り当てます:

/etc/subuid

your_username:165536:65536

/etc/subgid

your_username:165536:65536

docker.socket ユーザユニット を 有効化します。これにより、docker は systemd の socket activation を利用して開始されます。

最後に docker ソケットの環境変数を設定します:

$ export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock

ネイティブ overlay diff エンジンを有効化する

デフォルトでは、Docker は Arch Linux 上でネイティブの overlay diff エンジンを使用できません。これにより、Docker イメージのビルドが遅くなります。頻繁にイメージをビルドする場合は、[9] で説明されているようにネイティブの diff エンジンを設定してください:

/etc/modprobe.d/disable-overlay-redirect-dir.conf

options overlay metacopy=off redirect_dir=off

その後、docker.service を停止し、以下のように overlay モジュールを再読込してください:

# modprobe -r overlay
# modprobe overlay

そして、docker.service を再起動してください。

確認するには、docker info を実行して、Native Overlay Diff が true になっているかどうか見てください。

イメージ

Arch Linux

以下のコマンドは archlinux x86_64 イメージを pull します。これはネットワークなどを落とした Arch コア環境です:

# docker pull archlinux

README.md も見てください。

完全な Arch ベースは、上記からリポジトリを clone し、独自のイメージをビルドしてください。

$ git clone https://gitlab.archlinux.org/archlinux/archlinux-docker.git

パッケージ devtools、fakechroot、fakeroot はインストールされていることに注意してください。

ベースイメージをビルドするには:

$ make image-base

Alpine Linux

Alpine Linux は、(特に静的バイナリとしてコンパイルされたソフトウェアための) 小さなコンテナイメージとして人気の選択肢です。以下のコマンドは最新の Alpine Linux イメージを pull します:

# docker pull alpine

Alpine Linux は、ほとんどの Linux ディストリビューションで使用されている glibc libc 実装ではなく、musl libc 実装を使用します。Arch Linux は glibc を使用するので、Arch Linux ホストと Alpine Linux コンテナの間には機能的な違いが一定数存在し、ソフトウェアのパフォーマンスと正確性に影響を与えます。これらの違いのリストは、ここでドキュメント化されています。

Arch Linux (または glibc を使用する他のシステム) でビルドされた動的リンクのソフトウェアは、Alpine Linux (または異なる libc を使用する他のシステム) 上で実行すると、バグとパフォーマンス上の問題を生じる場合があります。例は、[10]、[11]、[12] を見てください。

CentOS

次のコマンドは最新の centos イメージを pull します:

# docker pull centos

各 CentOS リリースで利用可能なタグの完全なリストは Docker Hub ページを見てください。

Debian

次のコマンドは最新の debian イメージを pull します:

# docker pull debian

(各 Debian リリースの標準バージョンとスリムバージョンの療法を含む) 利用可能なタグの完全なリストは Docker Hub ページを見てください。

Distroless

Google は、パッケージマネージャやシェルなどの OS コンポーネントの無い最小イメージである distroless イメージをメンテナンスしています。これにより、ソフトウェアをパッケージングするためにイメージのサイズを非常に小さくできます。

イメージのリストと様々なプログラミング言語での使用法に関する指示は GitHub README を見てください。

NVIDIA GPU で GPU アクセラレートされた Docker コンテナを動かす

NVIDIA Container Toolkit を使う (推奨)

Docker バージョン 19.03 より、NVIDIA GPU が Docker デバイスとしてネイティブにサポートされています。NVIDIA GPU を活用するコンテナの実行方法として NVIDIA Container Toolkit が推奨されています。

nvidia-container-toolkit^AUR パッケージをインストールしてください。次に、docker を再起動してください。これで、--gpus オプションを使うことで、NVIDIA GPU を使用するコンテナを実行できるようになります:

# docker run --gpus all nvidia/cuda:11.3.0-runtime-ubuntu20.04 nvidia-smi

コンテナ内でいくつの GPU を有効化するかを指定するには:

# docker run --gpus 2 nvidia/cuda:11.3.0-runtime-ubuntu20.04 nvidia-smi

どの GPU を使用するかを指定するには:

# docker run --gpus '"device=1,2"' nvidia/cuda:11.3.0-runtime-ubuntu20.04 nvidia-smi

あるいは

# docker run --gpus '"device=UUID-ABCDEF,1"' nvidia/cuda:11.3.0-runtime-ubuntu20.04 nvidia-smi

コンテナで使用する機能 (グラフィックス、計算、...) を指定するには (とはいえ、この方法が使用されるのは稀です):

# docker run --gpus all,capabilities=utility nvidia/cuda:11.3.0-runtime-ubuntu20.04 nvidia-smi

詳細は README.md と Wiki を見てください。

NVIDIA Container Runtime を使う

nvidia-container-runtime^AUR パッケージをインストールしてください。次に、/etc/docker/daemon.json を編集して NVIDIA ランタイムを登録してください:

/etc/docker/daemon.json

{
  "runtimes": {
    "nvidia": {
      "path": "/usr/bin/nvidia-container-runtime",
      "runtimeArgs": []
    }
  }
}

そして、docker を再起動してください。

ランタイムは、dockerd にコマンドラインオプションを渡すことでも登録できます:

# /usr/bin/dockerd --add-runtime=nvidia=/usr/bin/nvidia-container-runtime

その後、GPU アクセラレートされたコンテナを実行するには:

# docker run --runtime=nvidia nvidia/cuda:9.0-base nvidia-smi

あるいは (以下の方法は Docker バージョン 19.03 およびそれ以降が必要です):

# docker run --gpus all nvidia/cuda:9.0-base nvidia-smi

README.md も見てください。

nvidia-docker を使う (非推奨)

nvidia-docker は NVIDIA Container Runtime のラッパーです。デフォルトで NVIDIA ランタイムを登録し、nvidia-docker コマンドを提供します。

nvidia-docker を使うには、nvidia-docker^AUR パッケージをインストールし、docker を再起動してください。NVIDIA GPU サポートのあるコンテナは以下の方法で実行できます:

# docker run --runtime=nvidia nvidia/cuda:9.0-base nvidia-smi

# nvidia-docker run nvidia/cuda:9.0-base nvidia-smi

または (以下の方法は Docker バージョン 19.03 およびそれ以降が必要です):

# docker run --gpus all nvidia/cuda:9.0-base nvidia-smi

ノート: nvidia-docker は、NVIDIA GPU でアクセラレートされたコンテナを実行する、Docker 19.03 以前で使用されていた旧来の方法で、非推奨となっています。Docker バージョン 19.03 およびそれ以降を使用している場合、代わりに NVIDIA Container Toolkit を使用することを推奨します。

CUDA 付き Arch Linux イメージ

以下の Dockerfile を使うことで、CUDA 付きのカスタム Arch Linux イメージをビルドできます。ホスト上で pacman パッケージをキャッシュするために Dockerfile frontend syntax 1.2 を使用します。Docker イメージをビルドする前に、クライアント上で DOCKER_BUILDKIT=1 環境変数を設定する必要があります。

Dockerfile

# syntax = docker/dockerfile:1.2

FROM archlinux

# install packages
RUN --mount=type=cache,sharing=locked,target=/var/cache/pacman \
    pacman -Syu --noconfirm --needed base base-devel cuda

# configure nvidia container runtime
# https://github.com/NVIDIA/nvidia-container-runtime#environment-variables-oci-spec
ENV NVIDIA_VISIBLE_DEVICES all
ENV NVIDIA_DRIVER_CAPABILITIES compute,utility

便利なヒント

実行中のコンテナの IP アドレスを取得するには:

$ docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' <container-name OR id> 

172.17.0.37

それぞれの実行中のコンテナについて、/etc/hosts で使うために名前と対応する IP アドレスを出力:

#!/usr/bin/env sh
for ID in $(docker ps -q | awk '{print $1}'); do
    IP=$(docker inspect --format="{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}" "$ID")
    NAME=$(docker ps | grep "$ID" | awk '{print $NF}')
    printf "%s %s\n" "$IP" "$NAME"
done

クロスコンパイルに buildx を使う

Docker バージョン 19.03 から [13]、Docker パッケージには、新しい BuildKit building toolkit (日本語訳ページ) を使う buildx CLI プラグインが含まれています。buildx インターフェイスはマルチプラットフォームなイメージのビルドをサポートしています (ホストのアーキテクチャ以外も)。

イメージのクロスコンパイルには QEMU が必要です。Docker 内で QEMU の静的ビルドをセットアップする方法については、multiarch/qemu-user-static イメージの情報を見てください。あるいは、QEMU をホストのシステム上でセットアップして、Docker と一緒に使う方法については、QEMU#x86_64 から arm/arm64 環境への chrooting を見てください。どちらの場合にせよ、あなたのシステムはゲストアーキテクチャのユーザモードエミュレート用に設定されます。

$ docker buildx ls
NAME/NODE DRIVER/ENDPOINT STATUS  PLATFORMS
default * docker                  
  default default         running linux/amd64, linux/386, linux/arm64, linux/riscv64, linux/s390x, linux/arm/v7, linux/arm/v6

Docker とイメージの削除

Docker を完全に削除したい場合は以下の手順に従ってください。

ノート: コマンドを実行する前にどういう意味なのか考えてください。何も考えずにコピーアンドペーストしてはいけません。

実行中のコンテナをチェックする:

# docker ps

削除するために、ホスト上で実行中のコンテナをすべて表示する:

# docker ps -a

実行中のコンテナを停止する:

# docker stop <CONTAINER ID>

依然として実行中のコンテナを kill する:

# docker kill <CONTAINER ID>

ID でリストされたコンテナを削除する:

# docker rm <CONTAINER ID>

Docker イメージをすべて表示する:

# docker images

ID でイメージを削除する:

# docker rmi <IMAGE ID>

コンテナに関連付けられていない (ダングリング) すべてのイメージ、コンテナ、ボリューム、ネットワークを削除する:

# docker system prune

停止中のコンテナと未使用のイメージ (ダングリングイメージでないもの) を追加で削除するには、-a フラグをコマンドに追加してください:

# docker system prune -a

すべての Docker データを削除する (ディレクトリを削除する):

# rm -R /var/lib/docker

トラブルシューティング

systemd-networkd を使用していると、docker0 ブリッジが IP を取得できない / コンテナからインターネットにアクセスできない

Docker はグローバルに IP フォワーディングを有効化しようと試みますが、デフォルトでは、定義されているネットワークプロファイルのグローバルな sysctl 設定を systemd-networkd が上書きしてしまいます。ネットワークプロファイルに IPForward=yes を設定してください。詳しくは インターネット共有#パケット転送の有効化 を参照してください。

systemd-networkd が Docker によって作成されたネットワークインターフェイスを管理しようとする場合 (例えば、Match セクションに Name=* を設定した場合)、接続の問題が発生する可能性があります。それらのインターフェイスの管理を無効化してみてください。例えば、networkctl list を実行すると、SETUP 列ですべての Docker によって作成されたネットワークは unmanaged と表示される必要があります。

ノート:

• systemd-networkd.service や iptables.service を再起動したときは docker.service を再起動する必要があります。
• また、デフォルトで nftables が docker の接続をブロックする可能性も考慮してください。nft list ruleset を使ってブロックしているルールを確認してください。nft flush chain inet filter forward で一時的に全ての転送ルールを削除できます。変更を永続化するには /etc/nftables.conf を編集してください。設定ファイルからルールをリロードするために nftables.service を再起動することを忘れないでください。Docker での nftables サポートに関する詳細は [14] を見てください。

デフォルトで使用できるプロセスやスレッドの数が少なすぎる

以下のようなエラーメッセージが表示される場合:

# Java の場合
java.lang.OutOfMemoryError: unable to create new native thread
# C、bash などの場合
fork failed: Resource temporarily unavailable

systemd によって許可されるプロセスの数を調整する必要があります。デフォルトは 500 ですが (system.conf を確認してください)、複数の docker コンテナを動作させるには少なすぎます。以下のように docker.service を編集してください:

[Service]
TasksMax=infinity

Error initializing graphdriver: devmapper

systemctl で docker の起動に失敗して以下のエラーが表示される場合:

Error starting daemon: error initializing graphdriver: devmapper: Device docker-8:2-915035-pool is not a thin pool

エラーを解消するには、サービスを停止して、/var/lib/docker/ を (必要に応じて) バックアップし、/var/lib/docker/ の中身を消してから、サービスを起動してみてください。詳しくは GitHub issue を参照。

Failed to create some/path/to/file: No space left on device

以下のようにエラーメッセージが表示される場合:

ERROR: Failed to create some/path/to/file: No space left on device

Docker イメージの作成・実行時、ディスク容量が十分に存在するにもかかわらず、上記のメッセージが表示されるときは以下を確認してください:

• Tmpfs が無効になっているか。十分なメモリが割り当てられているか。Docker が /tmp にファイルを書き出そうとしていて、ディスク容量ではなくメモリ使用量が制限となっている可能性があります。
• XFS を使っている場合、/etc/fstab の (/tmp や /var/lib/docker がある) エントリから noquota マウントオプションを削除するべきかもしれません。詳しくはディスククォータを参照してください。Docker ストレージドライバーの overlay2 を使用するときは特に注意してください。
• XFS クォータのマウントオプション (uquota, gquota, prjquota など) がファイルシステムの再マウント時に失敗している。ルートファイルシステムでクォータを使うには、マウントオプションを rootflags= カーネルパラメータで initramfs に渡す必要があります。その場合、root (/) ファイルシステムのマウントオプションとして /etc/fstab に指定してはいけません。

ノート: XFS のクォータと Linux 標準のディスククォータには違いが存在します。[15] は読む価値があるかもしれません。

virtualbox ドライバーを使用したときに Docker-machine が仮想マシンの作成に失敗する

以下のように virtualbox ドライバーで docker-machine が仮想マシンの作成に失敗する場合:

VBoxManage: error: VBoxNetAdpCtl: Error while adding new interface: failed to open /dev/vboxnetctl: No such file or directory

vboxreload で CLI から virtualbox をリロードしてください。

Docker を起動すると KVM のブリッジネットワークが壊れる

この問題は、Docker のスクリプトがいくつかの iptables ルールを追加し、それ自体のインターフェイス以外のインターフェイスのフォワーディングをブロックしてしまうというものです。これは既知の問題です。

以下の解決策では、br0 をあなたのブリッジ名に置き換えてください。

最も速い解決策は (しかし、これは Docker の iptabkes 自己追加調整機能をすべて無効化してしまいます。これは望ましくない場合があります。):

/etc/docker/daemon.json

{
  "iptables": false
}

KVM 用に設定されたネットワークブリッジがすでに存在する場合、Docker にそのことを伝えることで解決できる場合があります。[16] を見て、以下のように docker の設定を変更してください:

/etc/docker/daemon.json

{
  "bridge": "br0"
}

上記の設定がうまく行かない場合や、UFW のようなマネージャ、あるいは iptables を通して直接この問題を解決したい場合、以下を追加してください:

iptables -I FORWARD -i br0 -o br0 -j ACCEPT

更に詳しい解決策は ここ にあります。

Docker Hub からのイメージ取得に速度制限が掛かる

2020年11月1日より、無名アカウントや無料アカウントによる Docker Hub からのダウンロードには速度制限がかかるようになりました。詳細は 速度制限に関するドキュメント を見てください。

認証されていない速度制限はソースの IP によって追跡され、認証済みの速度制限はアカウントによって追跡されます。

速度制限を超過する必要がある場合、有料プランに登録するか、必要なイメージを別のイメージレジストリでミラーすることで可能です。自分自身のレジストリをホストする (日本語訳ページ) こともできますし、Amazon ECR、Google Container Registry、Azure Container Registry、Quay Container Registry などのクラウドでホストされているレジストリを使うこともできます。

イメージをミラーするには、Docker CLI のサブコマンド pull、tag、push を使ってください。例えば、Nginx イメージの 1.19.3 タグを、cr.example.com でホストされているレジストリでミラーするには:

$ docker pull nginx:1.19.3
$ docker tag nginx:1.19.3 cr.example.com/nginx:1.19.3
$ docker push cr.example.com/nginx:1.19.3

その後に、そのミラーからイメージを pull または実行することができます:

$ docker pull cr.example.com/nginx:1.19.3
$ docker run cr.example.com/nginx:1.19.3

iptables (legacy): unknown option "--dport"

コンテナの実行中にこのエラーが発生する場合は、iptables (legacy) の代わりに iptables-nft をインストールして、再起動してください [17]。

参照

• 公式ウェブサイト
• docs.docker.com の Arch Linux (日本語訳)
• Are Docker containers really secure? — opensource.com
• Awesome Docker
• Why A Privileged Container in Docker Is a Bad Idea