Docker run リファレンス¶

デタッチド (-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 のふりをするだけでなく（TTY は大部分のコマンド・ラインで実行可能なものと想定しています）、シグナルも渡せます。

-a=[]           : Attach to `STDIN`, `STDOUT` and/or `STDERR`
-t=false        : Allocate a pseudo-tty
--sig-proxy=true: Proxify all received signal to the process (non-TTY mode only)
-i=false        : Keep STDIN open even if not attached

もし 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 のようにリダイレクトやパイプできます。

名前（–name）¶

オペレータはコンテナを３つの方法で識別できます。

• UUID 長い（ロング）識別子（”f78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778”）
• UUID 短い（ショート）識別子（”f78375b1c487”）
• 名前（”evil_ptolemy”）

UUID 識別子は Docker デーモンから与えられます。コンテナの名前を --name オプションで割り当てなければ、デーモンはランダムな文字列から名前を生成します。コンテナに対する目的を表すために、 name を定義するのが簡単な方法でしょう。 name を指定すると、これは Docker ネットワーク内でコンテナを参照するために使えます。この参照機能は、バックグラウンドでもフォアグラウンドでも、両方の Docker コンテナで動作します。

PID 相当¶

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

--cidfile="": コンテナの ID をファイルに書き出す

イメージ[:タグ]¶

イメージ[@ダイジェスト値]¶

v2 以降のイメージ・フォーマットのイメージを使うと、その中にダイジェスト値（digest）と呼ばれる識別子が、内容に対して割り当てられています。入力に使われたイメージファイルに対する変更がなければ、ダイジェスト値とは予想されうる値であり、参照可能なものです。

ネットワーク：none¶

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

ネットワーク：bridge¶

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

デフォルトでは、コンテナは各々の IP アドレスを経由して通信できます。コンテナ名で通信するには、リンクする必要があります。

ネットワーク：host¶

host ネットワークをコンテナに設定すると、ホスト側のネットワーク・スタックと、全てのホスト上のインターフェースがコンテナ上でも共有できます。コンテナのホスト名はホストシステム上のホスト名と一致します。 host ネットワーク・モードでは、 --add-host 、 --hostname 、 --dns 、 --dns-search 、 --dns-opt 、 --mac-address が無効になるのでご注意ください。

デフォルトの bridge モードと比較すると、 host モードは 著しく ネットワーク性能が良いです。これは、bridge の場合は docker デーモンの仮想化レベルを通過しているのに対して、host の場合はネイティブなネットワーク・スタックを用いるからです。例えば、プロダクションのロードバランサや高性能のウェブサーバのような、ネットワーク性能がクリティカルな環境では、このモードでのコンテナ動作を推奨します。

ネットワーク：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 ネットワーク・ドライバを使ってネットワークを作成し、作成したネットワーク上でコンテナを実行します。

$ docker network create -d bridge my-net
$ docker run --net=my-net -itd --name=container3 busybox

/etc/hosts の管理¶

/etc/hosts には localhost や一般的な項目と同じように、自分が定義したコンテナのホスト名が追加されます。 --add-host フラグを使うことで、 /etc/hosts に行を追加できます。

$ 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 run --restart=always redis

こちらの例は、 常に (always) 再起動するポリシーで redis コンテナを実行しているので、停止すると Docker は再起動します。

$ docker run --restart=on-failure:10 redis

こちらの例は、 失敗したら (on-failure) 10回カウントするまで再起動を行うポリシーで redis コンテナを起動しています。もし redis コンテナが 0 以外の状態で終了すると、Docker はコンテナの再起動を１０回続けて試みます。再起動の上限を設定できるのは、 on-failure ポリシーを有効にした場合のみです。

クリーンアップ（–rm）¶

デフォルトではコンテナを終了しても、コンテナのファイルシステム（の内容）を保持し続けます。これにより、多くのデバッグをより簡単にし（最後の状態を確認できるので）、そして、全てのデータを維持し続けるのがデフォルトです。しかし、短い期間だけ フォアグラウンド で動かしたとしても、これらのコンテナのファイルシステムが溜まり続けます。そうではなく、 コンテナが終了した時に、自動的にコンテナをクリーンアップし、ファイルシステムを削除する には --rm フラグを追加します。

--rm=false: Automatically remove the container when it exits (incompatible with -d)

ユーザ・メモリの制限¶

ユーザのメモリ使用を制限するには、４つの方法があります。

例：

$ 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 はメモリのコンテンション（競合）や少ないメモリを検出し、コンテナが予約した上限まで使えるようにします。

メモリ予約の値は、常にハード・リミット以下に設定しなければ、ハード・リミットが先に処理されてしまいます。予約値を 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

これらのメモリを制限するため、カーネル・メモリの上限を設定できます。たとえば、各プロセスが同じスタック・ページ（stack page）を使うようにする場合です。カーネル・メモリの制限により、カーネル・メモリの使用量が大きいとき、新しいプロセスの作成を妨げます。

カーネル・メモリはユーザ・メモリとは完全に独立しています。その代わり、ユーザ・メモリを制限すると同時に、カーネル・メモリの制限も必要です。上限の設定には３つの方法があります。ここでは、「U」はユーザ・メモリの上限で、「K」はカーネルの上限とみなしています。

例：

$ 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 を使います。

割合が適用されるのは　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    container    CPU CPU share
100    {C0}     0   100% of CPU0
101    {C1}     1   100% of CPU1
102    {C1}     2   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 の周期の半分のため）。

より詳しい情報については、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 上でのみ、どのコンテナをメモリ上で実行するか設定できます。

$ 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 ウェイトの割合により、処理にかかる時間の割合が変わるのが分かるでしょう。

CMD（デフォルトのコマンドかオプション）¶

Docker コマンドラインでのオプション コマンド を取り消します。

$ docker run [オプション] イメージ[:タグ|@DIGEST] [コマンド] [引数...]

このコマンドはオプションの指定です。 イメージ の作者が Dockerfile の CMD 命令を使い、デフォルトの コマンド を既に設定している場合があるためです。オペレータ（イメージからコンテナを十個売る人のこと）によって、 CMD 命令を上書きして新しい コマンド を実行します。

イメージに ENTRYPOINT も指定されていれば、 CMD や コマンド は ENTRYPOINT に対する引数となります。

ENTRYPOINT（実行時に処理するデフォルトのコマンド）¶

--entrypoint="": Overwrite the default entrypoint set by the image

イメージの ENTRYPOINT は コマンド と似ています。これはコンテナを開始する時に実行するコマンドを指定しているためです。しかし、こちらは（意図的に）上書きを難しくしています。 ENTRYPOINT が提供するのは、コンテナ自身が持つデフォルトの特性や振る舞いです。そのため 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 a port or a range of ports inside the container.
             These are additional to those exposed by the `EXPOSE` instruction
-P=false   : Publish all exposed ports to the host interfaces
-p=[]      : Publish a container᾿s port or a range of ports to the host
               format: ip:hostPort:containerPort | ip::containerPort | hostPort:containerPort | containerPort
               Both hostPort and containerPort can be specified as a
               range of ports. When specifying ranges for both, the
               number of container ports in the range must match the
               number of host ports in the range, for example:
                   -p 1234-1236:1234-1236/tcp

               When specifying a range for hostPort only, the
               containerPort must not be a range.  In this case the
               container port is published somewhere within the
               specified hostPort range. (e.g., `-p 1234-1236:1234/tcp`)

               (use 'docker port' to see the actual mapping)

--link=""  : Add link to another container (<name or id>:alias or <name 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 をリッスンしているとします（そして、イメージ開発者は Dockerfile で EXPOSE 80 を指定しているでしょう ）。実行する時に、ホスト側のポート 42800 以上が使われます。公開用ポートがホスト側のどのポートに割り当てられたかを確認するには、 docker port コマンドを使います。

デフォルトのブリッジ・ネットワークにおいて、新しいクライアント・コンテナの起動時にオペレータが --link を指定すると、クライアント・コンテナはプライベートなネットワーク・インターフェースを経由して公開ポートにアクセスできます。 Docker ネットワーク概要 にあるユーザ定義ネットワーク上で --link を指定すると、コンテナをリンクするためのエイリアス名を作成します。

ENV（環境変数）¶

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

さらに、オペレータはコンテナに対して 環境変数の組み合わせ を -e フラグで追加出来ます。先ほど言及した環境変数や、開発者が Dockerfile の中で 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=[]: Create a tmpfs mount with: container-dir[:<options>],
            where the options are identical to the Linux
            'mount -t tmpfs -o' command.

この例では、オプションで rw 、 noexec 、 nosuid 、 size=65536k 、コンテナに対して空の tmpfs をマウントしています。

$ docker run -d --tmpfs /run:rw,noexec,nosuid,size=65536k my_image

VOLUME（共有ファイルシステム）¶

-v=[]: Create a bind mount with: [host-dir:]container-dir[:<options>], where
options are comma delimited and selected from [rw|ro] and [z|Z].
       If 'host-dir' is missing, then docker creates a new volume.
       If neither 'rw' or 'ro' is specified then the volume is mounted
       in read-write mode.
--volumes-from="": Mount all volumes from the given container(s)

ボリューム関連コマンドは コンテナでデータを管理する セクション自身のドキュメントでも複雑なものです。開発者は１つまたは複数の VOLUME を作成し、イメージと関連づけることが可能です。しかし、オペレータができるのは、あるコンテナから別のコンテナに対してのみです（あるいは、コンテナからホスト側のボリュームにマウントする場合）。

コンテナ側ディレクトリ は /src/docs のように常に絶対パスの必要があります。 ホスト側ディレクトリ は絶対パスか 名前 の値を指定できます。 ホスト側ディレクトリ に絶対パスを指定する場合は、 Docker は指定したパスを拘束マウント（bind-mounts）します。 名前 を指定する場合は、Docker は 名前 を持つボリュームを作成します。

名前 は英数字で始まる必要があり、以降は a-z0-9 、_ （アンダースコア）、 . （ピリオド）、 - （ハイフン）が使えます。絶対パスは / （フォアワード・スラッシュ）で始める必要があります。

例えば、 ホスト側ディレクトリ の値に /foo か foo を指定したとします。 /foo 値を指定した場合は、Docker はホスト上に拘束マウントを作成します。 foo を指定すると、Docker は指定された名前でボリュームを作成します。

USER¶

開発者は Dockerfile の USER 命令を使い、１つめのプロセスを実行する時のユーザを定義できます。コンテナが起動するとき、 -u オプションを使うと USER 命令を上書きできます。

-u="", --user="": Sets the username or UID used and optionally the groupname or GID for the specified command.

以下の例は無効です。

--user=[ user | user:group | uid | uid:gid | user:gid | uid:group ]

WORKDIR¶

コンテナ内でバイナリを実行する時、デフォルトの作業用ディレクトリはルート( / ) ディレクトリです。しかし開発者は Dockerfile の WORKDIR コマンドを使い、デフォルトの作業用ディレクトリを変更できます。オペレータが更に設定を上書きするには、次のようにします。

-w="": Working directory inside the container