Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

このガイドについて

はじめに

Docker Engine ユーザガイド〜リファレンス編

このガイドについて
Docker Engine ドキュメント（https://docs.docker.com/）の⽇本語翻訳版（http://docs.docker.jp/）をもとに電⼦データ化しました。

免 責事項
現時点ではベータ版であり、内容に関しては無保証です。PDF の評価⽤として公開しました。Docker は活発な開発と改善が続いています。同様に、ドキュメントもオリジナルですら⽇々書き換えが進んでいますので、あらかじめご了承願います。
このドキュメントに関する問題や翻訳に対するご意⾒がありましたら、GitHub リポジトリ上の Issue までご連絡いただくか、pull request をお願いいたします。

 https://github.com/zembutsu/docs.docker.jp

履歴 2016 年 5 ⽉ 20 ⽇ リファレンス編 beta1 を公開- 1 -docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

このガイドについて目次

このガイドについて
免責事項
履歴

1

1

1

A1.1 ⽤ 語 集

9aufs (エ ー ユ ー エ フ エ ス )9

ベ ー ス ・ イ メ ー ジ （ base image）
boot2docker
btrfs

9

9

9

ビ ル ド （ build）
cgroups

10

Compose

10

コンテナ

10

9

データ・ボリューム
Docker10

10Docker Hub
D o c k e r fi l e

1011

ファイルシステムイメージ

11

libcontainer
libnetwork

1111

リ ン ク 機 能 （ link）
Machine

11

11

12

オーバレイ・ネットワーク・ドライバ
オーバレイ・ストレージ・ドライバ
レ ジ ス ト リ （ registry）
リポジトリ
Swarm
タグ

12

12

12

12

12

12

Toolbox13

ユニオン・ファイル・システム
仮想マシン

13

13

A2.1 docker run リ フ ァ レ ン ス

14

- 2 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

⼀般的な形式

このガイドについて

14

作業者専⽤のオプション

15

デタッチドまたはフォアグラウンド
デ タ ッ チ ド (-d)

15

フォアグラウンド

15

コンテナの識別16

名 前 （ --name）

16

PID 相 当 の 機 能16

イ メ ー ジ [:タ グ ]16

イ メ ー ジ [@ダ イ ジ ェ ス ト 値 ]PID 設 定 （ --pid）

17

UTS 設 定 （ --uts）

17

IPC 設 定 （ --ipc）

17

ネットワーク設定

18

ネ ッ ト ワ ー ク ： none

ネ ッ ト ワ ー ク ： host

18

19

ネ ッ ト ワ ー ク ： container

19

ユーザ定義ネットワーク

19/etc/hosts の 管 理

1718

ネ ッ ト ワ ー ク ： bridge

20

再 起 動 ポ リ シ ー （ --restart）

20

終 了 ス テ ー タ ス （ exit status）
ク リ ー ン ア ッ プ （ --rm）
セキュリティ設定

21

22

22

カ ス タ ム cgroups の 指 定

23

実⾏時のリソース制限

23

ユーザ・メモリの制限

24

カーネル・メモリ制限

25

ス ワ ッ プ 回 避 （ swappiness） 制 限
CPU 共 有 制 限

2626

CPU 周 期 （ period） 制 約
CPU セ ッ ト 制 限

27

27

CPU ク ォ ー タ 制 限

28

ブ ロ ッ ク IO 帯 域 （ blkio） 制 限
グループの追加

15

28

28

実 ⾏ 時 の 権 限 、 Linux 機 能 、 LXC 設 定
ロ グ 記 録 ド ラ イ バ （ --log-driver）

28

31

Dockerﬁ le イ メ ー ジ の デ フ ォ ル ト よ り 優 先

32
- 3 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

このガイドについてCMD（ デ フ ォ ル ト の コ マ ン ド か オ プ シ ョ ン ）32

ENTRYPOINT（ 実 ⾏ 時 に 処 理 す る デ フ ォ ル ト の コ マ ン ド ）EXPOSE （ 露 出 ⽤ の ポ ー ト ）ENV（ 環 境 変 数 ）33

34

TMPFS（ tmfps フ ァ イ ル シ ス テ ム の マ ウ ン ト ）VOLUME（ 共 有 フ ァ イ ル シ ス テ ム ）
USER

32

34

34

35

WORKDIR

36

A2.2 Docker コ マ ン ド

37

A1.2.1 Docker コ マ ン ド ラ イ ン を 使 う
環境変数

39

設定ファイル
ヘルプ

38

39

41

オプションの種類

41

A2.3 管 理 ⽤ コ マ ン ド
daemon(デ ー モ ン )43

43

デーモン・ソケットのオプション

44

ストレージ・ドライバのオプション

45

Docker ラ ン タ イ ム 実 ⾏ オ プ シ ョ ン

50

ランタイム⽤のオプション50

デ ー モ ン の DNS オ プ シ ョ ン

51

安全ではないレジストリ
過去のレジストリ

51

52

Docker デ ー モ ン を HTTPS_PROXY の 背 後 で 実 ⾏
Ulimits の デ フ ォ ル ト

52

ノードのディスカバリ（検出）
アクセス認証52

53

デーモンのユーザ名前空間オプション

53

ユーザ名前空間を有効にしてデーモンを起動
subuid/subgid 範 囲 に つ い て の 詳 細 情 報

55

コンテナ⽤のユーザ名前空間を無効化

55

その他のオプション

56

デーモン設定ファイル

56

59

inspect(イ ン ス ペ ク ト )
例

54

56

デ フ ォ ル ト の 親 cgroupinfo(イ ン フ ォ )

52

61

61

version(バ ー ジ ョ ン )

63
- 4 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

デフォルトの出⼒

このガイドについて

63

サーバのバージョンを取得
raw デ ー タ の ダ ン プ

63

63

A2.4 イ メ ー ジ ⽤ コ マ ン ド
build(ビ ル ド )6464

戻り値（リターンコード）
65
例

66

.dockerignore の 使 い ⽅67

イ メ ー ジ の タ グ （ -t）67

Dockerﬁ le の 指 定 （ -f）67

親 cgroup の オ プ シ ョ ン （ --cgroup-parent）
コ ン テ ナ の ulimit を セ ッ ト （ --ulimit）
構 築 時 の 変 数 を 指 定 （ --build-arg）
commit(コ ミ ッ ト )

68

68

68

69

コンテナのコミット

69

新しい設定でコンテナをコミット

69

新 し い CMD と EXPOSE 命 令 で コ ン テ ナ を コ ミ ッ ト
export(エ ク ス ポ ー ト )
例

71

71

history(ヒ ス ト リ )72

images(イ メ ー ジ ー ズ )73

直近で作成したイメージから⼀覧表⽰
イメージ名とタグで⼀覧表⽰
フィルタリング

73

77

77

load(ロ ー ド )
rmi

73

75

import(イ ン ポ ー ト )
例

70

79

80

save(セ ー ブ )tag(タ グ )82

83

A2.5 コ ン テ ナ ⽤ コ マ ン ド
attach(ア タ ッ チ )84

デタッチ・シーケンスの上書き
cp

84

86

create(ク リ エ イ ト )
例

84

88

89

diﬀ (デ ィ フ )

91
- 5 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

events(イ ベ ン ツ )フィルタリング
例

93
95

95

kill(キ ル )96logs(ロ グ ズ )97pause(ポ ー ズ )port(ポ ー ト )
ps

92
92

exec(エ ク ゼ ク )
例

98
99

100

フィルタリング
フォーマット100

103

rename(リ ネ ー ム )105

restart(リ ス タ ー ト )
rm

107

例

107

run(ラ ン )
例

106

108

110

start(ス タ ー ト )119stats(ス タ ッ ツ )120

例

このガイドについて

120

stop(ス ト ッ プ )top(ト ッ プ )

121

122

unpause(ア ン ポ ー ズ )wait(ウ エ イ ト )

123

124

A2.6 Hub・ レ ジ ス ト リ ⽤ コ マ ン ド
login(ロ グ イ ン )証明書ストア125

125

logout(ロ グ ア ウ ト )pull(プ ル )
例

125

127

128

128

別のレジストリから取得

130

リポジトリから複数のイメージを取得
取得を中⽌

130

131

push(プ ッ シ ュ )132search(サ ー チ )133

A2.7 ネ ッ ト ワ ー ク と 接 続 ⽤ コ マ ン ド
network connect(コ ネ ク ト )

134

134
- 6 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

network create(ク リ エ イ ト )コンテナに接続136137

⾼度なオプションの設定

137

ブリッジ・ドライバのオプション

138

network disconnect(デ ィ ス コ ネ ク ト )network inspect(イ ン ス ペ ク ト )network ls

このガイドについて

139

140

142

フィルタリング
network rm

142

145

A2.8 共 有 デ ー タ ・ ボ リ ュ ー ム ⽤ コ マ ン ドvolume create(ク リ エ イ ト )146

ドライバ固有のオプション

146

volume inspect(イ ン ス ペ ク ト )volume ls

146

147

148

使 い ⽅ : docker volume ls [オ プ シ ョ ン ]フィルタリング
volume rm

148

148

150

A 3 . 1 D o c k e r fi l e
使い⽅
書式

151

151

152

環境変数の置き換え

152.dockerignore フ ァ イ ル

154

A3.2 Dockerﬁ le 命 令FROM(フ ロ ム )

156

156

MAINTAINER(メ ン テ ナ )RUN(ラ ン )158

既 知 の 問 題 (RUN)
CMD

157

158

160

LABEL(ラ ベ ル )161

EXPOSE(エ ク ス ポ ー ズ )ENV(エ ン ブ )163

ADD(ア ッ ド )164

COPY(コ ピ ー )

166

162

ENTRYPOINT(エ ン ト リ ポ イ ン ト )exec 形 式 の ENTRYPOINT 例
シ ェ ル 形 式 の ENTRYPOINT 例

167

167
169

CMD と ENTRYPOINT が ど の よ う に 作 ⽤ す る か 学 ぶ
VOLUME(ボ リ ュ ー ム )

170

172
- 7 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

USER(ユ ー ザ )173

WORKDIR(ワ ー ク デ ィ レ ク ト リ )ARG(ア ー グ )176

ONBUILD(オ ン ビ ル ド )181

例 :Nginx

174

175

構築キャッシュの影響

Dockerﬁ le の 例

このガイドについて

183

183

例 :Firefox over VNC
例 :複 数 の イ メ ー ジ

183

183

- 8 -

docs.docker.jp

16/05/20

Appendix.1

Appendix.

1 Docker 用語集

A1.1 用語集
Docker プロジェクト界隈で使われる⽤語の⼀覧です。
エー ユ ーエ フエ ス

aufs

ア ド バ ン ス ド

マ ル チ

レイヤード

ユニフィケーシヨン ファ イ ル シス テ ム

aufs （advanced multi layered uniﬁcation ﬁlesystem；複数のレイヤを統合した高度なファイルシステム、の意味）は、Docker がストレージ⽤のバックエンドとしてサポートする Linux のファイルシステムです。

ベース・イメージ（base image）
親イメージを持たないイメージを、 ベース・イメージと呼びます。

boot2docker
boot2docker*1 （ブート・トゥ・ドッカー）は Docker コンテナの実⾏に特化した Linux ディストリビューショ
ンです。Mac および Windows 向けの boot2docker は、Docker Toolbox のインストールに含まれる docker-machineに置き換えられました。

btrfs
btrfs（B-tree ﬁle system；ビー・ツリー・ファイルシステム、バター・エフエス）は、Docker がストレージ⽤のバックエンドとしてサポートする Linux のファイルシステムです。

ビルド（build）
ビルド（build）とは、Dockerfile を使って Docker イメージを構築する⽅法です。構築時には Dockerﬁle と「コンテクスト」（内容物の意味）を使います。コンテクストとは、イメージ構築に必要なファイル群が置かれている
ディレクトリです。

*1 http://boot2docker.io/- 9 -docs.docker.jp

16/05/20

cgroups
シーグループス

コントロールグループス

cgroups（control groups；コントロール・グループ）は Linux カーネルの機能であり、プロセスの集合が使うリソース（CPU、メモリ、ディスク I/O、ネットワーク等）を制限・計算・隔離します。Docker はリソース上限の管理と隔離に cgroups を使います。
cgroups の別名：control groups

ComposeCompose（コンポーズ）は、Docker で複雑なアプリケーションの実⾏と定義をするツールです。Compose を使
えば、１つのファイルに複数のコンテナ・アプリケーションを定義しておき、コマンドを１つ実⾏するだけで、ア
プリケーションを使うために必要な全てを実⾏します。
フィグ

Compose の別名： docker-compose、ﬁ g

コンテナ
ランタイム

インスタンスコンテナ（container）は docker イメージを実⾏する時の実体（runtime instance）です。
Docker コンテナには、次のものを含みます。

 Docker イメージ
 実⾏環境 命令の標準セット
Docker コンテナの概念は、輸送⽤のコンテナから拝借したものです。コンテナは「物」を世界的に輸送するために標準が定義されています。Docker はソフトウェアを送るための標準を定義しています。

データ・ボリューム
データ・ボリューム（data volume）は、コンテナ内部でユニオン・ファイル・システムを迂回するため特別に設計されたディレクトリです。データ・ボリュームは⻑期的なデータ保管のために設計されており、コンテナのラ
イフサイクルからは独⽴しています。そのため、コンテナを削除してもボリュームが⾃動的に消されることは有り
ガ ベ ー ジ

コレクト

得ませんし、コンテナから参照されなくなったボリュームが「掃除」（garbage collect）されることもありません。

DockerDocker（ドッカー）には次の意味があります。

 Docker プロジェクト全体を指す⾔葉であり、開発者やシステム管理者がアプリケーションを開発・移動・実⾏するためのプラットフォームです。
 ホスト上で動く docker デーモンプロセスであり、イメージとコンテナを管理します。

Docker Hub
Docker Hub（ドッカー・ハブ）は Docker とこのコンポーネントで動くリソースを集めた場所です。以下のサービスを提供します。
- 10 -

docs.docker.jp

16/05/20

 Docker イメージを預かる（ホスティング）
 ユーザ認証 イメージの⾃動構築と、構築トリガ（build triggers）やウェブ・フック（web hooks）のようなワークフロー・ツール GitHub および Bitbucket との統合

Dockerfile
Dockerﬁle（ドッカーファイル）はテキスト形式のドキュメントであり、通常 Docker イメージを構築するために⼿動で実⾏が必要になる全てのコマンドを含みます。Docker は Dockerﬁle の命令を読み込み、⾃動的にイメージを構築します。

ファイルシステム
ファイルシステムとは、オペレーティング・システムがファイルに名前を付け、かつ、効率的な保管と修正のためにファイルに場所を割り当てます。
例： Linux : ext4, aufs, btrfs, zfs
 Windows : NTFS
 OS X : HFS+

イメージ
Docker イメージはコンテナの元です。イメージとはルート・ファイルシステムに対する変更を並べ集めたもの
で、コンテナを実⾏する間に使われる実⾏パラメータに相当します。典型的なイメージはユニオン・ファイル・シ
ステムの層（スタック）がお互いに積み重なっています。イメージは状態を保持せず、変更もできません。

libcontainer
libcontainer（リブコンテナ）は Go ⾔語のネイティブな実装であり、名前空間・cgroup・機能・ファイルシス
テムへのアクセス管理を持つコンテナを作成します。コンテナを作成後、コンテナに対してライフサイクル上の追加操作を可能にします。

libnetwork
libnetwork（リブネットワーク）は Go ⾔語のネイティブな実装であり、コンテナのネットワーク名前空間や他のネットワーク・リソースを作成・管理します。コンテナを作成後、コンテナに対してライフサイクル上の追加操作を可能にします。

リンク機能（link）
リンク機能は同じホスト上で実⾏している Docker コンテナ間を接続するための、レガシーな（古い）インター- 11 -

docs.docker.jp

16/05/20

フェースです。リンク機能を使うと、ホスト側のネットワーク・ポートを開く必要がありません。現在は、この機
能の替わりに Docker ネットワーク機能を使います。

MachineMachine（マシン）は Docker ホストを簡単に作成できるようにするツールであり、クラウド・プロバイダ上やデータセンタでも利⽤できます。Machine はサーバを作成し、そこに Docker をインストールし、Docker クライ
アントで通信できるように設定します。
別名： docker-machine

オーバレイ・ネットワーク・ドライバ
オーバレイ・ネットワーク・ドライバ（overlay network driver）は、クラスタ上の Docker コンテナに対して、複数ホスト間のネットワーク接続性を簡単に提供します。

オーバレイ・ストレ ージ ・ドライバ
オーバレイエフエス

OverlayFS は、他のファイルシステムに対するユニオン・マウントを Linux に実装するもので、ファイルシステ

ム向けのサービスです。

レジストリ（registry）
レジストリ（registry）とはイメージを持つリポジトリを預かるサービス（ホステッド・サービス）であり、レジストリ API に応答します。
デフォルトのレジストリにアクセスするには、ブラウザで Docker Hub を開くか、docker search コマンドを使
います。

リポジトリ
リポジトリ（repository）とは Docker イメージの集まりです。リポジトリはレジストリ・サーバに送信すると、共有されるようにできます。リポジトリの中では、イメージの違いをタグでラベル付けします。

Swarm
Swarm（スウォーム）は Docker ⽤のネイティブなクラスタリング・ツールです。Swarm は複数の Docker ホストを⼀緒にまとめ（プールする）、１つの仮想的な Docker ホストのように装います。Swarm は標準 Docker API
を提供するため、既に Docker で使えるツールであれば、複数のホスト上で透過的にスケールさせることができます。
別名：docker-swarm

タグ
タグ（tag）は リポジトリ上の Docker イメージに割り当てるラベルです。タグを使い、リポジトリ上のイメー
ジを互いに識別します。

- 12 -

docs.docker.jp

16/05/20

ここでのラベルとは、docker デーモン⽤のキー・バリューで設定するラベルとは関係がありません。

ToolboxDocker Toolbox（ツールボックス）は Mac あるいは Windows ユーザ向けのインストーラです。

ユニオン・ファイル・システム
ユニオンエフエス

ユニオン・ファイル・システム（Union ﬁle system）や UnionFS は、⾮常に軽量で⾼速なレイヤを作成できるファイルシステムです。Docker はコンテナのブロック構築にユニオン・ファイル・システムを使います。

仮想マシン
仮想マシン（Virtual Machine）とは、コンピュータと疑似専⽤ハードウェアの全体をエミュレートするプログラ
ムです。他のユーザと物理ハードウェアのリソースを共有しますが、オペレーティング・システムからは隔離されています。エンドユーザは専⽤ハードウェアと同じように仮想マシンを操作できます。
コンテナと⽐べると、仮想マシンの実⾏は重たいものですが、更なる隔離を提供し、⾃⾝でリソースを持っており、共有は最低限です。
別名：VM- 13 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス

Appendix.2

Appendix.

2 Docker コマンドライン・リファレンス

A2.1 docker run リファレンス
Docker は隔離（独⽴）したコンテナでプロセスを実⾏します。コンテナはホスト上で動くプロセスです。ホストとはローカルまたはリモートの環境です。作業者が docker run を実⾏したら、コンテナのプロセスを隔離（独⽴）して実⾏します。コンテナは⾃⾝ファイルシステムとネットワークを持ち、ホスト上の他のプロセス・ツリー
からは隔離されて（独⽴して）います。
このセクションではコンテナ実⾏時にリソースを指定できるよう、docker run コマンドの使い⽅の詳細を説明します。

一般的な形式
基本的な docker run コマンドの形式は、次の通りです。
$ docker run [オプション] イメージ[:タグ|@ダイジェスト値] [コマンド] [引数...]
docker run コマンドは、コンテナ形成の元になるイメージ指定が必要です。イメージの開発者はイメージに関連するデフォルト値を定義できます。

 デタッチドあるいはフォアグラウンドで実⾏
 コンテナの識別 ネットワーク設定
 実⾏時の CPU とメモリの制限
 権限と LXC 設定
docker run [オプション] の実⾏時、作業者は設定の追加や、開発者がイメージに指定したデフォルト設定を上書き可能です。そして更に、作業者は Docker の実⾏時、ほぼ全てのデフォルト設定を上書きできます。run コマ
ンドは他の docker コマンドより多くのオプションがあるため、作業者はイメージと Docker 実⾏時のデフォルト設
定を上書きできます。
様々な種類の [オプション] を理解するには、「オプションの種類」のセクションをご覧ください。
Docker システムの設定によっては、docker run コマンドを sudo で実⾏する必要があるかもしれません。docker コマンドで sudo を使わないようにするには、システム管理者に docker という名称のグループの作成と、そこにユーザの追加を依頼してください。この設定に関するより詳しい情報は、各オペレーティング・システム向けのインストール⽤ドキュメントをご覧ください。

- 14 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス

作業者専用のオプション
作業者（ docker run の実⾏者 ）のみ、以下のオプションを設定できます。

 デタッチドまたはフォアグラウンド コンテナの識別 IPC 設定
 ネットワーク設定
 再起動ポリシー
 クリーンアップ
 実⾏時のリソース制限
 実⾏時の権限、Linux 機能、LXC 設定

デタッチドまたはフォアグラウンド
Docker コンテナの起動時に、まず、コンテナをバックグラウンドで「デタッチド」モード（detached mode）
で実⾏するか、デフォルトのフォアグラウンド・モード（foreground mode）で実⾏するかを決める必要があります。
-d=false: デタッチド・モード：コンテナをバックグラウンドで実行し、新しいコンテナ ID を表示

デ タッチ ド(-d)
コンテナをデタッチド・モードで起動するには、 -d=true か -d オプションを使います。設計上、コンテナが実⾏するルート・プロセスが終了したら、デタッチド・モードで起動したコンテナも終了します。デタッチド・モー
ドのコンテナは停⽌しても⾃動的に削除できません。つまり -d オプションでは --rm を指定できません。
デタッチドのコンテナでは service x start コマンドを受け付けません。例えば、次のコマンドは nginx サービスの起動を試みます。
$ docker run -d -p 80:80 my_image service nginx start
コンテナ内で nginx サービスの起動は成功します。しかしながら、デタッチド・コンテナの枠組み内では処理に失敗します。これはルート・プロセス（service nginx start）が終了するため、デタッチド・コンテナは停⽌されます。その結果、nginx サービスは実⾏しますが、実⾏を継続できません。この⽅法を使わず nginx ウェブ・サー
バのプロセスを実⾏するには、次のようにします。
$ docker run -d -p 80:80 my_image nginx -g 'daemon off;'
コンテナの⼊出⼒はネットワーク接続や共有ボリュームも扱えます。コマンドラインで docker run を実⾏し終わった後でも、必要になる場合があるでしょう。
デタッチド・コンテナに再度アタッチ（接続）するには、docker attach コマンドを使います。

フォアグラ ウンド
フォアグラウンド・モード（ -d を指定しないデフォルト）の場合、docker run はコンテナの中でプロセスを開始し、プロセスの標準⼊出⼒・標準エラーをコンソールにアタッチします。これは TTY の振りをするだけでなく- 15 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス（TTY は⼤部分のコマンド・ラインで実⾏可能なものと想定しています）、シグナルも渡せます。
-a=[]: 「標準入力」「標準出力」かつ／または「標準エラー出力」にアタッチ-t=false: 疑似ターミナル（pseudo-tty）の割り当て--sig-proxy=true: 受信したシグナルをプロセスに中継（ターミナルモード以外のみ）-i=false: アタッチしていなくても、標準入力をオープンに維持
Docker で -a を指定しなければ、Docker は⾃動的に全ての標準ストリームをアタッチします。３つの標準ストリーム（STDIN、STDOUT、STDERR）のうち、特定のものに対してのみ接続も可能です。
$ docker run -a stdin -a stdout -i -t ubuntu /bin/bash（シェルのような）インタラクティブなプロセスでは、コンテナのプロセスに対して tty を割り当てるために、 -i-t を⼀緒に使う必要があります。 -i -t は -it と書けます。後の例で出てきます。 -t を指定したら、クライア
ント側の出⼒を echo test | docker run -i busybox cat のようにリダイレクトやパイプできます。
コンテナ内で PID 1 として実⾏しているプロセスは、Linux が特別に扱います。デフォルトの操作
では、あらゆるシグナルを無視します。そのため、プロセスは SIGINT か SIGTERM で停⽌するようにコードを書かない限り、停⽌できません。

コンテナの識別名 前（--name）
作業者はコンテナを３つの⽅法で識別できます。

 ⻑い（ロング）UUID 識別⼦（” f78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778 ”）
 短い UUID（ショート）識別⼦（” f78375b1c487 ”）
 名前（” evil_ptolemy ”）
UUID 識別⼦は Docker デーモンから与えられます。コンテナの名前を --name オプションで割り当てなければ、デーモンはランダムな⽂字列から名前を⽣成します。コンテナに対する⽬的を表すためには、name の定義が簡単な⽅法でしょう。name を指定したら、これを Docker ネットワーク内でコンテナを参照⽤に使えます。この参照機能
は、バックグラウンドでもフォアグラウンドどちらの Docker コンテナでも動作します。
デフォルトのブリッジ・ネットワーク内にあるコンテナの場合は、相互に名前で通信するにはリンクする必要があります。

PID 相 当の 機能
あとは、⾃動処理を簡単にするため、Docker は任意に選択したファイルに対してコンテナ ID を書き出せます。
これは、プログラムがプロセス ID をファイルに書き出す（いわゆる PID ファイルです）のに似ています。
--cidfile="": コンテナの ID をファイルに書き出す

イ メージ [:タ グ]- 16 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス

コンテナ実⾏時のコマンドでイメージ[:タグ]を追加すると、イメージのバージョンを厳密に指定できます。例
えば docker run ubuntu:14.04 と実⾏します。

イ メージ [@ダイジェス ト値]
イメージ形式 v2 以降のイメージを使えば、その中にダイジェスト値（digest）と呼ばれる識別⼦が、内容に対して割り当てられています。⼊⼒に使われたイメージファイルに対する変更が無ければ、ダイジェスト値とは予想されうる値であり、参照可能なものです。

PID 設定（--pid）--pid="" : コンテナに対する PID（プロセス）名前空間モードを指定'host':コンテナ内のホストが使う PID 名前空間
デフォルトでは、全てのコンテナは有効な PID 名前空間を持っています。
PID 名前空間はプロセスの分離をもたらします。PID 名前空間はシステム・プロセスを⾒えないようにし、PID
1 を含むプロセス ID を再利⽤できるようにします。
コンテナがホスト上の特定のプロセス名前空間を共有する場合は、コンテナ内のプロセスが、システム上の全プ
ロセスを基本的に⾒られるようにします。例えば、strace や gdb のようなデバッグ⽤ツールを含むコンテナを構築した時、コンテナ内のデバッグ⽤プロセスのみツールを使えるように指定する場合です。
$ docker run --pid=host rhel7 strace -p 1234
これはホスト上の pid 1234 にあるコンテナ内で strace を使うコマンドです。

UTS 設 定（--uts）--uts="" : UTS 名前空間モードをコンテナに設定する'host': コンテナ内でホストの UTS 名前空間を使用
UTS 名前空間とは、プロセスを実⾏する名前空間上で⾒えるホスト名とドメイン名を設定するものです。デフォ
ルトでは、全てのコンテナは --uts=host の指定により、⾃⾝の UTS 名前空間を持っています。host には、ホスト名として同じ UTS 名前空間をコンテナで使えるよう設定します。なお、host UTS モードでは --hostname の指定ができないため、ご注意ください。
ホスト上と UTS 名前空間を共有したい場合もあるでしょう。例えば、コンテナを動かすホストがホスト名を変更してしまい、コンテナのホスト名も変更したい場合です。より⾼度な使い⽅としては、コンテナからホスト側のホスト名の変更を⾏うケースです。

IPC 設 定（--ipc）--ipc="" : コンテナに IPC モードを設定する'container:<名前|id>': 他のコンテナの IPC 名前空間を再利用'host': ホストの IPC 名前空間をコンテナの中で使用
デフォルトでは、全てのコンテナが有効な IPC 名前空間を持っています。
IPC (POSIX/SysV IPC) 名前空間は、共有メモリ・セグメント、セマフォ、メッセージ・キューと呼ばれる分離を提供します。
- 17 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス

プロセス間通信は共有メモリ・セグメントはメモリの速度まで（ネットワーク・スタックをパイプするか通過す
るよりも速く加速）します。共有メモリとは、⼀般的にデータベースや、科学計算や緊急サービス産業向けの⾼性
能アプリケーション向けカスタム・ビルド（典型的なのは、C/OpenMPI、C++ の⾼速化ライブラリ）に⽤いられます。この種のアプリケーションが複数のコンテナに分割される場合は、コンテナの IPC 機構を使って共有する必要があるでしょう。

ネットワーク設定--dns=[]--net="bridge": コンテナ用のカスタム DNS サーバを設定: コンテナをネットワークに接続'bridge': docker ブリッジ上でコンテナ用に新しいネットワーク・スタックを作成'none': コンテナにネットワーク機能を付けない'container:<name|id>': 他のコンテナ用ネットワーク・スタックを再利用'host': コンテナ内でホスト側ネットワーク・スタックを使用'NETWORK': 「docker network create」コマンドでユーザ作成したネットワークに作成--net-alias=[] : コンテナにネットワーク内部用のエイリアスを追加--add-host="": /etc/hosts に行を追加（ホスト名:IP アドレス）--mac-address="" : コンテナのイーサネット・デバイス Mac アドレスを指定--ip="": コンテナのイーサネット・デバイスに IPv4 アドレスを指定--ip6="": コンテナのイーサネット・デバイスに IPv6 アドレスを指定
デフォルトでは、全てのコンテナはネットワーク機能を持っており、外部に対する接続が可能です。作業者がネットワークを無効化したい場合は docker run --net=none を指定し、内側と外側の両⽅のネットワーク機能を無効化します。このように指定したら、I/O 処理はファイルに対してか、STDIN と STDOUT のみになります。
公開⽤のポートを他のコンテナとリンクできるのは、デフォルト（ブリッジ）のみです。リンク機能はレガシー（過去の）機能です。リンク機能を使うよりも、常に Docker ネットワーク機能を使うべきです。
コンテナは、デフォルトではホストと同じ DNS サーバを使いますが、 --dns で上書きできます。
デフォルトでは、コンテナに割り当てられる IP アドレスを使い、MAC アドレスを⽣成します。コンテナの MAC
アドレスの指定は、 --mac-address パラメータ（書式：12:34:56:78:9a:bc）を使い MAC アドレスを指定できます。Docker は MAC アドレスがユニークかどうか（重複しているかどうか）を確認する仕組みが無いため、ご注意ください。
サポートしているネットワーク：
ネットワーク説明

none

コンテナにネットワーク機能を持たせません。

bridge（デフォルト）

コンテナを各インターフェースに接続します。

hostコンテナ内でホスト側のネットワーク・スタックを使います。

container:<名前|id>

他のコンテナ名か ID を指定し、そのネットワーク・スタックを使います。

ユーザ定義ネットワーク ユーザが作成したネットワーク（docker network create コマンドを使⽤）にコンテナを接続します。

ネットワ ーク ：none
コンテナのネットワークを none に指定したら、外部の経路に対してアクセス不能になります。コンテナ内ではloopback （ループバック）インターフェースが有効ですが、外部のトラフィックに対する経路が無くなります。

ネットワ ーク ：bridge- 18 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス

コンテナのネットワークを bridge に指定したら、コンテナは Docker のデフォルト・ネットワーク機能をセットアップします。ブリッジはホスト上で設定されるもので、通常は docker0 と名前が付けられます。そして、veth イ
ンターフェースのペアがコンテナ⽤に作成されます。veth ペアの⽚⽅はホスト側にアタッチされたままとなります。
もう⼀⽅は、コンテナの名前空間の中で loopback インターフェースに加えて追加します。ブリッジ・ネットワー
ク上で IP アドレスがコンテナに割り当てられ、コンテナに対するトラフィックはこのブリッジを経由します。
デフォルトでは、コンテナは各々の IP アドレスを経由して通信できます。コンテナ名で通信するには、リンクする必要があります。

ネットワ ーク ：host
host ネットワークをコンテナに設定したら、ホスト側のネットワーク・スタックと、全てのホスト上のインターフェースがコンテナ上でも共有できます。コンテナのホスト名はホストシステム上のホスト名と⼀致します。host
ネットワーク・モードでは、 --add-host、 --hostname、 --dns、 --dns-search、 --dns-opt、 --mac-addressが無効になるのでご注意ください。 たとえ host ネットワーク・モードだとしても、コンテナは⾃⾝の UTS 名前
空間をデフォルトで持ちます。そのため、host ネットワーク・モードで --hostname が許可されるのは、コンテナの中でホスト名を変えるだけです。
デフォルトの bridge モードと⽐べ、host モードは著しくネットワーク性能が優れます。これは、bridge の場合
は docker デーモンの仮想化レベルを通過しているのに対して、host の場合はネイティブなネットワーク・スタッ
クを⽤いるからです。例えば、プロダクションのロードバランサや⾼性能のウェブサーバのような、ネットワーク
性能がクリティカルな環境では、このモードでのコンテナ動作を推奨します。
--net="host"の指定時は、コンテナは D-bus のようなローカル・システム・サービスに対してフルアクセス可能なため、安全ではないと考えられます。

ネットワ ーク ：container
container ネットワークをコンテナに指定したら、他のコンテナのネットワーク・スタックを共有します。他のコンテナ名は --net container:<名前|id> の書式で指定する必要があります。container ネットワーク・モードでは、 --add-host、 --hostname、 --dns、 --dns-search、 --dns-opt、 --mac-address が無効になるだけでなく、--publish、 --publish-all、 --expose も無効になるのでご注意ください。
次の例は、Redis コンテナで Redis が localhost をバインドしている時、localhost インターフェースを通してRedis サーバに redis-cli コマンドを実⾏して接続します。
$ docker run -d --name redis example/redis --bind 127.0.0.1$ # redis コンテナのネットワーク・スタックにある localhost にアクセスします$ docker run --rm -it --net container:redis example/redis-cli -h 127.0.0.1

ユ ーザ定 義ネットワ ーク
ネットワークを作成するには、Docker ネットワーク・ドライバか外部のネットワーク・ドライバ・プラグインを使います。同じネットワークに対して、複数のコンテナが接続できます。ユーザ定義ネットワークに接続したら、コンテナはコンテナの名前や IP アドレスを使い、簡単に通信できるようになります。
overlay ネットワークやカスタム・プラグインは、複数のホストへの接続性をサポートしています。コンテナが同⼀のマルチホスト・ネットワークに接続していれば、別々のエンジンで起動していても、このネットワークを通して通信可能です。
以下の例は、内部 bridge ネットワーク・ドライバを使ってネットワークを作成し、作成したネットワーク上でコンテナを実⾏します。
- 19 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス$ docker network create -d bridge my-net$ docker run --net=my-net -itd --name=container3 busybox/etc/hosts の 管理
/etc/hosts には localhost や⼀般的な項⽬と同じように、⾃分が定義したコンテナのホスト名を追加できます。
/etc/hosts に⾏を追加するには --add-host フラグを使います。
$ docker run -it --add-host db-static:86.75.30.9 ubuntu cat /etc/hosts
172.17.0.22
09d03f76bf2c
fe00::0
ip6-localnet
ff00::0
ip6-mcastprefix
ff02::1
ip6-allnodes
ff02::2
ip6-allrouters
127.0.0.1
localhost::1
localhost ip6-localhost ip6-loopback
86.75.30.9
db-static
コンテナがデフォルト・ブリッジ・ネットワークに接続し、他のコンテナと link（リンク）すると、コンテナの/etc/hosts ファイルが更新され、リンクされたコンテナ名が書き込まれます。
もしもコンテナがユーザ定義ネットワークに接続した場合は、コンテナの /etc/hosts ファイルが更新され、ユーザ定義ネットワーク上の他のコンテナ名が書き込まれます。
Docker がコンテナの /etc/hosts ファイルをリアルタイムに更新するかもしれません。そのため、コンテナ内のプロセスが /etc/hosts ファイルを読み込もうとしても空だったり、あるいは最後まで読み込めなかったりする場合が有り得ます。ほとんどの場合、再読み込みで問題が解決するでしょう。

再起動ポリシー（--restart）
Docker で実⾏時に --restart フラグを使えば、再起動ポリシーを指定できます。再起動ポリシーとは、コンテ
ナが終了時に再起動すべきかどうかを定義します。
コンテナの再起動ポリシーが有効な場合、 docker ps でコンテナを⾒たら、常に Up か Restarting のどちらかです。また、再起動ポリシーが有効かどうかを確認するため、docker events を使うのも便利です。
Docker は以下の再起動ポリシーをサポートしています。
ポリシー

説明

no（なし）

コンテナが終了しても、⾃動的には再起動しません。これがデフォルトです。
on-failure[:最⼤リトライ数]
コンテナが 0 以外の終了コードで停⽌したら再起動します。オプ
ションで Docker デーモンが何度再起動を試みるかを指定できます。
always（常に）コンテナの終了コードに拘わらず、常にコンテナの再起動を試みます。Docker デーモンは無制限に再起動を試みます。また、デーモンの起動時にも、コンテナの状況に拘わらず常に起動を試みます。
unless-stopped（停⽌していない場合） コンテナの終了コードに拘わらず、常にコンテナの再起動を試みます。しかし、直近のコンテナが停⽌状態であったのであれば、デーモンの起動時にコンテナを開始しません。

- 20 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス

サーバが溢れかえるのを防ぐため、再起動の前に遅延時間が追加されます（遅延は 100 ミリ秒から開始し、直前の値の２倍になります）。つまり、デーモンは 100 ミリ秒待った後は、200 ミリ秒、400、800、1600 …と on-failure
上限に到達するか、あるいは、コンテナを docker stop で停⽌するか、 docker rm -f で強制削除するまで続けます。
コンテナの再起動が成功すると（コンテナは少なくとも 10 秒以内で起動します）、遅延時間の値は再び 100 ミリ
秒にリセットされます。
on-failure ポリシーを使えば、Docker がコンテナの再起動を試みる最⼤回数を指定できます。デフォルトでは、Docker はコンテナを永久に再起動し続けます。コンテナの再起動（を試みる）回数は docker inspect で確認可能です。例えば、コンテナ「my-container」の再起動数を取得するには、次のようにします。
$ docker inspect -f "{{ .RestartCount }}" my-container#2あるいは、コンテナが（再）起動した時刻を知るには、次のようにします。
$ docker inspect -f "{{ .State.StartedAt }}" my-container# 2015-03-04T23:47:07.691840179Z
再起動ポリシーとクリーンアップは同時に指定できません。 --restart と --rm を同時に指定してもエラーになります。
例$ docker run --restart=always redis
こちらの例は、 常に (always) 再起動するポリシーで redis コンテナを実⾏します。そのため、コンテナが停⽌したら Docker はコンテナを再起動します。
$ docker run --restart=on-failure:10 redis
こちらの例は、 失敗したら (on-failure) 10 回カウントするまで再起動を⾏うポリシーで redis コンテナを起動しています。もし redis コンテナが 0 以外の状態で終了したら、Docker はコンテナの再起動を 10 回続けて試みます。再起動の上限を設定できるのは、on-failure ポリシーを有効にした場合のみです。

終了ステータス（exit status）
docker run の終了コードから得られる情報は、なぜコンテナが実⾏に失敗したかや、なぜ終了したかです。docker
run がゼロ以外のコードで終了する時、終了コードは chroot 標準に従います。
125 は Docker デーモン自身のエラー発⽣です。
$ docker run --foo busybox; echo $?
# 定義されていない --foo フラグを指定したためSee 'docker run --help'.
125
126 はコンテナ内のコマンドが実⾏できない場合のエラーです。
$ docker run busybox /etc; echo $?
# "/etc" には実行権限がありません
docker: Error response from daemon: Contained command could not be invoked- 21 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス

126
127 はコンテナ内のコマンドが⾒つからない場合です。
$ docker run busybox foo; echo $?
# 環境変数 $PATH の中に "foo" 実行ファイルが見つかりません。
docker: Error response from daemon: Contained command not found or does not exist
127
コンテナ内におけるコマンドの終了コードは上書きできます。

$ docker run busybox /bin/sh -c 'exit 3'#3

クリーンアップ（--rm）
デフォルトではコンテナを終了しても、コンテナのファイルシステム（の内容）を保持し続けます。これにより、多くのデバッグをより簡単にします（最後の状態を確認できるため）。そして、全てのデータを維持し続けるのがデフォルトです。しかし、短い期間だけフォアグラウンドで動かしたとしても、これらのコンテナのファイルシス
テムが溜まり続けます。そうではなく、 コンテナの終了時に、⾃動的にコンテナをクリーンアップし、ファイルシステムを削除する には --rm フラグを追加します。
--rm=false: 終了時に自動的にコンテテナを削除する（-d と同時に使用不可）--rm フラグを設定したら、コンテナの削除時、関連するボリュームも削除します。これは docker rm-v my-container の実⾏と同じです。ただし、名前を指定しなかったボリュームのみ削除します。
例えば docker run --rm -v /foo -v awesome:/bar busybox top の場合、 /foo ボリュームを削除します。しかし、 /bar は削除されません。 --volume-form で継承しているボリュームが削除されないのと同じ仕組みです。このように、オリジナルのボリュームに名前が指定されていれば、そこは削除されません 。

セキュリティ設定--security-opt="label=user:USER" : コンテナの user ラベルを指定--security-opt="label=role:ROLE" : コンテナの role ラベルを指定--security-opt="label=type:TYPE" : コンテナの type ラベルを指定--security-opt="label=level:LEVEL" : コンテナの lovel ラベルを指定--security-opt="label=disable": コンテナのラベル割り当てを無効化--security-opt="apparmor=PROFILE" : コンテナに適用する apparmor profile を指定--security-opt="no-new-privileges" : コンテナが新しい権限を得るのを無効化--security-opt="seccomp=unconfined": コンテナ用の seccomp 制限を無効化--security-opt="seccomp=profile.json": sccomp フィルタで使うホワイトリスト syscall seccompo Json ファ
イルを指定
各コンテナに対するデフォルトのラベリング・スキーマ（labeling scheme）は --security-opt フラグを指定することで上書き可能です。例えば、MCS/MLS レベルを指定するには MLS システムが必要です。コンテナ間で同じ内容を共有できるようにレベルを指定するには、次のようにコマンドを実⾏します。
$ docker run --security-opt label=level:s0:c100,c200 -i -t fedora bash
- 22 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス

MLS であれば、次のような例になります。
$ docker run --security-opt label=level:TopSecret -i -t rhel7 bash
コンテナに対するセキュリティ・ラベリングを無効化するには、 --permissive フラグを使い、次のように指定します。
$ docker run --security-opt label=disable -i -t fedora bash
コンテナ内のプロセスに対して、何らかのセキュリティ・ポリシーを適⽤するには、コンテナに対して何らかのタイプを指定します。コンテナを実⾏する時、Apache のポートのみがリッスンできるようにするには、次のように実⾏します。
$ docker run --security-opt label=type:svirt_apache_t -i -t centos bash

ここでは svirt_apache_t タイプに対する書き込みポリシーがあるものと想定しています。

コンテナのプロセスに特権を追加できないようにするには、次のコマンドを実⾏します。
$ docker run --security-opt no-new-privileges -it centos bash*1より詳しい情報は、カーネルのドキュメント をご覧ください。

カスタム cgroups の指定--cgroup-parent フラグを使うことで、コンテナを特定の cgroup で実⾏できるようにします。これにより⾃分⾃⾝で cgroup の作成や管理が可能になります。各 cgroup に対してカスタム・リソースを定義でき、コンテナを共通の親グループ下に置くこともできます。

実行時のリソース制限
作業者はコンテナのパフォーマンス・パラメータも調整できます。
オプション

説明

-m , --memory=""--memory-swap=""

メモリの上限（書式：<数値> [<単位>]、単位は b、k、m、g のいずれか）
合計メモリの上限（メモリ＋スワップ、書式：<数値> [<単位>]、単位は b、k、m、gのいずれか）--memory-reservation="" メモリのソフト・リミット（書式：<数値> [<単位>]、単位は b、k、m、g のいずれか）--kernel-memory=""
カーネル・メモリの上限（書式：<数値> [<単位>] 、単位は b、k、m、g のいず
れか）-c , --cpu-shares=0
CPU 共有（CPU shares）を相対値で指定--cpu-period=0
CPU CFS(Completely Fair Scheduler) ピリオドの上限（訳者注：cgroup による
CPU リソースへのアクセスを再割り当てする間隔）--cpuset-cpus=""
実⾏する CPU の割り当て（0-3, 0,1）--cpuset-mems=""
実⾏するメモリ・ノード（MEM）の割り当て（0-3, 0,1）
。NUMA システムのみ*1 https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt- 23 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1--cpu-quota=0--blkio-weight=0--oom-kill-disable=false--memory-swappiness=""

A2.1 docker runリファレンス

で動作
CPU CFS (Completely Fair Scheduler) のクォータを設定
ブロック I/O ウエイト（相対値）を 10 〜 1000 までの値でウエイトを設定
コンテナを OOM killer による停⽌を無効化するかどうか指定コンテナがメモリのスワップ度合いを調整。整数値の 0 〜 100 で指定

ユ ーザ・ メモ リの制 限
ユーザのメモリ使⽤を制限するには、４つの⽅法があります。
オプション

説明

memory=inf, memory-swap=inf（デフォルト） コンテナに対する上限を設けない。コンテナは必要な分のメモ
リを使える
memory=L<inf, memory-swap=inf（memory を指定し、memory-swap を -1 にする）コンテナはL バイト以上のメモリ使⽤が許されないが、必要があればスワップを使える（ホスト側がスワップ・メモリをサポートしている場合）
memory=L<inf, memory-swap=2*L（memory を指定するが memory-swap は指定しない）コンテ
ナは L バイト以上のメモリ使⽤は許されないが、指定した値の２倍の「追加」スワップ・メモリが使える
memory=L<inf, memory-swap=S<inf, L<=S
（memory も memory-swap も指定する）コンテナは L バイト
以上のメモリ使⽤が許されないが、「追加」スワップ・メモリは S
バイトまで使える例：$ docker run -ti ubuntu:14.04 /bin/bash
メモリを設定していません。これはコンテナ内のプロセスは必要な分だけメモリが使えます。それだけでなく、スワップ・メモリも同様に必要なだけ使えます。
$ docker run -ti -m 300M --memory-swap -1 ubuntu:14.04 /bin/bash
メモリ上限を指定し、スワップ・メモリの制限を無効化しました。これはコンテナ内のプロセスは 300M のメモ
リを使えます。それだけでなく、スワップ・メモリは必要なだけ使えます（ホスト側がスワップ・メモリをサポートしている場合）。
$ docker run -ti -m 300M ubuntu:14.04 /bin/bash
メモリの上限のみ設定しました。これはコンテナが 300M のメモリと 300M のスワップ・メモリを使えます。合計の仮想メモリサイズ（total virtual memory size、 ‒ memory-swap で指定）はメモリの２倍に設定されます。今回の例では、メモリ＋スワップは 2 × 300M ですので、プロセスは 300M のスワップ・メモリを利⽤できます。
$ docker run -ti -m 300M --memory-swap 1G ubuntu:14.04 /bin/bash
メモリとスワップ・メモリを指定しましたので、コンテナ内のプロセスは 300M のメモリと 700M のスワップ・メモリを使えます。
メモリ予約（memory reservation）は、メモリに対するある種のソフト・リミットであり、共有メモリを⼤きくします。通常の状況下であれば、コンテナは必要とするだけ多くのメモリを使うことができます。そして、 -m か--memory オプションがある時のみ、コンテナに対してハード・リミットが設定されます。メモリ予約を設定したら、Docker はメモリのコンテンション（競合）や少ないメモリを検出し、コンテナが予約した上限まで使えるように- 24 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス

します。
メモリ予約の値は、常にハード・リミット以下に設定しなければ、ハード・リミットが先に処理されてしまいます。予約値を 0 に設定するのは、予約しないのと同じです。デフォルトでは（予約をセットしない場合）、メモリ予約とはメモリのハード・リミットと同じです。
メモリ予約とはソフト・リミット機能であり、制限を超過しないことを保証しません。その代わりに、かなりメモリが競合する場合、予約のヒント/設定に基づいてメモリの割り当てを試みる機能があります。
次の例はメモリの上限（-m）を 500M に制限し、メモリ予約を 200M に設定します。
$ docker run -ti -m 500M --memory-reservation 200M ubuntu:14.04 /bin/bash
この設定の下では、コンテナはメモリを 200MB 以上〜 500MB 以下まで使えます。次のシステム・メモリはコ
ンテナのメモリが 200MB 以下になるよう縮⼩を試みます。
次の例はメモリのハード・リミットを設定せず、メモリ予約を 1G に設定します。
$ docker run -ti --memory-reservation 1G ubuntu:14.04 /bin/bash
コンテナはメモリを必要なだけ使えます。メモリ予約設定により、コンテナが⻑時間多くのメモリを消費しなくなります。これはコンテナがメモリを消費したとしても、予約分を使えるようにメモリの使⽤を縮⼩しようとするからです。
デフォルトでは、アウト・オブ・メモリ（OOM; out of memory）エラーが発⽣したら、カーネルはコンテナ内のプロセスを停⽌（kill）します。この振る舞いを変更するには、 --oom-kill-disable オプションを使います。また、 -m/--memory オプションを指定した時のみ、コンテナに対する OOM が無効化できます。もし -m フラグがセットされなければ、ホスト側でアウト・オブ・メモリ処理が発⽣します。また、ホスト側のシステム・プロセスが空きメモリを必要とするため、対象のプロセスを停⽌（kill）します。
次の例はメモリの上限を 100M とし、対象となるコンテナに対する OOM killer（アウト・オブ・メモリ処理による強制停⽌）を無効化します。
$ docker run -ti -m 100M --oom-kill-disable ubuntu:14.04 /bin/bash
次の例では、危険なフラグの使い⽅を説明します。
$ docker run -ti --oom-kill-disable ubuntu:14.04 /bin/bash
コンテナは無制限にメモリを使えるため、ホスト上のメモリを使い果たしたら、空きメモリ確保のために、シス
テム・プロセスを停⽌する必要が出てきます。

カ ーネル ・メモ リ制 限
カーネル・メモリはスワップ・アウトできないため、ユーザ・メモリとは根本的に異なります。このスワップができないことにより、システム・サービスがカーネル・メモリを多く使えないように妨害する可能性があります。
カーネル・メモリとは、次の項⽬を指します。

 stack pages
 slab pages
 sockets memory pressure
 tcp memory pressure
これらのメモリを制限するため、カーネル・メモリの上限を設定できます。例えば、各プロセスが同じスタック- 25 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス・ページ（stack page）を使うようにする場合です。カーネル・メモリの制限により、カーネル・メモリの使⽤量が⼤きい時、新しいプロセスの作成を妨げます。
カーネル・メモリはユーザ・メモリとは完全に独⽴しています。その代わり、ユーザ・メモリを制限すると同時に、カーネル・メモリの制限も必要です。上限の設定には３つの⽅法があります。ここでは、「U」はユーザ・メモ
リの上限で、「K」はカーネルの上限とみなしています。
オプション

結果

U != 0, K = inf （デフォルト）

カーネル・メモリが使う前に、標準的なメモリ制限を設ける仕組み。
カーネル・メモリは完全に無視される。
カーネル・メモリをユーザ・メモリのサブセットとする。この設定
は cgroup ごとに⼤きな合計メモリ容量をオーバーコミットで割り当て、デプロイする場合に使いやすい。カーネル・メモリ制限のオーバ
ーコミットは、全く推奨されていない。範囲が再利⽤できないメモリ領域の場合が有り得るため。この例では、K を設定したので、全グループの合計は、全メモリ容量を超えられない。そして、システム・サービスの品質のために U を任意に設定できる。
カーネルのメモリを使⽤するため、コンテナ向けに両⽅のメモリが、
ユーザ・カウンタと再利⽤トリガに影響を与えます。

U != 0, K < U

U != 0, K > U

例：$ docker run -ti -m 500M – kernel-memory 50M ubuntu:14.04 /bin/bash
メモリとカーネルメモリを設定しました。これにより、コンテナ内のプロセスは合計 500M まで使えます。この500M のメモリのうち、トップに 50M のカーネル・メモリがあります。
$ docker run -ti --kernel-memory 50M ubuntu:14.04 /bin/bash-m オプションを指定せずカーネル・メモリを指定しました。そのため、コンテナ内のプロセスは必要なだけ多くのメモリを利⽤可能ですが、そこに最低限 50M のカーネル・メモリを使います。

ス ワップ 回避（ swappiness）制 限
デフォルトでは、コンテナのカーネルは、アノニマス・ページ・メモリ上の何パーセントかをスワップ・アウト
します。コンテナ向けのこのパーセントを指定するには --memory-swappiness で 0 〜 100 までの値を設定します。
この値が 0 であればアノニマス・ページのスワッピング（anonymous page swapping）を無効にします。値を 100にすると全てのページがスワップ可能となります。デフォルトでは、 --memory-swappiness を指定しなければ、メ
モリのスワップ回避（swappiness）は親の値を継承します。
例：$ docker run -ti --memory-swappiness=0 ubuntu:14.04 /bin/bash--memory-swappiness オプションが役⽴つのは、コンテナの作業セットを維持し、スワップによるパフォーマン
スのペナルティを避ける場合です。

CPU 共有制 限
デフォルトでは、全てのコンテナは同じ CPU サイクルの割合を持っています。この割合は変更可能なものであり、コンテナの CPU 共有ウエイトを、実⾏中の全てのコンテナに対する相対的な値として変更できます。
割合をデフォルトの 1024 から変更するには、 -c か --cpu-shares フラグでウエイトを 2 以上の値で設定します。もし 0 を設定しても、システムは値を無視してデフォルトの 1024 を使います。
- 26 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス

割合が適⽤されるのは CPU に対する処理が集中する時のみです。あるコンテナのタスクがアイドル（何もしていない待機状態）であれば、他のコンテナは CPU 時間の余剰を利⽤できます。実際に割り当てられる CPU 時間の量は、システム上で実⾏するコンテナの下図に⾮常に依存します。
例えば、３つのコンテナがあるとしましょう。１つめの CPU 共有は 1024 で、残り２つの CPU 共有は 512 とします。もし３つのコンテナが CPU を 100%使⽤している状態になれば、１つめのコンテナが合計 CPU 時間の50%を扱えます。４つめのコンテナを CPU 共有 1024 として追加したら、１つめのコンテナが得られるのは CPUの 33%になります。そして、残りの２つめ以降のコンテナが得られる CPU 時間は、それぞれ 16.5%（２つめ）、16.5%（３つめ）、33% （４つめ）となります。
複数のコアを持つ（マルチ・コア）システム上では、全ての CPU コアに分散し CPU 時間が共有されます。コンテナが CPU 時間の 100%より低く制限していても、個々の CPU コアでは 100%利⽤できます。
例えば、システムが３つ以上のコアを持っていると想定してみましょう。１つめのコンテナ{C0}では -c=512 を指定し、１つのプロセスを実⾏するものとします。そして、他のコンテナ{C1}は -c=1024 を指定し、２つのプロセスを実⾏するとします。この結果、CPU 共有は個々のコアに分散されます。
PID
100
101
102

container
{C0}
0
{C1}
1
{C1}
2

CPU CPU share
100% of CPU0
100% of CPU1
100% of CPU2

CPU 周期（ period）制 約
デフォルトの CPU CFS（Completely Fair Scheduler）周期は 100 ミリ秒です。コンテナの CPU 使⽤率を制限するには、 --cpu-period で CPU の周期を制限します。そして、通常の --cpu-period は --cpu-quota と⼀緒に使われるでしょう。
例：$ docker run -ti --cpu-period=50000 --cpu-quota=25000 ubuntu:14.04 /bin/bash
もし１ CPU であれば、コンテナは 50 ミリ秒ごとに CPU の 50%を利⽤できます（訳者注：‒ cpu-quota のクォータ値が、 ‒ cpu-period 周期の半分のため）。
*1より詳しい情報については、CFS ドキュメントの帯域制限について をご覧ください。

CPU セット 制限
どの CPU でコンテナを実⾏するか指定できます。
例：$ docker run -ti --cpuset-cpus="1,3" ubuntu:14.04 /bin/bash
これはコンテナ内のプロセスを cpu 1 と cpu 3 で実⾏します。
$ docker run -ti --cpuset-cpus="0-2" ubuntu:14.04 /bin/bash
こちらはコンテナ内のプロセスを cpu 0 、cpu 1 、 cpu 2 で実⾏します。
NUMA system 上でのみ、どのコンテナをメモリ上で実⾏するか設定できます。

*1 https://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt- 27 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス$ docker run -ti --cpuset-mems="1,3" ubuntu:14.04 /bin/bash
この例ではコンテナ内でのプロセスを、メモリ・ノード 1 と 3 上のメモリのみに使⽤を制限します。
$ docker run -ti --cpuset-mems="0-2" ubuntu:14.04 /bin/bash
この例ではコンテナ内でのプロセスを、メモリ・ノード ０と１と２ 上のメモリのみに使⽤を制限します。

CPU クォー タ制限--cpu-quota フラグはコンテナの CPU 使⽤を制限します。デフォルト値 0 の場合、コンテナは CPU リソース
（1 CPU）の 100%を扱えます。CFS (Completely Fair Scheduler)がプロセス実⾏時のリソース割り当てを扱っており、これがカーネルによってデフォルトの Linux スケジューラとして使われています。この値を 50000 に指定
したら、コンテナは CPU リソースの 50%までの使⽤に制限されます。複数の CPU の場合は、 --cpu-quota の調整が必要です。より詳しい情報については、CFS ドキュメントの帯域制限についてをご覧ください。

ブ ロック IO 帯域 （blkio）制限
デフォルトでは、全てのコンテナはブロック IO 帯域（blkio）を同じ割合で取得します。デフォルトの割合は 500です。割合を変更するには --blkio-weight フラグを使い、実⾏中の全てのコンテナに対する装置亜的な blkio ウ
エイトを指定します。
--blkio-weight フラグは、10 〜 1000 までのウエイト値を設定できます。例えば、次のコマンドは２つのコンテ
ナに対し、別々の blkio ウエイトと設定しています。
$ docker run -ti --name c1 --blkio-weight 300 ubuntu:14.04 /bin/bash$ docker run -ti --name c2 --blkio-weight 600 ubuntu:14.04 /bin/bash
例えば、次のようにして２つのコンテナで同時にブロック IO を確認できます。
$ time dd if=/mnt/zerofile of=test.out bs=1M count=1024 oflag=direct
２つのコンテナ間の blkio ウエイトの割合により、処理にかかる時間の割合が変わるのが分かるでしょう。
blkio ウエイトの設定は直接 IO (direct IO)のみです。現時点ではバッファ IO(buﬀered IO)をサポートしていません。

グル ープの追加--group-add: 実行時のグループを追加
Docker コンテナのプロセスを実⾏できるのは、デフォルトでは、補助的なグループに所属しているユーザのみです（訳者注：docker グループに所属するユーザ）。グループを更に追加したい場合は、このフラグを使います。
$ docker run --rm --group-add audio --group-add nogroup --group-add 777 busybox id
uid=0(root) gid=0(root) groups=10(wheel),29(audio),99(nogroup),777

実行時の権限、Linux 機能、LXC 設定--cap-add: Linux ケーパビリティの追加--cap-drop: Linux ケーパビリティの削除（ドロップ）- 28 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス--privileged=false: コンテナに拡張権限を与える--device=[]: --privileged（特権）フラグが無いコンテナ内でもデバイスの実行を許可--lxc-conf=[]: カスタム lxc オプションの追加

Docker 1.10 以降では、デフォルトの seccomp プロフィールでは、コンテナに対して --cap-addを指定しても、システムコールをブロックします。このような場合に私たちが推奨するのは、私たちの デフォルト プロフィールを元に書き換える⽅法です。あるいはデフォルトの seccomp プロフ
ァイルを使いたくないのであれば、実⾏時に --security-opt=seccomp=unconfined を指定できます。

デフォルトでは、Docker コンテナは「unprivileged」（権限が無い）ため、Docker コンテナの中で Docker デー
モンを動かす等ができません。これは、デフォルトのコンテナはあらゆるデバイスに対して接続できないためであり、「privileged」（特権）コンテナのみが全てのコンテナに接続できます（lxc-template.go*1 と cgroups devices*2 のドキュメントをご覧ください ）作業者が docker run --privileged を実⾏したら、Docker はホスト上の全てのデバイスに対して接続可能になります。この時、AppArmor や SELinux の設定があれば、ホスト上のコンテナ外のプロセスと同じように、ホスト上の同じアクセス権限が与えられた状態で利⽤可能になります。 --privileged の実⾏に関する追加情報については、Docker ブログの投稿*3 をご覧ください。
特定のデバイスに対する許可だけ加えたい時は、 --device フラグが使えます。これを指定したら、１つまたは複数のデバイスがコンテナ内から接続できるようになります。
$ docker run --device=/dev/snd:/dev/snd ...
デフォルトでは、コンテナはデバイスに対して read、write、mknod が可能です。それぞれの --device フラグは、:rwm という３つのオプション・セットで上書きできます。
$ docker run --device=/dev/sda:/dev/xvdc --rm -it ubuntu fdisk /dev/xvdc
Command (m for help): q$ docker run --device=/dev/sda:/dev/xvdc:r --rm -it ubuntu fdisk /dev/xvdc
You will not be able to write the partition table.
Command (m for help): q$ docker run --device=/dev/sda:/dev/xvdc:w --rm -it ubuntu fdisk /dev/xvdc
crash....
$ docker run --device=/dev/sda:/dev/xvdc:m --rm -it ubuntu fdisk /dev/xvdc
fdisk: unable to open /dev/xvdc: Operation not permitted--privileged に加え、作業者は --cap-add と --cap-drop を使い、ケーパビリティに対する詳細な制御が可能になります。デフォルトでは、Docker はデフォルトのケーパビリティ⼀覧を保持しています。次の表は、追加・削除可能な Linux ケーパビリティのオプション⼀覧です。

*1 https://github.com/docker/docker/blob/master/daemon/execdriver/lxc/lxc_template.go*2 https://www.kernel.org/doc/Documentation/cgroups/devices.txt*3 http://blog.docker.com/2013/09/docker-can-now-run-within-docker/- 29 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス

ケーパビリティのキー

説明

SETPCAP
SYS_MODULESYSRAWIOSYS_PACCTSYS_ADMINSYS_NICE

プロセスの機能を変更
カーネル・モジュールのロード(load)・アンロード(unload)
ランダム I/O ポート操作(iopl(2)と ioperm(2))
acct(2)を⽤いたプロセスのスイッチ回数のカウント有無
システム管理オペレーションの処理範囲
プロセスの nice 値(nice(2), setpriority(2)) を上げるのと、任意プロセスに対する
nice 値を設定
リソース上限の上書きシステム・クロック(settimeofday(2), stime(2), adjtimex(2))の設定
vhangup(2)を使⽤。仮想ターミナル上で ioctl(2)オペレーションの関連権限
mknod(2)で特別ファイルを作成
カーネル監査（auditing）ログに記録
カーネルの監査（auditing）を有効化。監査フィルタルールの変更や、監査状態やフィルタリング・ルールの読み出し
MAC 設定や状態の変更。Smack LSM ⽤の実装
Mandatory アクセス・コントロール（MAC）の上書き。Smack Linux Security
Module (LSM) ⽤の実装
様々なネットワーク関連処理の実施
特権 syslog(2)処理の実施
ファイルの UID と GID 属性を変更（chown(2)を参照）
RAW と PACKET ソケットを使⽤
ファイル⾳読み書き実⾏時に迂回し、権限を確認
操作権限の確認時に迂回し、ファイルの UID がシステム上で必要とする UID と⼀致するか確認
ファイル読み込み権限の確認を迂回し、ディレクトリの読み込み・実⾏権限を確認
ファイル変更時にユーザ ID とグループ ID を変更しない
シグナル送信時の権限確認をバイパスプロセス GID を GID ⼀覧にある任意のものに変更
プロセス UID を任意のものに変更
FS_APPEND_FL と FS_IMMUTABLE_FL i-node フラグを設定
ソケットをインターネット・ドメイン権限⽤のポート（ポート番号は 1024 以下）に割り当て
ソケットをブロードキャストし、マルチキャストをリッスンする
メモリのロック（mlock(2), mlockall(2), mmap(2), shmctl(2)）
System V IPC オブジェクト操作⽤の権限確認
chroot(2)を使い、ルート・ディレクトリを変更
ptrace(2)を使い、任意のプロセスをトレース
reboot(2)と kexec_load(2)を使い、後の処理⽤にリブートと新しいカーネルを読み込
み任意のファイルのリースを確⽴（詳細は fcntl(2) ）ファイルの機能を設定
システムを起動する何らかのトリガ
ブロック・システムをサスペンドする機能

SYS_RESOURCESYS_TIMESYS_TTY_CONFIGMKNODAUDIT_WRITE
AUDIT_CONTROL
MAC_OVERRIDE
MAC_ADMIN
NET_ADMINSYSLOGCHOWN
NET_RAWDAC_OVERRIDEFOWNER
DAC_READ_SEARCHFSETIDKILL
SETGIDSETUIDLINUX_IMMUTABLE
NET_BIND_SERVICE
NET_BROADCAST
IPC_LOCKIPC_OWNERSYS_CHROOT
SYS_PTRACESYS_BOOTLEASE
SETFCAP
WAKE_ALARMBLOCK_SUSPEND

より詳細なリファレンス情報は Linux man ページの capabilities(7)*1 をご覧ください。
作業者は全ての機能を有効化するために ALL 値を使えますが 、MKNOD だけ除外したい時は次のようにします。
$ docker run --cap-add=ALL --cap-drop=MKNOD ...

*1 http://linux.die.net/man/7/capabilities- 30 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス

ネットワーク・スタックとやりとりするには、 --privileged を使う替わりに、ネットワーク・インターフェースの変更には --cap-add=NET_ADMIN を使うべきでしょう。
$ docker run -t -i --rm ubuntu:14.04 ip link add dummy0 type dummy
RTNETLINK answers: Operation not permitted$ docker run -t -i --rm --cap-add=NET_ADMIN ubuntu:14.04 ip link add dummy0 type dummy
FUSE を基盤とするファイルシステムをマウントするには、 --cap-add と --device の両⽅を使う必要があります。
$ docker run --rm -it --cap-add SYS_ADMIN sshfs sshfs sven@10.10.10.20:/home/sven /mnt
fuse: failed to open /dev/fuse: Operation not permitted$ docker run --rm -it --device /dev/fuse sshfs sshfs sven@10.10.10.20:/home/sven /mnt
fusermount: mount failed: Operation not permitted$ docker run --rm -it --cap-add SYS_ADMIN --device /dev/fuse sshfs# sshfs sven@10.10.10.20:/home/sven /mnt
The authenticity of host '10.10.10.20 (10.10.10.20)' can't be established.
ECDSA key fingerprint is 25:34:85:75:25:b0:17:46:05:19:04:93:b5:dd:5f:c6.
Are you sure you want to continue connecting (yes/no)? yessven@10.10.10.20's password:root@30aa0cfaf1b5:/# ls -la /mnt/src/docker
total 1516
drwxrwxr-x 1 1000 1000 4096 Dec 4 06:08 .
drwxrwxr-x 1 1000 1000 4096 Dec 4 11:46 ..
-rw-rw-r-- 1 1000 1000
16 Oct 8 00:09 .dockerignore-rwxrwxr-x 1 1000 1000
464 Oct 8 00:09 .drone.yml
drwxrwxr-x 1 1000 1000 4096 Dec 4 06:11 .git
-rw-rw-r-- 1 1000 1000
461 Dec 4 06:08 .gitignore....
Docker デーモンを lxc 実⾏ドライバを使って起動する時（docker daemon --exec-driver=lxc）、作業者は１つまたは複数の LXC オプションを --lxc-conf パラメータで指定できます。これにより、lxc-template.go*1 にある新しいパラメータの追加や既存のパラメータ上書きが可能です。将来的には、Docker ホストによっては LXC が使えなくなる可能性があるため、注意が必要です。そのため、特定の実装に関する設定操作のためには、LXC の直接操作に慣れておいた⽅が良いでしょう。
Docker デーモンに管理されているコンテナに対して、--lxc-conf を使いコンテナの設定を変更可能です。しかし Docker デーモンは変更が施されたことを把握できないため、⾃分⾃⾝で管理上の不⼀致を解決する必要があります。例えば、 --lxc-conf でコンテナの IP アドレスを設定しても、コンテナ内の /etc/hosts ファイルには反映されません。

ログ記録ドライバ（--log-driver）
Docker デーモンはコンテナごとに異なったログ記録ドライバを指定できます。コンテナのログ記録ドライバを指定するには、docker run コマンドで --log-driver=VALUE を指定します。以下のオプションがサポートされています。

*1 https://github.com/docker/docker/blob/master/daemon/execdriver/lxc/lxc_template.go- 31 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

nonejson-filesyslogjournald
fluentd
awslogs

A2.1 docker runリファレンス

コンテナのログ記録ドライバを無効化します。このドライバでは docker logs が機能しません。
Docker に対応するデフォルトのログ記録ドライバです。ファイルに JSON メッセージを書き込みます。このドライバに対するオプションはありません。
Docker に対応する Syslog ログ記録ドライバです。ログのメッセージを syslog に書き込みます。
Docker に対応する Journald ログ記録ドライバです。ログのメッセージを journald に書き込みます。
シ Docker に対応する Fluentd ログ記録ドライバです。ログ・メッセージを fluentd に書き込みます（forward input）。
Docker に対応する Amazon CloudWatch Logs ロギング・ドライバです。ログ・メッセージを
Amazon CloudWatch Logs に書き込みます。

docker logs コマンドが使えるのは json-file と journald ログ記録ドライバのみです。ログ記録ドライバの詳細な情報については ログ記録ドライバの設定 をご覧ください。

Dockerﬁle イ メージのデフォルトより優先
開発者は Dockerﬁle を使ってイメージ構築時やコミット時、対象イメージを使ったコンテナを起動時に有効な各種パラメータを、開発者⾃⾝が設定できます。
実⾏時に４つのコマンド FROM、MAINTAINER、RUN、ADD は上書きできません。それ以外のコマンド全ては docker run
で上書きできます。開発者が Dockerﬁle で個々の命令を設定していたとしても、作業者はその設定を上書きして操作できます。

 CMD（デフォルトのコマンドかオプション）
 ENTRYPOINT（実⾏時に処理するデフォルトのコマンド） EXPOSE （受信⽤のポート）
 ENV（環境変数）
 VOLUME（共有ファイルシステム）
 USER WORKDIR

CMD（ デフォ ルト のコマ ンドか オプショ ン）
Docker コマンドラインでのオプションコマンドを取り消します。
$ docker run [オプション] イメージ[:タグ|@DIGEST] [コマンド] [引数...]
このコマンドは様々なオプションを指定します。イメージの作者が Dockerﬁle の CMD 命令を使い、デフォルトのコマンドを既に設定している場合があるためです。作業者（イメージからコンテナを実⾏する⼈）は、CMD 命令を上書きして新しいコマンドを実⾏します。
イメージに ENTRYPOINT も指定されていれば、CMD やコマンドは ENTRYPOINT に対する引数となります。

ENTRYPOINT（ 実行時 に処 理するデ フォル トのコ マンド ）--entrypoint="": Overwrite the default entrypoint set by the image
イメージの ENTRYPOINT はコマンドと似ています。これはコンテナを開始する時に実⾏するコマンドを指定しているためです。しかし、こちらは（意図的に）上書きを難しくしています。ENTRYPOINT が提供するのは、コンテナ- 32 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス

⾃⾝が持つデフォルトの特性や振る舞いです。そのため ENTRYPOINT を指定しておけば、コンテナ実⾏時、あたかもコンテナ⾃⾝をバイナリのようにして実⾏可能です。その場合は、デフォルトのオプションを持っているでしょうし、あるいは⾃分でコマンドを指定してオプションを指定することも可能です。しかし、時々オペレータはコンテナの中で何らかのコマンドを実⾏したい場合もあるでしょう。例えば、デフォルトの ENTRYPOINT の代わりに、⾃分で ENTRYPOINT を新たに指定したい場合です。次の例はコンテナ上でシェルを実⾏するものであり、同様に何らかのもの（/usr/bin/redis-server のように）を⾃動的に起動できます。
$ docker run -i -t --entrypoint /bin/bash example/redis
あるいは、次の２つの例は ENTRYPOINT に更にパラメータを渡すものです。
$ docker run -i -t --entrypoint /bin/bash example/redis -c ls -l$ docker run -i -t --entrypoint /usr/bin/redis-cli example/redis --help

EXPOSE （露出 用のポ ート）
run コマンドには、コンテナのネットワークに対応する以下のオプションがあります。
--expose=[]: コンテナ内のポートまたはポート範囲を露出する
これらは「EXPOSE」命令の露出ポートに追加する-P=false : 全ての露出ポートをホスト側インターフェースに公開する-p=[]: コンテナのポートまたはポート範囲をホスト側に公開する
書式: ip:ホスト側ポート:コンテナ側ポート | ip::コンテナ側ポート | ホスト側ポート:コン
テナ側ポート | コンテナ側ポート
ホスト側ポートとコンテナ側のポートは、どちらもポート範囲を指定可能です。
両方で範囲を指定した時は、コンテナ側のポート範囲とホスト側のポート範囲が一致する必要があります。例：-p 1234-1236:1234-1236/tcp
ホスト側のポート範囲しか指定しない時は、コンテナ側ポートが範囲になるとは限りません。
このような場合、コンテナ側で公開されるポートはホスト側のポート範囲のいずれかです。
(例 ``-p 1234-1236:1234/tcp`` )(実際の割り当てを確認するには ``docker port`` を使う)--link="" : 他のコンテナに対するリンクを追加 (<名前 or id>:エイリアス or <名前 or id>)
イメージの開発者は、EXPOSE 命令以外のネットワーク機能に関する管理は⾏えません。EXPOSE 命令が定義するのは、サービスが初期化時に提供する受信⽤ポートです。このポートはコンテナの中のプロセスが利⽤可能にします。作業者は --expose オプションを使い、公開⽤ポートを追加できます。
コンテナの内部ポートを露出（expose）するために、作業者はコンテナ実⾏時に -P か -p フラグを使えます。
公開⽤のポートはホスト上でアクセス可能であり、そのポートはホストに到達可能なクライアントであれば誰でも利⽤できます。
-P オプションはホスト・インターフェース上に全てのポートを公開します。Docker は公開されたポートを、ホ
スト側のポートに対してランダムに拘束（bind）します。このポートの範囲を エフェメラル・ポート範囲（ephemeral
port range）と呼び、/proc/sys/net/ipv4/ip_local_port_range によって定義されています。 -p フラグを使えば、特定のポートやポートの範囲を割り当てます。
コンテナ内のポート番号（サービスがリッスンしているポート番号）は、コンテナの外に露出するポート番号（クライアントが接続する番号）と⼀致させる必要がありません。例えば、コンテナ内の HTTP サービスがポート 80をリッスンしているとします（そして、イメージ開発者は Dockerﬁle で EXPOSE 80 を指定しているでしょう）。実- 33 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス

⾏する時に、ホスト側のポート 42800 以上が使われます。公開⽤ポートがホスト側のどのポートに割り当てられたかを確認するには、docker port コマンドを使います。
デフォルトのブリッジ・ネットワークにおいて、新しいクライアント・コンテナの起動時にオペレータが --linkを指定したら、クライアント・コンテナはプライベートなネットワーク・インターフェースを経由して公開ポートにアクセスできます。Docker ネットワーク概要 にあるユーザ定義ネットワーク上で --link を指定したら、コン
テナをリンクするためのエイリアス名を作成します。

ENV（ 環境変 数）
新しいコンテナの作成時、Docker は以下の環境変数を⾃動的に設定します。
変数

値

HOME
HOSTNAMEPATHUSER の値を元にして指定コンテナに関連づけるホスト名/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin のような⼀般的なディレクト
リを含む
コンテナが疑似ターミナル（pseudo-TTY）を割り当

TERM

更に、オペレータはコンテナに対して環境変数の組み合わせを -e フラグで追加できます。先ほど⾔及した環境
変数や、開発者が Dockerﬁle の中で ENV で定義済みの環境変数を上書きできます。
$ docker run -e "deep=purple" --rm ubuntu /bin/bash -c export
declare -x HOME="/"
declare -x HOSTNAME="85bc26a0e200"
declare -x OLDPWD
declare -x PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
declare -x PWD="/"declare -x SHLVL="1"declare -x container="lxc"declare -x deep="purple"
似たようなものとして、オペレータは -h で hostname （ホスト名）も定義できます。

TMPFS（tmfps ファイルシステムの マウ ント）--tmpfs=[]: tmpfs マウントを作成: コンテナ側ディレクトリ[:<オプション>],オプションは Linux コマンドの 'mount -t tmpfs -o' オプションと同⼀形式
この例では、オプションで rw、noexec、nosuid、size=65536k、コンテナに対して空の tmpfs をマウントしています。
$ docker run -d --tmpfs /run:rw,noexec,nosuid,size=65536k my_image

VOLUME（ 共有フ ァイルシステム）-v=[]: バインド（拘束）マウントを作成: [ホスト側ディレクトリ:]コンテナ側ディレクトリ[:<オプション>]
オプションはカンマ区切りで [rw|ro] または [z|Z]、[[r]shared|[r]slave|[r]private]、
そして [nocopy] から選択
host-src は絶対パスもしくは名前を値にします。
- 34 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス

rw（読み書き）または ro（読み込み専⽤）の指定が無ければ、読み書き可能なモードでマウントします。
nocopy モードを指定したら、コンテナ内に要求したボリューム・パスに対して、ボリュームを保存している場所
からの⾃動コピーを無効にします。名前付きボリュームの場合は、copy がデフォルトのモードです。コピー・モー
ドではバインド（拘束）マウント（bind-mounted）したボリュームに対するコピーをサポートしていません。
--volumes-from="": 指定したコンテナにある全てのボリュームをマウント

Ubuntu Utopic 14.10 と 15.04 には Docker の apt リポジトリが存在しますが、（Docker が）公式にサポートしていないものです。

注釈
Docker デーモンの開始・停⽌を systemd で管理する場合は、Docker デーモン⾃⾝がマウント・プロパゲーショ
ン（mount propagation）を管理できるよう、systemd の unit ファイル上で MountFlags というオプションを設定します。このマウントポイントが変更されても、Docker はマウント・プロパゲーションの変更を把握できません。
例えば、値を slave としているのであれば、ボリュームのプロパゲーション値に shared や rshared を指定すべきではないでしょう。
ボリューム関連コマンドは コンテナでデータを管理 セクション⾃⾝のドキュメントでも複雑なものです。開発者は１つまたは複数の VOLUME を作成し、イメージと関連づけることが可能です。しかし、作業者ができるのは、あるコンテナから別のコンテナに対してのみです（あるいは、コンテナからホスト側のボリュームにマウントする
場合）。
コンテナ側ディレクトリは /src/docs のように常に絶対パスの必要があります。ホスト側ディレクトリは絶対パ
スか名前を値に指定できます。ホスト側ディレクトリに絶対パスを指定する場合は、Docker は指定したパスを拘
束マウント（bind-mounts）します。名前を指定する場合は、Docker は名前を持つボリュームを作成します。
名前は英数字で始まる必要があり、以降は a-z0-9 、_（アンダースコア）、 .（ピリオド）、 -（ハイフン）が使えます。絶対パスは / （フォアワード・スラッシュ）で始める必要があります。
例えば、ホスト側ディレクトリの値に /foo か foo を指定したとします。 /foo 値を指定した場合は、Docker はホスト上に拘束マウントを作成します。foo を指定したら、Docker は指定された名前でボリュームを作成します。

USER
開発者は Dockerﬁle の USER 命令を使い、１つめのプロセスを実⾏する時のユーザを定義できます。コンテナ起
動時 -u オプションを使えば USER 命令を上書きできます。
-u="", --user="": ユーザ名または UID を指定する命令。オプションでグループ名や GUID を指定
以下は有効な例です。
--user=[ user | user:group | uid | uid:gid | user:gid | uid:group ]数値で UID を指定する場合は、0 〜 2147483647 の範囲内の必要があります。

- 35 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.1 docker runリファレンス

WORKDIR
コンテナ内でバイナリを実⾏する時、デフォルトの作業⽤ディレクトリはルート( / ) ディレクトリです。しかし開発者は Dockerﬁle の WORKDIR コマンドを使い、デフォルトの作業⽤ディレクトリを変更できます。作業者が更に設定を上書きするには、次のようにします。
-w="": コンテナ内の作業用（ワーキング）ディレクトリ

- 36 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.2 Dockerコマンド

A2.2 Docker コマンド
このセクションは、Docker のコマンドライン・クライアントを使うにあたってのリファレンス情報です。各コ
マンドのリファレンス・ページにはサンプルもあります。コマンドラインに慣れていなければ、次のセクション「Docker コマンドラインを使う」から読み始めた⽅が良いでしょう。
Docker デーモンの起動はコマンドラインで⾏います。Docker デーモンは Docker コンテナに影響を与えるものです。そのため、daemon のリファレンス・ページも読んだ⽅が望ましいでしょう。
Docker 管理コマンド

 daemon info inspect version
イメージ用コマンド build
 commit
 export
 history
 images import
 load rmi
 save tag

コンテナ用コマンド attach
 cp
 create diff events
 exec kill logs pause port ps rename- 37 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.2 Dockerコマンド

 restart
 rm
 run
 start stats
 stop
 top
 unpause waitHub ・レジストり用コマンド

 login logout pull push search
ネットワークと接続用コマンド

 network_connect
 network_create
 network_disconnect
 network_inspect network_ls
 network_rm
共有データボリューム用コマンド

 volume_create
 volume_inspect
 volume_ls
 volume_rm

A1.2.1 Docker コマンドラインを使う
利⽤可能なコマンドを確認するには、docker にパラメータを付けずに実⾏するか、docker help を実⾏します。
$ docker
Usage: docker [OPTIONS] COMMAND [arg...]docker daemon [ --help | ... ]docker [ --help | -v | --version ]-H, --host=[]: The socket(s) to talk to the Docker daemon in the format of tcp://host:port/path,- 38 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.2 Dockerコマンド

unix:///path/to/socket, fd://* or fd://socketfd.
A self-sufficient runtime for Linux containers.
...
Docker のシステム設定によっては、各 docker コマンドの前に sudo を付ける必要があるかもしれません。docker
コマンドを実⾏する度に sudo を実⾏しないようするには、システム管理者に docker という Unix グループの作成を、そこへのユーザの追加を依頼ください。
Docker のインストールや sudo 設定については、各オペレーティング・システム向けのインストール⽅法のセクションをご覧ください。

環 境変数
簡単に利⽤できるように、 docker コマンドラインは以下の環境変数をサポートしています。

 DOCKER_CONFIG クライアントの設定ファイルの場所。
 DOCKER_CERT_PATH 認証鍵ファイルの場所。
 DOCKER_DRIVER 使⽤するグラフドライバ。
 DOCKER_HOST デーモンのソケット接続先。
 DOCKER_NOWARN_KERNEL_VERSION Docker に対応していない Linux カーネルで警告を出さない。
 DOCKER_RAMDISK ʻ pivot_root ʼ を無効に設定。
 DOCKER_TLS_VERIFY Docker で TLS とリモート認証を使う。
 DOCKER_CONTENT_TRUST Docker でイメージの署名・確認⽤のために Notary 使⽤時に設定。これは、build、
create、pull、push、run で --disable-content-trust=false を実⾏するのと同等
 DOCKER_CONTENT_TRUST_SERVER Notary サーバが使う URL を指定。デフォルトはレジストリと同じ URL 。
 DOCKER_TMPDIR ⼀時 Docker ファイルの場所。
Docker は「Go」⾔語で開発されているので、「Go」ランタイムが利⽤する環境変数も使えます。特に次のものは便利です。

 HTTP_PROXY HTTPS_PROXY NO_PROXY
これら Go ⾔語の環境変数は⼤⽂字と⼩⽂字を区別しません。変数の詳細については Go ⾔語の仕様*1 をご確認ください。

設 定ファイル
Docker コマンドラインは、ホームディレクトリ$HOME にある .docker ディレクトリ内に保管されている設定フ
ァイルを、デフォルトで使います。しかし、DOCKER_CONFIG 環境変数や --config コマンドライン・オプションを使い、異なった場所を指定できます。両⽅が指定された場合は --config オプションが DOCKER_CONFIG 環境変数を上書きします。例：*1 http://golang.org/pkg/net/http/- 39 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.2 Dockerコマンド

docker --config ~/testconfigs/ ps
ps コマンドの実⾏時、 ~/testconfigs/ ディレクトリにある設定ファイルで Docker に命令します。
Docker は設定ディレクトリにある対部分のファイルを管理していますので、これらを⾃分で変更すべきではありません。しかし、docker コマンドの振る舞いを制御するため、config.json を編集できます 。
現在、docker コマンドの挙動を環境変数かコマンドラインのオプションで変更可能です。あるいは、オプション
として config.json を使い、同じように淀宇を設定できます。これらの仕組みを使う場合は、優先順位に気を付ける必要があります。コマンドラインのオプションは環境変数で上書きされ、環境変数は config.json ファイルで指定した項⽬に上書きされます。
config.json ファイルは複数の属性 JSON エンコーディングで記述します。
HttpHeader 属性は、Docker クライアントがデーモンに対して送信する時、全てのメッセージに含めるヘッダを指定します。Docker は、これらのヘッダを解釈したり理解しようとしません。つまり、単純にメッセージの中に追加するだけです。Docker は設定したヘッダ⾃⾝に対する変更を許可しません。
psFormat 属性は docker ps 出⼒のデフォルトの出⼒フォーマットを指定します。docker ps コマンドで --format
フラグが指定されなければ、Docker クライアントはこの属性を使います。この属性が設定されなければ、クライア
ントはデフォルトの表フォーマットに戻ります。サポートされている形式を確認するには、docker ps ドキュメン
トにあるフォーマットのセクションをご覧ください。
コンテナにアタッチ後は、CTRL-p CTRL-q キー・シーケンスで使ってデタッチできます。このデタッチ⽤キー・シーケンスは detachKeys 属性を使ってカスタマイズできます。カスタマイズでは <シーケンス> 値の属性を指定します。 <シーケンス> の書式は [a-Z] までの⽂字列をカンマ区切りにしたリストにするか、 ctrl- に以下のいずれかを組み合わせます。

 a-z （⼩⽂字のアルファベット⽂字列）
 @ （アット記号）
 [ （左かっこ） \\ （２つのバックスラッシュ） _ （アンダースコア） ^ （キャレット）Docker クライアントで起動するコンテナ全てにカスタマイズが適⽤されます。ユーザはコンテナごとにデフォ
ルトのキー・シーケンスを変更可能です。ユーザが指定するには、 --detach-keys フラグを docker attach、docker
exec、docker run、docker start コマンドで使います。
imageFormat 属性は docker ps 出⼒のデフォルトの出⼒フォーマットを指定します。docker images コマンドで--format フラグが指定されなければ、Docker クライアントはこの属性を使います。この属性が設定されなければ、クライアントはデフォルトの表フォーマットに戻ります。サポートされている形式を確認するには、docker images
ドキュメントにあるフォーマットのセクションをご覧ください。
以下は config.json ファイルの記述例です：{"HttpHeaders": {"MyHeader": "MyValue"},"psFormat": "table {{.ID}}\\t{{.Image}}\\t{{.Command}}\\t{{.Labels}}"}- 40 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.2 Dockerコマンド

Notaryノータリー

⾃⾝で Notary サーバを使っている場合で、もしも⾃⼰証明の証明書や、内部の証明機関を使っているのであれば、docker 設定ディレクトリにある tls/<レジストリの URL>/ca.crt 証明書を置き換える必要があります。
あるいは、⾃分の証明書を信頼できるようにするためには、⾃分のシステム上のルート証明機関⼀覧に証明書を追加する⽅法もあります。

ヘ ルプ
ヘルプの⼀覧を表⽰するには、単純にコマンドを実⾏するか、 --help オプションを付けます。
$ docker run --help
Usage: docker run [OPTIONS] IMAGE [COMMAND] [ARG...]Run a command in a new container-a, --attach=[]--cpu-shares=0...

Attach to STDIN, STDOUT or STDERR
CPU shares (relative weight)

オ プション の種 類
１⽂字のコマンドラインのオプションは、連結できます。 docker run -i -t --name test busybox sh は、 docker
run -it -name test busybox sh に書き換えられます。
ブール値
ブール値のオプションとは -d=false のような形式です。何らかのフラグを設定しない場合のデフォルト値は、
ヘルプテキストで確認できます。ブール値にフラグ値を指定しなければ、デフォルト値に関係なくフラグは trueになります。
例えば、docker run -d を実⾏すると、値は true になります。そのため、コンテナは「デタッチド」モードとしてバックグラウンドで動作します。
オプションのデフォルトは true（例：docker build --rm=true）ですが、デフォルトではない値を指定するには
false を明⽰します。
$ docker build --rm=false .
複数回の指 定-a=[] のようなオプションは、コマンドライン上で複数回使えます。例えば、次のようなコマンドです。
$ docker run -a stdin -a stdout -i -t ubuntu /bin/bash$ docker run -a stdin -a stdout -a stderr ubuntu /bin/ls
オプションによっては -v オプションのように複雑になる場合もあります。
$ docker run -v /host:/container example/mysql
pty 実装に限界があるため、 -t と -a stderr オプションを同時に使わないでください。 pty モー
ドの stderr （標準エラー出力）は、単純に stdout （標準出力）になります。

- 41 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.2 Dockerコマンド

文字列と整 数--name="" のように⽂字が含まれるオプションは、１つしか指定できません。 -c=0 のように整数の場合も、１つしか指定できません。

- 42 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド

A2.3 管理用コマンド
デ

ー

モ

ン

daemon使い方: docker daemon [オプション]
Linux コンテナの自給自足ランタイム
オプション:--api-cors-header=""
リモート API の CORS ヘッダをセットする--authorization-plugin=[]
読み込む認証プログインを指定-b, --bridge=""
コンテナをネットワーク・ブリッジにアタッチ--bip=""
ネットワーク・ブリッジ IP の指定--cgroup-parent=
全てのコンテナの親 cgroup を指定--cluster-store=""
分散ストレージバックエンドの URL--cluster-advertise=""
クラスタ上のデーモン・インスタンスのアドレス--cluster-store-opt=map[]
クラスタのオプションを指定--config-file=/etc/docker/daemon.json デーモン設定ファイル--containerd
containerd ソケットのパス-D, --debug
デバッグ・モードの有効化--default-gateway=""
コンテナのデフォルト・ゲートウェイ IPv4 アドレス--default-gateway-v6=""コンテナのデフォルト・ゲートウェイ IPv6 アドレス--dns=[]DNS サーバの指定--dns-opt=[]
DNS オプションの指定--dns-search=[]DNS の検索に使うドメイン（search domain）--default-ulimit=[]
コンテナのデフォルト ulimit 設定を指定--exec-opt=[]
実行時のオプションを指定--exec-root="/var/run/docker"
実行ステート・ファイルのルート・ディレクトリ
--fixed-cidr=""IP アドレスの IPv4 サブネットを固定--fixed-cidr-v6=""
IP アドレスの IPv6 サブネットを固定-G, --group="docker"
unix ソケット用のグループ-g, --graph="/var/lib/docker"
Docker 実行時の Docker ルート-H, --host=[]
接続するデーモンのソケット--help
使い方を表示--icc=true
コンテナ内部通信（inter-container communication）を有効化--insecure-registry=[]
安全ではないレジストリとの通信を有効化--ip=0.0.0.0
コンテナのポートがデフォルトでバインドする IP--ip-forward=true
net.ipv4.ip_forward の有効化--ip-masq=true
IP マスカレードの有効化--iptables=true
iptables のルール追加の有効化--ipv6
IPv6 ネットワークの有効化-l, --log-level="info"
ログ記録レベルの設定--label=[]デーモンにキー=バリューのラベルを指定--log-driver="json-file"
デフォルトのコンテナのログ記録ドライバ--log-opt=[]
ログドライバのオプションを指定--mtu=0コンテナ・ネットワークの MTU を指定--disable-legacy-registry
レガシーのレジストリには接続しない-p, --pidfile="/var/run/docker.pid"
デーモン PID ファイル用のパス--registry-mirror=[]Docker レジストリの優先ミラー-s, --storage-driver=""
使用するストレージ・ドライバ--selinux-enabled
SELinux サポートの有効化--storage-opt=[]
ストレージ・ドライバのオプションを指定--tls
TLS を使用、--tlsverify を含む--tlscacert="~/.docker/ca.pem"
この CA で署名された証明書のみ信頼--tlscert="~/.docker/cert.pem"
TLS 証明書ファイルのパス- 43 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1--tlskey="~/.docker/key.pem"--tlsverify--userns-remap="default"--userland-proxy=true

A2.3 管理⽤コマンド

TLS 鍵ファイルのパス
TLS でリモート認証
ユーザ名前空間の再マッピングを有効化
ループバック通信用に userland プロキシを使う[] が付いているオプションは、複数回指定できます。
Docker デーモン（daemon）はコンテナを管理するために常駐するプロセスです。Docker はデーモンもクライ
アントも同じバイナリを使います。デーモンを起動するには docker daemon を⼊⼒します。
デーモンでデバッグ出⼒を⾏うには、docker daemon -D を使います。

デ ーモン ・ソケ ット のオプ ション
Docker デーモンは Docker リモート API を受信できます。３種類のソケット unix、tcp、fd を通します。
デフォルトでは unix ドメイン・ソケット（あるいは IPC ソケット）を /var/run/docker.sock に作成します。
そのため、操作には root 権限または docker グループへの所属が必要です。
Docker デーモンにリモートからの接続を考えているのであれば、tcp ソケットを有効にする必要があります。デ
フォルトのセットアップでは、Docker デーモンとの暗号化や認証機能が無いのでご注意ください。また、安全に使うには内部の HTTP 暗号化ソケットを使うべきです。あるいは、安全なウェブ・プロキシをフロントに準備してください。ポート 2375 をリッスンしている場合は、全てのネットワーク・インターフェースで -H
tcp://0.0.0.0:2375 を指定するか、あるいは IP アドレスを -H tcp://192.168.59.103:2375 のように指定します。
慣例として、デーモンとの通信が暗号化されていない場合はポート 2375 を、暗号化されている場合はポート 2376
を使います。
HTTP 暗号化ソケットを使う時は、TLS 1.0 以上でサポートされているプロトコル SSLv3 以上をお使いください。以下のバージョンはセキュリティ上の理由によりサポートされていません。

systemd をベースとするシステムでは、Systemd ソケット・アクティベーション*1 を通し、docker daemon -H fd://で通信が可能です。 fd:// は⼤部分のセットアップで動作するため、個々のソケットを docker daemon -H fd://3のように指定できます。もし指定したソケットが⾒つからない時は、Docker が終了します。Docker で Systemd ソ
ケット・アクティベーションを使う例は Docker のソース・ツリー*2 をご覧ください。
Docker デーモンは複数の -H オプションを使い、複数のソケットをリッスンできます。
# デフォルトの unix ソケットと、ホスト上の２つの IP アドレスをリッスンする
docker daemon -H unix:///var/run/docker.sock -H tcp://192.168.59.106 -H tcp://10.10.10.2
Docker クライアントは DOCKER_HOST 環境変数か -H フラグで接続できるようになります。
$ docker -H tcp://0.0.0.0:2375 ps# あるいは$ export DOCKER_HOST="tcp://0.0.0.0:2375"$ docker ps# どちらも同じです
DOCKER_TLS_VERIFY 環境変数が設定してあれば、コマンド実⾏時に --tlsverify フラグを都度指定するのと同じです。以下はいずれも同じです。

*1 http://0pointer.de/blog/projects/socket-activation.html*2 https://github.com/docker/docker/tree/master/contrib/init/systemd/- 44 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド$ docker --tlsverify ps# または$ export DOCKER_TLS_VERIFY=1$ docker ps
Docker クライアントは HTTP_PROXY、HTTPS_PROXY、NO_PROXY 環境変数を（あるいは⼩⽂字でも）使えます。
HTTPS_PROXY は HTTP_PROXY よりも上位です。
デーモンのスト レ ージ・ ドラ イバ 用オ プション
Docker デーモンはイメージ・レイヤ⽤途に、様々に異なるストレージ・ドライバの利⽤をサポートします。ドライバは、aufs、devicemapper、btrfs、zfs、overlay です。
エーユーエフエス

最も古いのは aufs ドライバであり、Linux カーネルに対するパッチ群が基礎になっています。ドライバには
メイン・カーネルにマージされなかったコードも含まれます。そのため、深刻なカーネルのクラッシュを引き起こすのが分かっています。⼀⽅で、aufs はコンテナの共有実⾏と共有ライブラリ・メモリが使える唯⼀のストレージ・ドライバです。そのため、同じプログラムやライブラリで数千ものコンテナを実⾏する時は便利な選択でしょう。
デ バ イ ス マ ツ パ ーdevicemapper ドライバはシン・プロビジョニング（thin provisioning）とコピー・オン・ライト（Copy on Write）
ス ナ ッ プ シ ョ ッ ト を 使 い ま す 。 devicemapper の 各 グ ラ フ （ Graph） が あ る 典 型 的 な 場 所 は 、/var/lib/docker/devicemapper です。シン（thin）プールは２つのブロックデバイス上に作ります。１つはデータで、もう１つはメタデータです。デフォルトでは、別々のファイルとして⾃動作成したループバックのマウントを元に、これらのブロック・デバイスを⾃動的に作成します。セットアップのカスタマイズ⽅法は、以下にある ス
トレージ・ドライバのオプションをご覧ください。オプションを使わない設定⽅法については、jpetazzo/Resizing
Docker containers with the Device Mapper plugin *1 の記事に説明があります。
ビーツリーエフエス

b t r f s ドライバは docker build が⾮常に⾼速です。しかし devicemapper のような、デバイス間の実⾏メモ

リを共有しません。使うには docker daemon -s btrfs -g /mnt/btrfs_partition を実⾏します。
zfs ドライバは btrfs ほど速くありませんが、安定さのためレコードを⻑く追跡します。Single Copy ARC のおかげで、クローン間の共有ブロックを１度キャッシュします。使うには docker daemon -s zf を指定します。異なる zfs
ファイルシステムセットを選択するには、zfs.fsname オプションを ストレージ・ドライバのオプションで指定します。
overlay は⾮常に⾼速なユニオン・ファイル・システムです。ようやく Linux カーネル 3.18.0 でメインにマージされました。使うには docker daemon -s overlay を指定します。
前途有望な overlay ですが、機能がまだ若く、プロダクションで使うべきではありません。特にoverlay を使うと過度の inode 消費を引き起こします（特にイメージが⼤きく成⻑する場合）。また、RPM との互換性がありません。
現時点でサポートされていない btrfs や他のコピー・オン・ライトのファイルシステムは、ext4 パーティション上のみで使うべきです。

ス トレ ージ ・ドラ イバの オプショ ン
個々のストレージドライバは --storage-opt フラグでオプションを設定できます。devicemapper ⽤のオプショ
ンは dm で始まり、zfs ⽤のオプションは zfs で始まります。

*1 http://jpetazzo.github.io/2014/01/29/docker-device-mapper-resize/- 45 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド

dm.thinpooldev
シン・プール⽤に使うカスタム・ブロックストレージ・デバイスを指定します。
ブロック・デバイスをデバイスマッパー・ストレージに指定する場合は、lvm を使うシン・プール・ボリュームの作成・管理がベストです。その後、このボリュームは Docker により、イメージまたはコンテナで、排他的なス
ナップショット⽤ボリュームを作成するために使われます。
シン・プールの管理を Docker Engine の外で⾏うため、最も機能豊富な⼿法をもたらします。Docker コンテナの背後にあるストレージとして、Docker はデバイスマッパーによる シン・プロビジョニングを活⽤するからです。
lvm をベースにしたシン・プール管理機能に含まれるハイライトは、⾃動もしくはインタラクティブなシン・プー
ルの容量変更のサポートです。動的にシン・プールを変更する機能とは、lvm が シン・プールをアクティブにする時、⾃動的にメタデータのチェックを⾏います。
シン・プールが割り当てられなければフェイルバックします。この時、ループバックのファイルが作成されます。
ループバックは⾮常に遅いものですが、ストレージの再設定を⾏わなくても利⽤可能になります。プロダクション
環境においては、ループバックを使わないよう強く推奨します。Docker Engine デーモンで --storage-opt
dm.thinpooldev の指定があるのを確認してください。
使⽤例：$ docker daemon \--storage-opt dm.thinpooldev=/dev/mapper/thin-pooldm.basesize
ベース・デバイス作成時の容量を指定します。これはイメージとコンテナのサイズの上限にあたります。デフォ
ルトの値は 10GB です。シン・デバイスは本質的に「希薄」（sparse）なのを覚えて置いてください。そのため、10GBのデバイスの⼤半が空っぽで未使⽤だったとしても、10GB の領域がプールされます。しかしながら、ファイルシ
ステムがより⼤きなデバイスであれば、空っぽだとしても多くの容量を使う可能性があるでしょう。
以後のイメージや（イメージを元にする）コンテナが利⽤可能となる新しいベース・デバイス容量を増やしたい
場合は、デーモンの再起動で変更できます。
使⽤例：$ docker daemon --storage-opt dm.basesize=50G
これはベース・デバイス容量を 50GB に増やしています。Docker デーモンはこのベース・イメージの容量が50GB よりも⼤きくなるとエラーを投げます。ユーザはこのオプションを使ってベース・デバイス容量を拡張でき
ますが、縮⼩はできません。
システム全体の「ベース」となる空⽩のファイルシステムに対して、設定値が影響を与えます。これは、既に初期化されているか、取得しているイメージから継承している場合です。とりわけ、この値の変更時には、反映するために追加⼿順が必要です。
$ sudo service docker stop$ sudo rm -rf /var/lib/docker$ sudo service docker start
使⽤例：$ docker daemon --storage-opt dm.basesize=20G- 46 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド

dm.loopdatasize

この設定はデバイスマッパーのループバックを変更するものです。プロダクションで使うべきではありません。

「データ」デバイスがシン・プール⽤に使うためのループバック・ファイルの作成時、この容量の指定に使います。デフォルトの容量は 100GB です。ファイルは希薄なため、初期段階ではさほど容量を使いません。
使⽤例：$ docker daemon --storage-opt dm.loopdatasize=200G
dm.loopmetadatasize

この設定はデバイスマッパーのループバックを変更するものです。プロダクションで使うべきではありません。

「メタデータ」デバイスがシン・プール⽤に使うためのループバック・ファイルの作成時、この容量の指定に使います。デフォルトの容量は 2GB です。ファイルは希薄なため、初期段階ではさほど容量を使いません。
使⽤例：$ docker daemon – storage-opt dm.loopmetadatasize=4G
dm.fs
ベース・デバイスで使⽤するファイルシステムの種類を指定します。サポートされているオプションは「ext4」と「xfs」です。デフォルトは「xfs」です。
使⽤例：$ docker daemon --storage-opt dm.fs=ext4
dm.mkfsarg
ベース・デバイスの作成時に mkfs に対する追加の引数を指定します。
使⽤例：$ docker daemon --storage-opt "dm.mkfsarg=-O ^has_journal"
dm.mountopt

シン・デバイスをマウントする時に使う、追加マウントオプションを指定します。
使⽤例：$ docker daemon – storage-opt dm.mountopt=nodiscard
dm.datadev（廃⽌されました。dm.thinpooldev をお使いください ）- 47 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド

シン・プール⽤のブロック・デバイスが使うデータを指定します。
デバイスマッパー⽤のストレージにブロック・デバイスを使う時、datadev と metadatadev の両⽅がループバッ
ク・デバイスを完全に使わないようにするのが理想です。
使⽤例：$ docker daemon \--storage-opt dm.datadev=/dev/sdb1 \--storage-opt dm.metadatadev=/dev/sdc1
dm.metadatadev（廃⽌されました。dm.thinpooldev をお使いください ）シン・プール⽤のブロック・デバイスが使うメタデータを指定します。
最も性能の⾼いメタデータとは、データとは軸が異なる場所にあるものです。SSD を使うのが望ましいでしょう。
新しいメタデータ・プールのセットアップには有効化が必要です。次のように、ゼロ値を使い、始めから 4096
まで空⽩のメタデータを作ります。
$ dd if=/dev/zero of=$metadata_dev bs=4096 count=1
使⽤例：$ docker daemon \--storage-opt dm.datadev=/dev/sdb1 \--storage-opt dm.metadatadev=/dev/sdc1
dm.blocksize
シン・プールで使うカスタム・ブロックサイズを指定します。デフォルトのブロックサイズは 64K です。
使⽤例：$ docker daemon --storage-opt dm.blocksize=512K
dm.blkdiscard
デバイスマッパー・デバイスの削除時に blkdiscard を使うか使わないかを指定します。デフォルトは有効であり、
ループバック・デバイスを使っているのであれば、イメージやコンテナ削除時にループバック・ファイルを再希薄化させるために使います。
このループバックを無効にしたら、コンテナの削除時間がより早くなります。しかし、 /var/lib/docker ディレ
クトリで使⽤している領域量は、コンテナが削除された時点で使っていた領域を返してしまいます。
使⽤例：$ docker daemon --storage-opt dm.blkdiscard=false
dm.override̲udev̲sync̲checkdevicemapper と udev 間における udev 同期確認の設定を上書きします。udev は Linux カーネル⽤のデバイスマッパーです。
Docker デーモンが udev 同期をサポートしているかどうかは、devicemapper ドライバを使い確認します。

- 48 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド$ docker info[...]
Udev Sync Supported: true[...]
udev 同期サポートが true であれば、devicemapper と udev を組み合わせ、コンテナ向けのデバイスを有効化（activation）
・無効化（deactivation）します。
udev 同期サポートが false であれば、devicemapper と udev 間で作成・クリーンアップ時に競合を引き起こします。競合状態の結果、エラーが発⽣して失敗します（の失敗に関する詳しい情報は docker#4036*1 をご覧ください。
）
docker デーモンの起動時に有効にするには、udev 同期をサポートしているかどうかに拘わらず、
dm.override_udev_sync_check を true にします。
$ docker daemon --storage-opt dm.override_udev_sync_check=true
この値が true の場合、devicemapper はエラーが発⽣しても簡単に警告を表⽰するだけで、処理を継続します。
docker デーモンと環境を追跡するという考えは、udev の同期機能をサポートするためのものでした。このトピックに関しては docker#4036 をご覧ください。⼀⽅で、既存の Docker デーモンを、サポートされている別の環境に移⾏する時のフラグとしても使います。

dm.use̲deferred̲removal
libdm やカーネル・ドライバがサポートしている仕組みがあれば、デバイス削除の遅延を有効化します。
デバイス削除の遅延が意味するのは、デバイスを無効化・⾮アクティブ化しようとしてもビジー（使⽤中）であ
れば、デバイス上で遅延削除が予定されます。そして、最後にデバイスを使っているユーザが終了したら、⾃動的に削除します。
例えば、コンテナを終了したら、関連づけられているシン・デバイスも削除されます。デバイスが他のマウント
名前空間も利⽤しているの場合は、削除できません。コンテナの終了が成功したら、このオプションが有効であれ
ば、システムがデバイスの遅延削除をスケジュールします。使⽤中のデバイスが削除できるまで、ループを繰り返すことはありません。
使⽤例：$ docker daemon --storage-opt dm.use_deferred_removal=true
dm.use̲deferred̲deletion
シン・プール⽤デバイスの遅延削除を有効化するのに使います。デフォルトでは、シン・プールの削除は同期します。コンテナを削除する前に、Docker デーモンは関連するデバイスを削除します。ストレージ・ドライバがデバイスを削除できなければ、コンテナの削除は失敗し、デーモンはエラーを表⽰します。
この失敗を避けるには、デバイス遅延削除（deletion）と、デバイス遅延廃⽌（removal）をデーモンで有効化します。
$ docker daemon \--storage-opt dm.use_deferred_deletion=true \--storage-opt dm.use_deferred_removal=true*1 https://github.com/docker/docker/issues/4036- 49 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド

この２つのオプションが有効であれば、ドライバがコンテナを削除する時にデバイスが使⽤中でも、ドライバはデバイスを削除対象としてマークします。その後、デバイスが使えなくなったら、ドライバはデバイスを削除します。
通常、安全のためにデフォルトでこのオプションを有効化すべきです。複数のマウント名前空間にまたがり、マ
ウントポイントの意図しないリークが発⽣した時に役⽴つでしょう。

dm.min̲free̲space

シン・プールが新しいデバイスを正常に作成するために必要な最⼩ディスク空き容量を、パーセントで指定します。チェックはデータ領域とメタデータ領域の両⽅に適⽤します。有効な値は 0%~99%です。値を 0%に指定すると空き領域のチェック機構を無効にします。ユーザがオプションの値を指定しなければ、Engin はデフォルト値 10%を⽤います。
新しいシン・プール⽤デバイスを作成すると（docker pull 時やコンテナの作成時 ）、すぐに Engine は最⼩空き
容量を確認します。⼗分な領域が無ければデバイスの作成は失敗し、対象の docker オプションは失敗します。
このエラーから復帰するには、エラーが出なくなるようシン・プール内の空き容量を増やす必要があります。シン・プールかにある同じイメージやコンテナを削除することで、空き容量を増やせます。
LVM (Logical Volume Management；論理ボリューム管理) シン・プールの容量を増やすには、コンテナのシン・プールのボリューム・グループに対する領域を追加します。そうすると、エラーは出なくなります。もしループ・デバイスを使う設定であれば、Engine デーモンは停⽌します。この問題を解決するにはデーモンを再起動してループ・ファイルの容量を増やします。
指定例：$ docker daemon --storage-opt dm.min_free_space=10%
zfs.fsname
現時点で zfs がサポートしているオプションです。Docker が⾃⾝のデータセットとして、どの zfs ファイルシス
テムを使うか指定します。デフォルトの Docker は、docker グラフ（/var/lib/docker）がある場所を zfs ファイルシステムとして⽤います。
使⽤例：$ docker daemon -s zfs --storage-opt zfs.fsname=zroot/docker

Docker ランタイム実行 オプショ ン
コンテナディー

Docker デーモンは OCI*1 基準のランタイム（containerd デーモンの呼び出し）に基づいています。これに従いながら Linux カーネルの名前空間（namespaces）、コントロール・グループ（cgroups）、SELinux に対するインター
フェースとして動作します。

ラ ンタイム用 のオプ ション
ランタイムのオプションは --exec-opt フラグで指定できます。全てのオプションのフラグには、先頭に nativeが付きます。
（現時点では）唯⼀ native.cgroupdriver オプションを利⽤可能です。

*1 https://github.com/opencontainers/specs- 50 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド

native.cgroupdriver オプションはコンテナの cgroups 管理を指定します。systemd の cgroupfs で指定可能です。
systemd で指定時、対象が利⽤可能でなければ、システムはエラーを返します。native.cgroupdriver オプション
を指定しなければ cgroupfs を使います。
次の例は systemd に cgroupdriver を指定しています。
$ sudo docker daemon --exec-opt native.cgroupdriver=systemd
このオプション設定は、デーモンが起動した全てのコンテナに対して適⽤します。
また、Windows コンテナであれば特別な⽬的のために --exec-opt を使えます。Docker がデフォルトで使うコンテナの分離（isolation）技術を指定します。指定例：$ docker daemon --exec-opt isolation=hyperv
この指定は Windows 上のデフォルト分離技術として hyperv を使う指定です。デーモン起動時に分離技術の指定が無ければ、デフォルトでは Windows の分離技術として process を使います。

デ ーモン の DNS オ プション
全ての Docker コンテナ⽤の DNS サーバを設定するには、docker daemon --dns 8.8.8.8 を使います。
全ての Docker コンテナ⽤の DNS 検索ドメインを設定するには、docker daemon --dns-search example.com を使います。

安 全では ないレ ジス トリ
Docker はプライベート・レジストリが安全か否かを確認します。このセクションでは、レジストリの例として
プライベート・レジストリ (private registry) を使い、プライベート・レジストリが myregistry:5000 で動作しているものとします。
安全なレジストリは、TLS を使い、CA 証明書のコピーが /etc/docker/certs.d/myregistry:5000/ca.crt にあります。安全ではないレジストリとは、TLS を使っていない場合（例：平⽂の HTTP をリッスン）や、TLS を使っていても Docker デーモンが知らない CA 証明書を使う場合を指します。後者であれば、証明書が/etc/docker/certs.d/myregistry:5000/ 以下に存在しないか、証明書の照合に失敗しています（例：CA が違う）。
デフォルトでは、Docker はローカルにあるレジストリ（以下のローカル・レジストリについてをご覧ください）
は安全であるとみなします。Docker はレジストリが安全とみなさない限り、安全ではないレジストリとの通信はできません。安全ではないレジストリと通信できるようにするには、Docker デーモンに --insecure-registry という２つの形式のオプションが必要です。

 --insecure-registry myregistry:5000 は、Docker デーモンに対して myregistry:5000 が安全ではないと考えられると伝えます。
 --insecure-registry 10.1.0.0/16 は、Docker デーモンに対して、ドメインの逆引き時、CIDR 構⽂で記述した対象サブネット上に IP アドレスを持つ全てが安全ではないと伝えます。
このフラグは、複数のレジストリに対して安全ではないと複数回指定できます。
安全ではないレジストリを「安全ではない」と指定しなければ、docker pull、docker push、docker search を実⾏してもエラーメッセージが帰ってきます。ユーザは安全なレジストリを使うか、あるいは先ほどのように--insecure-registry フラグで Docker デーモンに対して明⽰する必要があります。
IP アドレスが 127.0.0.0/8 の範囲にあるローカルのレジストリは、Docker 1.3.2 以降、⾃動的に安全ではないレ
ジストリとしてマークされます。ですが、これを信⽤するのは推奨しません。将来のバージョンでは変更される可能性があります。
- 51 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド--insecure-registry を有効にするとは、暗号化されていない、あるいは信頼できない通信を可能にします。そのため、ローカル環境でのレジストリ実⾏には便利でしょう。しかし、セキュリティ上の脆弱性を⽣み出してしまうため、テスト⽬的のみで使うべきです。セキュリティを⾼めるには、 --insecure-registry を有効にするのではなく、信頼できる CA 機関が発⾏する CA を使うべきです。

過 去のレ ジス トリ--disable-legacy-registry を有効にしたら、Docker は v2 プロトコルをサポートしているデーモンとしか通信しないように強制します。この指定によって、デーモンは v1 レジストリへの push、pull、login を阻⽌します。
例外として、v1 レジストリでも search のみ実⾏できます。

Docker デーモ ンを HTTPS̲PROXY の 背後で 実行
LAN の内部で HTTPS プロキシを使う場合、Docker Hub の証明書がプロキシの証明書に置き換えられます。これら証明書を、Docker ホストの設定に追加する必要があります。
1. 各ディストリビューションに対応する ca-certificates パッケージをインストールします。
2. ネットワーク管理者にプロキシの CA 証明書を訊ね、 /etc/pki/tls/certs/ca-bundle.crt に追加します。
3. Docker デーモンに HTTPS_PROXY=http://ユーザ名:パスワード@proxy:port/ docker daemon を付けて起動します。ユーザ名:とパスワード@はオプションです。そして、プロ指揮の認証設定も必要であれば追加します。
これは Docker デーモンのリクエストに対してプロキシと認証の設定を追加しただけです。docker build でコンテナを実⾏する時は、プロキシを使うために更なる追加設定が必要です。

Ulimits の デフォ ルト--default-ulimit を使い、全てのコンテナに対するデフォルトの ulimit オプションを指定できます。これはdocker run 時に --ulimit オプションを指定するのと同じです。デフォルトを設定しなければ、ulimit 設定を継承します。 docker run 時に設定しなければ、Docker デーモンから継承します。docker run 時のあらゆる --ulimit
オプションは、デフォルトを上書きします。
noproc と ulimit フラグを使う時は注意してください。noproc は Linux がユーザに対して利⽤可能な最⼤プロセ
ス数を設定するものであり、コンテナ向けではありません。詳細については、 run リファレンスをご確認ください。

ノ ードの ディス カバリ （検 出）--cluster-advertise オプションは、 ホスト:ポート あるいは インターフェース:ポート の組み合わせを指定します。これは、この特定のデーモン・インスタンスがクラスタに⾃分⾃⾝の存在を伝える（advertising）ために使います。リモートホストに到達するデーモンの情報を、ここに指定します。インターフェースを指定する場合は、実際の Docker ホスト上の IP アドレスも含められます。例えば、docker-machine を使ってインストールする時、典型的なインターフェースは eth1 です。
デーモンはクラスタ内のノードに存在を伝えるため、 libkv*1 を使います。キーバリュー・バックエンドは相互に TLS をサポートします。デーモンが使⽤するクライアント TLS の設定は --cluster-store-opt フラグを使い、PEM エンコード・ファイルのパスを指定します。実⾏例：*1 https://github.com/docker/libkv/- 52 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド

docker daemon \--cluster-advertise 192.168.1.2:2376 \--cluster-store etcd://192.168.1.2:2379 \--cluster-store-opt kv.cacertfile=/path/to/ca.pem \--cluster-store-opt kv.certfile=/path/to/cert.pem \--cluster-store-opt kv.keyfile=/path/to/key.pem
現在サポートされているクラスタ・ストアのオプションは以下の通りです。
kv.cacertfile
頼すべき CA 証明書がエンコードされた PEM のローカル・パスを指定します。
kv.certfile
証明書でエンコードされた PEM のローカル・パスを指定。この証明書はクライアントがキーバリュー・ストアとの通信の証明に使います。
kv.keyfile
秘密鍵がエンコードされた PEM のローカル・パスを指定します。この秘密鍵はクライアントがキーバリュー・
ストアと通信時に鍵として使います。
kv.path
キーバリュー・ストアのパスを指定します。指定しなければ、デフォルトの docker/nodes を使います。

アク セス 認証
Docker のアクセス認証は認証プラグインの拡張であり、組織が組織⾃⾝で購⼊・構築できます。認証プラグイン（authorization plugin）を使うには、Docker daemon で --authorization-plugin=PLUGIN_ID オプションを使って起動します。
docker daemon --authorization-plugin=plugin1 --authorization-plugin=plugin2,...
PLUGIN_ID の値とは、プラグイン名かファイルのパスを指定します。どのプラグインを実装するかを決めるのは、名前またはパスです。あなたの Docker 管理者に対して、利⽤可能なプラグインの情報をお訊ねください。
プラグインをインストール後は、コマンドラインや Docker のリモート API を実⾏する時、プラグインを許可す
るか許可しないかを選べます。複数のプラグインをインストールした場合は、最後の１つだけが処理されます。
認証プラグインの作成⽅法については、この Docker ドキュメントの拡張に関するセクションにある 認証プラグ
イン をご覧ください。

デ ーモン のユーザ名 前空間 オプション
Linux カーネルの ユーザ名前空間(user namespace)サポート*1 はプロセスに対する追加のセキュリティを提供します。これを使えば、コンテナでユーザ ID とグループ ID を使う場合、それをコンテナの外、つまり Docker ホス
ト上で使うユーザ ID とグループ ID のユニークな範囲を指定できます。これは重要なセキュリティ改善になる可能性があります。デフォルトでは、コンテナのプロセスは root ユーザとして動作しますので、コンテナ内で管理特権（と制限）を持っていることが予想されます。しかし、その影響はホスト上の権限の無い uid に対して割り当てられます。
ユーザ名前空間のサポートを有効化したら、Docker はデーモンが扱うマッピングを作成します。これは、同じ
Engine のインスタンス上で実⾏する全コンテナと対応するものです。マッピングを使い、従属ユーザ（subordinate*1 http://man7.org/linux/man-pages/man7/user_namespaces.7.html- 53 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンドuser）ID と従属グループ ID を活⽤します。この機能は最近の全ての Linux ディストリビューション上において利⽤可能です。 --userns-remap パラメータを指定することで、 /etc/subuid と /etc/subguid ファイルがユーザとオプションのグループ⽤に使われます。このフラグに⾃分でユーザとグループを指定しなければ、ここでは defaultが指定されます。default のユーザとは dockremap と⾔う名前であり、各ディストリビューションの⼀般的なユー
ザとグループ作成ツールを使い、 /etc/passwd と /etc/group にエントリが追加されます。
現時点ではデーモンごとに１つしかマッピングしない制約があります。これは Engine インスタン
ス上で実⾏している全てのコンテナにまたがる共有イメージ・レイヤを Docker が共有しているためです。ファイルの所有者は、レイヤ内容を共有している全てのコンテナで共通の必要があるた
め、解決策としては docker pull の処理時、ファイル所有者をデーモンのユーザとグループに割り当てる（マッピングする）ことでした。そのため、イメージ内容をダウンロード後は遅延無くコンテナを起動できました。この設計は同じパフォーマンスを維持するため、docker pull と docker
push の実⾏時には維持されています。

ユ ーザ名 前空 間を有 効にしてデー モンを 起動
ユーザ名前空間のサポートを有効化するには、デーモン起動時に --userns-remap フラグを使います。以下のフォーマット形式が指定できます。

 uid
 uid:gid ユーザ名 ユーザ名:グループ名
整数値の ID を指定したら、有効なユーザ名かグループ名に交換されます。これにより、従属 uid と gid の情報が読み込まれ、指定されたこれらのリソースは ID ベースではなく名前ベースでとなります。 /etc/passwd や/etc/group にエントリが無い数値 ID 情報が指定された場合は、docker は起動せずにエラーを表⽰します。
Fedora 22 では、ユーザ作成時に範囲を割り当てるために必要な /etc/subuid と /etc/subgid フ
ァイルを、touch コマンドで作成する必要があります。この作業は --usernsremap オプションを有効にする前に行わなくてはいけません。ファイルが存在していれば、ユーザが作成した処理が範囲で処理が適切に行われるよう、デーモンを（再）起動できます。

例：default の Docker ユーザ管理$ docker daemon --userns-remap=default
default を指定したら、 Docker は dockermap というユーザ名とグループ名が存在しているかどうか確認し、無ければ作成します。ユーザを作成したら、 Linux ディストリビューションは /etc/subuid と /etc/subgid ファイ
ルの使⽤をサポートします。これは従属ユーザ ID と従属グループ ID を 65536 まで数える（カウントする）もので、これらは既存のファイルへのエントリをオフセットに使います。例えば、Ubuntu は次のような範囲を作成します。既存の user1 という名前のユーザは、既に 65536 までの範囲を持っています。
$ cat /etc/subuid
user1:100000:65536
dockremap:165536:65536- 54 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド

もしも、既に⾃分で⾏った従属ユーザの設定を使いたい場合は、 --userns-remap フラグにユーザ名または UIDを指定します。グループがユーザ名と⼀致しない場合は、同様に gid やグループ名も指定します。そうしなければ、従属グループ ID の範囲をシステムが応答する時に、ユーザ名がグループ名として使われます。

subuid/subgid 範 囲につ いての詳細 情報
パワーユーザであれば、従属 ID の範囲変更という⾼度な使い⽅があります。以下で扱うのは、現在どのようにして Docker デーモンが従属範囲のファイルから範囲を決めているかの定義です。
最も簡単なケースは、ユーザとグループに対する近接範囲（contiguous range）を１つだけ指定する場合です。
この例では、Docker はコンテナのプロセスに対し、ホスト側の uid と gid の全てを近接範囲として割り当て（マッピングし）ます。つまり、範囲において⼀番始めに割り当てるのが root ユーザです。この ID が初期 ID として、（ホスト側）範囲における最後をホスト ID 1 として（コンテナ側に）割り当てます。
先ほど取り上げた /etc/subuid の例では、root ユーザに再割り当てする uid は 165536 になります。
システム管理者は単⼀のユーザまたはグループに対して複数の範囲を設定できます。Docker デーモンは利⽤可能な範囲から、以下のアルゴリズムに基づき範囲を割り当てます。
1. 特定ユーザに対する範囲のセグメント（区分）が⾒つかれば、開始 ID を昇順でソートします。
2. セグメントの割り当てには、各セグメントの⻑さに⼀致するよう、範囲の値を増やします。そうすると、セグ
メントの範囲は最も低い数値から始まり、これを root として再割り当てし、あとはホスト側の uid/gid と⼀致する
範囲まで繰り返します。例えば、最⼩セグメントの ID が 1000 から始まり、⻑さが 100 としたら、1000 を 0 にマップし（root として再マップ）ます。これを対象セグメントでは 1100 が 100 にマップするまで続けます。次のセグメントは ID 10000 から始まる場合、次は 10000 が 101 にマップし、その⻑さの分だけ処理します。この処理を対象ユーザのサボーディネート（従属）ファイルに空きセグメントが無くなるまで繰り返します。
3. ユーザ向けのセグメント範囲が無くなった場合は、カーネルで５つまで使えるよう制限されているエントリ/proc/self/uid_map と /proc/self/gid_map が使えます。

コ ンテナ 用のユ ーザ 名前空 間を無 効化
デーモンでユーザ名前空間を有効にしたら、全てのコンテナはユーザ名前空間が有効な状態で起動します。状況
によってはコンテナに対するユーザ名前空間を無効化したい時があるでしょう。例えば、特権コンテナ（privileged
container）の起動時です（詳細は「ユーザ名前空間と既知の制限」のセクションをご覧ください ）。これらの⾼度な機能を使うには、コンテナの run exec create コマンド実⾏時に --userns=host を指定します。このオプション
を使えばコンテナの利⽤者に対するユーザ名前空間の割り当てを完全に無効化します。
ユーザ名前 空間 と既 知の制 限
Docker デーモンのユーザ名前空間を有効にした状態では、以下の Docker 標準機能は互換性がありません。

 ホスト・モードにおける PID 名前空間または NET 名前空間（--pid=host あるいは--net=host）
 --readonly コンテナ・ファイルシステム（ユーザ名前空間内において、現在のマウント・ファイルシステ
ムのフラグを変更してリマウントすることは、Linux カーネルの制約によりできません）
 デーモンが知らない／機能を持たない外部ドライバ（ボリュームやグラフ）をユーザ名前空間内で実⾏
 docker run で --privileged モードのフラグを指定（また --userns=host も指定できません ）⼀般的に、ユーザ名前空間は⾼度な機能であり、他の機能との調整を必要とします。例えば、ホストにボリュー
ムをマウントする時は、ファイルの所有者はユーザもしくは管理者がボリューム・コンテナにアクセスできるよう、
あらかじめ調整しておきます。
- 55 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド

最後に、ユーザ名前空間に対応したコンテナ・プロセス内の root ユーザとは、多くの管理特権を持っていると考えるかもしれません。ですが、Linux カーネルは内部情報に基づきユーザ名前空間内のプロセスとして制限を施します。現時点で最も注意が必要な制約は mknod の使⽤です。コンテナ内のユーザ名前空間では root であったとしてもデバイス作成の権限がありません。

そ の他の オプション
IP マスカレードはコンテナがパブリック IP を持っていなくても、インターネット上の他のマシンと通信するための仕組みです。これにより、インターフェースは複数のネットワーク・トポロジを持ちますが、 --ip-masq=falseを使って無効化できます。
Docker は Docker データ・ディレクトリ（/var/lib/docker）と /var/lib/docker/tmp に対するソフトリンクをサポートしています。DOCKER_TMPDIR を使っても、データディレクトリを次のように指定可能です。
DOCKER_TMPDIR=/mnt/disk2/tmp /usr/local/bin/docker daemon -D -g /var/lib/docker \-H unix:// > /var/lib/docker-machine/docker.log 2>&1
# あるいはexport DOCKER_TMPDIR=/mnt/disk2/tmp/usr/local/bin/docker daemon -D -g /var/lib/docker -H unix:// > /var/lib/docker-machine/docker.log 2>&1

デ フォル トの親 cgroup--cgroup-parent オプションは、コンテナがデフォルトで使う親 cgroup（cgroup parent）を指定できます。オプ
ションを設定しなければ /docker を fs cgroup ドライバとして使います。また system.slice を systemd cgroup ド
ライバとして使います。
cgroup はスラッシュ記号（ / ）で始まるルート cgroup の下に作成されますが、他の cgroup は daemon cgroupの下に作成されます。
デーモンが cgroup daemoncgroup で実⾏されており、--cgroup-parent=/foobar で/sys/fs/cgroup/memory/foobarの中に cgroup を作成したと仮定時、--cgroup-parent=foobar は/sys/fs/cgroup/memory/daemoncgroup/foobar にcgroup を作成します。
systemd cgroup ドライバは --cgroup-parent と異なるルールです。Systemd のリソース階層は、スライス（訳者
注：systemd における CPU やメモリなどのリソースを分割する単位のこと）とツリー上でスライスをエンコード
する場所の名前で表します。そのため systemd cgroups ⽤の --cgroup-parent はスライス名と同じにすべきです。
名前はダッシュ区切りの名前で構成します。つまりルート・スライスからのスライスに対するパスです。例えば--cgroup-parent=user-a-b.slice と 指 定 す る 意 味 は 、 コ ン テ ナ ⽤ の cgroup を/sys/fs/cgroup/memory/user.slice/user-a.slice/user-a-b.slice/docker-<id>.scope に割り当てます。
これらの指定はコンテナに対しても可能です。docker create と docker run の実⾏時に --cgroup-parent を使え
ば、デーモンのオプションで指定した --cgroup-parent よりも優先されます。

デ ーモン 設定フ ァイル--config-file オプションを使えば、デーモンに対する設定オプションを JSON 形式で指定できます。このファ
イルでは、フラグと同じ名前をキーとします。ただし、複数の項⽬を指定可能なフラグの場合は、キーを複数形で
指 定 し ま す （ 例 ： label フ ラ グ の 指 定 は labels に な り ま す ）。 デ フ ォ ル ト は 、 Linux の 場 合 は/etc/docker/daemon.json に あ る 設 定 フ ァ イ ル を Docker が 読 み 込 も う と し ま す 。 Windows の 場 合 は%programdata%\docker\config\daemon.json です。
設定ファイル上のオプションは、フラグで指定するオプションと競合してはいけません。ファイルとフラグが重複したまま docker デーモンを起動しようとしても、どのような値を指定しても、起動に失敗します。例えば、デーモンの起動時にラベルを設定ファイルで定義し、かつ、 --label フラグを指定したら、デーモンは起動に失敗し- 56 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド

ます。
デーモン起動時、ファイルに記述しないオプション項⽬は無視します。次の例は、利⽤可能な全てのオプション
をファイルに記述したものです。
{"authorization-plugins": [],"dns": [],"dns-opts": [],"dns-search": [],"exec-opts": [],"exec-root": "","storage-driver": "","storage-opts": [],"labels": [],"log-driver": "","log-opts": [],"mtu": 0,"pidfile": "","graph": "","cluster-store": "","cluster-store-opts": [],"cluster-advertise": "","debug": true,"hosts": [],"log-level": "","tls": true,"tlsverify": true,"tlscacert": "","tlscert": "","tlskey": "","api-cors-headers": "","selinux-enabled": false,"userns-remap": "","group": "","cgroup-parent": "","default-ulimits": {},"ipv6": false,"iptables": false,"ip-forward": false,"ip-mask": false,"userland-proxy": false,"ip": "0.0.0.0","bridge": "","bip": "","fixed-cidr": "","fixed-cidr-v6": "","default-gateway": "","default-gateway-v6": "","icc": false,"raw-logs": false,"registry-mirrors": [],"insecure-registries": [],"disable-legacy-registry": false}- 57 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド

設定の再読 み込 み
いくつかのオプションは設定を反映するために、デーモンのプロセスの再起動を必要とせず、実⾏中のまま⾏え
ま す 。 再 読 み 込 み す る た め に 、 Linux で は SIGHUP シ グ ナ ル を 使 い ま す 。 Windows で は
Global\docker-daemon-config-$PID をキーとするグローバル・イベントを使います。設定ファイルでオプションを変更できますが、指定済みのフラグと競合していなか確認されます。もし設定に重複があれば、デーモンは発⽣を反映できませんが、実⾏中のデーモンは⽌まりません。
現時点で変更可能なオプションは以下の通りです。

 debug：true を設定したら、デーモンをデバッグ・モードにします。
 cluster-store：新しいアドレスにディスカバリ・ストアを読み込み直します。
 cluster-store-opts：ディスカバリ・ストアをお⾒込む時の新しいオプションを指定します。
 cluster-advertise：再起動後のアドバタイズド・アドレスを指定します。
 labels：デーモンのラベルを新しく設定したものに変えます。
--cluster-store、 --cluster-advertise、 --cluster-store-opts のようなクラスタ設定情報の更新や再読み込みが反映できるのは、これまでに指定しない項⽬に対してのみです。フラグで --cluster-store を指定してもcluster-advertise を指定していなければ、 cluster-advertise は --cluster-store を⼀緒に指定しなくても反映します。
既に設定済みのクラスタ設定に対して変更を試みたら、設定読み込み時に警告メッセージをログに残します。

- 58 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド

イン フォ

info
使い方: docker info [オプション]システムの広範囲な情報を表示します。
--help

使い方を表示。

例：$ docker -D info
Containers: 14
Running: 3
Paused: 1
Stopped: 10
Images: 52
Server Version: 1.9.0
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 545
Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge null host
Kernel Version: 3.19.0-22-generic
OSType: linux
Architecture: x86_64
Operating System: Ubuntu 15.04
CPUs: 24
Total Memory: 62.86 GiB
Name: docker
ID: I54V:OLXT:HVMM:TPKO:JPHQ:CQCD:JNLC:O3BZ:4ZVJ:43XJ:PFHZ:6N2S
Docker Root Dir: /var/lib/docker
Debug mode (client): true
Debug mode (server): true
File Descriptors: 59
Goroutines: 159
System Time: 2015-09-23T14:04:20.699842089+08:00
EventsListeners: 0
Init SHA1:
Init Path: /usr/bin/docker
Docker Root Dir: /var/lib/docker
Http Proxy: http://test:test@localhost:8080
Https Proxy: https://test:test@localhost:8080
WARNING: No swap limit support
Username: svendowideit
Registry: [https://index.docker.io/v1/]
Labels:storage=ssd
Insecure registries:
myinsecurehost:5000
127.0.0.0/8- 59 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド

グローバルな -D オプションは 、docker コマンドのデバッグ情報を表⽰します。
issue レポートを送信する時は、私たちがどのような設定がされているか知るため、docker version と docker -D
info をお知らせください。

- 60 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド

インスペクトinspect
使い方: docker inspect [オプション] コンテナ|イメージ [コンテナ|イメージ...]
コンテナあるいはイメージの低レベル情報を表示-f, --format=""指定する go テンプレートを使い、出力を整形--help
使い方を表示--type=container|image JSON を返すイメージまたはコンテナの種類を指定-s, --size=false
種類がコンテナの場合、合計ファイルサイズを表示
デフォルトは、全ての結果を JSON 配列で表⽰します。フォーマットを指定した場合は、それぞれのテンプレー
トに従って結果を表⽰します。
デフォルトは、全ての結果を JSON 配列で表⽰します。コンテナとイメージが同じ名前を持つ場合は、タイプを指定しなければコンテナの JSON を返します。フォーマットを指定した場合は、それぞれのテンプレートに従って結果を表⽰します。
フォーマットの詳細については、Go ⾔語の text/template パッケージ*1 の説明をご覧ください。

例
インスタンス の IP ア ドレス を取 得
ほとんどの場合、通常の適切な処理で JSON フィールドから取得できます。
$ docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $INSTANCE_ID
インスタンス の MAC ア ドレス を取 得
ほとんどの場合、通常の適切な処理で JSON フィールドから取得できます。
$ docker inspect '{{range .NetworkSettings.Networks}}{{.MacAddress}}{{end}}' $INSTANCE_ID
インスタンス 用ログのパ スを 取得$ docker inspect --format='{{.LogPath}}' $INSTANCE_ID
バインドしてい るポ ート一 覧を 表示
配列の中をループして、割り当てられている結果を簡単な⽂字で出⼒します。
$ docker inspect \--format='{{range $p, $conf := .NetworkSettings.Ports}} {{$p}} -> {{(index $conf 0).HostPort}} {{end}}' \$INSTANCE_ID
特定のポ ート 割り当 てを 探す.Field 構⽂は数字で始まるフィールド名で使えませんが、テンプレート⾔語の index 機能では利⽤可能です。
.NetworkSettings.Prots セクションには、内部と外部にあるアドレス/ポートのオブジェクトに対する割り当てリス*1 http://golang.org/pkg/text/template/- 61 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド

トを含みます。index 0 は、そのオブジェクトの１番めの項⽬です。HostPort フィールドからパブリックアドレスを⼊⼿するには、次のようにします。
$ docker inspect --format='{{(index (index .NetworkSettings.Ports "8787/tcp") 0).HostPort}}' \$INSTANCE_ID
設定を取得 する
.Field 構⽂は JSON データを含む場合に使えませんが、テンプレート⾔語のカスタム json であれば利⽤可能です。 .config セクションは複雑な JSON オブジェクトですが、JSON 全体を取り込んでから、json を使って設定オ
ブジェクトを JSON に変換します。
$ docker inspect --format='{{json .config}}' $INSTANCE_ID- 62 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.3 管理⽤コマンド

バ ー ジ ョ ン

version使い方: docker version [オプション]
Docker バージョン情報を表示します。
-f, --format=""--help指定する go テンプレートを使い、出力を整形
使い方を表示

デフォルトでは、全てのバージョン情報を読みやすい形式で表⽰します。フォーマットを指定したら、特定のテンプレートで処理します。
Go ⾔語の text/template パッケージにフォーマットの全ての詳細が記載されています。

デ フォル トの出 力$ docker version
Client:Version:
1.8.0
API version: 1.20
Go version: go1.4.2
Git commit: f5bae0a
Built:
Tue Jun 23 17:56:00 UTC 2015
OS/Arch:linux/amd64
Server:Version:API version:
Go version:
Git commit:
Built:
OS/Arch:

1.8.0
1.20
go1.4.2
f5bae0a
Tue Jun 23 17:56:00 UTC 2015
linux/amd64

サ ーバの バージョン を取得$ docker version --format '{{.Server.Version}}'
1.8.0

raw デー タのダ ンプ$ docker version --format '{{json .}}'{"Client":{"Version":"1.8.0","ApiVersion":"1.20","GitCommit":"f5bae0a","GoVersion":"go1.4.2","Os":"linux","Arch":"amd64","BuildTime":"Tue Jun 23 17:56:00 UTC
2015"},"ServerOK":true,"Server":{"Version":"1.8.0","ApiVersion":"1.20","GitCommit":"f5bae0a","GoVersion":"go1.4.2","Os":"linux","Arch":"amd64","KernelVersion":"3.13.2-gentoo","BuildTime":"Tue Jun 23
17:56:00 UTC 2015"}}- 63 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

A2.4 イメージ用コマンド
ビ ル ド

build
使い方: docker build [オプション] パス | URL | パスにあるソースコードから新しいイメージを構築--build-arg=[]
構築時の変数を指定--cpu-shares
CPU 共有 (相対ウエイト)--cgroup-parent=""
コンテナ用のオプション親 cgroup--cpu-period=0
CPU CFS (Completely Fair Scheduler) 間隔の制限--cpu-quota=0
CPU CFS (Completely Fair Scheduler) クォータの制限--cpuset-cpus=""
実行時に許可する CPU。例 `0-3`, `0,1`--cpuset-mems=""
実行時に許可するメモリ。例 `0-3`, `0,1`--disable-content-trust=true
イメージの認証をスキップ-f, --file=""Dockerfile の名前 (デフォルトは 'PATH/Dockerfile')--force-rm
常に中間コンテナを削除--help
使い方を表示--isolation=""
コンテナの隔離（独立）技術--label=[]
イメージ用のメタデータを指定-m, --memory=""
構築コンテナのメモリ上限を指定--memory-swap=""
整数値の指定はメモリにスワップ値を追加。-1 は無制限スワップを有効化--no-cache
イメージ構築時にキャッシュを使わない--pull
常に新しいイメージのダウンロードを試みる-q, --quiet
構築時の表示を抑制し、成功時はイメージ ID を表示--rm=true構築に成功したら、全ての中間コンテナを削除--shm-size=[]`/dev/shm` のサイズ。書式は `<数値><単位>`。 `数値` は `0` 以上。単位は `b` (bytes)、`k` (kilobytes)、 `m` (megabytes)、 `g` (gigabytes) のどれか。単位を省略するとバイトになる。サイズを省略すると `64m` になる。
-t, --tag=[]'名前:タグ' 形式で名前とオプションのタグを指定--ulimit=[]
Ulimit オプション
Docker イメージは Dockerﬁle とコンテクスト（context）を使って構築します。構築時のコンテクストとは、特定のパスや URL の場所にあるファイルのことです。構築中のステップで、対象コンテクスト内のファイルを参照できます。
URL パラメータは Git リポジトリの場所を指定できます。つまり、リポジトリの内容をコンテクストとして構築できます。システムでリポジトリの再帰的なクローンを作成するには git clone --depth 1 --recursive コマンドを使います。このコマンドはローカルホスト上の⼀時ディレクトリで実⾏されます。コマンドが成功したら、ディレクトリが Docker デーモンにコンテクストとして送信されます。ローカルのクローンであれば、ローカルなユーザ
認証や VPN などを使うプライベート・リポジトリへのアクセスも可能にします。
Git の URL は、コロン : がコンテクストのセクションを分割する設定に使えます。１つめの場所は Git が調査⽤に参照します。これはブランチ、タグ、コミット SHA が使えます。２つめの場所はリポジトリ内にあるサブディレクトリであり、構築時のコンテクストとして使われます。
例えば、container ブランチを docker という名称のディレクトリでコマンドを実⾏するには：$ docker build https://github.com/docker/rootfs.git#container:docker
次の表は構築コンテクストで有効なサフィックスの⼀覧です。

- 64 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

構築構文のサフィックス

コミットで利用

構築コンテクストに利用

myrepo.git
myrepo.git#mytag
myrepo.git#mybranch
myrepo.git#abcdef
myrepo.git#:myfolder
myrepo.git#master:myfolder
myrepo.git#mytagr:myfolder
myrepo.git#mybranch:myfolder
myrepo.git#abcdef:myfolder

refs/heads/master
refs/heads/mytag
refs/heads/mybranchsha1 = abcdef
refs/heads/master
refs/heads/master
refs/heads/mytag
refs/heads/mybranchsha1 = abcdef/////myfolder/myfolder/myfolder/myfolder/myfolder

コンテクストを指定する代わりに、Dockerﬁle の URL や STDIN（標準⼊⼒）のファイルをパイプできます。STDINから Dockerﬁle をパイプするには：docker build - < Dockerfile
STDIN や URL を指定したら、システムはコンテクストを Dockerﬁle という名称のファイルに置き換えるため、-f および --file オプションは無視されます。今回の例では、コンテクストは指定していません。
デフォルトの docker build コマンドは、構築コンテクストのルートにある Dockerfile を探します。-f および--file オプションは、内容が含まれている代替ファイルのパスを指定します。これは複数のファイル群を使って、複数の構築をする場合に便利です。パスには構築コンテクスト⽤のファイルが必要です。相対パスを指定する時は、
現在のディレクトリに対する相対パスを指定する必要があります。
多くの場合、それぞれの Dockerﬁle を空のディレクトに⼊れるのがベストな⽅法です。それから、ディレクトリ
内には Dockerﬁle の構築に必要なものしか置きません。構築のパフォーマンスを向上するには、.dockerignore フ
ァイルを設置し、特定のファイルやディレクトリを除外する設定が使えます。このファイルを作るための詳しい⽅法は、.dockerignore ファイルのセクションをご覧ください。
Docker クライアントがデーモンと通信できなければ、構築はキャンセルされます。Docker クライアントで ctrl-cを使うか、何らかの理由により Docker クライアントが停⽌されても、構築は中断されます。
現時点で中断できるのは構築を「実⾏中」の段階のみです（pull の中断が実装されるまで）。

戻 り値（ リター ンコ ード）構築に成功したら、成功の 0 という戻り値を返します。構築に失敗したら、ゼロ以外の戻り値を返します。
失敗理由に関する情報は STDERR に表⽰されます。
$ docker build -t fail .
Sending build context to Docker daemon 2.048 kB
Sending build context to Docker daemon
Step 1 : FROM busybox---> 4986bf8c1536
Step 2 : RUN exit 13---> Running in e26670ec7a0a
INFO[0000] The command [/bin/sh -c exit 13] returned a non-zero code: 13$ echo $?
1
Dockerﬁle リファレンスのセクションも別途ご覧ください。
- 65 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

例
PATH で 構築$ docker build .
Uploading context 10240 bytes
Step 1 : FROM busybox
Pulling repository busybox---> e9aa60c60128MB/2.284 MB (100%) endpoint: https://cdn-registry-1.docker.io/v1/
Step 2 : RUN ls -lh /---> Running in 9c9e81692ae9
total 24drwxr-xr-x
2 rootroot
4.0K Mar 12 2013 bin
drwxr-xr-x
5 rootroot
4.0K Oct 19 00:19 dev
drwxr-xr-x
2 rootroot
4.0K Oct 19 00:19 etc
drwxr-xr-x
2 rootroot
4.0K Nov 15 23:34 lib
lrwxrwxrwx
1 rootroot
3 Mar 12 2013 lib64 -> lib
dr-xr-xr-x 116 rootroot
0 Nov 15 23:34 proc
lrwxrwxrwx
1 rootroot
3 Mar 12 2013 sbin -> bin
dr-xr-xr-x 13 rootroot
0 Nov 15 23:34 sys
drwxr-xr-x
2 rootroot
4.0K Mar 12 2013 tmp
drwxr-xr-x
2 rootroot
4.0K Nov 15 23:34 usr---> b35f4035db3f
Step 3 : CMD echo Hello world---> Running in 02071fceb21b---> f52f38b7823e
Successfully built f52f38b7823e
Removing intermediate container 9c9e81692ae9
Removing intermediate container 02071fceb21b
この例では PATH に . を指定しています。このローカルディレクトリにある全てのファイルは tar 化され、Docker
デーモンに送られます。PATH が⽰すのは、Docker デーモンが構築時に使う「コンテクスト」（内容物）としてのファイルを⾒つけるための場所です。デーモンはリモート上のマシンでも操作できるのを思い出してください。これは、クライアント側（docker build コマンドを実⾏した場所 ）では Dockerﬁle は何らパース（解析）されません。
つまり、PATH に含まれる全てのファイルが送信されるだけでなく、Dockerﬁle の ADD 命令で追加した場所も含みます。
ローカルのマシンから Docker デーモンにコンテクストを送信時、docker クライアントには「Sending build
context」（構築コンテクストの送信中）とメッセージが表⽰されます。
構築が完了しても中間コンテナをそのまま維持したい場合は、 --rm=false の指定が必要です。こちらを指定す
ると構築キャッシュに何もしません。
URL で構築$ docker build github.com/creack/docker-firefox
これは GitHub リポジトリのクローンを作成し、クローンしたリポジトリをコンテクストとして利⽤します。リ
ポジトリのルートにある Dockerﬁle を、構築時の Dockerﬁle として使います。git://や git@など、その他の Git
リポジトリのスキーマを使っても指定可能です。

- で構 築- 66 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド$ docker build - < Dockerfile
これはコンテクストを使わずに STDIN から Dockerﬁle を読み込みます。コンテクストが無く、内容物の無いロ
ーカルのディレクトリが Docker デーモンに送信されます。コンテクストがありませんので、Dockerﬁle の ADD は
リモートの URL の参照に使えます。
$ docker build - < context.tar.gz
これは STDIN から圧縮されたコンテクストを読み込み、イメージを構築しています。サポートしているフォーマ
ットは、bzip2、gzip、xz です。

.dockerignore の使い 方$ docker build .
Uploading context 18.829 MB
Uploading context
Step 1 : FROM busybox---> 769b9341d937
Step 2 : CMD echo Hello world---> Using cache---> 99cc1ad10469
Successfully built 99cc1ad10469$ echo ".git" > .dockerignore$ docker build .
Uploading context 6.76 MB
Uploading context
Step 1 : FROM busybox---> 769b9341d937
Step 2 : CMD echo Hello world---> Using cache---> 99cc1ad10469
Successfully built 99cc1ad10469
この例で表⽰しているのは、.dockerignore ファイルを使い、コンテクストから.git ディレクトリを除外しています。この効果により、アップロードされるコンテクストの容量を⼩さくしています。構築時のリファレンス.dockerignore ファイルの作成 に、より詳しい情報があります。

イ メージ のタ グ（-t）$ docker build -t vieux/apache:2.0 .
これまでの例のように構築していますが、作成されるイメージに対してタグ付けをしています。リポジトリ名はvieux/apache になり、タグは 2.0 になります。

Dockerﬁle の 指定（ -f）$ docker build -f Dockerfile.debug .
構築時の命令に Dockerfile ではなく、Dockerfile.debug を使うように呼び出しています。
$ docker build -f dockerfiles/Dockerfile.debug -t myapp_debug .
$ docker build -f dockerfiles/Dockerfile.prod -t myapp_prod .
- 67 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

上記のコマンドは、どちらも現在のディレクトリにあるコンテント（ . で場所を指定 ）を使い構築するものです。デバッグ⽤とプロダクション⽤で別々の Dockerfile を使いますが、コンテクストは同じです。
$ cd /home/me/myapp/some/dir/really/deep$ docker build -f /home/me/myapp/dockerfiles/debug /home/me/myapp$ docker build -f ../../../../dockerfiles/debug /home/me/myapp
２つの docker build コマンドは同じことをしています。いずれの Dockerfile にも debug ファイルが含まれており、構築コンテクストのルートとして /home/me/myapp を使います。なお注意点として、debug は構築コンテクス
トのサブディレクトリにあるもので、先ほどのコマンドライン上では指定の必要がありませんでした。
docker build が no such file or directory エラーを返すのは、アップロードすべきコンテクスト
としてのファイルやディレクトリが存在しない時です。これは、コンテクストが存在しないか、指定したファイルがホストシステム上に存在していない可能性があります。コンテクストはカレント・ディレクトリ（と、その⼦ディレクトリ）のみに安全上の理由で制限されています。これはリモートの Docker ホスト上でも、繰り返し構築できるようにするためです。これが ADD ../file が動作しない理由でもあります。

親 cgroup のオプ ション（ --cgroup-parent）
docker build に --cgroup-parent オプションを付けて構築したら、構築時の docker run 実⾏時に適切なフラグを付けて実⾏します。

コ ンテナ の ulimit を セット （--ulimit）
docker build に --ulimit オプションを付けて実⾏したら、コンテナの構築ステップを開始する時、都度 --ulimit
フラグの値を設定 します。

構 築時の 変数を 指定 （--build-arg）
Dockerﬁle の ENV 命令を使い、変数を定義できます。これらの値は構築時に⼀定のものです。しかし、⼀定の値が必要でない場合もあります。ユーザがイメージを構築するホストによっては、依存性に対する変数が必要になるかもしれません。
良い例が http_proxy や中間ファイルの取得に使うソースのバージョン指定です。ARG 命令は Dockerﬁle の作者が定義する値であり、ユーザが構築時に --build-arg フラグを指定できます。
$ docker build --build-arg HTTP_PROXY=http://10.20.30.2:1234 .
このフラグを使うことで、構築時の変数が Dockerﬁle の RUN 命令で通常の環境変数のように扱えます。それだけでなく、これらの値は ENV のように使えますが、中間ファイルや最終的なイメージでは⼀定ではありません。
ARG と ENV 命令の詳細については、Dockerﬁle リファレンス をご覧ください。

- 68 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

コ ミ ッ トcommit使い方: docker commit [オプション] コンテナ [リポジトリ[:タグ]]
コンテナの変更を元に新しいイメージを作成-a, --author=""-c, --change=[]--help-m, --message=""-p, --pause=true

作者 (例 "John Hannibal Smith <hannibal@a-team.com>")
イメージをコミット時の Dockerfile 命令を追加指定
使い方を表示コミット・メッセージ
コンテナをコミット時に一時停止（pause)する

コンテナのファイル変更や設定を、新しいイメージに収容（commit；コミット）するために便利です。これにより、インタラクティブなシェル上でコンテナをデバッグ⽤に動かしたり、作業中のデータセットを他のサーバに持っていくため出⼒したりできます。通常は、イメージを管理するためには、⽂書化されメンテナンスのしやすいDockerﬁle を使のが望ましい⽅法です。
コンテナ内でマウントされているボリュームに含まれるデータは、コミット作業に含まれません。
デフォルトでは、コンテナをコミットする時、その過程のいてイメージをコミットする間は⼀時的に停⽌します。
これはコミットする糧において、データ破損が発⽣する可能性を減らします。この動作を理解しているのであれば、--pause オプションを使って無効化もできます。
--cache オプションは Dockerﬁle の命令でイメージが作られる時のみ適⽤されます。対応している Dockerﬁle 命
令は、CMD、ENTRYPOINT、ENV、EXPOSE、LABEL、ONBUILD、USER、VOLUME、WORKDIR です。

コ ンテナ のコミ ット$ docker ps
ID
IMAGE
COMMAND
CREATED
PORTS
c3f279d17e0a
ubuntu:12.04/bin/bash
7 days ago
197387f1b436
ubuntu:12.04/bin/bash
7 days ago$ docker commit c3f279d17e0a svendowideit/testimage:version3
f5283438590d$ docker images
REPOSITORY
TAG
ID
svendowideit/testimage
version3
f5283438590d

STATUSUp 25 hours
Up 25 hours

CREATED
16 seconds ago

SIZE
335.7 MB

新 しい設 定でコ ンテ ナをコ ミット$ docker ps
ID
IMAGE
COMMAND
CREATEDSTATUS
PORTS
c3f279d17e0a
ubuntu:12.04/bin/bash
7 days ago
Up 25 hours
197387f1b436
ubuntu:12.04/bin/bash
7 days ago
Up 25 hours$ docker inspect -f "{{ .Config.Env }}" c3f279d17e0a[HOME=/ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin]$ docker commit --change "ENV DEBUG true" c3f279d17e0a svendowideit/testimage:version3
f5283438590d$ docker inspect -f "{{ .Config.Env }}" f5283438590d[HOME=/ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin DEBUG=true]- 69 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

新 しい CMD と EXPOSE 命令で コンテ ナを コミッ ト$ docker ps
ID
PORTS
c3f279d17e0a
197387f1b436

IMAGE

COMMAND

CREATEDSTATUS

ubuntu:12.04
ubuntu:12.04/bin/bash/bin/bash

7 days ago
7 days ago

Up 25 hours
Up 25 hours$ docker commit --change='CMD ["apachectl", "-DFOREGROUND"]' -c "EXPOSE 80" c3f279d17e0a
svendowideit/testimage:version4
f5283438590d$ docker run -d svendowideit/testimage:version489373736e2e7f00bc149bd783073ac43d0507da250e999f3f1036e0db60817c0$ docker ps
ID
PORTS
89373736e2e780/tcpc3f279d17e0a
197387f1b436

IMAGE

COMMAND

CREATEDSTATUS

testimage:version4 "apachectl -DFOREGROU" 3 seconds ago

Up 2 seconds

ubuntu:12.04
ubuntu:12.04

Up 25 hours
Up 25 hours/bin/bash/bin/bash- 70 -

7 days ago
7 days ago

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

エクスポート

export使い方: docker export [オプション] コンテナ
コンテナのファイルシステム内容を tar アーカイブとして出力--help-o, --output=""

使い方の表示STDOUT（標準出力）ではなくファイルに書き出し

docker export コマンドは、コンテナに関連づけられているボリュームに含まれる内容を出⼒しません。もしボリュームがコンテナ内にある既存ディレクトリの上位にマウントされている場合は、docker export は配下にあるディレクトリを出⼒しますが、ボリュームの内容は含みません。
詳細はユーザ・ガイドの「データ・ボリュームのバックアップ、移⾏、レストア にある、ボリューム上のデー
タの出⼒について」のセクションをご覧ください。

例$ docker export red_panda > latest.tar
または$ docker export --output="latest.tar" red_panda- 71 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

ヒ ス ト リ

history
使い方: docker history [オプション] イメージ
イメージの履歴を表示-H, --human=true--help--no-trunc=false-q, --quiet=false

サイズと日付を人が読みやすい形式で表示
使い方の表示トランケート（truncate）を出力しない
整数値の ID のみ表示

docker:latest イメージをどのように構築したかを確認します。
$ docker history docker
IMAGE
CREATEDCOMMENT
3e23a5875458
8 days ago
8578938dd170
8 days ago
be51b77efb42
8 days ago
4b137612be55
6 weeks ago
750d58736b4b
6 weeks ago
511136ea3c5a
9 months ago
Imported from -CREATED BY

SIZE/bin/sh -c #(nop) ENV LC_ALL=C.UTF-8
0B/bin/sh -c dpkg-reconfigure locales &&loc 1.245 MB/bin/sh -c apt-get update && apt-get install
338.3 MB/bin/sh -c #(nop) ADD jessie.tar.xz in /121 MB/bin/sh -c #(nop) MAINTAINER Tianon Gravi <ad 0 B
0B

docker:scm イメージが何のコンテナ・ベース・イメージから作られたかを確認します。
$ docker history docker:scm
IMAGE
CREATEDCOMMENT2ac9d1098bf1
3 months ago
Added Apache to Fedora base image
88b42ffd1f7c
5 months ago
c69cab00d6ef
5 months ago
511136ea3c5a
19 months ago

CREATED BY

SIZE/bin/bash

241.4 MB/bin/sh -c #(nop) ADD file:1fd8d7f9f6557cafc7 373.7 MB/bin/sh -c #(nop) MAINTAINER Lokesh Mandvekar 0 B
0B- 72 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

イメージーズimages使い方: docker images [オプション] [リポジトリ[:タグ]]
イメージを一覧表示します。
-a, --all=false--digests=false-f, --filter=[]--help--no-trunc=false-q, --quiet=false

全てのイメージを表示（デフォルトは中間コンテナを非表示）
digest 値を表示
指定した状況に応じて出力を整形
使い方の表示トランケート（truncate）を出力しない
整数値の ID のみ表示

標準の docker image は全てのトップ・レベルのイメージと、リポジトリ・タグ・容量を表⽰します。
Docker イメージは中間レイヤ（intermediate layer）を持っています。これは再利⽤性を⾼め、ディスク容量を減らし、docker build は各ステップをキャッシュするので速度を向上します。デフォルトでは、これらの中間レイ
ヤは表⽰されません。
SIZE（容量）は、イメージと全ての親イメージの累積した領域です。また、docker save でイメージを作成していた場合、Tar ファイルの内容に含まれるディスク容量です。
イメージ⼀覧では、複数のリポジトリ名やタグが表⽰されます。イメージ（IMAGE ID が⼀致するもの ）ごとの SIZE
が複数表⽰されますが、実際に対象としている容量は１つだけです。

直 近で作 成した イメ ージか ら一覧 表示$ docker images
REPOSITORY<none>
committ<none>
docker<none>
postgrespostgrespostgrespostgres

TAG<none>
latest<none>
latest<none>
99.3
9.3.5
latestIMAGE ID
77af4d6b9913
b6fa739cedf578a85c484f71
30557a29d5ab
5ed6274db6ce
746b819f315e
746b819f315e
746b819f315e
746b819f315e

CREATED
19 hours ago
19 hours ago
19 hours ago
20 hours ago
24 hours ago
4 days ago
4 days ago
4 days ago
4 days ago

SIZE
1.089 GB1.089 GB1.089 GB1.089 GB1.089 GB
213.4 MB213.4 MB213.4 MB213.4 MBイ メージ 名と タグで 一覧表 示
docker images コマンドは、オプションで [リポジトリ[:タグ]] を指定できます。これはイメージ⼀覧から条件が⼀致するものだけ表⽰します。リポジトリはタグを指定しなくても使えますので、docker images で対象となる
リポジトリの全イメージのみ表⽰します。
例えば、「java」リポジトリにあるイメージを表⽰するには、次のコマンドを実⾏します。
$ docker images java
REPOSITORY
TAG
java
8
java
7
java
latestIMAGE ID
308e519aac60493d82594c15
2711b1d6f3aa

CREATED
6 days ago
3 months ago
5 months ago

SIZE
824.5 MB656.3 MB603.9 MB[リポジトリ[:タグ]] 値は「完全⼀致」の必要があります。つまり、docker images jav は java イメージに⼀致しません。
- 73 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

リポジトリとタグの両⽅が指定された場合は、リポジトリとタグが⼀致するイメージのみ表⽰します。ローカルにある「java」リポジトリで、タグが「8」のイメージを表⽰するには、次のように実⾏します。
$ docker images java:8
REPOSITORY
TAG
java
8

IMAGE ID
308e519aac60

CREATED
6 days ago

SIZE
824.5 MB

もし⼀致する [リポジトリ[:タグ]] が無ければ、何も表⽰しません。
$ docker images java:0
REPOSITORYTAG

IMAGE ID

CREATED

SIZE

長いイメージ ID で 全てを 表示$ docker images --no-trunc
REPOSITORYTAG
IMAGE ID
CREATED
SIZE<none><none>
sha256:77af4d6b9913e693e8d0b4b294fa62ade6054e6b2f1ffb617ac955dd63fb0182
committest
latestsha256:b6fa739cedf5ea12a620a439402b6004d057da800f91c7524b5086a5e4749c9f<none><none>
sha256:78a85c484f71509adeaace20e72e941f6bdd2b25b4c75da8693efd9f61a37921
dockerlatestsha256:30557a29d5abc51e5f1d5b472e79b7e296f595abcf19fe6b9199dbbc809c6ff4<none><none>
sha256:0124422dd9f9cf7ef15c0617cda3931ee68346455441d66ab8bdc5b05e9fdce5<none><none>
sha256:18ad6fad340262ac2a636efd98a6d1f0ea775ae3d45240d3418466495a19a81b<none><none>
sha256:f9f1e26352f0a3ba6a0ff68167559f64f3e21ff7ada60366e2d44a04befd1d3a
tryoutlatestsha256:2629d1fa0b81b222fca63371ca16cbf6a0772d07759ff80e8d1369b926940074<none><none>
sha256:5ed6274db6ceb2397844896966ea239290555e74ef307030ebb01ff91b1914df

19 hours ago

1.089 GB19 hours ago

1.089 GB19 hours ago

1.089 GB20 hours ago

1.089 GB20 hours ago

1.089 GB

22 hours ago

1.082 GB23 hours ago

1.089 GB23 hours ago

131.5 MB24 hours ago

1.089 GB

イメージの digest 値を 表示
v2 以降の形式を使うイメージには、digest と呼ばれる識別⼦が割り振られます。イメージ⽣成後に変更が加えられなければ、digest 値は変更されていないと考えられます。全ての digest 値を表⽰するには、 --digests フラグを使います。
$ docker images --digests
REPOSITORYTAGDIGEST
IMAGE ID
CREATED
SIZE
localhost:5000/test/busybox<none>
sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf
ago
2.43 MB

4986bf8c1536

9 weeks

2.0 レジストリに対して送信（push）や取得（pull ）する場合は、push と pull コマンドの出⼒にイメージの digest
値も含まれます。digest 値を使っても pull できます。digest 値が使えるのは create、run、rmi の各コマンドと、Dockerﬁle のイメージを参照する FROM でも同様です。

- 74 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

フィ ルタリ ング
フィルタリング・フラグ（ -f と --filter）の形式は「key=value」です。複数のフィルタを使う時は、複数のフラグを使います（例： --filter "foo=bar" --filter "bif=baz" ）。
現在サポートされているフィルタ： ダングリング（宙ぶらりんな状態）なイメージ （ブール値： true か false ） ラベル（ label=<key> か lavel=<key>=<value> ）タグ付けさ れてい ない イメージ（ dangling）$ docker images --filter "dangling=true"
REPOSITORY<none><none><none><none><none><none>

TAG<none><none><none><none><none><none>

IMAGE ID
8abc22fbb042
48e5f45168b9
bf747efa0e2f
980fe10e5736
dea752e4e117
511136ea3c5a

CREATED
4 weeks ago
4 weeks ago
4 weeks ago
12 weeks ago
12 weeks ago
8 months ago

SIZE
0B
2.489 MB
0B
101.4 MB101.4 MB
0B

これはタグ付けされておらず、イメージ・ツリーから離れた（中間レイヤではない）イメージを表⽰します。これらのタグが無いイメージは、イメージを使って新しく構築しようとしてもリポジトリ:タグの形式が利⽤できな
いため、その場合はイメージ ID を使います。コンテナが利⽤中であれば、イメージを削除しようとしても警告が表⽰されます。バッチ処理でクリーンアップする時に、このフラグが使えます。
docker rmi に対応するには：$ docker rmi $(docker images -f "dangling=true" -q)
8abc22fbb042
48e5f45168b9
bf747efa0e2f
980fe10e5736
dea752e4e117
511136ea3c5a

タグ付けされていないイメージでも、何らかのコンテナが使⽤中であれば Docker は警告を表⽰します。

ラベル付け され たイメ ージ
label フィルタは、label そのものが⼀致するイメージか、ラベルの値に⼀致する場合に表⽰します。
次のフィルタは com.example.version に⼀致するラベルだけでなく、その値にも適⽤されます。
$ docker images --filter "label=com.example.version"
REPOSITORY
match-me-1
match-me-2

TAG
latestlatestIMAGE IDeeae25ada2aa
eeae25ada2aa- 75 -

CREATED
About a minute ago
About a minute ago

SIZE
188.3 MB188.3 MB

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

次のフィルタは com.example.version ラベルと 1.0 値に⼀致するイメージを表⽰します。
$ docker images --filter "label=com.example.version=1.0"
REPOSITORYTAG
IMAGE ID
match-melatesteeae25ada2aa

CREATED
About a minute ago

SIZE
188.3 MB

次の例は、0.1 値を持つものをフィルタしますが、⼀致するものが無かったため、何も表⽰されません。
$ docker images --filter "label=com.example.version=0.1"
REPOSITORYTAG
IMAGE ID

- 76 -

CREATED

SIZE

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

インポート

import使い方: docker import ファイル|URL|- [リポジトリ[:タグ]]
空のファイルシステム・イメージを作成し、tar ボールの内容を読み込む（import）
tar ボールの形式は (.tar, .tar.gz, .tgz, .bzip, .tar.xz, .txz)
オプションで、取り込み後にタグ付け-c, --change=[]--help-m, --message=

イメージ読み込み時に Dockerfile の命令を追加変更
使い方を表示イメージを取り込み時、コミット用のメッセージを設定

URL か - （ダッシュ）の指定、あるいは STDIN（標準⼊⼒）から直接データを取り込みます。URL はアーカイブ（ .tar、.tar.gz、.tgz、.bzip、.tar.xz、txz）に含まれる圧縮ファイルシステムや、Docker ホスト上の個々のファイルを指定します。アーカイブを指定したら、Docker はコンテナの / （ルート）以下の相対パスとして展開します。
個々のファイルを指定する場合、ホスト上のフルパスを指定する必要があります。リモートの場所から import す
る場合、URI の形式は、http://か https://プロトコルで始まる必要があります。
--change オプションが適⽤されるのは、Dockerfile 命令でイメージの作成時です。サポートされているDockerfile の命令は、CMD ENTRYPOINT ENV EXPOSE ONBUID USER VOLUME WORKDIR です。

例
リモートか ら取 り込む
新しいタグ付けされていないイメージを作成します。
$ docker import http://example.com/exampleimage.tgz
ローカル・ ファイルを 取り込 む
STDIN のパイプ経由で Docker に取り込みます。
$ cat exampleimage.tgz | docker import - exampleimagelocal:new
コミット・メッセージを付けて取り込みます。
$ cat exampleimage.tgz | docker import --message "New image imported from tarball" exampleimagelocal:new
ローカルのアーカイブから取り込みます。
$ docker import /path/to/exampleimage.tgz
ローカルの ディレ クト リを取 り込 む

$ sudo tar -c . | docker import - exampleimagedir
新しい設定 でロ ーカル のディ レク トリ を取り込む$ sudo tar -c . | docker import --change "ENV DEBUG true" - exampleimagedir
この例では sudo を使っているのに気を付けてください。これは、tar アーカイブを処理する時にファイル（特に- 77 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンドroot）の所有権を保持するためです。root でなければ（あるいは sudo を使わなければ）、tar の利⽤時に権限を得られない可能性があります。

- 78 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

ロ ー ド

load
使い方: docker load [オプション]
tar アーカイブまたは STDIN （標準入力）からイメージを読み込む--help
使い方の表示-i, --input=""
STDIN ではなく、tar アーカイブ・ファイルから読み込む。tar は gzip、bzip、 xz で圧縮されている場合がある-q, --quiet
読み込み時に出力を抑制。オプションを指定しなければ、進捗バーを表示
ファイルか標準⼊⼒のストリームから tar 化されたリポジトリを読み込み（load）ます。イメージとタグを復元します。
$ docker images
REPOSITORY
TAG$ docker load < busybox.tar.gz$ docker images
REPOSITORY
TAG
busyboxlatest$ docker load --input fedora.tar$ docker images
REPOSITORY
TAG
busyboxlatestfedorarawhidefedora20
fedoraheisenbug
fedoralatestIMAGE ID

CREATEDSIZE

IMAGE ID
769b9341d937

CREATED
7 weeks ago

SIZE
2.489 MB

IMAGE ID
769b9341d937
0d20aec6529d
58394af37342
58394af37342
58394af37342

CREATED
7 weeks ago
7 weeks ago
7 weeks ago
7 weeks ago
7 weeks ago

SIZE
2.489 MB387 MB
385.5 MB385.5 MB385.5 MB- 79 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

rmi
使い方: docker rmi*1 [オプション] イメージ [イメージ...]１つまたは複数のイメージを削除-f, --force--help--no-prune

イメージの共生削除
使い方の表示タグが無い親イメージを削除しない

ショート ID かロング ID、タグ、digest を使ってイメージを削除できます。イメージがタグによって参照されている場合、イメージを削除する前にそれらの削除が必要です。Digest の参照はイメージのタグを削除する時、⾃動的に削除されます。
$ docker images
REPOSITORY
test1
MB)
test
MB)
test2
MB)

TAG
latestIMAGE ID
fd484f19954f

CREATED
23 seconds ago

SIZE
7 B (virtual 4.964

latestfd484f19954f

23 seconds ago

7 B (virtual 4.964

latestfd484f19954f

23 seconds ago

7 B (virtual 4.964$ docker rmi fd484f19954f
Error: Conflict, cannot delete image fd484f19954f because it is tagged in multiple repositories, use -f toforce
2013/12/11 05:47:16 Error: failed to remove one or more images$ docker rmi test1
Untagged: test1:latest$ docker rmi test2
Untagged: test2:latest$ docker images
REPOSITORYTAG
IMAGE ID
CREATEDtest
latestfd484f19954f
23 seconds ago
MB)$ docker rmi test
Untagged: test:latest
Deleted: fd484f19954f4920da7ff372b5067f5b7ddb2fd3830cecd17b96ea9e286ba5b8

SIZE
7 B (virtual 4.964-f フラグでイメージのショート ID かロング ID を指定したら、このコマンド対象の ID に⼀致するイメージは全てのタグを外し、削除されます。
$ docker images
REPOSITORY
test1
MB)
test
MB)
test2

TAG
latestIMAGE ID
fd484f19954f

CREATED
23 seconds ago

SIZE
7 B (virtual 4.964

latestfd484f19954f

23 seconds ago

7 B (virtual 4.964

latestfd484f19954f

23 seconds ago

7 B (virtual 4.964*1 訳 者 注 ： rmi と は remove image、 つ ま り イ メ ー ジ 削 除 コ マ ン ド で す 。

- 80 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンドMB)$ docker rmi -f fd484f19954f
Untagged: test1:latest
Untagged: test:latest
Untagged: test2:latest
Deleted: fd484f19954f4920da7ff372b5067f5b7ddb2fd3830cecd17b96ea9e286ba5b8
取得したイメージがタグ付けされていなくても、digest を確認できます。
$ docker images --digests
REPOSITORYTAGDIGEST
IMAGE ID
CREATED
SIZE
localhost:5000/test/busybox<none>
sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf
2.43 MB

4986bf8c1536

9 weeks ago

digest を使ってイメージを削除するには、次のようにします。
$ docker rmi
localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf
Untagged:
localhost:5000/test/busybox@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf
Deleted: 4986bf8c15363d1c5d15512d5266f8777bfba4974ac56e3270e7760f6f0a8125
Deleted: ea13149945cb6b1e746bf28032f02e9b5a793523481a0a18645fc77ad53c4ea2
Deleted: df7546f9f060a2268024c8a230d8639878585defcc1bc6f79d2728a13957871b- 81 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

セ ー ブ

save
使い方: docker save [オプション] イメージ [イメージ...]１つまたは複数のイメージを tar アーカイブに保存（デフォルトは STDOUT にストリーム）--help-o, --output=""

使い方の表示STDOUT（標準出力）の代わりに、ファイルへ書き込む

tar 化されたリポジトリを、標準出⼒のストリームに出⼒します。ここには全ての親レイヤが含まれ、全てのタグとバージョンだけでなく、リポジトリ名:タグ が指定されれば、それぞれの引数に応じて出⼒します。
これはバックアップの作成のために利⽤でき、再度使うには docker load を指定します。
$ docker save busybox > busybox.tar$ ls -sh busybox.tar
2.7M busybox.tar$ docker save --output busybox.tar busybox$ ls -sh busybox.tar
2.7M busybox.tar$ docker save -o fedora-all.tar fedora$ docker save -o fedora-latest.tar fedora:latest
イメージのリポジトリで、適切なタグを指定する場合にも便利でしょう。
$ docker save -o ubuntu.tar ubuntu:lucid ubuntu:saucy- 82 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.4 イメージ⽤コマンド

タ グ

tag
使い方: docker tag [オプション] イメージ[:タグ] [レジストリのホスト/][ユーザ名/]名前[:タグ]
リポジトリ内のイメージにタグ付け--help

使い方の表示

⾃分のイメージを名前やタグを使ってグループ化し、 リポジトリを通してイメージを共有するためアップロー
ドできます。

- 83 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

A2.5 コンテナ用コマンド
ア タ ッ チattach使い方: docker attach [オプション] コンテナ
実行中のコンテナにアタッチする--detach-keys="<sequence>"--help--no-stdin--sig-proxy=true

エスケープ・キー・シーケンスを設定
使い方の表示STDIN（標準入力）にアタッチしない
受信したシグナルをプロセスに全てプロキシする

docker attach コマンドは、コンテナ ID や名前を使って実⾏中のコンテナにアタッチ（attach；装着/取り付けの意味）します。処理中の出⼒を表⽰するだけでなく、インタラクティブ（双⽅向）の管理もできます。同じコンテナ化されたプロセスに対して、画⾯を共有する形式として擬似的に複数回のアタッチが可能ですし、デタッチ（detach；分離の意味）したプロセスも迅速に表⽰できます。
コンテナを停⽌するには、CTRL-c を使います。このキー・シーケンスはコンテナに対して SIGKILL を送信します。
もしも --sig-proxy が true であれば（デフォルト）、CTRL-c はコンテナに対して SIGINT を送信します。CTRL-p
CTRL-q キー・シーケンスを使えば、実⾏中のコンテナからデタッチして離れられます。
コンテナ内で PID 1 として実⾏しているプロセスは、Linux では特別な扱いがされます。通常の操作では、あらゆるシグナルを無視します。そのため、特別にコード化しない限り、プロセスを SIGINT
や SIGTERM では停⽌できません。

tty を有効化したコンテナにアタッチした状態（例： -t を使って起動）では、docker attach コマンドを使った標準⼊⼒のリダイレクトは禁⽌されています。

デ タッチ ・シー ケンス の上書 き
必要であれば、デタッチ⽤の Docker キー・シーケンスの設定を上書きできます。Docker デフォルトのキー・シーケンスが他のアプリケーションと重複している場合に役⽴ちます。デタッチ⽤キー・シーケンスを指定するには、２つの⽅法があります。１つはコンテナごとに設定するか、あるいは全体に対してのプロパティを設定します。
個々のコンテナに対するシーケンスを上書きするには、docker attach コマンドに --detach-keys="<シーケンス>" を指定します。 <シーケンス> の書式は、 [a-Z] までの⽂字を使うか、 ctrl- と次の項⽬を組み合わせます。

 a-z （⼩⽂字のアルファベット⽂字列）
 @ （アット記号）
 [ （左かっこ） \\ （２つのバックスラッシュ） _ （アンダースコア） ^ （キャレット）
例えば、a、ctrl-a、x、ctrl-\\は、いずれも有効なキー・シーケンスです。全てのコンテナに対する異なったキー・シーケンスを設定するには、 設定ファイル のセクションをご覧ください。

- 84 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド例$ docker run -d --name topdemo ubuntu /usr/bin/top -b$ docker attach topdemo
top - 02:05:52 up 3:05, 0 users, load average: 0.01, 0.02, 0.05
Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.1%us, 0.2%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stMem:373572k total, 355560k used,
18012k free,
27872k buffers
Swap: 786428k total,
0k used, 786428k free, 221740k cached
PID USER
1 rootPR NI VIRT RES SHR S %CPU %MEM
TIME+ COMMAND
20 0 17200 1116 912 R
0 0.3 0:00.03 top

top - 02:05:55 up 3:05, 0 users, load average: 0.01, 0.02, 0.05
Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.2%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stMem:373572k total, 355244k used,
18328k free,
27872k buffers
Swap: 786428k total,
0k used, 786428k free, 221776k cached
PID USER
1 rootPR NI VIRT RES SHR S %CPU %MEM
TIME+ COMMAND
20 0 17208 1144 932 R
0 0.3 0:00.03 top

top - 02:05:58 up 3:06, 0 users, load average: 0.01, 0.02, 0.05
Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2%us, 0.3%sy, 0.0%ni, 99.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stMem:373572k total, 355780k used,
17792k free,
27880k buffers
Swap: 786428k total,
0k used, 786428k free, 221776k cached
PID USERPR NI VIRT RES SHR S %CPU %MEM
TIME+ COMMAND
1 root20 0 17208 1144 932 R
0 0.3 0:00.03 top^C$$ echo $?
0$ docker ps -a | grep topdemo
7998ac8581f9
ubuntu:14.04"/usr/bin/top -b" 38 seconds ago
ago
topdemoExited (0) 21 seconds

次の２つめの例は、docker attach コマンドで処理された終了コードが、bash プロセスに戻ってきても使えることが分かります。
$ docker run --name test -d -it debian275c44472aebd77c926d4527885bb09f2f6db21d878c75f0a1c212c03d3bcfab$ docker attach test$$ exit 13
exit$ echo $?
13$ docker ps -a | grep test
275c44472aeb
debian:7"/bin/bash"
26 seconds ago
ago
test

- 85 -

Exited (13) 17 seconds

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

cp
使い方: docker cp [オプション] コンテナ:パス ローカル・パス|docker cp [オプション] ローカル・パス|- コンテナ:パス
コンテナとローカル・ファイルシステム間でファイルとフォルダをコピーする--help

使い方の表示概要の１つめは、コンテナのファイルシステム上のパスにある内容をローカルのパスにコピーするために、
docker cp が役⽴ちます。
概要の２つめは、ローカルパス（あるいは STDIN で - で指定した tar アーカイブを流し込み）に含まれる内容を、ローカルマシン上からコンテナのファイルシステム上のパスにコピーします。
コピーはコンテナが実⾏中でも停⽌中でも可能です。パスとはファイルまたはディレクトリです。docker cp コ
マンドは、全てのコンテナ:パス値をコンテナ内の /（ルート）ディレクトリとみなします。つまり、転送先の冒頭にスラッシュを付けるのはオプションです。つまり、コマンド compassionate_darwin:/tmp/foo/myfile.txt とcompassionate_darwin:tmp/foo/myfile.txt は同⼀です。ローカルパスの値は絶対パスではなく、現在の作業ディレクトリからの相対パスとみなされます。
動作は⼀般的な Unix ユーティリティ cp -a に似ています。可能であればパーミッションと⼀緒に、ディレクト
リも再帰的にコピーします。所有者の権限は、転送終了時にユーザとプライマリ・グループが指定されます。例えば、ファイルをコンテナにコピーすると、UID:GID は root ユーザとして作成されます。ファイルをローカルのマシ
ン上にコピーする時は、docker cp コマンドを実⾏したユーザの UID:GID が作成されます。もしも docker cp で -L
オプションを指定すると、送信元パスのシンボリック・リンクをフォローします。docker cp は送信先パスが存在しなければ、親ディレクトリを作成しません。
パスは / で分離され、１つめの引数は送信元のパス、２つめの引数は送信先のパスとみなされます。次のように動作します。

 送信元のパスでファイルを指定する
送信先のパスが存在しない
送信先のパスにファイルを作成し、ファイルを保存する
送信先のパスが存在せず、最後に / がある場合
エラーが発⽣：送信先ディレクトリが存在しなくてはいけない
送信先のパスが存在し、ファイルである場合
送信元にあるファイルで、送信先のファイル内容を上書きする
送信先のパスが存在し、ディレクトリの場合
送信元のパスにある名前を元に、対象のディレクトリにファイルをコピー 送信元のパスでディレクトリを指定する
送信先のパスが存在しない
送信先のパスにディレクトリを作成し、送信元ディレクトリに含まれる内容をコピーする
送信先のパスが存在し、ファイルである場合
エラーが発⽣：ディレクトリをファイルにコピーできない
送信先のパスが存在し、ディレクトリの場合
送信元のパスが / で終わる場合
送信元ディレクトリを対象のディレクトリにコピー
送信元のパスが / で終わらない場合- 86 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

送信元ディレクトリの内容を対象のディレクトリにコピー
コマンドで使う送信元のパスと送信先のパスは上記のルールに従う必要があります。送信元のパスがローカル上
かつシンボリックリンクの場合は、その対象ではなくシンボリックリンクがコピーされます。
コロン（ : ）はコンテナとパスのデリミタ（区切り⽂字）として使われますが、 : は file:name.txt のように有効なローカルのパスとしても使われます。この曖昧さを解決するには、ローカルパスで : を明確な絶対パス・相対パスの指定に使います。例：`/path/to/file:name.txt` or `./file:name.txt`/proc、/sys、/dev 配下にあるリソースのような特定のシステムファイルはコピーできません。これらはコンテ
ナの中にマウントされます。
送信元のパスに - を使うと、STDIN（標準⼊⼒）を tar アーカイブの内容として流し込みます。このコマンドにより、対象となるコンテナ上にあるファイルシステムの送信先パスに展開します。この場合、送信先パスにはディレクトリを指定する必要があります。 送信先パスに - を使うと、tar アーカイブを STDOUT（標準出⼒）します。
ローカルパスの１番めの引数に - を使うと、tar アーカイブからの内容を STDIN（標準⼊⼒）としてストリーム（流し込み）ます。これにより、対象となるコンテナのファイルシステムにあるパスに展開します。元となるコン
テナのリソースに含まれる内容が、tar アーカイブとして STDOUT（標準出⼒）にストリーム出⼒します。

- 87 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

クリエイト

create新しいコンテナを作成します。
使い方: docker create [オプション] イメージ [コマンド] [引数...]新しいコンテナを作成-a, --attach=[]--add-host=[]--blkio-weight=0--blkio-weight-device=[]

STDIN、STDOUT、STDERR にアタッチするホストから IP アドレスのマッピングをカスタマイズして追加 (host:ip)
ブロック IO ウエイト (相対ウエイト)ブロック IO ウエイト (相対デバイス・ウエイト。
書式： `デバイス名:ウエイト`)--cpu-shares=0
CPU 共有 (相対ウエイト)--cap-add=[]
Linux ケーパビリティの追加--cap-drop=[]Linux ケーパビリティの削除--cgroup-parent=""
コンテナ用のオプション親 cgroup を指定--cidfile=""コンテナ ID をファイルに書き出し--cpu-period=0
CPU CFS (Completely Fair Scheduler) ペイロードの制限--cpu-quota=0
CPU CFS (Completely Fair Scheduler) クォータの制限--cpuset-cpus=""
実行を許可する CPU (0-3, 0,1)--cpuset-mems=""
実行を許可するメモリ必要量 (0-3, 0,1)--device=[]
ホスト・デバイスをコンテナに追加--device-read-bps=[]
デバイスからの読み込みレート (バイト/秒) を制限--device-read-iops=[]
デバイスからの読み込みレート (IO/秒) を制限--device-write-bps=[]
デバイスへの書き込みレート (バイト/秒) を制限(例: --device-write-bps=/dev/sda:1mb)--device-write-iops=[]
デバイスへの書き込みレート (IO/秒) を制限(例: --device-write-iops=/dev/sda:1000)--disable-content-trust=true イメージの認証をスキップ--dns=[]
カスタム DNS サーバの指定--dns-opt=[]
カスタム DNS オプションの指定--dns-search=[]カスタム DNS 検索ドメインの指定-e, --env=[]
環境変数を指定--entrypoint=""
イメージのデフォルト ENTRYPOINT を上書き--env-file=[]ファイルから環境変数を読み込み--expose=[]
ポートまたはポート範囲を露出--group-add=[]
参加するグループを追加-h, --hostname=""コンテナのホスト名--help
使い方の表示-i, --interactive
アタッチしていなくても STDIN を開き続ける--ip=""
コンテナの IPv4 アドレス (例: 172.30.100.104)--ip6=""
コンテナの IPv6 アドレス (例: 2001:db8::33)--ipc=""
使用する IPC 名前空間--isolation=""
コンテナの分離（独立）技術--kernel-memory=""
Kernel メモリ上限-l, --label=[]
コンテナにメタデータを指定 (例: --label=com.example.key=value)--label-file=[]
行ごとにラベルを記述したファイルを読み込み--link=[]他のコンテナへのリンクを追加--log-driver=""
コンテナ用のログ記録ドライバを追加--log-opt=[]
ログドライバのオプションを指定-m, --memory=""
メモリ上限--mac-address=""
コンテナの MAC アドレス (例： 92:d0:c6:0a:29:33)--memory-reservation=""
メモリのソフト上限--memory-swap=""
整数値の指定はメモリにスワップ値を追加。-1 は無制限スワップを有効化--memory-swappiness=""
コンテナ用メモリのスワップ程度を調整。整数値の 0 から 100 で指定- 88 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド--name=""--net="bridge"

コンテナに名前を割り当て: コンテナをネットワークに接続'bridge': docker ブリッジ上でコンテナ用に新しいネットワーク・
スタックを作成'none': コンテナにネットワーク機能を付けない'container:<name|id>': 他のコンテナ用ネットワーク・スタックを再利用'host': コンテナ内でホスト側ネットワーク・スタックを使用'NETWORK': 「docker network create」コマンドでユーザ作成したネットワークを使用--net-alias=[]コンテナにネットワーク内部用のエイリアスを追加--oom-kill-disable
コンテナの OOM Killer を無効化するかどうか指定--oom-score-adj=0
コンテナに対してホスト側の OOM 優先度を設定 ( -1000 ～ 1000 を指定)
-P, --publish-all
全ての露出ポートをランダムならポートに公開-p, --publish=[]コンテナのポートをホスト側に公開--pid=""
使用する PID 名前空間--pids-limit=-1
コンテナの pids 制限を調整 (kernel 4.3 以上は -1 で無制限に設定)--privileged
このコンテナに対して拡張権限を与える--read-only
コンテナのルート・ファイルシステムを読み込み専用としてマウント--restart="no"再起動ポリシー (no, on-failure[:max-retry], always, unless-stopped)--security-opt=[]
セキュリティ・オプション--stop-signal="SIGTERM"
コンテナの停止シグナル--shm-size=[]`/dev/shm` のサイズ。書式は `<数値><単位>`. `数値` は必ず `0` より大きい。単位はオプションで `b` (bytes)、 `k` (kilobytes)、 `m` (megabytes)、 `g` (gigabytes) を指定可能。
単位を指定しなければ、システムは bytes を使う。数値を指定しなければ、システムは `64m` を使う-t, --tty
疑似ターミナル (pseudo-TTY) を割り当て-u, --user=""
ユーザ名または UID--userns=""
コンテナのユーザ名前空間'host': Docker ホストで使うユーザ名前空間'': Docker デーモンのユーザ名前空間を指定するには `--userns-remap`
オプションを使う--ulimit=[]
Ulimit オプション--uts=""
使用する UTS 名前空間
-v, --volume=[ホスト側ソース:]コンテナ側送信先[:<オプション>]
ボリュームを拘束マウント。カンマ区切りで指定`オプション` は [rw|ro], [z|Z], [[r]shared|[r]slave|[r]private],[nocopy]'ホスト側ソース' は絶対パスまたは名前の値--volume-driver=""
コンテナのボリューム・ドライバ--volumes-from=[]
指定したコンテナからボリュームをマウント-w, --workdir=""
コンテナ内の作業用ディレクトリを指定
docker create コマンドは、特定のイメージ上に書き込み可能なコンテナ・レイヤ（層）を作成し、測定のコマ
ンドを実⾏する準備をします。それから、コンテナ ID を STDOUT（標準出⼒）に表⽰します。これは開始したことが無いコンテナに対して docker run -d する時も同様です。それから、docker start <コンテナ ID> コマンドを使って、いつてもコンテナを実⾏できます。
コンテナが必要な時に直ちに実⾏できるよう、事前に設定を済ませて使えるように準備したい場合に役⽴ちます。
新しいコンテナ作成時の初期状態を作成しました。
より詳細に関しては run セクションと Docker run リファレンスをご覧ください。

例$ docker create -t -i fedora bash
6d8af538ec541dd581ebc2a24153a28329acb5268abe5ef868c1f1a261221752$ docker start -a -i 6d8af538ec5- 89 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

bash-4.2#
バージョン 1.4.0 以降では、docker create の段階で（docker run も同様）コンテナのボリュームが初期化されます。例えば、データ・ボリュームコンテナを create したら、他のコンテナからも利⽤可能になります。
$ docker create -v /data --name data ubuntu
240633dfbb98128fa77473d3d9018f6123b99c454b3251427ae190a7d951ad57$ docker run --rm --volumes-from data ubuntu ls -la /data
total 8drwxr-xr-x 2 root root 4096 Dec 5 04:10 .
drwxr-xr-x 48 root root 4096 Dec 5 04:11 ..
同様に、 ホスト側のディレクトリをバインドするボリューム・コンテナを作成したら、次に処理するコンテナ
からも利⽤可能になります。
$ docker create -v /home/docker:/docker --name docker ubuntu
9aa88c08f319cd1e4515c3c46b0de7cc9aa75e878357b1e96f91e2c773029f03$ docker run --rm --volumes-from docker ubuntu ls -la /docker
total 20
drwxr-sr-x 5 1000 staff 180 Dec 5 04:00 .
drwxr-xr-x 48 root root 4096 Dec 5 04:13 ..
-rw-rw-r-- 1 1000 staff 3833 Dec 5 04:01 .ash_history-rw-r--r-- 1 1000 staff 446 Nov 28 11:51 .ashrc-rw-r--r-- 1 1000 staff 25 Dec 5 04:00 .gitconfig
drwxr-sr-x 3 1000 staff 60 Dec 1 03:28 .local-rw-r--r-- 1 1000 staff 920 Nov 28 11:51 .profile
drwx--S--- 2 1000 staff 460 Dec 5 00:51 .ssh
drwxr-xr-x 32 1000 staff 1140 Dec 5 04:01 docker- 90 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

ディフ

diff
使い方: docker diff [オプション] コンテナ
コンテナのファイルシステムに対する変更を調査--help

使い方の表示コンテナのファイルシステム上で、変更したファイルやディレクトリの⼀覧を表⽰します。

 A - 追加（Add）
 D - 削除（Delete）
 C - 変更（Change）
実⾏例：$ docker diff 7bb0e258aefe
C /devA /dev/kmsg
C /etcA /etc/mtab
A /go
A /go/src
A /go/src/github.com
A /go/src/github.com/docker
A /go/src/github.com/docker/docker
A /go/src/github.com/docker/docker/.git....

- 91 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

イ ベ ン ツevents使い方: docker events [オプション]
サーバからリアルタイムのイベントを取得-f, --filter=[]--help--since=""--until=""

指定した状態に基づき出力をフィルタ
使い方の表示タイムスタンプ以降に発生した全てのイベントを表示
タイムスタンプまで発生したイベントを表示

Docker コンテナは以下のイベントを報告します。
attach, commit, copy, create, destroy, die, exec_create, exec_start, export, kill, oom, pause, rename,resize, restart, start, stop, top, unpause, update
Docker イメージは以下のイベントを報告します。
delete, import, pull, push, tag, untag
Docker ボリュームは以下のイベントを報告します。
create, mount, unmount, destroy
Docker ネットワークは以下のイベントを報告します。
create, connect, disconnect, destroy--since と --until パラメータでは、Unix タイムスタンプ、RFC 3339 の dates、Go ⾔語の期間⽂字列（例：10m、1h30m）をクライアントのマシン時刻から相対的に扱えます。 --since オプションを指定しなければ、コマンドは
新しく追加されたか現在のイベントのみ表⽰します。

フィ ルタリ ング
フィルタリング・フラグ（ -f と --filter）は key=value の形式です。複数のフィルタを使いたい場合は、複数回フラグを指定します（例： --filter "foo=bar" --filter "bif=baz" ）。
同じフィルタを複数回指定したら、「OR」（または）という条件として処理します。例えば --filter
container=588a23dac085 --filter container=a8f7720b8c22 は、コンテナ 588a23dac085 かコンテナ a8f7720b8c22のイベントを表⽰します。
複 数 の フ ィ ル タ を 使 え ば 、「 AND」（ お よ び ） と い う 条 件 と し て 処 理 し ま す 。 例 え ば --filter
container=588a23dac085 --filter event=start は、コンテナ 588a23dac085 のイベントタイプが start のイベント
のみ表⽰します。
現時点でサポートされているフィルタは次の通りです。

 コンテナ（ container=<名前か ID> ） イベント（ event=<イベント・タイプ> ） イメージ（ image=<タグか ID> ） ラベル（ label=<key> または label=<key>=<value> ）- 92 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド例
この例には２つのシェルが必要です。
シェル１：イベント⼀覧を表⽰：$ docker events
シェル２：コンテナを開始して停⽌$ docker start 4386fb97867d$ docker stop 4386fb97867d$ docker stop 7805c1d35632
シェル１：（再度実⾏したら、イベントを表⽰）
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) start
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) die
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) stop
2014-05-10T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) die
2014-05-10T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) stop
時間を指定したら、過去のイベントを表⽰：$ docker events --since 1378216169
2014-03-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) die
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) stop
2014-05-10T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) die
2014-03-10T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) stop
$ docker events --since '2013-09-03'
2014-09-03T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) start
2014-09-03T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) die
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) stop
2014-05-10T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) die
2014-09-03T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) stop
$ docker events --since '2013-09-03T15:49:29'
2014-09-03T15:49:29.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) die
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) stop
2014-05-10T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) die
2014-09-03T15:49:29.999999999Z07:00 7805c1d35632: (from redis:2.8) stop
この例では、過去３分間に発⽣した全イベントを表⽰しています。クライアント側のマシン上からの相対的な時間です。
$ docker events --since '3m'
2015-05-12T11:51:30.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) die
2015-05-12T15:52:12.999999999Z07:00 4 4386fb97867d: (from ubuntu-1:14.04) stop
2015-05-12T15:53:45.999999999Z07:00 7805c1d35632: (from redis:2.8) die
2015-05-12T15:54:03.999999999Z07:00 7805c1d35632: (from redis:2.8) stop

- 93 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

イベントをフィルタします：$ docker events --filter 'event=stop'
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) stop
2014-09-03T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) stop
$ docker events --filter 'image=ubuntu-1:14.04'
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) start
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) die
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) stop
$ docker events --filter 'container=7805c1d35632'
2014-05-10T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) die
2014-09-03T15:49:29.999999999Z07:00 7805c1d35632: (from redis:2.8) stop
$ docker events --filter 'container=7805c1d35632' --filter 'container=4386fb97867d'
2014-09-03T15:49:29.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) die
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) stop
2014-05-10T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) die
2014-09-03T15:49:29.999999999Z07:00 7805c1d35632: (from redis:2.8) stop
$ docker events --filter 'container=7805c1d35632' --filter 'event=stop'
2014-09-03T15:49:29.999999999Z07:00 7805c1d35632: (from redis:2.8) stop
$ docker events --filter 'container=container_1' --filter 'container=container_2'
2014-09-03T15:49:29.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) die
2014-05-10T17:42:14.999999999Z07:00 4386fb97867d: (from ubuntu-1:14.04) stop
2014-05-10T17:42:14.999999999Z07:00 7805c1d35632: (from redis:2.8) die
2014-09-03T15:49:29.999999999Z07:00 7805c1d35632: (from redis:2.8) stop

- 94 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

エクゼク

exec
使い方: docker exec [オプション] コンテナ コマンド [引数...]
実行中のコンテナでコマンドを実行-d, --detach=false--detach-keys--help=false-i, --interactive=false--privileged=false-t, --tty=false-u, --user=

デタッチド・モード: コマンドをバックグラウンドで実行
デタッチド・コンテナに特定のエスケープ・キー・シーケンスを設定
使い方の表示
アタッチしていなくても STDIN をオープンにし続ける
コマンドに拡張 Linux ケーパビリティの追加
疑似ターミナル (pseudo-TTY) の割り当て
ユーザ名か UID (書式: <名前|uid>[:<グループ|gid>])docker exec コマンドは実⾏中のコンテナ内で、新しいコマンドを実⾏します。
docker exec コマンドが使えるのは、コンテナのプラマリ・プロセス（ PID 1 ）が実⾏中の時のみです。そして、コンテナが再起動されても、こちらは再起動されません。
コンテナを⼀時停⽌すると、docker exec コマンドは停⽌し、エラーになります。
$ docker pause test
test
$ docker ps
CONTAINER ID
IMAGE
COMMAND
CREATEDSTATUS
PORTS
NAMES
1ae3b36715d2
ubuntu:latest"bash"
17 seconds ago
Up 16 seconds (Paused)test$ docker exec test ls
FATA[0000] Error response from daemon: Container test is paused, unpause the container before exec
$ echo $?
1

例$ docker run --name ubuntu_bash --rm -i -t ubuntu bash
これは ubuntu_bash という名前のコンテナを作成し、Bash セッションを開始します。
$ docker exec -d ubuntu_bash touch /tmp/execWorks
こちらは実⾏中の ubuntu_bash コンテナ内で、新しいファイル /tmp/execWorks をバックグラウンドで作成します。
$ docker exec -it ubuntu_bash bash
こちらは ubuntu_bash コンテナ内に新しい Bash セッションを作成します。

- 95 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

キ ル

kill
使い方: docker kill [オプション] コンテナ [コンテナ...]
実行中のコンテナを SIGKILL か指定したシグナルで停止--help-s, --signal="KILL"

使い方の表示コンテナに送信するシグナル

コンテナの中のメイン・プロセス（ PID 1 ）に対して SIGKILL を送信するか、 --signal オプションで指定したシグナルを送信します。
ENTRYPOINT と CMD をシェル形式で実⾏している場合は、 /bin/sh -c のサブコマンドとして実⾏されていますので、シグナルを受け取ることができません。つまり、（シェル形式では）コンテナの PID
1 は Unix シグナルを受け取りません。

- 96 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

ロ グズ

logs
使い方: docker logs [オプション] コンテナ
コンテナのログを取得-f, --follow=false--help--since=""-t, --timestamps=false--tail="all"ログの出力をフォロー（表示し続ける）
使い方の表示タイムスタンプ以降のログを表示
タイムスタンプを表示
ログの最後から指定した行数を表示

このコマンドが使えるのは、コンテナが json-file と journald ロギング・ドライバを使う時のみです。

docker logs コマンドは、コンテナの実⾏時から現在に⾄るまでのログを、逐次表⽰します。
docker logs --follow および docker logs -f コマンドは、コンテナの STDOUT と STDERR から新しい出⼒があれば、表⽰し続けます。
負の値の指定や、 --tail に値を付けなければ、全てのログを表⽰します。
docker logs --timestamp コ マ ン ド は RFC3339 ナ ノ 秒 タ イ ム ス タ ン プ *1 を 追 加 し ま す 。 例 え ば
2014-09-16T06:17:46.000000000Z のように、各ログ⾏に追加されます。タイムスタンプはナノ秒で表⽰されるため、不要な場合でもゼロが付加されます。
--since オプションは指定した⽇時以降のログを表⽰します。指定できる⽇付は RFC 3339 date、UNIX タイム
スタンプ、Go ⾔語の期間⽂字（例：1m30s、3h）です。Docker はクライアント側のマシン上からの相対時間を計算します。 --since オプションは --follow と --tail と同時に使えます。

*1 https://golang.org/pkg/time/#pkg-constants- 97 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

ポA2.5 コンテナ⽤コマンド

ー ズ

pause
使い方: docker pause [オプション] コンテナ [コンテナ...]
コンテナ内の全てのプロセスを一時停止--help

使い方の表示docker pause コマンドは cgroup を凍結（freezer）するもので、コンテナ内の全てのプロセスを⼀時停⽌（suspend）
します。これまで、プロセスの⼀時停⽌には SIGSTOP シグナルが使われてきました。これはプロセスが⼀時停⽌状
態に⾒えるようにするためのものです。cgroup の凍結により、プロセスの状態は分からなくなり、操作できなくなります。再開されるまで、⼀時停⽌状態のままです。
*1

更に詳しい詳細については cgroup freezer ドキュメント をご覧ください。

*1 https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt- 98 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

ポ ー ト

port
使い方: docker port [オプション] コンテナ [プライベート・ポート[/プロトコル]]
コンテナに対するマッピング（割り当て）を一覧表示
あるいは NAT されたプライベート・ポートを探して表示--help

使い方の表示

プライベート・ポートや、特定の割り当て状況を指定しなければ、全てのポートの割り当て状況（マッピング）を確認できます。
$ docker ps
CONTAINER ID
IMAGE
COMMAND
CREATED
PORTS
NAMES
b650456536c7
busybox:latest
top
54 minutes ago
0.0.0.0:1234->9876/tcp, 0.0.0.0:4321->7890/tcp test
$ docker port test
7890/tcp -> 0.0.0.0:4321
9876/tcp -> 0.0.0.0:1234$ docker port test 7890/tcp
0.0.0.0:4321$ docker port test 7890/udp
2014/06/24 11:53:36 Error: No public port '7890/udp' published for test
$ docker port test 7890
0.0.0.0:4321- 99 -STATUSUp 54 minutes

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンドps
使い方: docker ps [オプション]
コンテナの一覧-a, --all-f, --filter=[]--format=[]--help-l, --latest-n=-1--no-trunc-q, --quiet-s, --size

全てのコンテナを表示 (デフォルトは実行中コンテナのみ表示)
以下の状況に応じて出力をフィルタ:- exited=<整数> 終了コードを <整数> で指定- label=<key> または label=<key>=<value>- status=(created|restarting|running|paused|exited)- name=<文字列> コンテナ名- id=<ID> コンテナ ID- before=(<コンテナ名>|<コンテナ ID>)- since=(<コンテナ名>|<コンテナ ID>)- ancestor=(<イメージ名>[:タグ]|<イメージ ID>|<イメージ@ダイジェスト値>)- 特定のイメージや子孫から作成されたコンテナ- volume=(<ボリューム名>|<マウント・ポイント>)Go テンプレートを使いコンテナの表示を整形
使い方の表示最後に作成したコンテナを表示 (どのような状態でも)直近で作成した n コンテナを表示 (どのような状態でも)トランケート (truncate) を出力しない
整数値の ID のみ表示
合計ファイルサイズを表示

docker ps --no-trunc を実⾏すると、リンクされた２つのコンテナを表⽰します。
$ docker ps
CONTAINER ID

IMAGE

COMMAND

CREATEDSTATUS

PORTS

NAMES

4c01db0b339c

ubuntu:12.04

bash

17 seconds ago

Up 16 seconds

3300-3310/tcp

webappd7886598dbe2

crosbymichael/redis:latest/redis-server --dir33 minutes ago

Up 33 minutes

6379/tcp

redis,webapp/db

デフォルトの docker ps は実⾏中のコンテナだけ表⽰します。全てのコンテナを表⽰するには docker ps -a を使います。
docker ps は、可能であれば公開ポートのグループを範囲で表⽰します。例えば、コンテナが 100、101、102 を公開している場合、PORT 列に 100-102/tcp と表⽰します。

フィ ルタリ ング
フィルタリング・フラグ（ -f と --filter）の形式は key=value の組です。複数のフィルタを指定するには、複数のフラグを使います（例： --filter "foo=bar" --filter "bif=baz"）。
現在、以下のフィルタをサポートします。

 ID（コンテナの ID）
 ラベル（ label=<key> か label=<key>=<value> ） 名前（コンテナの名前）
 終了コード（整数値 - コンテナの終了コード。実⽤的なのは --all）
ア ン セ ク タ 先祖/ancestor（ <イメージ名>[:<タグ>] 、 <イメージ ID> 、 <イメージ@digest> ） - 特定のイメージから作られた⼦コンテナを作成します。

- 100 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

label
label フィルタに⼀致する条件は、コンテナ⾃⾝に割り当てられている label か、その label と値です。
次のフィルタは、color ラベルがどのような値を持っているかに拘わらず、⼀致するものを表⽰します。
$ docker ps --filter "label=color"
CONTAINER ID
IMAGE
PORTS
NAMES
673394ef1d4c
busyboxnostalgic_shockley
d85756f57265
busyboxhigh_albattani

COMMAND

CREATEDSTATUS"top"

47 seconds ago

Up 45 seconds"top"

52 seconds ago

Up 51 seconds

次のフィルタは color ラベルの値が blue に⼀致するコンテナを表⽰します。
$ docker ps --filter "label=color=blue"
CONTAINER ID
IMAGE
COMMAND
PORTS
NAMES
d85756f57265
busybox"top"high_albattani

CREATEDSTATUS

About a minute ago

Up About a minute

name
name フィルタはコンテナ名の全て、または⼀部に⼀致するコンテナを表⽰します。
次のフィルタは nostalgic_stallman ⽂字列を含む名前のコンテナを表⽰します。
$ docker ps --filter "name=nostalgic_stallman"
CONTAINER ID
IMAGE
COMMAND
PORTS
NAMES
9b6247364a03
busybox"top"nostalgic_stallman

CREATEDSTATUS

2 minutes ago

Up 2 minutes

あるいは、⼀部が⼀致する場合でも、次のようにフィルタできます。
$ docker ps --filter "name=nostalgic"
CONTAINER ID
IMAGE
PORTS
NAMES
715ebfcee040
busyboxi_am_nostalgic
9b6247364a03
busyboxnostalgic_stallman
673394ef1d4c
busyboxnostalgic_shockley

COMMAND

CREATEDSTATUS"top"

3 seconds ago

Up 1 seconds"top"

7 minutes ago

Up 7 minutes"top"

38 minutes ago

Up 38 minutes

exitedexited は、コンテナの終了コードに⼀致するものでフィルタします。例えば、正常終了したコンテナでフィルタをするには、次のようにします。
$ docker ps -a --filter 'exited=0'
CONTAINER ID
IMAGE
COMMAND
PORTS
NAMES
ea09c3c82f6e
registry:latest /srv/run.sh
127.0.0.1:5000->5000/tcp desperate_leakey
106ea823fe4e
fedora:latest/bin/sh -c 'bash -l'- 101 -

CREATEDSTATUS

2 weeks ago

Exited (0) 2 weeks ago

2 weeks ago

Exited (0) 2 weeks ago
docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

48ee228c9464

determined_albattani
fedora:20
bash
tender_torvalds

A2.5 コンテナ⽤コマンド

2 weeks ago

Exited (0) 2 weeks ago

statusstatus はコンテナの状態が⼀致するものでフィルタします。フィルタとして使えるのは created、restarting、
running、paused、exited、dead です。例えば、running（実⾏中）のコンテナでフィルタするには、次のようにします。
$ docker ps --filter status=running
CONTAINER ID
IMAGE
PORTS
NAMES
715ebfcee040
busyboxi_am_nostalgic
d5c976d3c462
busyboxtop9b6247364a03
busyboxnostalgic_stallman

COMMAND

CREATEDSTATUS"top"

16 minutes ago

Up 16 minutes"top"

23 minutes ago

Up 23 minutes"top"

24 minutes ago

Up 24 minutes

paused コンテナでフィルタをするには：$ docker ps --filter status=paused
CONTAINER ID
IMAGE
COMMAND
PORTS
NAMES
673394ef1d4c
busybox"top"nostalgic_shockley

CREATEDSTATUS

About an hour ago

Up About an hour (Paused)

ancestor
ancestor（先祖）フィルタはコンテナのベースとなったイメージや、その派⽣に⼀致するものです。フィルタは以下の形式で指定できます。
イメージ
イメージ:タグ
イメージ:タグ@digest
ショート ID
フル ID
タグを指定しなければ、latest タグが使われます。例えば、最新（latest）の ubuntu イメージでフィルタするには：$ docker ps --filter ancestor=ubuntu
CONTAINER ID
IMAGE
PORTS
NAMES
919e1179bdb8
ubuntu-c1
admiring_lovelace
5d1e4a540723
ubuntu-c2
admiring_sammet
82a598284012
ubuntusleepy_bose
bab2a34ba363
ubuntufocused_yonath

COMMAND

CREATEDSTATUS"top"

About a minute ago

Up About a minute"top"

About a minute ago

Up About a minute"top"

3 minutes ago

Up 3 minutes"top"

3 minutes ago

Up 3 minutes- 102 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

ubuntu-c1 イメージをベースにするコンテナ、この例では ubuntu の⼦供に⼀致するものを表⽰：$ docker ps --filter ancestor=ubuntu-c1
CONTAINER ID
IMAGE
COMMAND
PORTS
NAMES
919e1179bdb8
ubuntu-c1"top"admiring_lovelace

CREATEDSTATUS

About a minute ago

Up About a minuteubuntu バージョン 12.04.5 のイメージをベースとするコンテナをフィルタ：$ docker ps --filter ancestor=ubuntu:12.04.5
CONTAINER ID
IMAGE
COMMAND
PORTS
NAMES
82a598284012
ubuntu:12.04.5"top"
sleepy_bose

CREATEDSTATUS

3 minutes ago

Up 3 minutes

レイヤ d0e008c6cf02 あるいはイメージをベースにしたコンテナでフィルタします。
$ docker ps --filter ancestor=d0e008c6cf02
CONTAINER ID
IMAGE
COMMAND
PORTS
NAMES
82a598284012
ubuntu:12.04.5"top"
sleepy_bose

CREATEDSTATUS

3 minutes ago

Up 3 minutes

フォーマ ット
フォーマットのオプション（ --format）は Go テンプレートを使いコンテナの出⼒を整形します。
Go テンプレートで置き換え可能な⼀覧は、次の通りです：.ID.Image.Command.CreatedAt.RunnnngFor.Ports.Status.Size.Names.Lables.Labelコンテナ ID
イメージ ID
クォートされたコマンド
コンテナが作成された時間
コンテナが起動してからの時間
公開しているポート
コンテナのステータス
コンテナの容量
コンテナ名
コンテナに割り当てられた全ラベル
コンテナに対する特定のラベル。例： {{.Label "com.docker.swarm.cpu"}}

ps コマンドに --format オプションを使えば、テンプレートで指定したデータを出⼒するだけでなく、table 命令を使うとカラム（例）ヘッダも同様に表⽰します。
次の例はヘッダを除くテンプレートを使い、実⾏中の全てのコンテナに対して、ID と Command エントリを句切って出⼒します。
$ docker ps --format "{{.ID}}: {{.Command}}"a87ecb4f327c: /bin/sh -c #(nop) MA
01946d9d34d8: /bin/sh -c #(nop) MA
c1d3b0166030: /bin/sh -c yum -y up
41d50ecd2f57: /bin/sh -c #(nop) MA
実⾏中のコンテナのラベルを表形式で出⼒するには、次のようにします。
- 103 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド$ docker ps --format "table {{.ID}}\t{{.Labels}}"
CONTAINER ID
LABELS
a87ecb4f327c
com.docker.swarm.node=ubuntu,com.docker.swarm.storage=ssd
01946d9d34d8
c1d3b0166030
com.docker.swarm.node=debian,com.docker.swarm.cpu=641d50ecd2f57
com.docker.swarm.node=fedora,com.docker.swarm.cpu=3,com.docker.swarm.storage=ssd- 104 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

リ ネ ー ムrename使い方: docker rename [オプション] 古い名前 新しい名前
コンテナの名前を変更--help

使い方の表示docker rename コマンドは、コンテナ名を別の名前にします。

- 105 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

リスタート

restart
使い方: docker restart [オプション] コンテナ [コンテナ...]
コンテナを再起動--help-t, --time=10

使い方の表示コンテナを停止するまで待機する秒数- 106 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンドrm
使い方: docker rm [オプション] コンテナ [コンテナ...]
１つまたは複数のコンテナを削除-f, --force--help-l, --link-v, --volumes

実行中のコンテナを（SIGKILL を使い）強制的に削除
使い方の表示指定したリンクを削除
コンテナと関連づけられたボリュームを削除

例$ docker rm /redis/redis
これは /redis リンクとして参照されているコンテナを削除します。
$ docker rm --link /webapp/redis/webapp/redis
これは /webapp/redis でリンクされているコンテナを削除します。
$ docker rm --force redis
redis
これは /link でリンクされているコンテナを SIGKILL し、コンテナを削除します。
$ docker rm $(docker ps -a -q)
このコマンドは停⽌しているコンテナを全て削除します。コマンド docker ps -a -q は終了した全てのコンテナ
ID を rm コマンドに渡し、全て削除するものです。実⾏中のコンテナは削除されません。
$ docker rm -v redis
redis
このコマンドはコンテナと、コンテナに関連づけられた全ボリュームを削除します。ただし、ボリュームに名前を指定していた場合は、このコマンドでは削除されません。
$ docker create -v awesome:/foo -v /bar --name hello redis
hello$ docker rm -v hello
この例では、ボリューム /foo は残り続けますが、ボリューム /bar は削除します。同様に --volumes-from で継承関係にあるボリュームも保持します。

- 107 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

ラ ン

run
使い方: docker run [オプション] イメージ [コマンド] [引数...]新しいコンテナを実行する命令-a, --attach=[]--add-host=[]--blkio-weight=0--blkio-weight-device=[]イト`)--cpu-shares=0--cap-add=[]--cap-drop=[]--cgroup-parent=""--cidfile=""--cpu-percent=0--cpu-period=0--cpu-quota=0--cpuset-cpus=""--cpuset-mems=""-d, --detach--detach-keys--device=[]--device-read-bps=[]

STDIN、STDOUT、STDERR にアタッチするホストから IP アドレスのマッピングをカスタマイズして追加 (host:ip)
ブロック IO ウエイト (相対ウエイト)ブロック IO ウエイト (相対デバイス・ウエイト。書式： `デバイス名:ウエ

CPU 共有 (相対ウエイト)Linux ケーパビリティの追加
Linux ケーパビリティの削除
コンテナ用のオプション親 cgroup を指定コンテナ ID をファイルに書き出しコンテナが実行可能な CPU 使用率のパーセントを制限。Windows のみ
CPU CFS (Completely Fair Scheduler) ペイロードの制限
CPU CFS (Completely Fair Scheduler) クォータの制限
実行を許可する CPU (0-3, 0,1)
実行を許可するメモリ必要量 (0-3, 0,1)
コンテナをバックグラウンドで実行し、コンテナ ID を表示
コンテナのデタッチに使うエスケープ・キー・シーケンスを設定
ホスト・デバイスをコンテナに追加デバイスからの読み込みレート (バイト/秒) を制限(例: --device-read-bps=/dev/sda:1mb)--device-read-iops=[]
デバイスからの読み込みレート (IO/秒) を制限(例: --device-read-iops=/dev/sda:1000)--device-write-bps=[]
デバイスへの書き込みレート (バイト/秒) を制限(例: --device-write-bps=/dev/sda:1mb)--device-write-iops=[]
デバイスへの書き込みレート (IO/秒) を制限(例: --device-write-bps=/dev/sda:1000)--disable-content-trust=true イメージの認証をスキップ--dns=[]
カスタム DNS サーバの指定--dns-opt=[]
カスタム DNS オプションの指定--dns-search=[]カスタム DNS 検索ドメインの指定-e, --env=[]
環境変数を指定--entrypoint=""
イメージのデフォルト ENTRYPOINT を上書き--env-file=[]ファイルから環境変数を読み込み--expose=[]
ポートまたはポート範囲を露出--group-add=[]
参加するグループを追加-h, --hostname=""コンテナのホスト名--help
使い方の表示-i, --interactive
アタッチしていなくても STDIN を開き続ける--ip=""
コンテナの IPv4 アドレス (例: 172.30.100.104)--ip6=""
コンテナの IPv6 アドレス (例: 2001:db8::33)--ipc=""
使用する IPC 名前空間--isolation=""
コンテナの分離（独立）技術--kernel-memory=""
Kernel メモリ上限-l, --label=[]
コンテナにメタデータを指定 (例: --label=com.example.key=value)--label-file=[]
行ごとにラベルを記述したファイルを読み込み--link=[]他のコンテナへのリンクを追加--log-driver=""
コンテナ用のログ記録ドライバを追加--log-opt=[]
ログドライバのオプションを指定-m, --memory=""
メモリ上限--mac-address=""
コンテナの MAC アドレス (例： 92:d0:c6:0a:29:33)- 108 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド--io-maxbandwidth=""システム・デバイスの IO 帯域に対する上限を指定（Windows のみ）。
書式は `<数値><単位>`。単位はオプションで `b` (バイト/秒)、`k` (キロバイト/秒)、 `m` (メガバイト/秒)、 `g` (ギガバイト/秒)。
単位を指定しなければ、システムはバイト/秒とみなす。
--io-maxbandwidth と --io-maxiops は相互排他オプション--io-maxiops=0
システム・ドライブの最大 IO/秒に対する上限を指定 *Windows のみ)--io-maxbandwidth と --io-maxiops は相互排他オプション--memory-reservation=""
メモリのソフト上限--memory-swap=""
整数値の指定はメモリにスワップ値を追加。-1 は無制限スワップを有効化--memory-swappiness=""
コンテナ用メモリのスワップ程度を調整。整数値の 0 から 100 で指定--name=""コンテナに名前を割り当て--net="bridge" : コンテナをネットワークに接続'bridge': docker ブリッジ上でコンテナ用に新ネットワーク・スタック作成'none': コンテナにネットワーク機能を付けない'container:<name|id>': 他のコンテナ用ネットワーク・スタックを再利用'host': コンテナ内でホスト側ネットワーク・スタックを使用'NETWORK': docker network create でユーザが作成したネットワークを使用--net-alias=[]コンテナにネットワーク内部用のエイリアスを追加--oom-kill-disable
コンテナの OOM Killer を無効化するかどうか指定--oom-score-adj=0
コンテナに対してホスト側の OOM 優先度を設定 ( -1000 ～ 1000 を指定)
-P, --publish-all
全ての露出ポートをランダムならポートに公開-p, --publish=[]コンテナのポートをホスト側に公開--pid=""
使用する PID 名前空間--pids-limit=-1
コンテナの pids 制限を調整 (kernel 4.3 以上は -1 で無制限に設定)--privileged
このコンテナに対して拡張権限を与える--read-only
コンテナのルート・ファイルシステムを読み込み専用としてマウント--restart="no"再起動ポリシー (no, on-failure[:max-retry], always, unless-stopped)--rm
コンテナ終了時、自動的に削除--shm-size=[]`/dev/shm` のサイズ。書式は `<数値><単位>`. `数値` は必ず `0` より大きい。単位はオプションで `b` (bytes)、 `k` (kilobytes)、 `m` (megabytes)、 `g` (gigabytes) を指定可能。
単位を指定しなければ、システムは bytes を使う。数値を指定しなければ、システムは `64m` を使う--security-opt=[]
セキュリティ・オプション--sig-proxy=true
受信したシグナルをプロセスにプロキシ--stop-signal="SIGTERM"
コンテナの停止シグナル--storage-opt=[]
コンテナごとにストレージ・ドライバのオプションを指定--sysctl[=*[]*]]
実行時に名前空間カーネル・パラメータを調整-t, --tty
疑似ターミナル (pseudo-TTY) を割り当て-u, --user=""
ユーザ名または UID--userns=""
コンテナのユーザ名前空間'host': Docker ホストで使うユーザ名前空間'': Docker デーモンのユーザ名前空間を指定するには`--userns-remap` オプションを使う--ulimit=[]
Ulimit オプション--uts=""
使用する UTS 名前空間
-v, --volume=[ホスト側ソース:]コンテナ側送信先[:<オプション>]
ボリュームを拘束マウント。カンマ区切りで指定。`オプション` は [rw|ro],[z|Z], [[r]shared|[r]slave|[r]private], [nocopy]'ホスト側ソース' は絶対パスまたは名前の値--volume-driver=""
コンテナのボリューム・ドライバ--volumes-from=[]
指定したコンテナからボリュームをマウント-w, --workdir=""
コンテナ内の作業用ディレクトリを指定
docker run コマンドは、まず指定されたイメージ上に書き込み可能なコンテナ・レイヤを create（作成）します。それから、指定されたコマンドを使って start（開始）します。この docker run は、API の/containers/createの後で/containers/(id)/start を実⾏するのと同じです。以前に使っていたコンテナは docker start で再起動で- 109 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

きます。全てのコンテナを表⽰するには docker ps -a を使います。
docker run コマンドは、コンテナの内容を確定するために、docker commit コマンドと連携して使えます。
コンテナをネットワークで接続する詳細については、Docker ネットワーク概要のセクションをご覧ください。

例
名前と疑似 TTY の割 り当 て（--name、-it）$ docker run --name test -it debianroot@d6c0fe130dba:/# exit 13$ echo $?
13$ docker ps -a | grep test
d6c0fe130dba
debian:7
ago
test"/bin/bash"

26 seconds ago

Exited (13) 17 seconds

この例は debian:latest イメージを使い、test という名称のコンテナを実⾏します。-it は疑似 TTY（pseudo-TTY）をコンテナの標準⼊⼒に接続するよう、Docker に対して命令します。つまり、コンテナ内でインタラクティブな bash シェルを作成します。例の中で、bash シェルを終了コード 13 で終了しています。この終了コードは docker run を呼び出したもの（docker）にも送られ、test コンテナのメタデータに記録されます。
コンテナ ID の 取得（ --cidﬁle）$ docker run --cidfile /tmp/docker_test.cid ubuntu echo "test"
これはコンテナを作成し、コンソール上に test を表⽰します。cidfile フラグは Docker に新しいファイルを作成させ、そこにコンテナ ID を書かせるものです。もしファイルが既に存在している場合、Docker はエラーを返します。docker run を終了したら、Docker はこのファイルを閉じます。
コンテナの ケー パビリ ティ （--privileged）$ docker run -t -i --rm ubuntu bash
root@bc338942ef20:/# mount -t tmpfs none /mnt
mount: permission denied
これは動作しません。デフォルトでは、カーネルに対して潜在的に危険になりうる処理を破棄します。これには
cap_sys_admin も含まれます（ファイルシステムのマウントに必要なものです）。しかしながら、--privileged フ
ラグがあれば、実⾏できるようになります。
$ docker run -t -i --privileged ubuntu bash
root@50e3f57e16e6:/# mount -t tmpfs none /mnt
root@50e3f57e16e6:/# df -hFilesystem
Size Used Avail Use% Mounted on
none
1.9G
0 1.9G 0% /mnt--privileged フラグはコンテナに対して全ての能⼒を与えます。また、そのために device cgroup コントローラの制限を昇格します。⾔い換えますと、コンテナはホスト上であらゆる処理が可能となります。このフラグが存在する時、 Docker の中で Docker を動かすといった特別な使い⽅ができます。
作業ディレ クトリ を指 定（-w）$ docker run -w /path/to/dir/ -i -t ubuntu pwd- 110 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド-w は、指定したディレクトリの中でコマンドを実⾏します。この例では /path/to/dir で実⾏します。コンテナ
内にパスが存在しなければ、作成されます。
コンテナご とに ストレ ージ・ オプショ ンを指定

$ docker create -it --storage-opt size=120G fedora /bin/bash
これ（容量）はコンテナの作成時にルート・ファイルシステムの容量を 120GB に指定しています。ただし、デフォルトの BaseFS 容量よりも⼩さく指定できません。
tmpfs のマ ウン ト（--tmpfs）$ docker run -d --tmpfs /run:rw,noexec,nosuid,size=65536k my_image--tmpfs フラグはコンテナに対して空の tmfps をマウントします。この時、オプション rw、noexec、nosuid、
size=65536k オプションを指定しています。
ボリュームの マウ ント （-v, --read-only）$ docker run -v `pwd`:`pwd` -w `pwd` -i -t ubuntu pwd-v フラグは現在の作業ディレクトリをコンテナ内にマウントします。 -w によって、コマンドは現在の作業⽤ディレクトリの中で実⾏されます。ディレクトリとは、pwd を実⾏して得られるディレクトリが該当します。このコ
マンドを組み合わせてコンテナを実⾏しても、現在の作業ディレクトリの中で実⾏されるのです。
$ docker run -v /doesnt/exist:/foo -w /foo -i -t ubuntu bash
ボリュームとしてマウントするホスト側のディレクトリが存在しなければ、Docker は⾃動的にホスト上にディレクトリを作成します。先ほどの例では、Docker はコンテナ起動前に /doesnt/exit ディレクトリを作成します。
$ docker run --read-only -v /icanwrite busybox touch /icanwrite here
ボリュームに --read-only を指定して使うことで、コンテナの書き込み可能なファイルを制御できます。
--read-only フラグはコンテナのルート・ファイルシステムを読み込み専⽤としてマウントし、コンテナで指定したボリューム以外での書き込みを禁⽌します。
$ docker run -t -i -v /var/run/docker.sock:/var/run/docker.sock \-v /path/to/static-docker-binary:/usr/bin/docker busybox shDocker Unix ソケットと docker バイナリ（https://get.docker.com から⼊⼿）に対するマウントにより、コンテ
ナはホスト側の Docker デーモンに対して作成や各種操作といった完全アクセスをもたらします。

ポートの公 開と 露出（ -p、 --expose）$ docker run -p 127.0.0.1:80:8080 ubuntu bash
コンテナのポート 8080 を 127.0.0.1 上のポート 80 にバインド（割り当て）します。 Docker ユーザ・ガイド
で Docker がどのようにポートを操作するか詳細を説明しています。
$ docker run --expose 80 ubuntu bash

- 111 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

コンテナのポート 80 を露出（expose）しますが、ホストシステム側のインターフェースには公開しません。
環境 変数の 設定 （-e、--env、 --env-ﬁle）$ docker run -e MYVAR1 --env MYVAR2=foo --env-file ./env.list ubuntu bash
これはコンテナ内におけるシンプルな（配列ではない）環境変数を設定します。この３つのフラグについて説明します。 -e と --env は環境変数と値を指定する場所です。あるいは、もし = が指定されなければ、現在の環境変数がそのまま送られます（例： ホスト上の$MYVAR1 がコンテナ内の$MYVAR1 にセットされます ）。 = が指定されず、クライアント側の環境変数が無い場合は、コンテナ内の環境変数からは削除されます。この３つのフラグ -e、--env、--env-file は何度でも指定できます。
これらの３つのフラグに関係なく、 --env-file が始めに処理され、その後 -e と --env フラグが処理されます。
この⽅法は、必要な時に -e と --env で変数を上書きするために使えます。
$ cat ./env.list
TEST_FOO=BAR$ docker run --env TEST_FOO="This is a test" --env-file ./env.list busybox env | grep TEST_FOO
TEST_FOO=This is a test--env-file フラグは、ファイル名を引数として使います。ファイルの内容は、それぞれの⾏が VAR=VAL の形式であり、 --env のようなものです。コメント⾏は、⾏頭に # を付けます。
$ cat ./env.list
TEST_FOO=BAR# ここはコメント
TEST_APP_DEST_HOST=10.10.0.127
TEST_APP_DEST_PORT=8888_TEST_BAR=FOO
TEST_APP_42=magic
helloWorld=true
123qwe=bar
org.spring.config=something# 実行者は環境変数を渡す
TEST_PASSTHROUGH$ TEST_PASSTHROUGH=howdy docker run --env-file ./env.list busybox env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=5198e0745561
TEST_FOO=BAR
TEST_APP_DEST_HOST=10.10.0.127
TEST_APP_DEST_PORT=8888_TEST_BAR=FOO
TEST_APP_42=magic
helloWorld=true
TEST_PASSTHROUGH=howdy
HOME=/root
123qwe=bar
org.spring.config=something$ docker run --env-file ./env.list busybox env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=5198e0745561
TEST_FOO=BAR- 112 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

TEST_APP_DEST_HOST=10.10.0.127
TEST_APP_DEST_PORT=8888_TEST_BAR=FOO
TEST_APP_42=magic
helloWorld=true
TEST_PASSTHROUGH=
HOME=/root
123qwe=bar
org.spring.config=something
メタデータ をコ ンテナ に設 定（-l、--label、--label-ﬁle）
ラベルとは key=value のペアであり、コンテナにメタデータを提供します。コンテナに２つのラベルをラベル付
けします：$ docker run -l my-label --label com.example.foo=bar ubuntu bash
my-label キーが値を指定しなければ、対象のラベルは空の⽂字列（ "" ）がデフォルトで割り当てられます。複数のラベルを追加するには、ラベルのフラグ（ -l か --label）を繰り返します。
key=value はラベル値を上書きしないよう、ユニークにする必要があります。ラベルが値の違う特定のキーを指定した場合は、以前の値が新しい値に上書きされます。Docker は最新の key=value 指定を使います。
--label-file フラグはファイルから複数のラベルを読み込みます。ラベルとしての区切りは各⾏の EOL マークが現れるまでです。
$ docker run --label-file ./labels ubuntu bash
label-file の書式は、環境変数の読み込み書式と似ています（環境変数との違いは、ラベルはコンテナ内で実⾏中のプロセスから⾒えません）。以下は label-file 形式の記述例です。
com.example.label1="a label"# これはコメントです
com.example.label2=another\ label
com.example.label3
複数のラベル⽤ファイルを読み込むには、複数回 --label-file フラグを使います。
ラベルの動作に関する詳しい情報は、Docker ユーザ・ガイドの「Label - Docker でカスタム・メタデータを使う」セクションをご覧ください。
コンテナを ネッ トワ ークに 接続 （--net）
コンテナ実⾏時に --net フラグを付けるとネットワークに接続します。次の例は busybox コンテナに my-net ネットワークを追加します。
$ docker run -itd --net=my-net busybox
また、ユーザ定義ネットワーク上でコンテナを起動時、 --ip と --ipv6 フラグを使い、コンテナに対して IP ア
ドレスを割り当て可能です。
$ docker run -itd --net=my-net --ip=10.10.9.75 busybox
実⾏中のコンテナに対してネットワークを追加する時は、docker network connect サブコマンドを使います。

- 113 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

同じネットワークに複数のコンテナを接続できます。接続したら、コンテナは別のコンテナの IP アドレスや名前で簡単に通信できるようになります。overlay ネットワークやカスタム・プラグインは複数のホストへの接続をサポートしています。異なった Docker エンジンが起動していても、コンテナが同じマルチホスト・ネットワーク
上であれば、相互に通信できます。
サービス・ディスカバリはデフォルトの bridge ネットワークで利⽤できません。そのため、デフォルトでは、コンテナは IP アドレスで通信します。コンテナ名で通信するには、リンクされている必要があります。

ネットワークからコンテナを切断するには、docker network disconnect コマンドを使います。
コンテナか らボ リュームをマ ウン ト（--volumes-from）$ docker run --volumes-from 777f7dc92da7 --volumes-from ba8c0c54f0f2:ro -i -t ubuntu pwd--volumes-from フラグは、参照するコンテナで定義されたボリュームをマウントできます。コンテナは--volumes-from 引数を何度も指定できます。コンテナ ID はオプションで末尾に :ro か :rw を指定し、読み込み専⽤か読み書き可能なモードを個々に指定できます。デフォルトでは、ボリュームは参照しているコンテナと同じモード（読み書き可能か読み込み専⽤）です。
SELinux のようなラベリング・システムは、コンテナ内にボリューム内容をマウントするにあたり、適切なラベルを必要とします。ラベルが無ければ、対象の領域を使ったコンテナの中では、セキュリティ・システムがプロセスの実⾏を阻⽌します。デフォルトでは、Docker は OS によってセットされるラベルを変更しません。
コンテナ内にあるラベルを変更するには、ボリュームのマウントに :z か :Z の２つを末尾に追加できます。これらのサフィックスは、Docker に対して共有ボリューム上のファイル・オブジェクトに対して再度ラベル付けす
るように伝えます。その結果、Docker は共有コンテントのラベルを使ってラベル付けします。共有ボリュームのラベルは、全てのコンテナを読み書き可能なコンテントにします。 Z オプションは Docker に対してプライベートな共有されないラベルであると伝えます。現在のコンテナのみ、プライベート・ボリュームが使えます。
STDIN・STDOUT・STDERR のア タッ チ（-a）-a フラグは docker run 時にコンテナの STDIN、STDOUT、STDERR をバインドします。これにより、必要に応じて⼊出⼒を操作できるようにします。
$ echo "test" | docker run -i -a stdin ubuntu cat これはコンテナの中にデータをパイプし、コンテナ ID をコンテナの STDIN にアタッチして表⽰します。
$ docker run -a stderr ubuntu echo test
これはエラーでない限り、何も表⽰しません。これはコンテナの STDIRR にしかアタッチしていないためです。
コンテナのログに STDERR と STDOUT が書き込まれます。
$ cat somefile | docker run -i -a stdin mybuilder dobuild
これはファイルの内容をコンテナにパイプし、構築するものです。構築が完了するとコンテナ ID が表⽰され、構築ログは docker logs で取得できます。これはファイルや何かをコンテナ内にパイプし、コンテナで処理が終わるとコンテナ ID を表⽰するので便利です。
ホスト・デ バイスを コンテ ナに 追加（ --device）$ docker run --device=/dev/sdc:/dev/xvdc --device=/dev/sdd --device=/dev/zero:/dev/nulo -i -t ubuntu ls- 114 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド-l /dev/{xvdc,sdd,nulo}
brw-rw---- 1 root disk 8, 2 Feb 9 16:05 /dev/xvdc
brw-rw---- 1 root disk 8, 3 Feb 9 16:05 /dev/sdd
crw-rw-rw- 1 root root 1, 5 Feb 9 16:05 /dev/nulo
デバイスをコンテナに直接さらす必要が度々あります。 --device オプションは、これを可能にします。例えば、
特定のブロック・ストレージ・デバイス、ループ・デバイス、オーディオ・デバイスを使うにあたり、コンテナに特権を与えなくても（--privileged フラグを使わずに ）追加でき、アプリケーションが直接使えるようになります。
デフォルトでは、コンテナは read、write、mknod を各デバイスに指定できます。各 --device フラグのオプション設定で、３つの :rwm を利⽤できます。
$ docker run --device=/dev/sda:/dev/xvdc --rm -it ubuntu fdisk /dev/xvdc
Command (m for help): q$ docker run --device=/dev/sda:/dev/xvdc:r --rm -it ubuntu fdisk /dev/xvdc
You will not be able to write the partition table.
Command (m for help): q$ docker run --device=/dev/sda:/dev/xvdc:rw -it ubuntu fdisk /dev/xvdc
Command (m for help): q$ docker run --device=/dev/sda:/dev/xvdc:m --rm -it ubuntu fdisk /dev/xvdc
fdisk: unable to open /dev/xvdc: Operation not permitted--device はエフェメラルな（短命な）デバイスでは使うべきではありません。信頼できないコン
テナが --device を追加しようとしても、ブロック・デバイスは除外されるでしょう。

再起動ポリ シーDocker の --restart はコンテナの再起動ポリシーを指定します。再起動ポリシーは、コンテナの終了後、Docker
デーモンが再起動するかどうかを管理します。Docker は次の再起動ポリシーをサポートしています。
ポリシー

説明

no（なし）

コンテナが終了しても、⾃動的には再起動しません。これがデフォルトです。
on-failure[:最⼤リトライ数]
コンテナが 0 以外の終了コードで停⽌したら再起動します。オプ
ションで Docker デーモンが何度再起動を試みるかを指定できます。
always（常に）コンテナの終了コードに拘わらず、常にコンテナの再起動を試みます。Docker デーモンは無制限に再起動を試みます。また、デーモンの起動時にも、コンテナの状況に拘わらず常に起動を試みます。
unless-stopped（停⽌していない場合） コンテナの終了コードに拘わらず、常にコンテナの再起動を試みます。しかし、直近のコンテナが停⽌状態であったのであれば、デーモンの起動時にコンテナを開始しません。
$ docker run --restart=always redis
これは redis コンテナを再起動ポリシー always で起動するものです。つまり、コンテナが終了したら Docker がコンテナを再起動します。
- 115 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

再起動ポリシーに関するより詳しい情報は、「Docker run リファレンス」の「再起動ポリシー（--restart）」をご覧ください。
コンテナの hosts フ ァイル にエ ントリ 追加（--add-host）--add-host フラグを使い、コンテナの /etc/hosts ファイルに１つもしくは複数のホストを追加できます。次の例はホスト名 docker に静的なアドレスを追加しています。
$ docker run --add-host=docker:10.180.0.1 --rm -it debian$$ ping docker
PING docker (10.180.0.1): 48 data bytes
56 bytes from 10.180.0.1: icmp_seq=0 ttl=254 time=7.600 ms
56 bytes from 10.180.0.1: icmp_seq=1 ttl=254 time=30.705 ms^C--- docker ping statistics --2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 7.600/19.152/30.705/11.553 ms
時々、コンテナ内から Docker ホストに対して接続する必要があります。接続のためには、--add-host フラグをコンテナに使い、Docker ホストの IP アドレスを与えます。ホスト側の IP アドレスを確認するには、ip addr show
コマンドを使います。
コンテナが何の IPv4 ないし IPv6 ネットワークを使っているかは、ip addr show の結果次第です。次のフラグは、
ネットワーク・デバイス eth0 の IPv4 アドレスを指定します。
$ HOSTIP=`ip -4 addr show scope global dev eth0 | grep inet | awk '{print \$2}' | cut -d / -f 1`$ docker run --add-host=docker:${HOSTIP} --rm -it debian
IPv6 は -4 フラグの替わりに -6 を指定します。他のネットワーク・デバイスの場合は eth0 を適切なデバイス
名に置き換えます（例えば docker0 ブリッジ・デバイス）。
コンテナ内 の ulimits を 指定 （--ulimit）
コンテナ内で ulimit 設定をするには追加特権が必要であり、デフォルトのコンテナでは指定できません。そこで --ulimit フラグを指定できます。--ulimit はソフト・リミットとハード・リミットを指定できます。<type>=<
ソフト・リミット>[:<ハード・リミット>] の形式です。例：$ docker run --ulimit nofile=1024:1024 --rm debian sh -c "ulimit -n"
1024

ハード・リミットを指定しなければ、ソフト・リミットが両⽅の値として使われます。ulimits を設定しなければ、デーモンのデフォルト ulimits を継承します。as オプションは無効化されました。⾔い換えますと、次のようなスクリプトはサポートされていません：$ docker run -it --ulimit as=1024 fedora /bin/bash

設定したら適切な syscall が送信されます。Docker は転送に何ら介在しません。値が設定された時のみ処理されます。
nproc を使う にはulimit フラグに nproc を設定する時とは、nproc で Linux 利⽤者が利⽤可能な最⼤プロセス数をセットするものであり、コンテナに対してではないので注意してください。次の例は、daemon ユーザとして４つのコンテナを起動します。

- 116 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

docker run -d -u daemon --ulimit nproc=3 busybox top
docker run -d -u daemon --ulimit nproc=3 busybox top
docker run -d -u daemon --ulimit nproc=3 busybox top
docker run -d -u daemon --ulimit nproc=3 busybox top
４番めのコンテナは失敗し、“[8] System error: resource temporarily unavailable ” エラーを表⽰します。これが失敗するのは、実⾏時に nproc=3 を指定したからです。３つのコンテナが起動したら、daemon ユーザに指定されたプロセスの上限（quota）に達してしまうからです。
コンテナを シグ ナル で停止--stop-signal フラグは、システムコールのシグナルを設定します。これは、コンテナを終了する時に送るものです。このシグナルはカーネルの syscall テーブルにある適切な数値と⼀致する必要があります。例えば 9 や、
SIGNAME のような形式のシグナル名（例：SIGKILL）です。
コンテナの 分離 （独立 ）技 術を指 定（ --isolation）
このオプションは Docker コンテナを Microsoft Windows 上で使う状況で便利です。 --isolation <値> オプシ
ョンでコンテナの分離（isolation）技術を指定します。 Linux 上では Linux 名前空間（namespaces）を使う default
しかサポートしていません。Linux 上では次の２つのコマンドが同等です。
$ docker run -d busybox top$ docker run -d --isolation default busybox top
特に Microsoft Windows 上で daemon オプションを指定していなければ、次の２つのコマンドは同等です。
$ docker run -d --isolation default busybox top$ docker run -d --isolation process busybox top
Docker daemon 上で --exec-opt isolation=hyperv オプションを指定したら、各コマンドの実⾏に hyperv 分離を使った結果を表⽰します。
$ docker run -d --isolation default busybox top$ docker run -d --isolation hyperv busybox top
実行時に名 前空 間のカ ーネ ル・パ ラメ ータ（sysctl）を設定--sysctl はコンテナ内の名前空間におけるカーネル・パラメータ（sysctl）を設定します。例えば、コンテナのネットワーク名前空間で IP 転送を有効にするには、次のようにコマンドを実⾏します。
$ docker run --sysctl net.ipv4.ip_forward=1 someimage

全ての sysctl が名前空間で使えるわけではありません。Docker はコンテナ内の sysctl の変更をサ
ポートしません。つまり、コンテナ内だけでなくホスト側も変更します。カーネルが改良されれば、更に多くの sysctl を名前空間内で利⽤可能になると考えています。

サポート 中の sysctl
IPC 名前空間：
kernel.msgmax、 kernel.msgmnb、 kernel.msgmni、 kernel.sem、 kernel.shmall、 kernel.shmmax、
kernel.shmmni、 kernel.shm_rmid_forced、 fs.mqueue.* で始まる sysctl 。
--ipc=host オプションを使う場合は、これら sysctl のオプション指定が許可されません。
- 117 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

ネットワーク名前空間： net.* で始まる sysctl--ipc=host オプションを使う場合は、これら sysctl のオプション指定が許可されません。

- 118 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

スタート

start
使い方: docker start [オプション] コンテナ [コンテナ...]
１つまたは複数のコンテナを起動する-a, --attach--detach-keys--help-i, --interactive

STDIN、STDOUT、STDERR にアタッチするコンテナのデタッチに使うエスケープ・キー・シーケンスを設定
使い方の表示コンテナの STDIN にアタッチ- 119 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

スタッツ

stats
使い方: docker stats [オプション] [コンテナ...]
１つまたは複数のコンテナのリソース使用状況をライブで流し続ける-a, --all--help--no-stream

全てのコンテナを表示（デフォルトは実行中のものだけ）
使い方の表示ストリームを無効化し、初回の結果しか表示しない

docker stats コマンドは実⾏中のコンテナからライブ・データ・ストリームを返します。特定コンテナの情報のみを取得するには、コンテナ名またはコンテナ ID をスペース区切りで追加します。ここでは停⽌しているコンテナも指定できますが、停⽌中のコンテナは何も返しません。
コンテナのリソース使⽤詳細を知りたい場合は、 /containers/(id)/stats API エンドポイントを使います。

例docker stats を複数のコンテナに実⾏します。
$ docker stats
CONTAINERBLOCK I/O
1285939c1fd3
3.568 MB / 512 KB
9c76f7834ae2
12.4 MB / 0 B
d1ea048f04e4
27.7 MB / 0 B

CPU %MEM USAGE / LIMITMEM %NET I/O

0.07%

796 KiB / 64 MiB

1.21%

788 B / 648 B

0.07%

2.746 MiB / 64 MiB

4.29%

1.266 KB / 648 B

0.03%

4.583 MiB / 64 MiB

6.30%

2.854 KB / 648 B

docker stats で複数のコンテナ名・ID を指定します。
$ docker stats fervent_panini 5acfcb1b4fd1
CONTAINERCPU %MEM USAGE/LIMIT
MEM %5acfcb1b4fd1
0.00%
115.2 MiB/1.045 GiB 11.03%
fervent_panini
0.02%
11.08 MiB/1.045 GiB 1.06%- 120 -NET I/O
1.422 kB/648 B
648 B/648 B

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

ストップ

stop
使い方: docker stop [オプション] コンテナ [コンテナ...]コンテナに SIGTERM を送信し、一定期間後に SIGKILL を送信--help-t, --time=10

使い方の表示kill で停止する前に待機する秒数

コンテナ内のメイン・プロセスは SIGTERM を受信します。⼀定期間経過すると、SIGKILL を送ります。

- 121 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

トップ

top
使い方: docker top [オプション] コンテナ [ps オプション]
コンテナで実行中のプロセスを表示--help

使い方の表示- 122 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

ア ン ポ ー ズ

unpause
使い方: docker unpause [オプション] コンテナ [コンテナ...]
コンテナ内の全てのプロセスに対し、一時停止を解除--help

使い方の表示docker unpause コマンドは、cgroup freezer を使ってコンテナ内で⼀時停⽌している全プロセスを再開します。
より詳細については cgroups freezer ドキュメント*1 をご覧ください。

*1 https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt- 123 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.5 コンテナ⽤コマンド

ウエイト

wait
使い方: docker wait [オプション] コンテナ [コンテナ...]コンテナが停止するのを阻止し、終了コードを表示--help

使い方の表示- 124 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.6 Hub・レジストリ⽤コマンド

A2.6 Hub・レジストリ用コマンド
ログイン

login
使い方: docker login [オプション] [サーバ]Docker レジストリ・サーバに登録またはログインする
サーバの指定が無ければデフォルトで "https://index.docker.io/v1/" を使用-e, --email=""--help-p, --password=""-u, --username=""

メールアドレス
使い方の表示パスワード
ユーザ名

⾃分でホストしているレジストリにログインするには、サーバ名を指定します。
例：$ docker login localhost:8080
docker login の実⾏には sudo か root になる必要があります。ただし次の場合は除外します。
1. docker-machine を使い、docker engine を⾃動設定したようなリモート・デーモンに接続時。
2. docker グループに追加されたユーザ。システム上のセキュリティ・リスクになります。docker グループは rootと同等のためです。詳細は「Docker デーモンが直⾯する攻撃」のセクションをご覧ください。
証明書（credential）があれば、あらゆるパブリックないしプライベートなリポジトリにログインできます。ログ
インしたら、コマンドは符号化（エンコード）した証明書を Linux であれば $HOME/.docker/config.json に、Windowsであれば %USERPROFILE%/.docker/config.json に保管します。
sudo docker login を実⾏したら、証明書は /root/.docker/config.json に保管されます。

証 明書ス トア
Docker Engine はユーザの証明書（credential）を外部の証明書ストアに保存できます。外部の証明書ストアとは、
オペレーティング・システムのネイティブなキーチェーン（keychain）です。Docker 設定ファイルに証明書を保管するよりも、外部のストアを使う⽅がセキュリティは⾼いです。
証明書ストアを使うには、キーチェーンや外部ストアと接続する外部のヘルパー・プログラムが必要です。Docker
はクライアント・ホスト上の $PATH にヘルパー・プログラムが必要です。
こちらは現時点で利⽤可能な証明書ヘルパー・プログラムと、ダウンロード先の⼀覧です。

 D-Bus シークレット・サービス： https://github.com/docker/docker-credential-helpers/releases
 Apple OS X キーチェーン：https://github.com/docker/docker-credential-helpers/releases
 Microsoft Windows 資格情報マネージャ：https://github.com/docker/docker-credential-helpers/releases
使い方
証明書ストアを使うには $HOME/.docker/config.json で Docker Engine に対して指定する必要があります。

- 125 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.6 Hub・レジストリ⽤コマンド{"credsStore": "osxkeychain"}
既にログイン状態であれば、docker logout を実⾏し、ファイルから認証情報を削除します。それから docker
login を再び実⾏します。
プロトコル
証明書ヘルパーは、どのようなプログラムやスクリプトでも扱える⾮常にシンプルなプロトコルです。このプロ
トコルは Git のアイディアに強く影響を受けていますが、情報を共有する仕組みは違います。
ヘルパーはコマンドのアクションを決めるため、常に１番めの引数を使います。ここで利⽤可能な引数とは store
get erase のいずれかです。
store 命令は標準⼊⼒の JSON ペイロードを取得します。ペイロードではサーバのアドレス、証明書の指定、ユーザ名、パスワードあるいは識別⽤トークンを渡します。
{"ServerURL": "https://index.docker.io/v1","Username": "david","Secret": "passw0rd1"}
もしシークレット（訳者注：証明書やトークンなどの秘密情報の意味）が識別⽤トークンを保管する場合、ユー
ザ名にあたる部分は <token> がセットされます。
store 命令は何らかの問題が Docker Engine で発⽣した時、STDOUT（標準出⼒に）エラーを表⽰できます。
get 命令は STDIN（標準⼊⼒）からの⽂字列をペイロードとして読み込みます。Docker Engine が必要とする証明書を持っているサーバのアドレスをペイロードで渡します。 https://index.docker.io/v1 はペイロードの例です。
get 命令は JSON ペイロードを STDOUT（標準出⼒）に書き出します。Docker は、このペイロードからユーザ名とパスワードを読み込みます。読み込みます。
{"Username": "david","Secret": "passw0rd1"}
erase 命令は STDIN（標準⼊⼒）からの⽂字列をペイロードとして読み込みます。Docker Engine が必要とする証明書を持っているサーバのアドレスをペイロードで渡します。 https://index.docker.io/v1 はペイロードの例です。
store 命令は何らかの問題が Docker Engine で発⽣した時、STDOUT（標準出⼒に）エラーを表⽰できます。

- 126 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.6 Hub・レジストリ⽤コマンド

ログアウト

logout使い方: docker logout [サーバ]Docker レジストリからログアウトする
サーバの指定が無ければデフォルトで "https://index.docker.io/v1/" を使用--help

使い方の表示例：$ docker logout localhost:8080- 127 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.6 Hub・レジストリ⽤コマンド

プ ル

pull
使い方: docker pull [オプション] 名前[:タグ] | [レジストリ・ホスト[:レジストリ・ポート]/]名前[:タグ]
レジストリからイメージやリポジトリを取得-a, --all-tags=false
リポジトリでタグ付けられた全てのイメージをダウンロード--disable-content-trust=true イメージの認証をスキップ--help
使い方の表示⼤部分のイメージは、Docker Hub レジストリにあるベース・イメージを元に作られています。
Docker Hub には多くの構築済みのイメージがあります。⾃分で定義や設定をしなくても、イメージを取得（ダウンロード）して試せます。特定のイメージやイメージの集まり（例：リポジトリ）をダウンロードするには、docker
pull を使います。

例
イメージを Docker Hub から取 得（ pull）
特定のイメージやイメージ群（例：リポジトリ）をダウンロードするには、docker pull を使います。タグを指定しなければ、Docker Engine はデフォルトで :latest タグを使います。次のコマンドは debian:latest イメージを取得します：$ docker pull debianUsing default tag: latest
latest: Pulling from library/debian
fdd5d7827f33: Pull complete
a3ed95caeb02: Pull complete
Digest: sha256:e7d38b3517548a1c71e41bffe9c8ae6d6d29546ce46bf62159837aad072c90aa
Status: Downloaded newer image for debian:latest
Docker イメージは複数のレイヤ（層）で構成されています。上の例では、イメージには fdd5d7827f33 とa3ed95caeb02 の２つのレイヤがあります。
レイヤはイメージ間で再利⽤できます。例えば、debian:jessi イメージは debian:latest とレイヤを共有しています。そのため、debian:jessie イメージの取得時は、レイヤをダウンロードせずにメタデータのみ取得します。
なぜなら全てのレイヤがローカルにダウンロード済みだからです。
$ docker pull debian:jessie
jessie: Pulling from library/debian
fdd5d7827f33: Already exists
a3ed95caeb02: Already exists
Digest: sha256:a9c958be96d7d40df920e7041608f2f017af81800ca5ad23e327bc402626b58e
Status: Downloaded newer image for debian:jessie
どのようなイメージがローカルにあるかを確認するには docker images コマンドを使います。
$ docker images
REPOSITORY
debiandebianTAG
jessielatestIMAGE IDf50f9524513f
f50f9524513f

CREATED
5 days ago
5 days ago

SIZE
125.1 MB125.1 MB- 128 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.6 Hub・レジストリ⽤コマンド

Docker はコンテント・アドレッサブル（content-addressable；内容に対して割り当て可能な）イメージ・スト
アを使います。そして、イメージ ID とはイメージの設定とレイヤを扱う SHA256 ダイジェストです。先ほどの例
では debian:jessie と debian:latest は同じイメージ ID を持っています。イメージ名は違いますが、実際には同じイメージに対してタグ付けしています。どちらも同じイメージのため、レイヤのためのデータを保存するのは１度だけであり、余分なディスク容量は不要です。
イメージ、レイヤ、コンテント・アドレッサブル・ストアに関する詳しい情報は、「イメージ、コンテナ、スト
レージ・ドライバの理解」のセクションをご覧ください。
ダイジェス ト（ 変わ らない 識別 子）で イメージを取得

ここまではイメージを名前（または「タグ」）で取得しました。イメージを扱うのに名前とタグの指定は便利です。イメージに対して docker pull を実⾏する時にタグを指定したら、そのイメージの最新バージョンをダウンロードします。例えば docker pull ubuntu:14.04 は Ubuntu 14.04 イメージの最新バージョンを取得します。
イメージを最新バージョンではなく、特定のバージョンに固定したい場合があるでしょう。そのような場合、Docker はダイジェスト（digest 値）を指定してイメージを取得できます。ダイジェストを指定してイメージを取得しようとしたら、指定したバージョンのイメージを確実にダウンロードします。このようするとイメージのバージョンを「固定」し、常に同じイメージの使⽤を保証します。
イメージのダイジェスト値を知るには、まずイメージを取得します。Docker Hub から最新の ubuntu:14.04 イメージをダウンロードしましょう。
$ docker pull ubuntu:14.04
14.04: Pulling from library/ubuntu
5a132a7e7af1: Pull complete
fd2731e4c50c: Pull complete
28a2f68d1120: Pull complete
a3ed95caeb02: Pull complete
Digest: sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
Status: Downloaded newer image for ubuntu:14.04
Docker はダウンロードが完了したら、イメージのダイジェスト値を表⽰します。先ほどの例では、イメージのダイジェスト値とは、こちらです。
sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
Docker はイメージを送信（push）する時のダイジェスト値を表⽰します。イメージを送信時のバージョンを固定したい場合には便利になるでしょう。
イメージの取得時にダイジェスト値を使うには、タグとして扱います。例えば、イメージをダイジェスト値で取得するには、次のコマンドを実⾏します。
$ docker pull ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2: Pulling from library/ubuntu
5a132a7e7af1: Already exists
fd2731e4c50c: Already exists
28a2f68d1120: Already exists
a3ed95caeb02: Already exists
Digest: sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
Status: Downloaded newer image forubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2- 129 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.6 Hub・レジストリ⽤コマンド

Digest は Dockerﬁle の FROM でも指定可能です。以下は例です。
FROM ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
MAINTAINER some maintainer <maintainer@example.com>

この機能はイメージに対するバージョンを都度「固定」します。そのため Docker はイメージのバージョンを更新しないため、セキュリティの更新もしません。更新版のイメージを取得したい場合
は、適時ダイジェスト値を変更する必要があります。

別のレジストリから取得
docker pull のイメージは Docker Hub から取得するのがデフォルトです。取得するレジストリの場所は、⼿動で指定可能です。例えば、ローカルにレジストリをセットアップしておけば、そちらを指定してイメージを取得できます。レジストリのパスは URL と似ていますが、プロトコル指⽰⼦（https://）がありません。
以下のコマンドは、ポート 5000 を開いているローカルのレジストリ（myregistry.local:5000）から、
testing/test-image イメージを取得するコマンドです。
$ docker pull myregistry.local:5000/testing/test-image
レジストリの認証情報は docker login で管理します。
Docker はレジストリとの通信に https プロトコルを使います。ただし、レジストリが安全ではない接続（insecureconnection）を許可している場合は除外します。詳細は「安全ではないレジストリ」のセクションをご覧ください。

リ ポジト リから 複数 のイメ ージを 取得
デフォルトでは、docker pull はレジストリから単⼀のイメージを取得します。リポジトリには複数のイメージがあります。リポジトリから全てのイメージを取得するには docker pull で -a（あるいは --all-tags ）オプショ
ンを使います。
次のコマンドは fedora リポジトリから全てのイメージを取得します。
$ docker pull --all-tags fedora
Pulling repository fedora
ad57ef8d78d7: Download complete
105182bb5e8b: Download complete
511136ea3c5a: Download complete
73bd853d2ea5: Download complete....
Status: Downloaded newer image for fedora
取得が終わったら、取得した全てのイメージを確認するために docker images コマンドを使います。次の例はローカルに現在ある全ての fedora イメージを表⽰しています。
$ docker images fedora
REPOSITORY
fedorafedorafedorafedoraTAG
rawhide20
heisenbug
latestIMAGE ID
ad57ef8d78d7
105182bb5e8b105182bb5e8b105182bb5e8b

CREATED
5 days ago
5 days ago
5 days ago
5 days ago

SIZE
359.3 MB372.7 MB372.7 MB372.7 MB- 130 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.6 Hub・レジストリ⽤コマンド

取 得を中 止docker pull プロセスを停⽌するには、ターミナルで実⾏中に CTRL-c を押すと、pull 処理を中断します。
$ docker pull fedora
Using default tag: latest
latest: Pulling from library/fedora
a3ed95caeb02: Pulling fs layer
236608c7b546: Pulling fs layer^C

技術的に Engine を停⽌する処理とは、Docker Engine デーモンと起点となった Docker Engine
クライアント間における取得（pull）に対してです。何らかの理由によって Engine デーモンとの通信を切断した場合も、同様に取得処理が中断します。

- 131 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.6 Hub・レジストリ⽤コマンド

プッシュ

push
使い方: docker push [オプション] 名前[:タグ]
イメージやリポジトリをレジストリに送信 (push)--disable-content-trust=true--help

イメージの署名をスキップ
使い方の表示docker push を使うと、イメージを Docker Hub レジストリや、⾃分で作成したレジストリで共有できるようになります。
docker push プロセスを停⽌するには、ターミナルで実⾏中に CTRL-c を押すと、push 処理を中断します。
レジストリの認証情報は docker login で管理します。

- 132 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

サーA2.6 Hub・レジストリ⽤コマンド

チ

search使い方: docker search [オプション] 単語
Docker Hub のイメージを検索--automated--help--no-trunc-s, --stars=0

自動構築 (automated build) のみ表示
使い方の表示トランケート (truncate) を出力しない
最低限 x 個のスターがあるイメージのみ表示

Docker Hub のイメージを検索します。
共有イメージをコマンドラインで調べる詳細は、「Docker Hub で公開イメージを探す」セクションをご覧ください。
検索結果は 25 件までしか表⽰しません。

- 133 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.7 ネットワークと接続⽤コマンド

A2.7 ネットワークと接続用コマンド
コ

ネ

ク

ト

network connect
使い方: docker network connect [オプション] ネットワーク コンテナ
コンテナをネットワークに接続--alias=[]--help--ip--ip6--link=[]コンテナ用のネットワーク範囲エイリアスを追加
使い方の表示IPv4 アドレス
IPv6 アドレス
他のコンテナに対するリンクを追加

コンテナをネットワークに接続（connect）します。コンテナの接続はコンテナ名かコンテナ ID を使います。接
続後は、同⼀ネットワーク上にある他のコンテナと通信可能になります。
$ docker network connect multi-host-network container1
あるいは、docker run --net=<ネットワーク名> オプションを使えば、コンテナ起動時に直ちにネットワークに接続します。
$ docker run -itd --net=multi-host-network busybox
コンテナのインターフェースに任意の IP アドレスを割り当て可能です。
$ docker network connect --ip 10.10.36.122 multi-host-network container2--link オプションを使うことで、他のコンテナを任意のエイリアス名でリンクできます。
$ docker network connect --link container1:c1 multi-host-network container2--alias オプションを使うことで、ネットワークを接続したコンテナ間での名前解決に使う別名を指定できます。
$ docker network connect --alias db --alias mysql multi-host-network container2
コンテナを中断（pause）
・再起動・停⽌しても、ネットワークに接続したままです。中断したコンテナはネット
ワークに接続し続けており、network inspect で確認できます。コンテナを停⽌（stop）すると、再起動するまではネットワーク上に表⽰されません。
停⽌しているコンテナを再起動する時に IP アドレスを指定できます。もしも IP アドレスが使えなければ、コンテナは起動に失敗します。IP アドレスを確実に割り当てるためには、ネットワーク作成時に --ip-range（IP アド
レスの範囲）を指定しておき、その範囲内外にある静的な IP アドレスを割り当てる⽅法があります。そうしておけば、コンテナが対象のネットワークに所属していない間でも、他のコンテナに IP アドレスを使われる⼼配はありません。
$ docker network create --subnet 172.20.0.0/16 --ip-range 172.20.240.0/20 multi-host-network$ docker network connect --ip 172.20.128.2 multi-host-network container2
コンテナがどこに接続しているかを確認するには、docker network inspect コマンドを使います。docker network- 134 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.7 ネットワークと接続⽤コマンド

disconnect はコンテナをネットワークから切り離します。
ネットワークに接続したら、コンテナは他のコンテナの IP アドレスや名前を使って通信できるようになります。
overlay ネットワークやカスタム・プラグインは複数のホスト間の接続性（multi-host connectivity）をサポートしています。コンテナは同じマルチホスト・ネットワーク上で接続できるだけではありません。異なったエンジンによって起動されていたとしても、同様に通信できます。
コンテナは複数のネットワークにも接続できます。ネットワークは同じ種類でなくても構いません。例えば、コンテナ・ブリッジとオーバレイ・ネットワークの両⽅に接続できます。

- 135 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.7 ネットワークと接続⽤コマンド

クリエイト

network create
使い方: docker network create [オプション] ネットワーク名
ユーザが名付ける新しいネットワークを作成--aux-address=map[]-d --driver=DRIVER--gateway=[]--help--internal--ip-range=[]--ipam-driver=default--ipam-opt=map[]-o --opt=map[]--subnet=[]ネットワーク・ドライバが使う ipv4 または ipv6 追加アドレス
ネットワーク・ブリッジまたはオーバレイを管理するドライバ。デフォルトは bridge
マスタ・サブネット用の ipv4 または ipv6 ゲートウェイ
使い方の表示ネットワークの外部へのアクセスを制限
サブ・レンジからコンテナの IP アドレスを割り当て
IP アドレス管理用ドライバ
カスタム IPAM ドライバ固有のオプションを指定
カスタムドライバ固有のオプションを指定
ネットワーク・セグメントを表すサブネットを CIDR 形式で指定

新しいネットワークを作成します。DRIVER には bridge か overlay を指定できます。どちらも内蔵のネットワー
ク・ドライバです。サードパーティー製のドライバをインストールするか、カスタム・ネットワーク・ドライバを組み込むのであれば、同様に DRIVER で指定できます。 --driver オプションを指定しなければ、コマンドは⾃動的に bridge ネットワークを作成します。Docker エンジンをインストールしたら、bridge ネットワークを⾃動的に構築します。このネットワークは従来の docker0 ブリッジに相当します。新しいコンテナを docker run で起動した
ら、⾃動的にこのブリッジ・ネットワークに接続します。このデフォルト・ブリッジ・ネットワークは削除できま
せんが、新しいブリッジを network create コマンドで作成できます。
$ docker network create -d bridge my-bridge-network
ブリッジ・ネットワークは、単⼀の Docker エンジン上でネットワークを分離（isolate）します。ネットワーク
を作成する時、overlay（オーバレイ）ネットワークであれば、Docker エンジンが動作する複数のホスト上に渡ることも可能です。bridge ネットワークとは異なり、オーバレイ・ネットワークを作成するには、いくつかの条件が必要です。

 キーバリュー・ストアにアクセスできること。エンジンがサポートしているキーバリュー・ストアは
Consul、Etcd、ZooKeeper（分散ストア）です。
 クラスタの各ホストが、キーバリュー・ストアと接続できること。
 各ホスト上の Docker エンジンの daemon が、クラスタとしての適切な設定をすること。
docker daemon が overlay ネットワークをサポートするために必要なオプションは、次の通りです。

 --cluster-store --cluster-store-opt
 --cluster-advertise
各オプションや設定⽅法の詳細については、「マルチホスト・ネットワークを始めましょう」のセクションをご覧ください。
もう１つの良いアイディアとしては、これらの設定を⾏わなくても、Docker Swarm でネットワークも管理できるクラスタの管理もできます。Swarm は知的なディスカバリとサーバ管理を提供しますので、実装にあたっての⼿助けとなるでしょう。
- 136 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.7 ネットワークと接続⽤コマンド

overlay ネットワークに必要な準備が整った後は、クラスタ上にあるホストのどれかで次のようなネットワーク
作成コマンドを実⾏します。
$ docker network create -d overlay my-multihost-network
ネットワーク名はユニークにする必要があります。Docker デーモンは名前の衝突を避けようとしますが、保証されません。ユーザ・リポジトリも名前の衝突を避けようとします。

コ ンテナ に接続コンテナの起動時に --net フラグを指定したら、ネットワークに接続します。busybox コンテナが mynet ネット
ワークに接続するには、次のようにします。
$ docker run -itd --net=mynet busybox
既に実⾏中のコンテナに対してネットワークを接続したい場合は、docker network connect サブコマンドを使います。
同じネットワークに複数のコンテナが接続できます。接続したら、コンテナは他のコンテナの IP アドレスか名前で通信できるようになります。overlay ネットワークやカスタム・プラグインは、複数のホスト間の接続サポー
トしていますので、コンテナは同じマルチホスト・ネットワークに接続できるだけでなく、異なった Docker エン
ジンから起動された環境でも、同様に通信できます。
コンテナをネットワークから切断するには、docker network disconnect コマンドを使います。

高 度なオ プショ ンの設 定
ネットワークの作成時、デフォルトではエンジンはネットワークのサブネットワークが重複しないようにします。
サブネットワークは既存のネットワークの下位にはありません。純粋に IP アドレスを割り当てるためです。この
デフォルトを上書きするには、 --subnet オプションを使ってサブネットワークの値を直接指定します。
docker network create -d --subnet=192.168.0.0/16
更に、他にも --gateway --ip-range --aux-address オプションが利⽤可能です。
network create --driver=bridge --subnet=172.28.0.0/16 --ip-range=172.28.5.0/24 \--gateway=172.28.5.254 br0--gateway フラグを省略したら、エンジンは対象ネットワークの範囲内から１つ選びます。overlay ネットワー
クとネットワーク・ドライバ・プラグインの場合は、複数のサブネットワークの作成をサポートしています。
docker network create -d overlay--subnet=192.168.0.0/16 --subnet=192.170.0.0/16--gateway=192.168.0.100 --gateway=192.170.0.100--ip-range=192.168.1.0/24--aux-address a=192.168.1.5 --aux-address b=192.168.1.6--aux-address a=192.170.1.5 --aux-address b=192.170.1.6
my-multihost-network
サブ・ネットワークが重複しないように気を付けてください。重複したらネットワークの作成に失敗し、エンジンはエラーを表⽰します。

- 137 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.7 ネットワークと接続⽤コマンド

ブ リッジ ・ドラ イバの オプショ ン
カスタム・ネットワークの作成時、デフォルトのネットワーク・ドライバ（例： bridge ）では追加のオプションを指定できます。以下のオプション指定は、 docker デーモンで docker0 ブリッジ⽤のフラグを指定するのと同
等です。
オプション

同等

com.docker.network.bridge.name－com.docker.network.bridge.enable_ip_masquerade
com.docker.network.bridge.enable_icc
com.docker.network.bridge.host_binding_ipv4
com.docker.network.bridge.mtu

説明Linux ブリッジを作成する時に使うブリッジ名--ip-masq IP マスカレードの有効化--icc
内部におけるコンテナの接続性を、有効化または無効化--ip
コンテナのポートをバインドする時の、
デフォルト IP アドレスを指定--mtu
コンテナのネットワーク MTU を指定

以下の引数は docker network create 実⾏時、あらゆるネットワーク・ドライバで指定できます。ほとんどがdocker daemon で指定する項⽬と同等です。
オプション

同等

説明

--geteway--ip-range--internal--ipv6--subnet－--ﬁxed-cidr－--ipv6--bip

マスタ・サブネットに対する IPv4 または IPv6 ゲートウェイ
範囲内で割り当てる IP アドレス
外部ネットワークに対する接続を制限
IPv6 ネットワーク機能を有効化
ネットワーク⽤のサブネット

例えば、ポート公開⽤に使う IP アドレスを割り当てるには、 -o か --opt オプションを使います。
docker network create -o "com.docker.network.bridge.host_binding_ipv4"="172.19.0.1" simple-network
内部 ネット ワー ク(internal)モー ド
コンテナを overlay ネットワークに接続する時、デフォルトでは外部への接続性を提供するためブリッジ・ネッ
トワークにも接続します。外部された隔離された overlay ネットワークを作成したい場合は、 --internal オプシ
ョンを使います。

- 138 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.7 ネットワークと接続⽤コマンド

デ ィ ス コ ネ ク ト

network disconnect
使い方: docker network disconnect [オプション] ネットワーク コンテナ
ネットワークからコンテナを切断-f, --force--help

ネットワークからコンテナを強制切断
使い方の表示コンテナをネットワークから切り離します（disconnect）。ネットワークから切り離すためには、コンテナを実⾏している必要があります。
$ docker network disconnect multi-host-network container1- 139 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.7 ネットワークと接続⽤コマンド

インスペクト

network inspect
使い方: docker network inspect [オプション] ネットワーク [ネットワーク..]
ネットワークの詳細情報を表示-f, --format=--helpgo テンプレートで指定したフォーマットで表示
使い方の表示１つまたは複数のネットワークの情報を返します。デフォルトでは、このコマンドは結果を JSON オブジェクト形式で返します。例えば、２つのコンテナをデフォルトの bridge ネットワークに接続します。
$ sudo docker run -itd --name=container1 busybox
f2870c98fd504370fb86e59f32cd0753b1ac9b69b7d80566ffc7192a82b3ed27$ sudo docker run -itd --name=container2 busybox
bda12f8922785d1f160be70736f26c1e331ab8aaf8ed8d56728508f2e2fd4727
network inspect コマンドで、その結果からコンテナの情報を確認します。ネットワーク・バックエンドがOverlay のようなマルチホスト・ネットワーク・ドライバの場合は、コマンドはクラスタ上の他のホストに対するコンテナのエンドポイントも表⽰します。これらのエンドポイントは “ ep-{エンドポイント-id}” として表⽰されます。あるいは、結果表⽰の時に別のフォーマットも指定できます。フォーマットの詳細は Go ⾔語の text/template
パッケージで指定します。
$ sudo docker network inspect bridge[{"Name": "bridge","Id": "b2b1a2cba717161d984383fd68218cf70bbbd17d328496885f7c921333228b0f","Scope": "local","Driver": "bridge","IPAM": {"Driver": "default","Config": [{"Subnet": "172.17.42.1/16","Gateway": "172.17.42.1"}]},"Internal": false,"Containers": {"bda12f8922785d1f160be70736f26c1e331ab8aaf8ed8d56728508f2e2fd4727": {"Name": "container2","EndpointID": "0aebb8fcd2b282abe1365979536f21ee4ceaf3ed56177c628eae9f706e00e019","MacAddress": "02:42:ac:11:00:02","IPv4Address": "172.17.0.2/16","IPv6Address": ""},"f2870c98fd504370fb86e59f32cd0753b1ac9b69b7d80566ffc7192a82b3ed27": {"Name": "container1","EndpointID": "a00676d9c91a96bbe5bcfb34f705387a33d7cc365bac1a29e4e9728df92d10ad","MacAddress": "02:42:ac:11:00:01","IPv4Address": "172.17.0.1/16",- 140 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.7 ネットワークと接続⽤コマンド"IPv6Address": ""}},"Options": {"com.docker.network.bridge.default_bridge": "true","com.docker.network.bridge.enable_icc": "true","com.docker.network.bridge.enable_ip_masquerade": "true","com.docker.network.bridge.host_binding_ipv4": "0.0.0.0","com.docker.network.bridge.name": "docker0","com.docker.network.driver.mtu": "1500"}}]
ユーザ定義ネットワークに関する詳細情報を返します。
$ docker network create simple-network
69568e6336d8c96bbf57869030919f7c69524f71183b44d80948bd3927c87f6a$ docker network inspect simple-network[{"Name": "simple-network","Id": "69568e6336d8c96bbf57869030919f7c69524f71183b44d80948bd3927c87f6a","Scope": "local","Driver": "bridge","IPAM": {"Driver": "default","Config": [{"Subnet": "172.22.0.0/16","Gateway": "172.22.0.1/16"}]},"Containers": {},"Options": {}}]- 141 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.7 ネットワークと接続⽤コマンド

network ls
使い方: docker network ls [オプション]
ユーザが作成した全てのネットワークを一覧-f, --filter=[]
指定した状況に応じて出力をフィルタ--help
使い方の表示--no-trunc
出力を省略 (truncate) しない-q, --quiet
整数値の ID のみ表示
Docker エンジンの daemon が把握している全てのネットワーク⼀覧を表⽰します。ネットワークには、複数のホストによるクラスタ上にまたがるネットワークも含まれます。
$ sudo docker network ls
NETWORK ID
NAME
7fca4eb8c647
bridge9f904ee27bf5
none
cf03ee007fb4
host
78b03ee04fc4
multi-host

DRIVER
bridgenull
hostoverlay--no-trunk オプションを使えば、完全なネットワーク ID を表⽰します。
docker network ls --no-trunc
NETWORK ID
18a2866682b85619a026c81b98a5e375bd33e1b0936a26cc497c283d27bae9b3
c288470c46f6c8949c5f7e5099b5b7947b07eabe8d9a27d79a9cbf111adcbf47
7b369448dccbf865d397c8d2be0cda7cf7edc6b0945f77d2529912ae917a0185
95e74588f40db048e86320c6526440c504650a1ff3e9f7d60a497c4d2163e5bd
63d1ff1f77b07ca51070a8c227e962238358bd310bde1529cf62e6c307ade161

NAME
none
host
bridgefoo
dev

DRIVERnull
host
bridgebridgebridgeフィ ルタリ ング
フィルタリング・フラグ（ -f または --filter）の書式は key=value のペアです。フィルタを何回もしたい場合
は、複数のフラグを使います（例： -filter "foo=bar" --filter "bif=baz" ）。複数のフィルタを指定したら、OR（同⼀条件）フィルタとして連結されます。例えば、 -f type=custom -f type=builtin は custom と builtin ネッ
トワークの両⽅を返します。
現時点でサポートしているフィルタは、次の通りです。

 ID（ネットワーク ID）
 ラベル（ label=<キー> または label=<キー>=<値> ） 名前（ネットワーク名）
 タイプ（custom|builtin）
id
id フィルタはネットワーク ID の⼀部もしくは全体と⼀致します。
以下のフィルタは、コンテナ ID が 63d1ff1f77b0...⽂字列に⼀致する全てのネットワークを表⽰します。
$ docker network ls --filter id=63d1ff1f77b07ca51070a8c227e962238358bd310bde1529cf62e6c307ade161
NETWORK ID
NAME
DRIVER
63d1ff1f77b0
dev
bridge- 142 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.7 ネットワークと接続⽤コマンド

次のように ID の部分⼀致でもフィルタできます。
$ docker network ls --filter id=95e74588f40d
NETWORK ID
NAME
DRIVER
95e74588f40d
foo
bridge$ docker network ls --filter id=95e
NETWORK ID
NAME
95e74588f40d
foo

DRIVER
bridgeラベル
label フィルタは label だけ、あるいは label と値に⼀致する条件でフィルタします。
以下のフィルタはラベルの値が usage に⼀致するネットワークを表⽰します。
$ docker network ls -f "label=usage"
NETWORK ID
NAME
db9db329f835
test1
f6e212da9dfd
test2

DRIVER
bridgebridge以下のフィルタは usage ラベルの値が prod の値に⼀致するコンテナを表⽰します。
$ docker network ls -f "label=usage=prod"
NETWORK ID
NAME
DRIVER
f6e212da9dfd
test2
bridge名前name フィルタはネットワーク名の⼀部もしくは全体に⼀致します。
以下のフィルタは foobar ⽂字列を含む全てのネットワーク名でフィルタします。
$ docker network ls --filter name=foobar
NETWORK ID
NAME
DRIVER
06e7eef0a170
foobarbridge
次のように、部分⼀致でもフィルタできます。
$ docker network ls --filter name=foo
NETWORK ID
NAME
95e74588f40d
foo
06e7eef0a170
foobar

DRIVER
bridgebridgeタイ プ
type フィルタは２つの値をサポートしています。builtin は定義済みネットワーク（bridge、none、host）を表⽰します。custom はユーザ定義ネットワークを表⽰します。
以下のフィルタはユーザ定義ネットワークを全て表⽰します。
$ docker network ls --filter type=custom
NETWORK ID
NAME
DRIVER
95e74588f40d
foo
bridge63d1ff1f77b0
dev
bridge- 143 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.7 ネットワークと接続⽤コマンド

このフラグを指定したら、バッチ処理でクリーンアップできます。例えば、全てのユーザ定義ネットワークを削除するには、次のようにします。
$ docker network rm `docker network ls --filter type=custom -q`
コンテナがアタッチされているネットワークを削除しようとしたら、警告が表⽰されます。

- 144 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.7 ネットワークと接続⽤コマンド

network rm
使い方: docker network rm [オプション] 名前|ID
ネットワークを削除--help

使い方の表示ネットワーク名か ID を指定して削除します。ネットワークを削除するには、接続中の全てのコンテナとの接続を切断しなくてはいけません。
$ docker network rm my-network
複数のネットワークを削除する場合は、docker network rm コマンドで複数のネットワーク名や ID を指定できます。以下の例はネットワーク ID 3695c422697f とネットワーク名 my-network を削除します。
$ docker network rm 3695c422697f my-network
複数のネットワークを指定すると、コマンドは削除したネットワークの情報を返します。もしも、あるネットワ
ークの情報削除に失敗すると、コマンドはリスト上の次にあるネットワークを削除しようとします。コマンドは削除に成功したか失敗したかを表⽰します。

- 145 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.8 共有データ・ボリューム⽤コマンド

A2.8 共有データ・ボリューム用コマンド
クリエイト

volume create
使い方: docker volume create [オプション]
ボリュームを作成-d, --driver=local--help--label=[]--name=-o, --opt=map[]

ボリューム・ドライバ名を指定
使い方の表示ボリューム用のメタデータを指定
ボリューム名を指定
ドライバ固有のオプションを指定

コンテナが利⽤し、データを保管するための新しいボリュームを作成します。名前を指定しなければ、Docker
はランダムな名称を⽣成します。ボリュームを作成し、コンテナが使えるようにするには、次の例のように実⾏します。
$ docker volume create --name hello
hello$ docker run -d -v hello:/world busybox ls /world
これはコンテナ内の /world ディレクトリにマウントを作成します。Docker はコンテナ内のマウントポイントに、
相対パスの指定をサポートしません。
複数のコンテナが同時に同じボリュームを利⽤できます。２つのコンテナが共有データにアクセスする場合に便利です。例えば、⼀⽅のコンテナがデータを書き込み、もう⼀⽅がデータを読み込めます。
ボリューム名はドライバ間でユニークである必要があります。つまり２つの異なったドライバで、同じボリュー
ム名を使うことはできません。実⾏しようとしても、docker はエラーを返します。
A volume named %s already exists with the %s driver. Choose a different volume name.
現在のドライバが既に使⽤しているボリューム名を指定する場合は、Docker は既存のボリュームを再利⽤するとみなし、エラーを返しません。

ド ライバ 固有の オプショ ン
ボリューム・ドライバによっては、ボリューム作成のカスタマイズのためにオプションが使えます。 -o か --opt
フラグでドライバにオプションを渡します。
$ docker volume create --driver fake --opt tardis=blue --opt timey=wimey
これらのオプションは各ボリューム・ドライバに直接渡されます。オプションはボリューム・ドライバごとに別々の動作をします（あるいは何もしないかもしれません）。
内部の local ボリューム・ドライバは、現時点ではオプションを受け付けません。

- 146 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.8 共有データ・ボリューム⽤コマンド

インスペクトvolume inspect
使い方: docker volume inspect [オプション] ボリューム [ボリューム...]ボリュームの低レベル情報を返す-f, --format=--help指定した go テンプレートの形式で出力
使い方の表示ボリュームに関する情報を返します。デフォルトでは、コマンドは JSON 配列の形式です。実⾏テンプレートを個々に指定し、別のフォーマットを指定できます。Go ⾔語の text/template パッケージに、フォーマットの詳細に関する全てが記述されています。
出⼒例：$ docker volume create
85bffb0677236974f93955d8ecc4df55ef5070117b0e53333cc1b443777be24d$ docker volume inspect 85bffb0677236974f93955d8ecc4df55ef5070117b0e53333cc1b443777be24d[{"Name": "85bffb0677236974f93955d8ecc4df55ef5070117b0e53333cc1b443777be24d","Driver": "local","Mountpoint":"/var/lib/docker/volumes/85bffb0677236974f93955d8ecc4df55ef5070117b0e53333cc1b443777be24d/_data","Status": null}]$ docker volume inspect --format '{{ .Mountpoint }}'85bffb0677236974f93955d8ecc4df55ef5070117b0e53333cc1b443777be24d/var/lib/docker/volumes/85bffb0677236974f93955d8ecc4df55ef5070117b0e53333cc1b443777be24d/_data- 147 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.8 共有データ・ボリューム⽤コマンド

volume ls
使い方: docker volume ls [オプション]
ボリュームの一覧-f, --filter=[]--help-q, --quiet

次の状況に応じて出力フィルタ:- dangling=<boolean> ボリュームが参照されているかどうか- driver=<string> ボリュームのドライバ名- name=<string> ボリューム名
使い方の表示ボリューム名のみ表示

Docker が把握している全てのボリュームを表⽰します。 -f か --filter フラグを使ってフィルタできます。利
⽤可能なフィルタ・オプションに関する情報は「フィルタリング」のセクションをご覧ください。
出⼒例：$ docker volume create --name roserose
$docker volume create --name tyler
tyler$ docker volume ls
DRIVER
VOLUME NAME
local
rose
local
tyler

フィ ルタリ ング
フィルタリング・フラグ（ -f か --filter）は「key=value」の形式です。フィルタが複数ある場合は、複数回指定します（例： --filter "foo=bar" --filter "bif=baz" ）。
現時点でサポートしているフィルタ： ダングリング（ブール値 - true か false か 0 か 1 ） ドライバ（ボリュームのドライバ名）
 名前（ボリューム名）
ダ ングリ ング
dangling フィルタはコンテナから参照されていない（dangling ＝宙ぶらりんな）ボリュームに⼀致します。
$ docker run -d -v tyler:/tmpwork busybox
f86a7dd02898067079c99ceacd810149060a70528eff3754d0b0f1a93bd0af18$ docker volume ls -f dangling=true
DRIVER
VOLUME NAME
local
rosemary
ドライバ
driver フィルタはボリュームのドライバ名の全てまたは⼀部に⼀致します。
以下のフィルタはドライバ名に local ⽂字列を含む全てのボリュームを表⽰します。
- 148 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.8 共有データ・ボリューム⽤コマンド$ docker volume ls -f driver=local
DRIVER
VOLUME NAME
local
rosemary
local
tyler
名前
name フィルタはボリューム名の全てまたは⼀部に⼀致します。
以下のフィルタはボリューム名に rose ⽂字列を含む全てのボリュームを表⽰します。
$ docker volume ls -f name=rose
DRIVER
VOLUME NAME
local
rosemary- 149 -

docs.docker.jp

16/05/20

Docker Engine ユーザガイド〜リファレンス編 v1.11 - beta1

A2.8 共有データ・ボリューム⽤コマンド

volume rm
使い方: docker volume rm [オプション] ボリューム [ボリューム...]ボリュームを削除--help=false

使い方の表示１つまたは複数のボリュームを削除できます。コンテナが使⽤中のボリュームは削除できません。
$ docker volume rm hello
hello- 150 -

docs.docker.jp

16/05/20

Appendix.3

3 Dockerﬁle リファレンス

Appendix.

A3.1 Dockerfile
Docker は Dockerfile から命令を読み込み、⾃動的にイメージを構築できます。Dockerfile はテキスト形式のドキュメントであり、コマンドライン上でイメージを作り上げる命令を全て記述します。ユーザは docker build を使い、複数のコマンド⾏の命令を順次実⾏し、イメージを⾃動構築します。
このセクションでは Dockerfile 内で利⽤可能な命令を説明します。セクションを読み終えたら、より便利に使うために「Dockerﬁle のベスト・プラクティス」のセクションもご覧ください。

使い方
docker build コマンドは Dockerfile とコンテクスト(context；イメージに含まれる「内容」の意味) に従ってイメージを構築します。構築⽤コンテクストとは、ファイルを⽰す PATH や URL の場所です。PATH はローカルのファ
イルシステム上のディレクトリです。URL は Git リポジトリの場所です。
コンテクストの処理は再帰的です。そのため、PATH にはサブディレクトリを含みます。また URL であればリポジ
トリと、そのサブモジュールも含みます。単に build コマンドを実⾏したら、現在のディレクトリをコンテクスト
として使います。
$ docker build .
Sending build context to Docker daemon 6.51 MB...
構築を処理するのは Docker デーモンであり、CLI ではありません。まずはじめの構築プロセスは、対象のコンテクスト（再帰的）をデーモンに送信することです。多くの場合、空のディレクトリをコンテクストとして使いますので、Dockerﬁle をそのディレクトリ設置できます。Dockerﬁle の構築に必要なファイルのみを（ディレクトリ
に）追加します。
【警告】PATH として⾃分のルート・ディレクトリ / を使わないでください。これは、⾃分のハードディスクに含まれる内容を、Docker デーモンに転送しようとするためです。

Dockerﬁle に記述した COPY 命令などで使うファイル指定を参照し、コンテクスト（内容物の意味）を構築します。
構築パフォーマンスを向上するためには、 .dockerignore ファイルにファイルやディレクトリを追加し、コンテク
スト・ディレクトリから除外できます。より詳しい情報は、「.dockerignore ファイルの作成」セクションををご覧ください。
伝統的に Dockerfile は、Dockerfile とコンテクストがあるルートの場所を⽰します。docker build 時に -f フ
ラグを使えば、システム上のどこに Dockerﬁle があるか指定できます。

- 151 -

docs.docker.jp

16/05/20

$ docker build -f /path/to/a/Dockerfile .
新しいイメージの構築に成功する時は、新しいイメージにリポジトリとタグを指定できます。
$ docker build -t shykes/myapp .
Docker デーモンは Dockerfile の命令を 1 ⾏ずつ実⾏し、必要があれば命令ごとにイメージをコミットし、最終的に新しいイメージ ID を出⼒します。Docker デーモンは送信したコンテクストを⾃動的に削除します。
各命令は独⽴して実⾏されるのでご注意ください。新しいイメージの作成時、RUN cd /tmp を実⾏したとしても、次の命令には何ら影響を与えません。
Docker は可能であればいつでも中間イメージ（キャッシュ）を再利⽤します。これは docker build 処理を速くするためです。コンソール出⼒に Using cache（キャッシュを利⽤中）の⽂字列が表⽰されます。より詳しい情報
は Dockerﬁle ベスト・プラクティス・ガイドの「構築キャッシュ」のセクションをご覧ください。
$ docker build -t svendowideit/ambassador .
Sending build context to Docker daemon 15.36 kB
Step 0 : FROM alpine:3.2---> 31f630c65071
Step 1 : MAINTAINER SvenDowideit@home.org.au---> Using cache---> 2a1c91448f5f
Step 2 : RUN apk update &&apk add socat &&rm -r /var/cache/---> Using cache---> 21ed6e7fbb73
Step 3 : CMD env | grep _TCP= | sed 's/.*_PORT_\([0-9]*\)_TCP=tcp:\/\/\(.*\):\(.*\)/socat -t 100000000
TCP4-LISTEN:\1,fork,reuseaddr TCP4:\2:\3 \&/' && echo wait) | sh---> Using cache---> 7ea8aef582cc
Successfully built 7ea8aef582cc
構築が終わったら、レジストリにリポジトリを送信する準備が整います。

書式
ここでは Dockerfile の書式を説明します。
# コメント命令 引数
命令（instruction）は⼤⽂字と⼩⽂字を区別しません。しかし引数（arguments）を簡単に⾒分けられるよう、⼤⽂字にするのが便利です。
Docker は Dockerfile の命令を順番に実⾏します。イメージ構築にあたりベース・イメージを指定するため、１行めの命令は「FROM」であるべきです。
Docker は # で始まる⾏をコメントとみなします。 # マークは⾏における移⾏の⽂字をコメントとみなします。
コメントは次のような書き⽅ができます。
# コメントRUN echo '何か良いものを # で実行しています'
ここでは、Dockerfile でイメージ構築時に利⽤可能な命令セットを紹介します。

環 境変数 の置き 換え- 152 -

docs.docker.jp

16/05/20

Dockerfile は環境変数（env 命令で宣⾔）も解釈できます。命令⽂字（ステートメント・リテラル）中では、変数の様な構⽂でエスケープ・シーケンスも扱えます。
Dockerfile の中では、環境変数を$variable_name または${variable_name}の形式で記述します。これらは同等に扱われます。固定⽤の構⽂として典型的に使われるのは、空⽩スペースを変数名に⼊れず${foo}_bar のような変数名で割り当てることです。
${変数の_名前} 構⽂は、次のような bash の変更をサポートしています。

 ${変数:-文字}は、変数を設定したら、その値を使うことを意味します。もし変数がセットされなければ、文字が設定されます。
 ${変数:+文字}は、変数を設定したら、文字を使います。変数がセットされなければ、空⽩のままにします。
いずれの場合でも、文字とは何らかの⽂字列であり、追加の環境変数を含みます。
エスケープするには \$foo や \${foo} のように、変数名の前に \ を付けます。例えば、 $foo と ${foo} リテ
ラルは別々のものです。
例（変数展開したものは、 # のあとに表⽰）：
FROM busybox
ENV foo /bar
WORKDIR ${foo} # WORKDIR /bar
ADD . $foo
# ADD . /bar
COPY \$foo /quux # COPY $foo /quux
以下の命令で Dockerﬁle における環境変数の利⽤がサポートされています。

 ADD
 COPY
 ENV
 EXPOSE LABEL USER WORKDIR
 VOLUME STOPSIGNAL
同様に、

 ONBLIUD （上記の命令と組み合わせて使う場合にサポートされます）
1.4 より前のバージョンでは、環境変数における ONBUILD 命令と上記の命令の組み合わせはサポー
トしていません。

環境変数を使う代わりに、各変数をコマンド上で利⽤できます。次の例を⾒ましょう。
ENV abc=hello
ENV abc=bye def=$abc
ENV ghi=$abc- 153 -

docs.docker.jp

16/05/20

この結果は、def の値が hello であり、bye ではありません。しかしながら ghi の値は bye になります。これは abc
を bye に設定するのと同じコマンド⾏ではないためです。

.dockerignore ファイル
docker CLI がコンテクストを docker デーモンに送る前に、コンテクストのルートディレクトリ内の.dockerignore ファイルを探します。もしファイルが存在していれば、CLI はコンテクストからパターンに⼀致するファイルとディレクトリを除外します。これは不必要に⼤きくならないようにします。また、取り扱いに注意が必要なファイルやディレクトリをデーモンに送らないようにします。ですが、ADD や COPY でイメージに追加されるかもしれません。
CLI は .dockerignore ファイルを⾏ごとに隔てて解釈します。⾏の⼀致パターンは Unix シェル上のものに似ています。パターンがコンテクストの root に⼀致すると考えられる場合は、root ディレクトリとして動作します。
例えば、パターン /foo/bar と foo/bar がある場合、いずれも PATH における foo サブディレクトリの bar ファイ
ルを削除します。あるいは URL の場所にある git のルートでもです。どちらでも除外されます。
これは .dockerignore ファイルの例です：*/temp**/*/temp*
temp?
このファイルは構築時に以下の動作をします。

 */temp* … ルート以下のあらゆるサブディレクトリを含め、temp で始まる名称のファイルとディレクトリ
を除外します。例えば、テキストファイル /somedir/temporary.txt は除外しますし、ディレクトリ
/somedir/temp も除外します。
 */*/temp* … ルートから２レベル以下の temp で始まる名称のファイルとディレクトリを除外します。例
えば /somedir/subdir/temporary.txt を除外します。
 temp? … ルートディレクトリにあるファイル名が temp と１⽂字⼀致するファイルとディレクトリを除外します。例えば、 /tempa と /tempb を除外します。
⼀致には Go ⾔語の ﬁlepath.Match*1 ルールを使います。処理前のステップでは、空⽩スペースと . と .. 要素を*2

Go ⾔語の ﬁlepath.Clean を⽤いて除外します。
⾏を !（エクスクラメーション・マーク）で始めたら、除外ルールとして使えます。以下の例は .dockerignore
ファイルでこの仕組みを使ったものです。
*.md!README.md
README.md を除く全てのマークダウンファイルが、コンテントから除外されます。
! 除外ルールが影響を与えるのは、 .dockerignore ファイルに書いた場所以降に⼀致するパターンが現れた時、含めるか除外するかを決めます。次の例で考えて⾒ましょう。
*.md!README*.md
README-secret.md* 1 h t t p : / / g o l a n g . o r g / p k g / p a t h / fi l e p a t h # M a t c h* 2 h t t p : / / g o l a n g . o r g / p k g / p a t h / fi l e p a t h / # C l e a n- 154 -

docs.docker.jp

16/05/20

README を含むファイル以外は、README-secret.md も含め、残り全てのマークダウンファイルが除外対象です。
その次の例を考えましょう。
*.md
README-secret.md!README*.md
README を含む全てのファイル除外します。真ん中の⾏ README-secret.md は最終⾏の !README*.md に⼀致するため、何の影響もありません。
.dockerignore ファイルは Dockerﬁle と .dockerignore ファイルの除外にも使えます。それでも、これらのファ
イルはジョブを処理するためデーモンに送信されます。しかし ADD と COPY コマンドは、これらをイメージ内にコ
ピーしません。
最後に、特定のファイルのみコンテクストに含め、他を除外したい場合があるでしょう。実⾏するには、始めに*パターンに指定し、以下１つまたは複数の ! 例外パターンを記述します。
歴史的な理由により、 . パターンは無視されます。

- 155 -

docs.docker.jp

16/05/20

A3.2 Dockerﬁle 命令
フ ロ ム

FROM
FROM <イメージ>または
FROM <イメージ>:<タグ>
またはFROM <イメージ>@<digest>
FROM 命令は、以降の命令で使うベース・イメージを指定します。あるいは、有効な Dockerfile は、１⾏めを FROM
命令で指定する必要があります。イメージとは、あらゆる有効なものが利⽤できます。パブリック・リポジトリからイメージを取得する⽅法が⼀番簡単です。

 Dockerfile では、コメント以外では FROM を⼀番始めに書く必要があります。
 単⼀の Dockerfile から複数のイメージを作成するため、複数の FROM を指定できます。各 FROM 命令ごとに⾃動的にコミットし、最新のイメージ ID が出⼒されるのを覚えておいてください。
 タグや digest 値はオプションです。省略した場合、ビルダーはデフォルトの latest とみなします。ビル
ダーは⼀致する tag 値が無ければエラーを返します。

- 156 -

docs.docker.jp

16/05/20

メ

ン

テ

ナ

MAINTAINER
MAINTAINER <名前>
MAINTAINER 命令は、⽣成するイメージの Author（作者フィールドを指定します。

- 157 -

docs.docker.jp

16/05/20

ラ

ン

RUN
RUN には２つの形式があります。

 RUN <コマンド>（シェル形式、コマンドをシェル /bin/sh -c で実⾏する）
 RUN ["実行バイナリ", "パラメータ１", "パラメータ２"] （exec 形式）
RUN 命令は既存イメージ上の新しいレイヤで、あらゆるコマンドを実⾏し、その結果をコミットする命令です。
コミットの結果得られたイメージは、Dockerfile の次のステップで使われます。
RUN 命令の積み重ねとコミットによるイメージ⽣成は、Docker の中⼼となるコンセプト（概念）に従ったものです。コミットは簡単であり、ソース・コントロールのように、イメージの履歴上のあらゆる場所からコンテナを作成可能です。
exec 形式はシェルの⽂字列を変更できないようにします。また、 /bin/sh がベース・イメージに含まれなくても RUN コマンドを使えます。
シェル形式では、RUN 命令を \（バックスラッシュ）を使い、次の⾏と連結します。例えば、次の２⾏があるとします。
RUN /bin/bash -c 'source $HOME/.bashrc ;\echo $HOME'
これは、次のように１⾏にできます。
RUN /bin/bash -c 'source $HOME/.bashrc ; echo $HOME'「/bin/sh/」以外のシェルを使いたい場合は、exec 形式で任意のシェルを指定します。例： RUN["/bin/bash", "-c", "echo hello"] 。

exec 形式は JSON 配列でパースされます。つまり、⽂字を囲むのはシングル・クォート(ʻ) ではな
くダブル・クォート(”)を使う必要があります。

シェル形式と異なり、exec 形式はコマンド・シェルを呼び出しません。つまり、通常のシェルによる処理が⾏われません。例えば RUN [ "echo", "$HOME" ] は $HOME の変数展開を⾏いません。シ
ェルによる処理を⾏いたい場合は、シェル形式を使うか、あるいはシェルを直接指定します。例：RUN [ "sh", "-c", "echo", "$HOME" ] 。

次の構築時、RUN 命令によるキャッシュは⾃動的に無効化できません。RUN apt-get dist-upgrade -y のような命令のキャッシュがあれば、次の構築時に再利⽤されます。RUN 命令でキャッシュを使いたくない場合は、--no-cache フラグを使います。例： docker build --no-cache .
RUN 命令のキャッシュは、ADD 命令によって無効化されます。詳細は「ADD」命令のセクションをご覧ください。

既 知の問 題(RUN)
Issue 783*1 は、AUFS ファイルシステム使⽤時、ファイルのパーミッションに関する問題が起こり得ます。例え*1 https://github.com/docker/docker/issues/783- 158 -

docs.docker.jp

16/05/20

ば、ファイルを rm しようとする場合は注意が必要です。
最近の aufs バージョンを使っているシステムでは（例：dirperm1 マウント・オプションが利⽤可能 ）、docker
は dirperm1 オプションのレイヤをマウント時、⾃動的に問題を修正しようとします。dirperm1 オプションに関する詳細は、aufs man ページ*1 をご覧ください。
システムが dirperm1 をサポートしていない場合は、issue に回避⽅法があります。

*1 http://aufs.sourceforge.net/aufs3/man.html- 159 -

docs.docker.jp

16/05/20

CMD
CMD には３つの形式があります。

 CMD ["実行バイナリ", "パラメータ１", "パラメータ２"] （exec 形式、推奨する形式）
 CMD ["パラメータ１", "パラメータ２"] （ENTRYPOINT のデフォルト・パラメータ）
 CMD <コマンド> （シェル形式）
Dockerfile で CMD 命令を⼀度だけ指定できます。複数の CMD がある場合、最も後ろの CMD のみ有効です。
CMD の主な⽬的は、コンテナ実行時のデフォルトを提供します。デフォルトには、実⾏可能なコマンドが含まれているか、あるいは省略されるかもしれません。省略時は ENTRYPOINT 命令で同様に指定する必要があります。
ENTRYPOINT 命令のデフォルトの引数として CMD を使う場合、CMD と ENTRYPOINT 命令の両⽅がJSON 配列フォーマットになっている必要があります。

exec 形式は JSON 配列でパースされます。つまり、⽂字を囲むのはシングル・クォート(ʻ) ではな
くダブル・クォート(”)を使う必要があります。

シェル形式と異なり、exec 形式はコマンド・シェルを呼び出しません。つまり、通常のシェルによる処理が⾏われません。例えば CMD [ "echo", "$HOME" ] は $HOME の変数展開を⾏いません。シ
ェルによる処理を⾏いたい場合は、 シェル 形式を使うか、あるいはシェルを直接使います。例： CMD [ "sh", "-c", "echo", "$HOME" ] 。

シェルあるいは exec 形式を使う時、CMD 命令はイメージで実⾏するコマンドを指定します。
CMD をシェル形式を使えば、 <コマンド> は /bin/sh -c で実⾏されます。
FROM ubuntu
CMD echo "This is a test." | wc <コマンド>をシェルを使わずに実行したい場合、コマンドを JSON 配列で記述し、実⾏可能なフルパスで指定する必要があります。配列の形式が CMD では望ましい形式です 。あらゆる追加パラメータは個々の配列の⽂字列として指定する必要があります。
FROM ubuntu
CMD ["/usr/bin/wc","--help"]
もしコンテナで毎回同じものを実⾏するのであれば、CMD と ENTRYPOINT の使⽤を検討ください。詳細はENTRYPOINT をご覧ください。
ユーザが docker run で引数を指定した時、これらは CMD で指定したデフォルトを上書きします。
RUN と CMD を混同しないでください。RUN が実際に⾏っているのは、コマンドの実⾏と結果のコミットです。⼀⽅の CMD は構築時には何もしませんが、イメージで実⾏するコマンドを指定します。

- 160 -

docs.docker.jp

16/05/20

ラ

ベ

ル

LABEL
LABEL <key>=<value> <key>=<value> <key>=<value> ...
LABEL 命令はイメージにメタデータを追加します。LABEL はキーとバリューのペアです。LABEL の値に空⽩スペー
スを含む場合はクォートを使いますし、コマンドラインの分割にバックスラッシュを使います。使⽤例：
LABEL "com.example.vendor"="ACME Incorporated"
LABEL com.example.label-with-value="foo"
LABEL version="1.0"
LABEL description="This text illustrates \that label-values can span multiple lines."
イメージは複数のラベルを持てます。複数のラベルを指定したら、 Docker は可能であれば１つの LABEL にすることをお勧めします。各 LABEL 命令は新しいレイヤを準備しますが、多くのラベルを使えば、それだけレイヤを使います。次の例は１つのイメージ・レイヤを使うものです。
LABEL multi.label1="value1" multi.label2="value2" other="value3"
上記の例は、次のようにも書き換えられます。
LABEL multi.label1="value1" \multi.label2="value2" \other="value3"
ラベルには、FROM イメージが使う LABEL も含まれています。ラベルのキーが既に存在している時、Docker は特定のキーを持つラベルの値を上書きします。
イメージが使っているラベルを確認するには、docker inspect コマンドを使います。
"Labels": {"com.example.vendor": "ACME Incorporated""com.example.label-with-value": "foo","version": "1.0","description": "This text illustrates that label-values can span multiple lines.","multi.label1": "value1","multi.label2": "value2","other": "value3"},- 161 -

docs.docker.jp

16/05/20

エクスポーズ

EXPOSEEXPOSE <port> [<port>...]EXPOSE 命令は、特定のネットワーク・ポートをコンテナが実⾏時にリッスンすることを Docker に伝えます。
EXPOSE があっても、これだけではホストからコンテナにアクセスできるようにしません。アクセスするには、 -p
フラグを使ってポートの公開範囲を指定するか、 -P フラグで全ての露出ポートを公開する必要があります。外部への公開時は他のポート番号も利⽤可能です。
ホストシステム上でポート転送を使うには、docker run リファレンスをご覧ください。Docker のネットワーク
機能は、ネットワーク内でポートを公開しないネットワークを作成可能です。詳細な情報はユーザガイドをご覧ください。

- 162 -

docs.docker.jp

16/05/20

エンブ

ENV
ENV <key> <value>
ENV <key>=<value> ...
ENV 命令は、環境変数 <key> と値 <value> のセットです。値は Dockerfile から派⽣する全てのコマンド環境で利⽤でき、インラインで置き換えも可能です。
ENV 命令は２つの形式があります。１つめは、ENV <key> <value> であり、変数に対して１つの値を設定します。
はじめの空⽩以降の⽂字列が <value> に含まれます。ここには空⽩もクォートも含まれます。
２つめの形式は ENV <key>=<value> ... です。これは⼀度に複数の変数を指定できます。先ほどと違い、構⽂の２つめにイコールサイン（=）があるので気を付けてください。コマンドラインの分割、クォート、バックスラッ
シュは、空⽩スペースも含めて値になります。
例：
ENV myName="John Doe" myDog=Rex\ The\ Dog \myCat=fluffy
そしてENV myName John Doe
ENV myDog Rex The Dog
ENV myCat fluffy
この例では、どちらも最終的に同じ結果をコンテナにもたらしますが、私たちが推奨するのは前者です。理由は前者であれば単⼀のキャッシュ・レイヤしか使わないからです。
環境変数の設定に ENV を使えば、作成したイメージを使ってコンテナを実⾏しても有効です。どのような値が設定されているかは docker inspect で確認でき、変更するには docker run --env <key>=<value> を使います。
環境変数の⼀貫性は予期しない影響を与える場合があります。例えば、ENV DEBIAN_FRONTEND
noninteractive が設定されていると、Debian ベースのイメージで apt-get の利⽤者が混乱するかもしれません。１つのコマンドだけで値を設定するには、RUN <key>=<value> <コマンド> を使います。

- 163 -

docs.docker.jp

16/05/20

ア ッ ドADD
Add は２つの形式があります。

 ADD <ソース>... <送信先>
 ADD ["<ソース>", ... "<送信先>"]（この形式はパスに空⽩スペースを使う場合に必要）
ADD 命令は <ソース> にある新しいファイルやディレクトリをコピー、あるいはリモートの URL からコピーします。それから、コンテナ内のファイルシステム上にある送信先に指定されたパスに追加します。
複数の <ソース> リソースを指定できます。この時、ファイルやディレクトリはソースディレクトリ（構築時のコンテクスト）からの相対パス上に存在しないと構築できません。
それぞれの <ソース> にはワイルドカードと Go ⾔語の ﬁlepath.Mach ルールに⼀致するパターンが使えます。例
えば、次のような記述です。
ADD hom* /mydir/
ADD hom?.txt /mydir/# "hom" で始まる全てのファイルを追加# ? は１文字だけ一致します。例： "home.txt"<送信先> は絶対パスです。あるいは、パスは WORKDIR からの相対パスです。ソースにあるものが、対象となる
送信先コンテナの中にコピーされます。
ADD test relativeDir/
ADD test /absoluteDir/# "test" を `WORKDIR`/relativeDir/ （相対ディレクトリ）に追加# "test" を /absoluteDir/ （絶対ディレクトリ）に追加追加される新しいファイルやディレクトリは、全て UID と GID が 0 として作成されます。
<ソース> がリモート URL の場合は、送信先のパーミッションは 600 にします。もしリモートのファイルが HTTP
Last-Modified ヘッダを返す場合は、このヘッダの情報を元に送信先ファイルの mtime を指定するのに使います。
しかしながら、ADD を使ったファイルをコピーする⼿順では、mtime はファイルが更新されたかどうかの決定には使われず、ファイルが更新されればキャッシュも更新されます。
Dockerfile を標準⼊⼒（ docker build - < 何らかのファイル ）を通して構築しようとしても。構
築時のコンテントは存在しないため、Dockerfile には URL を指定する ADD 命令のみ記述可能です。
また、圧縮ファイルを標準⼊⼒（ docker build - < archive.tar.gz ）を通すことができ、アーカ
イブに含まれるルートに Dockerfile があれば、構築時のコンテクストとしてアーカイブが使われます。
URL で指定したファイルに認証がかかっている場合は、RUN wget や RUN curl や他のツールを使う必要があります。これは ADD 命令が認証機能をサポートしていないからです。

ADD 命令の処理時、まず <ソース> に含まれる内容が変更されていれば、以降の Dockerfile に書かれている命令のキャッシュを全て無効化します。これは RUN 命令のキャッシュ無効化も含まれます。より詳細な情報については Dockerfile のベスト・プラクティス・ガイドをご覧ください。

ADD は以下のルールに従います。

 <ソース> パスは、構築時のコンテント内にある必要があります。そのため、ADD ../something /somethingの指定はできません。docker build の最初のステップで、コンテクストのディレクトリ（と、サブディレクトリ）を docker デーモンに送るためです。
 <ソース> が URL であり、 <送信先> の末尾にスラッシュが無い場合、URL からファイルをダウンロード- 164 -

docs.docker.jp

16/05/20

し、 <送信先> にコピーします。
 もし <ソース> が URL であり、 <送信先> の末尾がスラッシュの場合、URL からファイル名を推測し、ファイルを <送信先>/<ファイル名> にダウンロードします。例えば、ADD http://example.com/foobar / は、
/foobar ファイルを作成します。URL には何らかのパスが必要です。これは適切なファイル名を⾒つけられない場合があるためです（今回の例では、http://example.com の指定は動作しません）。
 <ソース> がディレクトリの場合、ディレクトリの内容の全てをコピーします。これにはファイルシステムのメタデータを含みます。
ディレクトリ⾃⾝はコピーされません。ディレクトリは単なるコンテントの⼊れ物です。

 もし <ソース> がローカルにある tar アーカイブの場合、圧縮フォーマットを認識します（gzip、bzip2、xzを認識）。それからディレクトリに展開します。 リモートの URL が指定された場合は展開しません。ディ
レクトリにコピーまたは展開する時は、 tar -x と同じ働きをします。結果は次の処理を同時に⾏います。
1. 送信先のパスが存在しているかどうか
2. ファイル単位の原則に従って、ソース・ツリーの内容と衝突しないかどうか「2」を繰り返す
ファイルが圧縮フォーマットと認識するか、あるいはファイルの集まりをベースにしているのかは、ファイルの名前では判断しません。例えば、空のファイル名の拡張⼦が .tar.gz だとしても、圧縮ファイルと認識しないため、展開エラーのメッセージを表⽰しません。そして単純に送信先にファイルをコピーします。

 もし <ソース> がファイル以外であれば、個々のメタデータと⼀緒にコピーします。 <送信先> の末尾がスラッシュ / で終わる場合は、ディレクトリであるとみなし、 <ソース> の内容を <送信先>/base(<ソース>)に書き込みます。
 もし複数の <ソース> リソースが指定された場合や、ディレクトリやワイルドカードを使った場合、 <送
信先> は必ずディレクトリになり、最後はスラッシュ / にしなければいけません。
 もし <送信先> の末尾がスラッシュで終わらなければ、通常のファイルとみなされ、 <ソース> の内容は <送信先> として書き込まれます。
 <送信先> が存在しなければ、パスに存在しないディレクトリを作成します。

- 165 -

docs.docker.jp

16/05/20

コ ピ ー

COPY
COPY は２つの形式があります。

 COPY <ソース>... <送信先> COPY ["<ソース>",... "<送信先>"] （この形式はパスに空⽩スペースを使う場合に必要）
COPY 命令は <ソース> にある新しいファイルやディレクトリをコピーするもので、コンテナ内のファイルシステ
ム上にある <送信先> に指定されたパスに追加します。
複数の <ソース> リソースを指定できます。この時、ソースディレクトリ（構築時のコンテクスト）からの相対
パス上に存在しないと構築できません。
それぞれの <ソース> にはワイルドカードと Go ⾔語の ﬁlepath.Mach ルールに⼀致するパターンが使えます。例
えば、次のような記述です。
COPY hom* /mydir/
COPY hom?.txt /mydir/# "hom" で始まる全てのファイルを追加# ? は１文字だけ一致します。例： "home.txt"<送信先> は絶対パスです。あるいは、パスは WORKDIR からの相対パスです。ソースにあるものが、対象となる
送信先コンテナの中にコピーされます。
COPY test relativeDir/ # "test" を `WORKDIR`/relativeDir/ （相対ディレクトリ）に追加
COPY test /absoluteDir/ # "test" を /absoluteDir/ （絶対ディレクトリ）に追加追加される新しいファイルやディレクトリは、全て UID と GID が 0 として作成されます。
標準⼊⼒（ docker build - < 何らかのファイル ）を使って構築しようとしても、構築時のコンテントは存在しないため、 COPY を使えません。

COPY は以下のルールに従います。

 <ソース> パスは、構築時のコンテント内にある必要があります。そのため、 COPY ../something /somethingの指定はできません。docker build の最初のステップで、コンテクストのディレクトリ（と、サブディレクトリ）を docker デーモンに送るためです。
 <ソース> がディレクトリの場合、ディレクトリ内容の全てをコピーします。これにはファイルシステムのメタデータを含みます。
ディレクトリ⾃⾝はコピーしません。ディレクトリは単なるコンテントの⼊れ物です。

 もし <ソース> がファイル以外であれば、個々のメタデータと⼀緒にコピーします。 <送信先> の末尾がスラッシュ / で終わる場合は、ディレクトリであるとみなし、 <ソース> の内容を <送信先>/base(<ソース>)に書き込みます。
 もし複数の <ソース> リソースが指定された場合や、ディレクトリやワイルドカードを使った場合、 <送
信先> は必ずディレクトリになり、最後はスラッシュ / にしなければいけません。
 もし <送信先> の末尾がスラッシュで終わらなければ、通常のファイルとみなされ、 <ソース> の内容は <送信先> として書き込まれます。
 <送信先> が存在しなければ、パスに存在しないディレクトリを作成します。

- 166 -

docs.docker.jp

16/05/20

エ ン ト リ ポ イ ン ト

ENTRYPOINT
ENTRYPOINT には２つの形式があります。

 ENTRYPOINT ["実行可能なもの", "パラメータ１", "パラメータ２"] （exec 形式、推奨）
 ENTRYPOINT コマンド パラメータ１ パラメータ２ （シェル形式）
ENTRYPOINT はコンテナが実⾏するファイルを設定します。
例えば、次の例は nginx をデフォルトの内容で開始し、ポート 80 を開きます。
docker run -i -t --rm -p 80:80 nginx
コマンドラインで docker run <イメージ> コマンドに引数を付けますと、exec 形式の ENTRYPOINT で指定した全要素の後に追加します。そして、この時に CMD を使って指定していた要素を上書きします。この動きにより、引数はエントリ・ポイント（訳者注：指定されたバイナリ）に渡されます。例えば、docker run <イメージ> -d は、引数 -d をエントリ・ポイントに渡します。ENTRYPOINT 命令を上書きするには、 docker run --entrypoint フラグを使います。
シェル形式では CMD や run コマンド⾏の引数を使えないという不利な点があります。ENTRYPOINT は /bin/sh -cのサブコマンドとして実⾏されるため、シグナルを渡せません。つまり、何かを実⾏してもコンテナの PID 1 にはなりません。そして、Unix シグナルを受け付けません。そのため、実⾏ファイルは docker stop <コンテナ> を実⾏しても、SIGTERM を受信しません。
なお、Dockerfile の最後に現れた ENTRYPOINT 命令のみ有効です。

exec 形 式の ENTRYPOINT 例ENTRYPOINT の exec 形式を使い、適切なデフォルトのコマンドと引数を指定します。それから CMD を使い、変更する可能性のある追加のデフォルト引数も指定します。
FROM ubuntu
ENTRYPOINT ["top", "-b"]CMD ["-c"]コンテナを実⾏したら、top のプロセスが１つだけ⾒えます。
$ docker run -it --rm --name test top -H
top - 08:25:00 up 7:27, 0 users, load average: 0.00, 0.01, 0.05
Threads: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie%Cpu(s): 0.1 us, 0.1 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 2056668 total, 1616832 used, 439836 free,
99352 buffers
KiB Swap: 1441840 total,
0 used, 1441840 free. 1324440 cached Mem
PID USER
1 root

PR NI
20 0

VIRT
19744

RES
2336

SHR S %CPU %MEM
2080 R 0.0 0.1

TIME+ COMMAND
0:00.04 top

より詳細なテストをするには、docker exec コマンドが使えます。
$ docker exec -it test ps aux
USER
PID %CPU %MEM
VSZ RSS TTY
root
1 2.6 0.1 19752 2352 ?
root
7 0.0 0.1 15572 2164 ?

STAT STARTSs+ 08:24
R+ 08:25- 167 -

TIME COMMAND
0:00 top -b -H
0:00 ps aux

docs.docker.jp

16/05/20

それから、docker stop test を使い top を停⽌するよう、通常のリクエストを⾏えます。
次の Dockerfile は ENTRYPOINT を使って Apache をフォアグラウンドで実⾏します（つまり、PID 1 として）。
FROM debian:stable
RUN apt-get update && apt-get install -y --force-yes apache2
EXPOSE 80 443
VOLUME ["/var/www", "/var/log/apache2", "/etc/apache2"]
ENTRYPOINT ["/usr/sbin/apache2ctl", "-D", "FOREGROUND"]
もし実⾏するだけの起動スクリプトを書く必要があれば、最後に実⾏するコマンドが Unix シグナルを受信できるよう、exec と gosu コマンドを使うことで可能になります。
#!/bin/bash
set -eif [ "$1" = 'postgres' ]; thenchown -R postgres "$PGDATA"
if [ -z "$(ls -A "$PGDATA")" ]; thengosu postgres initdb
fiexec gosu postgres "$@"
fi
exec "$@"
もしも、シャットダウン時に何らかの追加クリーンアップ（あるいは、他のコンテナとの通信）が必要な場合や、１つ以上の実⾏ファイルと連携したい場合は、ENTRYPOINT のスクリプトが Unix シグナルを受信できるようにし、それを使って様々な処理を⾏います。
#!/bin/sh# メモ：これは sh を使っていますので、busyboy コンテナでも動きます# サービス停止時に手動でもクリーンアップが必要な場合は trap を使います。
# あるいは１つのコンテナ内に複数のサービスを起動する必要があります。
trap "echo TRAPed signal" HUP INT QUIT KILL TERM
# ここからバックグラウンドでサービスを開始します/usr/sbin/apachectl startecho "[hit enter key to exit] or run 'docker stop <container>'"read# ここからサービスを停止し、クリーンアップしますecho "stopping apache"/usr/sbin/apachectl stopecho "exited $0"
このイメージを docker run -it --rm -p 80:80 --name test apache で実⾏したら、コンテナのプロセス状態を
docker exec や docker top で調べられます。それから、スクリプトに Apache 停⽌を依頼します。

- 168 -

docs.docker.jp

16/05/20

$ docker exec -it test ps aux
USER
PID %CPU %MEM
VSZ RSS TTYSTAT START TIME COMMAND
root
1 0.1 0.0 4448 692 ?
Ss+ 00:42 0:00 /bin/sh /run.sh 123 cmd cmd2
root
19 0.0 0.2 71304 4440 ?
Ss 00:42 0:00 /usr/sbin/apache2 -k start
www-data
20 0.2 0.2 360468 6004 ?
Sl 00:42 0:00 /usr/sbin/apache2 -k start
www-data
21 0.2 0.2 360468 6000 ?
Sl 00:42 0:00 /usr/sbin/apache2 -k startroot
81 0.0 0.1 15572 2140 ?
R+ 00:44 0:00 ps aux$ docker top test
PID
USER
COMMAND
10035
root{run.sh} /bin/sh /run.sh 123 cmd cmd2
10054
root
/usr/sbin/apache2 -k start
10055
33/usr/sbin/apache2 -k start
10056
33/usr/sbin/apache2 -k start$ /usr/bin/time docker stop test
test
real 0m 0.27s
user 0m 0.03s
sys 0m 0.03s

ENTRYPIONT 設定は --entrypoint を使って上書きできますが、設定できるのはバイナリが実⾏可能な場合のみです（ sh -c が使われていない時のみ ）。

exec 形式は JSON 配列でパースされます。つまり、語句はシングルクォート(ʻ)ではなく、ダブルクォート(”)で囲む必要があります。

シェル 形式とは異なり、exec 形式はシェルを呼び出しません。つまり、通常のシェル上の処理はされません。例えば、ENTRYPOINT ["echo", "$HOME"] は $HOME を変数展開しません。シェル上の処理が必要であれば、 シェル 形式を使うか、シェルを直接実⾏します。例： ENTRYPOINT [ "sh","-c", "echo", "$HOME" ]。変数は Dockerfile で ENV を使って定義することができ、Dockerfile パーサー上で展開されます。

シェ ル形式 の ENTRYPOINT 例ENTRYPOINT に⽂字列を指定したら、 /bin/sh -c で実⾏されます。この形式はシェルの処理を使いますので、シェル上の環境変数を展開し、CMD や docker run コマンド⾏の引数を無視します。docker stop で ENTRYPOINT で指定している実⾏ファイルにシグナルを送りたい場合は、exec を使う必要があるのを思い出してください。
FROM ubuntu
ENTRYPOINT exec top -b
このイメージを実⾏したら、単⼀の PID 1 プロセスが表⽰されます。
$ docker run -it --rm --name test top
Mem: 1704520K used, 352148K free, 0K shrd, 0K buff, 140368121167873K cachedCPU: 5% usr 0% sys 0% nic 94% idle 0% io 0% irq 0% sirq
Load average: 0.08 0.03 0.05 2/98 6
PID PPID USERSTAT VSZ %VSZ %CPU COMMAND
10 rootR
3164 0% 0% top -b
終了するには、docker stop を実⾏します。
- 169 -

docs.docker.jp

16/05/20

$ /usr/bin/time docker stop test
test
real
0m 0.20s
user
0m 0.02s
sys 0m 0.04s
ENTRYPOINT に exec を追加し忘れたとします。
FROM ubuntu
ENTRYPOINT top -b
CMD --ignored-param1
次のように実⾏します（次のステップで名前を使います）。
$ docker run -it --name test top --ignored-param2
Mem: 1704184K used, 352484K free, 0K shrd, 0K buff, 140621524238337K cachedCPU: 9% usr 2% sys 0% nic 88% idle 0% io 0% irq 0% sirq
Load average: 0.01 0.02 0.05 2/101 7
PID PPID USERSTAT VSZ %VSZ %CPU COMMAND
10 rootS3168 0% 0% /bin/sh -c top -b cmd cmd2
7
1 rootR
3164 0% 0% top -b
top の出⼒から、ENTRYPOINT が PID 1 ではないことが分かるでしょう。
それから docker stop test を実⾏しても、コンテナはすぐに終了しません。これは stop コマンドがタイムアウ
ト後、SIGKILL を強制送信したからです。
$ docker exec -it test ps aux
PID USERCOMMAND
1 root/bin/sh -c top -b cmd cmd2
7 roottop -b8 rootps aux$ /usr/bin/time docker stop test
test
real
0m 10.19s
user
0m 0.04s
sys 0m 0.03s

CMD と ENTRYPOINT がどの ように 作用するか学 ぶ
CMD と ENTRYPOINT 命令はコンテナ起動時に実⾏するコマンドを定義します。両⽅を記述する時、動作には複数のルールがあります。
1. Dockerfile には少なくとも１つの CMD または ENTRYPOINT 命令を含むべきです。
2. ENTRYPOINT は実⾏可能なコンテナとして定義する時に使うべきです。
3. コンテナをアドホック（その場その場）で実⾏するコマンドを ENTRYPOINT にする場合、そのデフォルトの引数の指定として CMD を指定すべきです。
4. CMD はコンテナ実⾏時に引数を指定すると上書きします。

- 170 -

docs.docker.jp

16/05/20

以下の表は ENTRYPOINT / CMD を組み合わせたコマンドの実⾏結果です。

ENTRYPOINT なし

ENTRYPOINT exec_entry p1_entry

NTRYPOINT ["exec_entry", "p1_entry"]

CMD なしエラー。実行できない/bin/sh -c exec_entry p1_entry

exec_entry p1_entry

CMD ["exec_cmd","p1_cmd"]

exec_cmd p1_cmd/bin/shp1_entry

exec_entry p1_entry exec_cmd p1_cmd

exec_entry

p1_entry

exec_entry p1_entry p1_cmd p2_cmd

exec_entry

p1_entry-cexec_entry

exec_cmd p1_cmd
CMD ["p1_cmd", "p2_cmd"]

p1_cmd p2_cmd/bin/sh-c

p1_cmd p2_cmd
CMD exec_cmd p1_cmd/bin/sh -c exec_cmd p1_cmd/bin/sh-c/bin/sh -c exec_cmd p1_cmd- 171 -

exec_entry p1_entry /bin/sh -c exec_cmd
p1_cmddocs.docker.jp

16/05/20

ボ リ ュ ー ム

VOLUMEVOLUME ["/data"]
VOLUME 命令は指定した名前でマウントポイントを作成し、他のホストやコンテナから外部マウント可能なボリュームにします。指定する値は VOLUME ["/var/log"] といった JSON 配列になるべきです。あるいは⽂字列でVOLUME /var/log や VOLUME /var/log /var/db のように、複数の引数を書くこともできます。Docker クライアントを使ったマウント命令や詳しい情報やサンプルは「ボリュームを経由してディレクトリを共有」のセクションをご覧ください。
docker run コマンドは、ベース・イメージから指定した場所に、データを保存する場所として新規作成したボリ
ュームを初期化します。例えば、次の Dockerﬁle をご覧ください。
FROM ubuntu
RUN mkdir /myvol
RUN echo "hello world" > /myvol/greeting
VOLUME /myvol
この Dockerﬁle によって作られたイメージは、docker run を実⾏したら、新しいマウント・ポイント /myvol を作成し、greeting ファイルを直近で作成したボリュームにコピーします。
構築ステップでボリューム内においてあらゆる変更を加えても、宣⾔後に内容は破棄されます。

リストは JSON 配列でパースされます。これが意味するのは、単語はシングルクォート(ʻ)で囲むのではなく、ダブルクォート(”)を使う必要があります。

- 172 -

docs.docker.jp

16/05/20

ユ ー ザUSER
USER daemon
USER 命令セットはユーザ名か UID を使います。これはイメージを RUN、CMD、ENTRYPOINT 命令で実⾏時のものであり、Dockerfile で指定します。

- 173 -

docs.docker.jp

16/05/20

ワー ク ディ レ クト リ

WORKDIR
WORKDIR /path/to/workdir
WORKDIR 命令セットは Dockerfile で RUN、CMD、ENTRYPOINT、COPY、ADD 命令実⾏時の作業ディレクトリ（working
directory）を指定します。もし WORKDIR が存在しなければ、Dockerfile 命令内で使⽤しなくてもディレクトリを作成します。
１つの Dockerfile で複数回の利⽤が可能です。パスを指定したら、WORKDIR 命令は直前に指定した相対パスに切り替えます。例：
WORKDIR /a
WORKDIR b
WORKDIR c
RUN pwd
この Dockerfile を使えば、最後の pwd コマンドの出⼒は /a/b/c になります。
WORKDIR 命令は ENV 命令を使った環境変数も展開できます。環境変数を使うには Dockerfile で明確に定義する必要があります。例：ENV DIRPATH /path
WORKDIR $DIRPATH/$DIRNAMERUN pwd
この Dockerfile を使えば、最後の pwd コマンドの出⼒は /path/$DIRNAME になります。

- 174 -

docs.docker.jp

16/05/20

アーグ

ARG
ARG <名前>[=<デフォルトの値>]
ARG 命令は、構築時に作業者が docker build コマンドで使う変数、 --build-arg <変数名>=<値> フラグを定義するものです。ユーザが構築時に引数を指定しても Dockerﬁle で定義されていなければ、構築時に次のようなエラーが出ます。
One or more build-args were not consumed, failing build.
Dockerﬁle の作者は ARG 変数を１度だけ定義するだけでなく、複数の ARG を指定可能です。有効な Dockerfileの例：
FROM busybox
ARG user1
ARG buildno...
Dockerﬁle の作者は、オプションで ARG 命令のデフォルト値を指定できます。
FROM busybox
ARG user1=someuser
ARG buildno=1...
ARG がデフォルト値を持っている場合、構築時に値の指定が無ければ、このデフォルト値を使います。
ARG 変数は Dockerfile で記述した⾏以降で効果があります。ただし、コマンドライン上で引数の指定が無い場合です。次の Dockerfile の例を⾒てみましょう。
FROM busybox
USER ${user:-some_user}
ARG userUSER $user...
$ docker build --build-arg user=what_user Dockerfile
２⾏の USER は some_user を、３⾏めサブシーケントで定義された user 変数として評価します。４⾏めでは
what_user を USER で定義したものと評価し、what_user 値はコマンドラインで指定したものになります。ARG 命令
で定義するまで、あらゆる変数は空の⽂字列です。
構築時の変数として、GitHub の鍵やユーザの証明書などの秘密情報を含むのは、推奨される使い⽅ではありません。

ARG や ENV 命令を RUN 命令のための環境変数にも利⽤できます。ENV 命令を使った環境変数の定義は、常に同じ名前の ARG 命令を上書きします。Dockerﬁle における ENV と ARG 命令を考えましょう。
FROM ubuntu
ARG CONT_IMG_VER
ENV CONT_IMG_VER v1.0.0
RUN echo $CONT_IMG_VER- 175 -

docs.docker.jp

16/05/20

それから、イメージを次のように起動します。
$ docker build --build-arg CONT_IMG_VER=v2.0.1 Dockerfile
この例では、RUN 命令は v1.0.0 の代わりに、ARG でユーザから渡された v2.0.1 を使います。この動作はシェルスクリプトの挙動に似ています。ローカルのスコープにある環境変数が、与えられた引数や上位の環境変数によって上書きするようなものです。
上記の ENV 指定の他にも、更に ARG と ENV を使いやすくする指定も可能です。
FROM ubuntu
ARG CONT_IMG_VER
ENV CONT_IMG_VER ${CONT_IMG_VER:-v1.0.0}
RUN echo $CONT_IMG_VER
ARG 命令とは異なり、構築時の ENV 値は常に⼀定です。docker build で --build-arg フラグを使わない場合を考えてみましょう。
$ docker build Dockerfile
この Dockerﬁle の例では、CONT_IMG_VER はイメージの中では変わりませんが、３⾏めの ENV 命令でデフォルト
値を設定することにより、値は v1.0.0 となります。
この例における変数展開のテクニックは、コマンドラインから引数を渡せるようにし、ENV 命令を使うことで最終的に⼀貫したイメージを作成します。サポートされている変数展開は Dockerﬁle 命令の⼀部のみです。
Docker は Dockerﬁle に対応する ARG 命令が無くても、既定の ARG 変数セットを持っています。

 HTTP_PROXY
 http_proxy HTTPS_PROXY
 https_proxy FTP_PROXY
 ftp_proxy NO_PROXY no_proxy
これらを使うには、コマンドラインで --build-arg <変数名>=<値> フラグを単に渡すだけです。

構 築キャ ッシュの 影響
ARG 変数は、イメージ構築時の ENV 変数のように残り続けません。しかし、ARG 変数は構築キャッシュで似たような⽅法として扱えます。もし Dockerﬁle で ARG 変数を定義したら、この値が以前の値と違う時は、以降で ARG変数が出た時「キャッシュ・ミス」を発⽣します。
1 FROM ubuntu
2 ARG CONT_IMG_VER
3 RUN echo $CONT_IMG_VER
1 FROM ubuntu
2 ARG CONT_IMG_VER
3 RUN echo hello- 176 -

docs.docker.jp

16/05/20

1 FROM ubuntu
2 ARG CONT_IMG_VER
3 ENV CONT_IMG_VER $CONT_IMG_VER
4 RUN echo $CONT_IMG_VER
この例では、キャッシュミスが３⾏めで発⽣します。ミスが起こるのは ENV 変数が ARG 変数を参照しているのと、この変数がコマンドラインで変わるためです。例における ENV コマンドはイメージの中で処理されるものです。
もし ENV 命令を同じ名前の ARG 命令で、次のように上書きしたらどうでしょう。
1 FROM ubuntu
2 ARG CONT_IMG_VER
3 ENV CONT_IMG_VER hello
4 RUN echo $CONT_IMG_VER
３⾏めはキャッシュミスを引き起こしません。CONT_IMG_VAR は固定（hello）だからです。そのため、環境変数と値は RUN（４⾏め）で使われますが、構築時に変わりません。

- 177 -

docs.docker.jp

16/05/20

- 178 -docs.docker.jp

16/05/20

- 179 -docs.docker.jp

16/05/20

- 180 -docs.docker.jp

16/05/20

オ ン ビ ル ド

ONBUILDONBUILD [命令]イメージは他で構築したイメージを元にしている時、ONBUILD 命令はイメージに対して最終的に実⾏するトリガ
命令を追加します。トリガは構築後に⾏うもので、Dockerfile で FROM 命令のあとに書くことができます。
あらゆる構築時の命令をトリガとして登録可能です。
これは他のイメージからイメージを構築する時に役⽴つでしょう。例えば、アプリケーションの開発環境やデー
モンは、ユーザごとに設定をカスタマイズする可能性があります。
例えば、イメージが Python アプリケーション・ビルダーを再利⽤する時、アプリケーションのソースコードを
適切なディレクトリに追加し、その後、構築スクリプトを実⾏することもあるでしょう。この時点では ADD と RUN
を呼び出せません。なぜなら、まだアプリケーションのソースコードにアクセスしておらず、個々のアプリケーシ
ョン構築によって異なるからです。アプリケーションの開発者は、ボイラープレートである Dockerﬁle をコピーペーストでアプリケーションを⼊れるように編集するだけです。ですが、これは効率的ではなく、エラーを引き起こ
しやすく、アプリケーション固有のコードが混在することで更新が⼤変になります。
この解決⽅法として、ONBLUID を使い、実⾏後に別の構築ステージに進む上位命令を登録することです。
これは次のように動作します。
1. ONBUILD 命令が呼び出されたら、ビルダーはイメージ構築時のメタデータの中にトリガを追加します。
2. 構築が完了したら、全てのトリガはイメージのマニフェスト内の OnBuild キー配下に保管されます。この構築
時点では、命令は何ら影響を与えません。
3. このイメージは後で何らかのイメージの元になります。その時は FROM 命令で呼び出されます。FROM 命令の処理の⼀部として、ダウンストリームのビルダーは ONBULID トリガを探し、登録された順番で実⾏します。もしトリガが失敗したら、FROM 命令は処理を中断し、ビルドを失敗とします。もし全てのトリガが成功したら、FROM 命令は完了し、以降は通常の構築が進みます。
4. 実⾏する前に、最終的なイメージ上からトリガが削除されます。⾔い替えると構築された「孫」には、何ら親⼦関係がありません。
次のような例の記述を追加するでしょう。
[...]
ONBUILD ADD . /app/src
ONBUILD RUN /usr/local/bin/python-build --dir /app/src[...]【警告】ONBUILD ONBUILD 命令を使って ONBULID 命令の上書きはできません。

- 181 -

docs.docker.jp

16/05/20

ス ト ッ プ シ グ ナ ル

STOPSIGNALSTOPSIGNAL シグナル
STOPSIGNAL 命令は、コンテナを終了する時に送信するための、システム・コール・シグナルを設定します。シグナルはカーネルの syscall テーブルと⼀致する、有効な番号の必要があります。例えば、9 あるいはシグナル名
SIGNAME や、SIGKILL などです。

- 182 -

docs.docker.jp

16/05/20

Dockerﬁle の例
以下で Dockerﬁle 構⽂の例を参照できます。実際の環境に興味があれば、 Docker 化の例のセクションをご覧ください。

例 :Nginx# Nginx## VERSION

0.0.1

FROM
ubuntuMAINTAINER Victor Vieux <victor@docker.com>
LABEL Description="This image is used to start the foobar executable" Vendor="ACME Products"
Version="1.0"
RUN apt-get update && apt-get install -y inotify-tools nginx apache2 openssh-server

例 :Firefox over VNC# Firefox over VNC## VERSION

0.3

FROM ubuntu# 「フェイク」（偽）のディスプレイ用の vnc, xvfb と firefox をインストール
RUN apt-get update && apt-get install -y x11vnc xvfb firefox
RUN mkdir ~/.vnc# パスワードをセットアップ
RUN x11vnc -storepasswd 1234 ~/.vnc/passwd# firefox の自動起動（ベストな方法ではありませんが、動きます）
RUN bash -c 'echo "firefox" >> /.bashrc'
EXPOSE 5900
CMD["x11vnc", "-forever", "-usepw", "-create"]

例 :複 数のイ メージ# 複数のイメージ例## VERSION

0.1

FROM ubuntu
RUN echo foo > bar# 「===> 907ad6c2736f」 のような出力があります
FROM ubuntu
RUN echo moo > oink
# 「===> 695d7793cbe4」 のような出力があります# You ᾿ ll now have two images, 907ad6c2736f with /bar, and 695d7793cbe4 with# /oink.
# これで２つのイメージができました。
# /bar がある 907ad6c2736f と、/oink がある 695d7793cbe4 です- 183 -

docs.docker.jp

16/05/20