docker run

説明

新しいコンテナでコマンドを 実行(run) します。

使い方

$ docker run [OPTIONS] IMAGE [COMMAND] [ARG...]

補足説明

docker run コマンドは、まず指定されたイメージ上に書き込み可能なコンテナ・レイヤを create （作成）します。それから、指定されたコマンドを使って start （開始）します。この docker run は、 API の /containers/create の後で /containers/(id)/start を実行するのと同じです。以前に使っていたコンテナは docker start で再起動できます。全てのコンテナを表示するには docker ps -a を使います。

docker run コマンドは、 コンテナの内容を確定するため に、 docker commit コマンドと連携して使えます。

コンテナをネットワークで接続する詳細については、 Docker ネットワーク概要 をご覧ください。

コマンドの使用例は、以下の 使用例のセクション をご覧ください。

オプション

使用例

名前と: ruby:疑似 ターミナル <pseudo-TTY>` の割り当て（--name、-it）

$ docker run --name test -it debian
root@d6c0fe130dba:/# exit 13
$ echo $?
13
$ docker ps -a | grep test
d6c0fe130dba        debian:7            "/bin/bash"         26 seconds ago      Exited (13) 17 seconds ago                         test

この例は debian:latest イメージを使い、 test という名称のコンテナを実行します。 -it は疑似 TTY（pseudo-TTY）をコンテナの標準入力に接続するよう、 Docker に対して命令します。つまり、コンテナ内でインタラクティブな bash シェルを作成します。例の中で、 bash シェルを終了コード 13 で終了しています。この終了コードは docker run を呼び出したもの（docker）にも送られ、 test コンテナのメタデータに記録されます。

コンテナ ID の取得（--cidfile）

$ 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 -h
Filesystem      Size  Used Avail Use% Mounted on
none            1.9G     0  1.9G   0% /mnt

--privileged フラグはコンテナに対して 全ての 能力を与えます。また、そのために device cgroup コントローラの制限を昇格します。言い換えますと、コンテナはホスト上であらゆる処理が可能となります。このフラグが存在する時、 Docker の中で Docker を動かすといった特別な使い方ができます。

作業ディレクトリ(working directory) を指定（-w）

$ docker  run -w /path/to/dir/ -i -t  ubuntu pwd

-w は、指定したディレクトリの中でコマンドを実行します。この例では /path/to/dir で実行します。コンテナ内にパスが存在しなければ、作成されます。

コンテナごとにストレージ・オプションを指定

$ docker create -it --storage-opt size=120G fedora /bin/bash

この size（容量）とは、コンテナのルート・ファイルシステムの容量を作成時に 120GB と指定しています。このオプションを指定できるのは devicemapper 、 brtfs 、 overlay2 、 windowsfilter 、 zfs の各 グラフ・ドライバ(graph driver) を使う時のみです。 devicemapper 、 brtfs 、 overlay2 、 windowsfilter 、 zfs の各 グラフ・ドライバ(graph driver) では、ユーザはデフォルトの BaseFS 容量をよりも小さな値を指定できません。 overlay2 ストレージ上ージ・ドライバでは、バックエンドで使用するファイルシステムが xfs で、かつ、 pquota マウントオプションでマウント指定している場合のみ、size オプションを指定できます。

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 sh

Docker Unix ソケットと docker バイナリ（ https://get.docker.com から入手）に対するマウントにより、コンテナはホスト側の Docker デーモンに対して作成や各種操作といった完全アクセスをもたらします。

Windows では、Windows 方式の記法を使ってパスを指定する必要があります。

PS C:\> docker run -v c:\foo:c:\dest microsoft/nanoserver cmd /s /c type c:\dest\somefile.txt
Contents of file

PS C:\> docker run -v c:\foo:d: microsoft/nanoserver cmd /s /c type d:\somefile.txt
Contents of file

以下の例は、 Windows ベースのコンテナを使おうとしますが、失敗します。コンテナ内へのボリュームのマウント先やバインド・マウントは、存在していないか、空っぽのディレクトリの必要があります。また、C: ドライブの必要があります。さらに、バインド・マウントの元になるのはディレクトリの必要があり、ファイルではありません。

net use z: \\remotemachine\share
docker run -v z:\foo:c:\dest ...
docker run -v \\uncpath\to\directory:c:\dest ...
docker run -v c:\foo\somefile.txt:c:\dest ...
docker run -v c:\foo:c: ...
docker run -v c:\foo:c:\existing-directory-with-contents ...

ボリュームに関する詳しい情報は、 コンテナのデータ管理 をご覧ください。

--mount フラグによって、ボリューム、ホスト上のディレクトリや tmpfs をコンテナ内にマウントできます。

--mount フラグは -v または --volume フラグの大部分をサポートしますが、構文が異なります。 --mount フラグについてや、 --volume と --mount 間の比較は service create コマンドリファレンス をご覧ください。

--volume を非推奨にする計画はありませんが、 --mount の利用を推奨します。

使用例：

$ docker run --read-only --mount type=volume,target=/icanwrite busybox touch /icanwrite/here

$ docker run -t -i --mount type=bind,src=/data,dst=/data busybox sh

ポートの公開と露出（-p、--expose）

$ docker run -p 127.0.0.1:80:8080 ubuntu bash

コンテナのポート 8080 を 127.0.0.1 上のポート 80 にバインド（割り当て）します。 Docker ユーザ・ガイド で Docker がどのようにポートを操作するか詳細を説明しています。

ホストにバインドしていないポート（例： -p 127.0.0.1:80:80 ではなく -p 80:80 の場合）は、外からアクセスできるので、注意してください。また、 UFW を設定し、Docker が自身で管理する iptables ルールはそのままに、特定のポートをブロックできます。 こちらをご覧ください 。

$ docker run --expose 80 ubuntu bash

これは、コンテナのポート 80 を露出（expose）しますが、ホストシステム側のインターフェースにはポートを公開しません。

環境変数の設定（-e、--env、--env-file）

$ docker run -e MYVAR1 --env MYVAR2=foo --env-file ./env.list ubuntu bash

-e 、 --env 、 --env-file フラグを使い、シンプルに（配列ではない）環境変数を実行中のコンテナ内で指定できます。あるいは、実行中のイメージの Dockerfile 内で定義済みの環境変数を上書きします。

コンテナの実行時に、変数と値を定義できます。

$ docker run --env VAR1=value1 --env VAR2=value2 ubuntu env | grep VAR
VAR1=value1
VAR2=value2

また、ローカル環境で export した変数も使えます。

export VAR1=value1
export VAR2=value2

$ docker run --env VAR1 --env VAR2 ubuntu env | grep VAR
VAR1=value1
VAR2=value2

コマンドの実行時、 Docker CLI クライアントはローカル環境上の環境変数を確認し、それをコンテナに渡します。 = の指定が無い変数は、ローカル環境からエクスポートされず、コンテナ内には設定されません。

また、ファイルからも環境変数を読み込めます。このファイルで使える構文は <変数>=値 （変数に対して値を指定）か、 <変数> （ローカル環境変数から値を取得）か、コメント用の # です。

$ cat env.list
# This is a comment
VAR1=value1
VAR2=value2
USER

$ docker run --env-file env.list ubuntu env | grep VAR
VAR1=value1
VAR2=value2
USER=denis

メタデータをコンテナに設定（-l、--label、--label-file）

ラベルとは 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 でカスタム・メタデータを使う をご覧ください。

コンテナをネットワークに接続（--network）

コンテナ実行時に --net フラグを付けるとネットワークに接続します。次の例は busybox コンテナに my-net ネットワークを追加します。

$ docker run -itd --network=my-net busybox

また、ユーザ定義ネットワーク上でコンテナを起動時、 --ip と --ipv6 フラグを使い、コンテナに対して IP アドレスを割り当て可能です。

$ docker run -itd --network=my-net --ip=10.10.9.75 busybox

実行中のコンテナに対してネットワークを追加する時は、 docker network connect サブコマンドを使います。

同じネットワークに複数のコンテナを接続できます。接続したら、コンテナは別のコンテナの 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 -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 を利用できます。コンテナが 特権モード(privileged mode) で動作している場合、パーミッションの指定は無視されます。

$ 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 で追加すべきではありません。

Windows では、 --device オプションで文字を渡す形式は --device=<IdType>/<Id> です。Windows Server 2019 と Windows 10 Octover 2018 アップデート以降、Windows でサポートしている IdType は ``class `` のみで、 Id とは デバイス インターフェーイス クラス GUID です。コンテナがサポートしているデバイスインターフェースクラス GUID の一覧は、 Windows コンテナのドキュメント で定義された表をご覧ください。

プロセスを隔離した Windows コンテナのオプションを指定する場合は、要求したデバイスインターフェースクラス GUID の全デバイスがコンテナ内で利用可能になります。たとえば、以下のコマンドは、ホスト上にある全ての COM ポートをコンテナ内で見えるようにします。

PS C:\> docker run --device=class/86E0D1E0-8089-11D0-9CE4-08003E301F73 mcr.microsoft.com/windows/servercore:ltsc2019

注釈

--device オプションはプロセス隔離 Windows コンテナでのみサポートしています。コンテナ隔離が hyperv や Windows 上の LInux コンテナ（LCOW）の実行時には失敗します。

NVIDIA GPU にアクセス

--gpus フラグによって、NVIDIA GPU リソースにアクセス可能になります。はじめに、 nvidia-container-runtime のインストールが必要です。詳しい情報は コンテナのリソースを指定 をご覧ください。

--gpus には、どの GPU （あるいは全て）を使うか指定します。値の指定がなければ、利用可能な GPU 全てを使います。以下の例は利用可能なすべての GPU を見えるようにします。

$ docker run -it --rm --gpus all ubuntu nvidia-smi

device オプションを使い、 GPUS を指定します。以下の例は、特定の GPU を見えるようにします。

$ docker run -it --rm --gpus device=GPU-3a23c669-1f69-c64e-cf85-44e9b07e7a2a ubuntu nvidia-smi

以下の例は、1番目と3番目の GPU を見えるようにします。

$ docker run -it --rm --gpus device=0,2 nvidia-smi

再起動ポリシー

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

ポリシー

結果

no

終了してもコンテナを自動的に再起動しません。これがデフォルトです。

on-failure [:最大リトライ数]

コンテナが 0 以外のステータスで終了すると、再起動します。オプションで Docker デーモンが何度再起動するかを指定できます。

unless-stopped

終了コードの状態に関わらず、常に再起動します。しかし、以前に停止した状態であれば、Docker デーモンの起動時にコンテナを開始しません。

always

終了コードの状態に関わらず、常に再起動します。always を指定すると、 Docker デーモンは無制限に再起動を試みます。また、現在の状況に関わらず、デーモンの起動時にもコンテナの起動を試みます。

 
$ docker run --restart=always redis

これは redis コンテナを再起動ポリシー always で起動するものです。つまり、コンテナが終了したら Docker がコンテナを再起動します。

再起動ポリシーに関するより詳しい情報は、 Docker run リファレンス・ページ の 再起動ポリシー（--restart） をご覧ください。

コンテナの hosts ファイルにエントリ追加（--add-host）

--add-host フラグを使い、コンテナの /etc/hosts ファイルに１つもしくは複数のホストを追加できます。次の例はホスト名 docker に静的なアドレスを追加しています。

$ docker run --add-host=docker:93.184.216.34 --rm -it alpine
/ # ping docker
PING docker (93.184.216.34): 56 data bytes
64 bytes from 93.184.216.34: seq=0 ttl=37 time=93.052 ms
64 bytes from 93.184.216.34: seq=1 ttl=37 time=92.467 ms
64 bytes from 93.184.216.34: seq=2 ttl=37 time=92.252 ms
^C
--- docker ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 92.209/92.495/93.052 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 ユーザとして４つのコンテナを起動します。

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）です。

セキュリティ・オプションの追加（--security-opt）

Windows では、このフラグが credentialspec オプションを指定するのに使えます。 credentialspec は file://spec.txt もしくは registry://keyname の形式にする必要があります。

コンテナ停止のタイムアウト（--stop-timeout）

--stop-timeout フラグは、コンテナを停止するために定義済みの（ --stop-signal を参照 ）システムコール・シグナルを送った後、何秒待機するかを指定します。タイムアウトを経過してもコンテナが停止しない場合は、 KILLSIG シグナルで強制停止します。

--stop-timeout に -1 を指定すると、タイムアウトは適用されず、デーモンはコンテナが終了するまで無期限に待機します。

デーモンでのデフォルトは、 Linux コンテナでは 10 秒、 Windows コンテナでは 30 秒です。

コンテナの分離技術を指定（--isolation）

このオプションは Docker コンテナを Microsoft Windows 上で使う状況で便利です。 --isolation <値> オプションでコンテナの分離（isolation）技術を指定します。 Linux 上では Linux 名前空間（namespaces）を使う default しかサポートしていません。Linux 上では次の２つのコマンドが同等です。

$ docker run -d busybox top
$ docker run -d --isolation default busybox top

Windows server オペレーティングシステム上のデフォルト分離は process です。Windows クライアントのオペレーティングシステム上のデフォルト分離は hyperv です。Windows 10 1809 よりも古いクライアントのオペレーティングシステム上で、 --isolation process でコンテナの起動を試みても、失敗します。

Windows server 上では、デフォルトの設定であれば、以下のコマンドは同等で、結果 process 分離となります。

PS C:\> docker run -d microsoft/nanoserver powershell echo process
PS C:\> docker run -d --isolation default microsoft/nanoserver powershell echo process
PS C:\> docker run -d --isolation process microsoft/nanoserver powershell echo process

Docker daemon 上で --exec-opt isolation=hyperv オプションを指定するか、WIndows クライアント・ベース上で動作するデーモンの場合は、以下のコマンドは同等で、結果 hyperv 分離となります。

PS C:\> docker run -d microsoft/nanoserver powershell echo hyperv
PS C:\> docker run -d --isolation default microsoft/nanoserver powershell echo hyperv
PS C:\> docker run -d --isolation hyperv microsoft/nanoserver powershell echo hyperv

コンテナで利用可能なメモリのハードリミットを指定（-m, --memory）

これらのパラメータは、コンテナが常時利用可能なメモリの上限を指定します。Linux 上では、 cgorup に設定され、コンテナ内のアプリケーションは /sys/fs/cgroup/memory/memory.limit_in_bytes で確認できます。

Windows 上では、コンテナに対する影響は、何を隔離技術で使うかに依存します。

  • process 分離では、Windows はホストシステム上の全メモリを報告し、コンテナ内で実行しているアプリケーションに制限できません。

    PS C:\> docker run -it -m 2GB --isolation=process microsoft/nanoserver powershell Get-ComputerInfo *memory*
CsTotalPhysicalMemory      : 17064509440
CsPhyicallyInstalledMemory : 16777216
OsTotalVisibleMemorySize   : 16664560
OsFreePhysicalMemory       : 14646720
OsTotalVirtualMemorySize   : 19154928
OsFreeVirtualMemory        : 17197440
OsInUseVirtualMemory       : 1957488
OsMaxProcessMemorySize     : 137438953344

  • hyperv 分離では、 Windows はメモリ上限を十分維持できるユーティリティ VM を作成し、コンテナを保持するために必要な最小の OS を加えます。

    PS C:\> docker run -it -m 2GB --isolation=hyperv microsoft/nanoserver powershell Get-ComputerInfo *memory*
CsTotalPhysicalMemory      : 2683355136
CsPhyicallyInstalledMemory :
OsTotalVisibleMemorySize   : 2620464
OsFreePhysicalMemory       : 2306552
OsTotalVirtualMemorySize   : 2620464
OsFreeVirtualMemory        : 2356692
OsInUseVirtualMemory       : 263772
OsMaxProcessMemorySize     : 137438953344

実行時に名前空間のカーネル・パラメータ（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 のオプション指定が許可されません。

ネットワーク名前空間 ：

  • net.* で始まる sysctl

  • --ipc=host オプションを使う場合は、これら sysctl のオプション指定が許可されません。

親コマンド

コマンド

説明

docker

Docker CLI の基本コマンド

参考

docker run

https://docs.docker.com/engine/reference/commandline/run/