Docker運行引用
Docker 在獨立的容器中運行進程。容器是一個在主機上運行的進程。主機可能是本地或遠程的。當運營商執行時docker run，運行的容器進程是獨立的，因為它擁有自己的文件系統，自己的網絡以及獨立於主機的獨立進程樹。
本頁詳細介紹如何使用該docker run命令在運行時定義容器的資源。
一般形式
基本docker run命令采用這種形式：
$ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]
該docker run命令必須指定一個 IMAGE 以從中派生容器。圖像開發人員可以定義與以下相關的圖像默認值：
-
分離或前景運行
-
貨櫃識別
-
網絡設置
-
CPU和內存的運行時間限制
隨着docker run [OPTIONS]操作者可以添加或覆蓋由開發者設置的圖像的默認值。此外，運算符可以覆蓋 Docker 運行時自身設置的幾乎所有默認值。操作員重寫圖像和 Docker 運行時默認值的能力是為什么run比其他docker命令具有更多選項。
要了解如何解釋類型[OPTIONS]，請參閱選項類型。
注意：根據您的 Docker 系統配置，您可能需要使用前面的
docker run命令sudo。為了避免必須使用sudo該docker命令，系統管理員可以創建一個名為的 Unix 組docker並向其添加用戶。有關此配置的更多信息，請參閱適用於您的操作系統的 Docker 安裝文檔。
運營商獨享選項
只有操作員（執行人員docker run）可以設置以下選項。
-
分離與前景
-
分離（-d）
-
前景
-
容器標識
-
名稱（-name）
-
PID等值
-
IPC設置（-ipc）
-
網絡設置
-
重新啟動策略（-restart）
-
清理（-rm）
-
運行時對資源的限制
-
運行時權限和Linux功能
分離與前景
啟動 Docker 容器時，您必須先決定是否要在后台以“分離”模式或默認的前台模式運行容器：
-d=false: Detached mode: Run container in the background, print new container id
分離（-d）
要以分離模式啟動容器，可以使用-d=true或僅使用-d選項。按照設計，當用於運行容器的根進程退出時，容器以分離模式退出，除非您還指定了該--rm選項。如果使用-d帶--rm，容器，當它退出刪除或當守護進程退出，先發生者為准。
不要將service x start命令傳遞給分離的容器。例如，該命令嘗試啟動該nginx服務。
$ docker run -d -p 80:80 my_image service nginx start
這成功地啟動nginx了容器內的服務。然而，它不符合分離的容器范例，因為根進程（service nginx start）返回並且分離的容器按設計停止。因此，該nginx服務已啟動，但無法使用。相反，要啟動諸如nginxWeb服務器等進程，請執行以下操作：
$ docker run -d -p 80:80 my_image nginx -g 'daemon off;'
要使用分離的容器進行輸入/輸出，請使用網絡連接或共享卷。這些都是必需的，因為容器不再監聽docker run運行的命令行。
要重新附加到分離的容器，請使用docker attach 命令。
前景
在前台模式下（-d未指定默認值時），docker run可以在容器中啟動進程並將控制台附加到進程的標准輸入，輸出和標准錯誤。它甚至可以偽裝成 TTY（這是大多數命令行可執行文件所期望的）並傳遞信號。所有這些都是可配置的：
-a=[] : Attach to `STDIN`, `STDOUT` and/or `STDERR` -t : Allocate a pseudo-tty --sig-proxy=true: Proxy all received signals to the process (non-TTY mode only) -i : Keep STDIN open even if not attached
如果你沒有指定，-a那么 Docker 將連接到stdout和stderr。您可以指定其中三個標准流（STDIN，STDOUT，STDERR）你想，而不是連接，如：
$ docker run -a stdin -a stdout -i -t ubuntu /bin/bash
對於交互式進程（如shell），必須-i -t一起使用才能為容器進程分配tty。-i -t通常-it會按照后面的示例中的描述進行編寫。-t當客戶端從管道接收其標准輸入時，禁止指定，如下所示：
$ echo test | docker run -i busybox cat
注意：在容器中作為PID 1運行的進程會被Linux專門處理：它將忽略具有默認操作的任何信號。因此，該過程將不會終止
SIGINT或者SIGTERM除非它被編寫這樣做。
容器標識
名稱（-name）
操作員可以通過三種方式識別容器：
|
識別類型 |
示例值 |
|---|---|
|
UUID長標識符 |
“F78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778” |
|
UUID短標識符 |
“F78375b1c487” |
|
Name |
“evil_ptolemy” |
UUID 標識符來自 Docker 守護進程。如果您沒有為該--name選項分配容器名稱，則該守護程序會為您生成一個隨機字符串名稱。定義一個name可以方便地為容器添加含義。如果您指定了一個name，則可以在 Docker 網絡中引用容器時使用它。這適用於后台和前台 Docker 容器。
注意：默認網橋網絡上的容器必須鏈接以通過名稱進行通信。
PID 等值
最后，為了幫助實現自動化，您可以讓 Docker 將容器 ID 寫出到您選擇的文件中。這與某些程序可能會將其進程 ID 寫入文件（您已將其視為 PID 文件）類似：
--cidfile="": Write the container ID to the file
圖片：標簽
雖然不是嚴格意義上的容器識別方法，但您可以通過添加image[:tag]到命令中來指定要運行容器的圖像版本。例如，docker run ubuntu:14.04。
圖片@消化
使用v2或更高版本的圖像格式的圖像具有稱為摘要的內容可尋址標識符。只要用於生成圖像的輸入保持不變，摘要值是可預測和可引用的。
以下示例從包含摘要的alpine映像運行容器sha256:9cacb71397b640eca97488cf08582ae4e4068513101088e9f96c9814bfda95e0：
$ docker run alpine@sha256:9cacb71397b640eca97488cf08582ae4e4068513101088e9f96c9814bfda95e0 date
PID設置（-pid）
--pid="" : Set the PID (Process) Namespace mode for the container, 'container:<name|id>': joins another container's PID namespace 'host': use the host's PID namespace inside the container
默認情況下，所有容器都啟用了 PID 名稱空間。
PID 名稱空間提供了進程的分離。PID 名稱空間刪除系統進程的視圖，並允許重新使用進程 ID，包括 PID 1。
在某些情況下，您希望容器共享主機的進程名稱空間，基本上允許容器中的進程查看系統上的所有進程。例如，你可以建立與調試工具等的容器strace或gdb，但要在容器內調試過程時使用這些工具。
示例：在容器中運行 htop
創建這個 Dockerfile：
FROM alpine:latest RUN apk add --update htop && rm -rf /var/cache/apk/* CMD ["htop"]
構建 Dockerfile 並將圖像標記為myhtop：
$ docker build -t myhtop .
使用以下命令htop在容器內運行：
$ docker run -it --rm --pid=host myhtop
加入另一個容器的 pid 名稱空間可用於調試該容器。
例子
啟動運行 redis 服務器的容器：
$ docker run --name my-redis -d redis
通過運行另一個容器來調試 redis 容器：
$ docker run -it --pid=container:my-redis my_strace_docker_image bash $ strace -p 1
UTS設置（-uts）
--uts="" : Set the UTS namespace mode for the container, 'host': use the host's UTS namespace inside the container
UTS 命名空間用於設置在該命名空間中運行進程可見的主機名和域。默認情況下，所有容器（包括那些容器）--network=host都有自己的 UTS 名稱空間。該host設置將導致容器使用與主機相同的 UTS 名稱空間。請注意，--hostname在hostUTS 模式下無效。
如果您希望容器的主機名隨着主機的主機名更改而更改，您可能希望與主機共享 UTS 名稱空間。更高級的用例將從容器中更改主機的主機名。
IPC設置（-ipc）
--ipc="" : Set the IPC mode for the container, 'container:<name|id>': reuses another container's IPC namespace 'host': use the host's IPC namespace inside the container
默認情況下，所有容器都啟用了 IPC 命名空間。
IPC（POSIX / SysV IPC）命名空間提供命名共享內存段，信號量和消息隊列的分離。
共享內存段用於以內存速度加速進程間通信，而不是通過管道或通過網絡堆棧。共享內存通常由數據庫和定制（通常為C / OpenMPI，C ++ /使用boost庫）用於科學計算和金融服務行業的高性能應用程序使用。如果這些類型的應用程序分成多個容器，則可能需要共享容器的IPC機制。
網絡設置
--dns=[] : Set custom dns servers for the container--network="bridge" : Connect a container to a network 'bridge': create a network stack on the default Docker bridge 'none': no networking 'container:<name|id>': reuse another container's network stack 'host': use the Docker host network stack '<network-name>|<network-id>': connect to a user-defined network--network-alias=[] : Add network-scoped alias for the container--add-host="" : Add a line to /etc/hosts (host:IP)--mac-address="" : Sets the container's Ethernet device's MAC address--ip="" : Sets the container's Ethernet device's IPv4 address--ip6="" : Sets the container's Ethernet device's IPv6 address--link-local-ip=[] : Sets one or more container's Ethernet device's link local IPv4/IPv6 addresses
默認情況下，所有容器都已啟用網絡連接，並且可以進行任何傳出連接。運營商可以完全禁用網絡docker run --network none，禁用所有進入和離開的網絡。在這樣的情況下，你將I / O通過文件或執行STDIN和STDOUT只。
發布端口和鏈接到其他容器只能使用默認（橋接）。鏈接功能是一項傳統功能。您應該始終更喜歡使用 Docker 網絡驅動程序進行鏈接。
默認情況下，您的容器將使用與主機相同的 DNS 服務器，但您可以使用它覆蓋此容器--dns。
默認情況下，使用分配給容器的IP地址生成 MAC 地址。您可以通過--mac-address參數（format 12:34:56:78:9a:bc：）提供MAC地址來明確設置容器的MAC地址。請注意，Docker不會檢查手動指定的MAC地址是否唯一。
支持的網絡：
|
網絡 |
描述 |
|---|---|
|
沒有 |
容器中沒有網絡。 |
|
橋（默認） |
通過veth接口將容器連接到橋。 |
|
主辦 |
在容器內使用主機的網絡堆棧。 |
|
容器：<名稱| ID> |
使用另一個容器的網絡堆棧，通過其名稱或ID指定。 |
|
網絡 |
將容器連接到用戶創建的網絡（使用docker network create命令） |
網絡：無
與網絡是none一個容器將不能訪問任何外部路由。該容器仍然loopback在容器中啟用了一個接口，但它沒有任何到外部流量的路由。
網橋
將網絡設置為bridge容器將使用docker的默認網絡設置。在主機上設置docker0一個通常命名的網橋，並veth為該容器創建一對接口。該veth對中的一側將保留在連接到橋的主機上，而另一側將放置在容器的命名空間內，除了該loopback界面。一個IP地址將被分配給橋接網絡上的容器，流量將通過該橋接路由到容器。
容器默認通過 IP 地址進行通信。要通過名稱進行交流，他們必須聯系起來。
網絡：主機
將網絡設置為host容器將共享主機的網絡堆棧，並且主機的所有接口都可用於容器。容器的主機名將與主機系統上的主機名匹配。請注意，--mac-address在hostnetmode中無效。即使在host網絡模式下，默認情況下容器也有自己的UTS命名空間。因為這--hostname是在host網絡模式下允許的，並且只會改變容器內的主機名。類似--hostname的--add-host，--dns，--dns-search，和--dns-option選項可以用在host網絡模式。這些選項更新/etc/hosts或/etc/resolv.conf在容器內部。沒有變化的，以制作/etc/hosts，並/etc/resolv.conf在主機上。
與默認bridge模式相比，該host模式顯着提高了網絡性能，因為它使用主機的本地網絡堆棧，而網橋必須通過 docker 守護進程通過一級虛擬化。建議在網絡性能至關重要的情況下以此模式運行容器，例如生產負載平衡器或高性能 Web 服務器。
注意：
--network="host"給容器充分訪問本地系統服務，如 D-bus，因此被認為是不安全的。
網絡：容器
將網絡設置為container一個容器將共享另一個容器的網絡堆棧。另一個容器的名稱必須以格式提供--network container:<name|id>。請注意，--add-host --hostname --dns --dns-search --dns-option並且--mac-address在containernetmode 中無效，並且在netmode --publish --publish-all --expose中也無效container。
示例使用 Redis 綁定運行 Redis 容器，localhost然后運行該redis-cli命令並通過localhost接口連接到 Redis 服務器。
$ docker run -d --name redis example/redis --bind 127.0.0.1$ # use the redis container's network stack to access localhost $ docker run --rm -it --network container:redis example/redis-cli -h 127.0.0.1
用戶定義的網絡
您可以使用 Docker 網絡驅動程序或外部網絡驅動程序插件來創建網絡。您可以將多個容器連接到同一個網絡。一旦連接到用戶定義的網絡，容器就可以很容易地使用另一個容器的 IP 地址或名稱進行通信。
對於overlay支持多主機連接的網絡或自定義插件，連接到相同多主機網絡但從不同引擎啟動的容器也可以通過這種方式進行通信。
以下示例使用內置bridge網絡驅動程序創建網絡，並在創建的網絡中運行容器
$ docker network create -d bridge my-net $ docker run --network=my-net -itd --name=container3 busybox
Managing /etc/hosts
您的容器將具有/etc/hosts定義容器本身的主機名以及localhost其他一些常見事物的行。該--add-host標志可用於添加更多行/etc/hosts。
$ docker run -it --add-host db-static:86.75.30.9 ubuntu cat /etc/hosts172.17.0.22 09d03f76bf2c fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters127.0.0.1 localhost::1 localhost ip6-localhost ip6-loopback86.75.30.9 db-static
如果容器連接到默認橋接網絡和linked其他容器，則/etc/hosts使用鏈接容器的名稱更新容器的文件。
注意由於 Docker 可能實時更新容器的
/etc/hosts文件，因此容器中的進程最終可能會讀取空的或不完整的/etc/hosts文件。在大多數情況下，再次重試讀取應解決問題。
重新啟動策略（-restart）
--restart在Docker運行中使用標志，您可以指定一個重啟策略，以便在退出時應該或不應該重啟容器。
當重新啟動策略是活性的容器上，它將被顯示為任一Up或Restarting在docker ps。使用docker events查看重啟策略的效果也很有用。
Docker支持以下重啟策略：
|
政策 |
結果 |
|---|---|
|
沒有 |
退出時不要自動重啟容器。這是默認設置。 |
|
對故障：最大重試 |
僅在容器以非零退出狀態退出時才能重新啟動。或者，限制Docker守護程序嘗試重新啟動的次數。 |
|
總是 |
不管退出狀態如何，始終重新啟動容器。當你總是指定時，Docker守護進程將嘗試無限期地重啟容器。無論容器的當前狀態如何，容器也將始終在守護進程啟動時啟動。 |
|
除非，停止 |
無論退出狀態如何，始終重新啟動容器，但如果容器之前已處於停止狀態，則不要在守護進程啟動時啟動它。 |
在每次重新啟動前添加一個不斷增加的延遲（前一延遲的兩倍，從100毫秒開始），以防止服務器泛濫。這意味着守護進程將等待100毫秒，然后等待200毫秒，400,800,1600等，直到on-failure命中限制或者您docker stop或docker rm -f容器。
如果容器重新啟動成功（容器啟動並運行至少10秒鍾），延遲將重置為默認值100 ms。
您可以指定 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（清除）標志組合會導致錯誤。在容器重啟時，連接的客戶端被斷開連接 請參閱--rm本頁后面使用（清理）標志的示例。
例子
$ docker run --restart=always redis
這將運行redis一個始終重啟策略的容器，這樣如果容器退出，Docker 將重新啟動它。
$ docker run --restart=on-failure:10 redis
這將運行redis容器，其重啟策略為on-failure，最大重啟次數為10.如果redis容器以非零退出狀態在一行中退出10次以上，Docker 將中止嘗試重新啟動容器。提供最大重新啟動限制僅適用於故障策略。
退出狀態
退出碼docker run提供了有關容器無法運行或為何退出的信息。當docker run退出時非零碼時，退出代碼遵循chroot標准，見下文：
如果錯誤是 Docker 守護進程本身，則為 125
$ docker run --foo busybox; echo $?# flag provided but not defined: --foo See 'docker run --help'. 125
126 如果 包含的命令不能被調用
$ docker run busybox /etc; echo $?# docker: Error response from daemon: Container command '/etc' could not be invoked. 126
127 如果 包含的命令不能被找到
$ docker run busybox foo; echo $?# docker: Error response from daemon: Container command 'foo' not found or does not exist. 127
退出代碼 的 包含命令否則
$ docker run busybox /bin/sh -c 'exit 3'; echo $?# 3
清理（-rm）
即使在容器退出后，默認情況下容器的文件系統仍然存在。這使調試更容易（因為您可以檢查最終狀態），並且默認情況下保留所有數據。但是如果你正在運行短期的 前台 進程，這些容器文件系統可能真的堆積如山。相反，如果您希望Docker 在容器退出時自動清理容器並移除文件系統，則可以添加該--rm標志：
--rm=false: Automatically remove the container when it exits (incompatible with -d)
注意：設置
--rm標志時，當容器被移除時，Docker 也會刪除與容器關聯的卷。這與運行相似docker rm -v my-container。只有未指定名稱的卷才會被刪除。例如，與docker run --rm -v /foo -v awesome:/bar busybox top，音量/foo將被刪除，但音量/bar不會。通過--volumes-from相同的邏輯將繼承的卷將被刪除 - 如果原始卷指定了名稱，則不會被刪除。
安全配置
--security-opt="label=user:USER" : Set the label user for the container--security-opt="label=role:ROLE" : Set the label role for the container--security-opt="label=type:TYPE" : Set the label type for the container--security-opt="label=level:LEVEL" : Set the label level for the container--security-opt="label=disable" : Turn off label confinement for the container--security-opt="apparmor=PROFILE" : Set the apparmor profile to be applied to the container--security-opt="no-new-privileges:true|false" : Disable/enable container processes from gaining new privileges--security-opt="seccomp=unconfined" : Turn off seccomp confinement for the container--security-opt="seccomp=profile.json": White listed syscalls seccomp Json file to be used as a seccomp filter
您可以通過指定--security-opt標志來覆蓋每個容器的默認標簽方案。在以下命令中指定級別允許您在容器之間共享相同的內容。
$ docker run --security-opt label=level:s0:c100,c200 -it fedora bash
注意：目前不支持自動翻譯MLS標簽。
要禁用此容器的安全標簽而不是使用該--privileged標志運行，請使用以下命令：
$ docker run --security-opt label=disable -it fedora bash
如果您希望容器中的進程采用更嚴格的安全策略，則可以為容器指定備用類型。您可以通過執行以下命令來運行只允許在Apache端口上偵聽的容器：
$ docker run --security-opt label=type:svirt_apache_t -it centos bash
注意：您必須編寫定義
svirt_apache_t類型的策略。
如果你想阻止你的容器進程獲得額外的權限，你可以執行下面的命令：
$ docker run --security-opt no-new-privileges -it centos bash
這意味着提升諸如su或者sudo將不再起作用的特權的命令。它還會導致任何 seccomp 過濾器稍后應用，權限被刪除后，這可能意味着您可以擁有更多限制性的過濾器集。有關更多詳細信息，請參閱內核文檔。
指定一個 init 進程
您可以使用該--init標志來指示 init 過程應該用作容器中的 PID 1。指定init進程可確保在創建的容器內執行init系統的常規職責（如收割僵屍進程）。
使用的默認 init 進程是docker-init在 Docker 守護進程的系統路徑中找到的第一個可執行文件。docker-init包含在默認安裝中的這個二進制文件由tini提供支持。
指定自定義 cgroups
使用該--cgroup-parent標志，您可以傳遞特定的 cgroup 來運行容器。這允許您自行創建和管理 cgroup。您可以為這些 cgroup 定義自定義資源，並將容器放在公共父組下。
運行時對資源的限制
操作員還可以調整容器的性能參數：
|
選項 |
描述 |
|---|---|
|
-m，--memory =“” |
內存限制（格式：<數字> <單位>）。數字是一個正整數。單位可以是b，k，m或g中的一個。最低為4M。 |
|
--memory交換=“” |
內存總量限制（內存+交換，格式：<編號> <單位>）。數字是一個正整數。單位可以是b，k，m或g中的一個。 |
|
--memory預約=“” |
內存軟限制（格式：<編號> <單位>）。數字是一個正整數。單位可以是b，k，m或g中的一個。 |
|
--kernel內存=“” |
內核內存限制（格式：<數字> <單位>）。數字是一個正整數。單位可以是b，k，m或g中的一個。最低為4M。 |
|
-c，--cpu-shares = 0 |
CPU份額（相對重量） |
|
--cpus = 0.000 |
CPU數量。數字是一個小數。0.000表示沒有限制。 |
|
--cpu周期= 0 |
限制CPU CFS（完全公平調度程序）期限 |
|
--cpuset-的CPU = “” |
允許執行的CPU（0-3,0,1） |
|
--cpuset-MEMS = “” |
在其中允許執行的內存節點（MEM）（0-3,0,1）。只對NUMA系統有效。 |
|
--cpu配額= 0 |
限制CPU CFS（完全公平調度程序）配額 |
|
--cpu-RT-周期= 0 |
限制CPU實時期限。以微秒為單位。需要設置父cgroups並且不能高於父級。另請檢查rtprio ulimits。 |
|
--cpu-RT-運行時間= 0 |
限制CPU實時運行時間。以微秒為單位。需要設置父cgroups並且不能高於父級。另請檢查rtprio ulimits。 |
|
--blkio重量= 0 |
塊IO權重（相對權重）接受介於10和1000之間的權重值。 |
|
--blkio-重設備= “” |
阻止IO權重（相對設備權重，格式：DEVICE_NAME：WEIGHT） |
|
--device讀-BPS = “” |
限制設備的讀取速率（格式：<設備路徑>：<編號> <單元>）。數字是一個正整數。單位可以是kb，mb或gb中的一個。 |
|
--device - 寫 - BPS =“” |
限制寫入速率到設備（格式：<device-path>：<number> <unit>）。數字是一個正整數。單位可以是kb，mb或gb中的一個。 |
|
--device讀-IOPS = “” |
限制來自設備的讀取速率（每秒IO）（格式：<device-path>：<number>）。數字是一個正整數。 |
|
--device - 寫 - IOPS =“” |
限制寫入速率（每秒IO）到設備（格式：<device-path>：<number>）。數字是一個正整數。 |
|
--oom殺-禁用=假 |
是否禁用容器的OOM殺手。 |
|
--oom分數ADJ = 0 |
調整容器的OOM首選項（-1000到1000） |
|
--memory-swappiness = “” |
調整容器的內存swappiness行為。接受0到100之間的整數。 |
|
--shm尺寸=“” |
/ dev / shm的大小。格式是<編號> <單位>。數字必須大於0.單位是可選的，可以是b（字節），k（千字節），m（兆字節）或g（千兆字節）。如果您省略了單位，系統會使用字節。如果完全忽略尺寸，則系統使用64米。 |
User memory constraints
我們有四種方法來設置用戶內存使用情況：
|
選項 |
結果 |
|---|---|
|
memory = inf，memory-swap = inf（默認） |
容器沒有內存限制。容器可以根據需要使用盡可能多的內存。 |
|
內存= L <inf，內存交換= inf |
（指定內存並將內存交換設置為-1）容器不允許使用多於L字節的內存，但可以根據需要使用盡可能多的交換（如果主機支持交換內存）。 |
|
內存= L <inf，內存交換= 2 * L |
（指定沒有內存交換的內存）容器不允許使用超過L字節的內存，swap和內存使用率是其中的兩倍。 |
|
內存= L <inf，內存交換= S <inf，L <= S |
（指定內存和內存交換）容器不允許使用多於L字節的內存，交換加內存使用受S限制。 |
例子：
$ docker run -it ubuntu:14.04 /bin/bash
我們沒有設置內存，這意味着容器中的進程可以根據需要使用盡可能多的內存和交換內存。
$ docker run -it -m 300M --memory-swap -1 ubuntu:14.04 /bin/bash
我們設置內存限制和禁用交換內存限制，這意味着容器中的進程可以使用300M內存和盡可能多的交換內存（如果主機支持交換內存）。
$ docker run -it -m 300M ubuntu:14.04 /bin/bash
我們只設置內存限制，這意味着容器中的進程可以使用300M內存和300M交換內存，默認情況下，總虛擬內存大小（-memory-swap）將被設置為內存的兩倍，在這種情況下，內存+ swap 會是2 * 300M，所以進程也可以使用300M交換內存。
$ docker run -it -m 300M --memory-swap 1G ubuntu:14.04 /bin/bash
我們設置了內存和交換內存，因此容器中的進程可以使用 300M 內存和 700M 交換內存。
內存預留是一種內存軟限制，允許更大的內存共享。在正常情況下，容器可以根據需要使用盡可能多的內存，並且僅受限於使用-m/ --memory選項設置的硬限制。當設置了內存預留時，Docker 會檢測內存爭用或內存不足，並強制容器將其消耗限制在預留限制內。
始終將內存預留值設置為低於硬限制，否則硬限制優先。保留0與設置不保留相同。默認情況下（沒有預留設置），內存預留與硬內存限制相同。
內存預留是一項軟限制功能，並不保證不會超出限制。相反，該功能會嘗試確保在內存嚴重競爭時基於預留提示/設置分配內存。
以下示例將內存（-m）限制為 500M，並將內存預留設置為 200M。
$ docker run -it -m 500M --memory-reservation 200M ubuntu:14.04 /bin/bash
在此配置下，當容器消耗的內存超過200M且小於500M時，下一次系統內存回收嘗試將容器內存縮小到200M以下。
以下示例將內存預留設置為1G，但沒有硬內存限制。
$ docker run -it --memory-reservation 1G ubuntu:14.04 /bin/bash
容器可以根據需要使用盡可能多的內存。內存預留設置可確保容器不會消耗太多內存很長時間，因為每個內存回收都會將容器的消耗量縮減到預留量。
默認情況下，如果發生內存不足（OOM）錯誤，內核會殺死容器中的進程。要更改此行為，請使用該--oom-kill-disable選項。只有在您還設置-m/--memory選項的容器上禁用 OOM 殺手。如果-m未設置標志，則可能導致主機內存不足，並且需要殺死主機的系統進程以釋放內存。
以下示例將內存限制為100M，並禁用此容器的 OOM 殺手：
$ docker run -it -m 100M --oom-kill-disable ubuntu:14.04 /bin/bash
以下示例說明了使用該標志的危險方法：
$ docker run -it --oom-kill-disable ubuntu:14.04 /bin/bash
該容器具有無限制的內存，這可能導致主機耗盡內存並需要查殺系統進程以釋放內存。該--oom-score-adj參數是可以改變的選擇優先權，容器就會被殺死，當系統內存不足，負得分使他們不太可能被殺害，並積極分數的可能性較大。
內核內存限制
內核內存與用戶內存根本不同，因為內核內存不能被換出。無法進行交換使得容器可能通過消耗太多內核內存來阻塞系統服務。內核內存包括：
-
堆疊頁面
-
平板頁面
-
插座內存壓力
-
tcp 內存壓力
您可以設置內核內存限制來限制這些內存。例如，每個進程都會消耗一些堆棧頁面。通過限制內核內存，可以防止在內核內存使用率過高時創建新進程。
內核內存永遠不會完全獨立於用戶內存。相反，您在用戶內存限制的上下文中限制內核內存。假設“U”是用戶內存限制，“K”是內核限制。有三種可能的方式來設置限制：
|
選項 |
結果 |
|---|---|
|
U！= 0，K = inf（默認） |
這是使用內核內存之前已經存在的標准內存限制機制。內核內存被完全忽略。 |
|
U！= 0，K <U |
內核內存是用戶內存的一個子集。這種設置在每個cgroup的總內存數量過量的部署中非常有用。絕對不推薦過度使用內核內存限制，因為該方框仍可能耗盡不可回收的內存。在這種情況下，您可以配置K，使所有組的總和永遠不會大於總內存。然后，以系統服務質量為代價自由設置U. |
|
U！= 0，K> U |
由於內核內存電荷也被饋送到用戶計數器，並且為這兩種內存的容器觸發回收。這種配置為管理員提供了統一的內存視圖。對於只想跟蹤內核內存使用情況的人也很有用。 |
例子：
$ docker run -it -m 500M --kernel-memory 50M ubuntu:14.04 /bin/bash
我們設置內存和內核內存，所以容器中的進程總共可以使用500M內存，在這個500M內存中，它可以是50M內核內存。
$ docker run -it --kernel-memory 50M ubuntu:14.04 /bin/bash
我們在不使用-m的情況下設置內核內存，因此容器中的進程可以使用盡可能多的內存，但它們只能使用50M內核內存。
Swappiness constraint
默認情況下，容器的內核可以換出一定比例的匿名頁面。要為容器設置此百分比，請指定--memory-swappiness介於0和100之間的值。值為0將關閉匿名頁面交換。值為100將所有匿名頁面設置為可交換。默認情況下，如果你不使用--memory-swappiness，內存swappiness值將從父項繼承。
例如，您可以設置：
$ docker run -it --memory-swappiness=0 ubuntu:14.04 /bin/bash
如果--memory-swappiness要保留容器的工作集並避免交換性能處罰，設置該選項很有用。
CPU share constraint
默認情況下，所有容器都獲得相同比例的CPU周期。通過相對於所有其他正在運行的容器的權重更改容器的CPU份額權重，可以修改此比例。
要從默認值1024修改比例，請使用-c或--cpu-shares標志將權重設置為2或更高。如果設置為0，系統將忽略該值並使用默認值1024。
該比例僅適用於 CPU 密集型進程正在運行時。當一個容器中的任務空閑時，其他容器可以使用剩余的 CPU 時間。實際的 CPU 時間量取決於系統上運行的容器數量。
例如，考慮三個容器，一個 cpu-share 為1024，另外兩個 cpu-share 設置為512.當所有三個容器中的進程嘗試使用100％的 CPU 時，第一個容器將獲得50％的 CPU 總 CPU 時間。如果添加一個 cpu-share 為1024的第四個容器，則第一個容器只能獲得33％的 CPU。剩下的容器獲得 CPU 的16.5％，16.5％和33％。
在多核系統上，CPU 時間份額分布在所有 CPU 核心上。即使容器的CPU時間限制在100％以內，它也可以使用每個 CPU 內核的100％。
例如，考慮一個具有三個以上內核的系統。如果你開始一個容器{C0}與-c=512運行的一個過程，而另一個容器{C1}與-c=1024運行的兩個過程，這可能會導致CPU份額如下划分：
PID container CPU CPU share100 {C0}0100% of CPU0101 {C1}1100% of CPU1102 {C1}2100% of CPU2
CPU周期約束
默認 CPU CFS（完全公平調度程序）周期為100ms。我們可以使用--cpu-period設置 CPU 的時間段來限制容器的 CPU 使用率。通常--cpu-period應該與--cpu-quota。
例子：
$ docker run -it --cpu-period=50000 --cpu-quota=25000 ubuntu:14.04 /bin/bash
如果有1個 CPU，這意味着容器每50ms可以獲得50％的 CPU 運行時間。
除了使用--cpu-period和--cpu-quota設置 CPU 周期約束外，還可以--cpus使用浮點數指定以實現相同的目的。例如，如果有1個 CPU，--cpus=0.5則會達到與設置--cpu-period=50000和--cpu-quota=25000（50％ CPU）相同的結果。
--cpusis 的默認值是0.000，這意味着沒有限制。
有關更多信息，請參閱CFS有關帶寬限制的文檔。
Cpuset constraint
我們可以設置允許執行容器的 cpus。
例子：
$ docker run -it --cpuset-cpus="1,3" ubuntu:14.04 /bin/bash
這意味着容器中的進程可以在 cpu 1和 cpu 3上執行。
$ docker run -it --cpuset-cpus="0-2" ubuntu:14.04 /bin/bash
這意味着容器中的進程可以在 cpu 0，cpu 1和 cpu 2上執行。
我們可以設置允許執行容器的 mems。只對 NUMA 系統有效。
例子：
$ docker run -it --cpuset-mems="1,3" ubuntu:14.04 /bin/bash
此示例將容器中的進程限制為僅使用內存節點1和3中的內存。
$ docker run -it --cpuset-mems="0-2" ubuntu:14.04 /bin/bash
此示例將容器中的進程限制為僅使用內存節點0,1和2中的內存。
CPU配額限制
該--cpu-quota標志限制了容器的 CPU 使用率。默認的0值允許容器占用100％的 CPU 資源（1個CPU）。CFS（完全公平調度程序）為執行進程處理資源分配，並且是內核使用的默認 Linux 調度程序。將此值設置為50000以將容器限制為 CPU 資源的50％。對於多個 CPU，--cpu-quota根據需要進行調整。有關更多信息，請參閱CFS有關帶寬限制的文檔。
Block IO bandwidth (Blkio) constraint
默認情況下，所有容器都獲得相同比例的塊 IO 帶寬（blkio）。該比例為500.要修改此比例，請使用--blkio-weight標志更改容器的 blkio 權重與所有其他正在運行的容器的權重。
注意： blkio 權重設置僅適用於直接 IO。緩沖 IO 目前不受支持。
該--blkio-weight標志可以將權重設置為10至1000之間的值。例如，下面的命令創建兩個具有不同 blkio 權重的容器：
$ docker run -it --name c1 --blkio-weight 300 ubuntu:14.04 /bin/bash $ docker run -it --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-weight-device="DEVICE_NAME:WEIGHT"標志設置了特定的設備重量。這DEVICE_NAME:WEIGHT是一個包含冒號分隔的設備名稱和權重的字符串。例如，要將/dev/sda設備重量設置為200：
$ docker run -it \ --blkio-weight-device "/dev/sda:200" \ ubuntu
如果您同時指定--blkio-weight和--blkio-weight-device，則 Docker 將使用--blkio-weight默認權重，並使用--blkio-weight-device此值在特定設備上用新值覆蓋此默認值。以下示例使用默認權重300並將/dev/sda該權重設置為以下內容時將覆蓋此默認值200：
$ docker run -it \ --blkio-weight 300 \ --blkio-weight-device "/dev/sda:200" \ ubuntu
該--device-read-bps標志限制了設備的讀取速率（每秒字節數）。例如，該命令創建一個容器並將讀取速率限制為1mb每秒從以下位置開始/dev/sda：
$ docker run -it --device-read-bps /dev/sda:1mb ubuntu
該--device-write-bps標志限制了設備的寫入速率（每秒字節數）。例如，該命令創建一個容器並將寫入速率限制為1mb每秒的寫入速率/dev/sda：
$ docker run -it --device-write-bps /dev/sda:1mb ubuntu
兩種標志都采用<device-path>:<limit>[unit]格式限制。讀取和寫入速率都必須是正整數。您可以指定速率kb（千字節），mb（兆字節）或gb（千兆字節）。
該--device-read-iops標志限制了設備的讀取速率（每秒 IO）。例如，該命令創建一個容器，並且限制了讀出速度，以1000從 IO 每秒/dev/sda：
$ docker run -ti --device-read-iops /dev/sda:1000 ubuntu
該--device-write-iops標志限制寫入速率（每秒 IO）到設備。例如，該命令創建一個容器並將寫入速率限制為每秒1000IO，以便/dev/sda：
$ docker run -ti --device-write-iops /dev/sda:1000 ubuntu
兩種標志都采用<device-path>:<limit>格式限制。讀取和寫入速率都必須是正整數。
其他組
--group-add: Add additional groups to run as
默認情況下，泊塢窗容器進程運行時，為指定用戶查找補充組。如果你想添加更多的組，那么你可以使用這個標志：
$ 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功能
--cap-add: Add Linux capabilities--cap-drop: Drop Linux capabilities--privileged=false: Give extended privileges to this container--device=[]: Allows you to run devices inside the container without the --privileged flag.
默認情況下，Docker 容器是“非特權”的，例如不能在 Docker 容器中運行 Docker 守護進程。這是因為默認情況下容器不允許訪問任何設備，但“特權”容器可以訪問所有設備（請參閱cgroups設備上的文檔）。
當操作員執行時docker run --privileged，Docker 將啟用對主機上所有設備的訪問，並在 AppArmor 或 SELinux 中設置一些配置，以允許容器幾乎對主機的所有訪問權限與主機上容器外運行的進程相同。有關運行的更多信息--privileged可在Docker博客上找到。
如果你想限制訪問特定的設備或設備，你可以使用該--device標志。它允許您指定一個或多個在容器內可訪問的設備。
$ docker run --device=/dev/snd:/dev/snd ...
默認情況下，容器就可以read，write和mknod這些設備。這可以使用:rwm每個--device標志的第三組選項來覆蓋：
$ docker run --device=/dev/sda:/dev/xvdc --rm -it ubuntu fdisk /dev/xvdcCommand (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 功能選項。
|
能力密鑰 |
能力描述 |
|---|---|
|
SETPCAP |
修改過程功能。 |
|
MKNOD |
使用mknod（2）創建特殊文件。 |
|
AUDIT_WRITE |
將記錄寫入內核審計日志。 |
|
CHOWN |
對文件UID和GID進行任意更改（請參見chown（2））。 |
|
NET_RAW |
使用RAW和PACKET套接字。 |
|
DAC_OVERRIDE |
繞過文件讀取，寫入和執行權限檢查。 |
|
FOWNER |
對通常需要進程的文件系統UID的操作繞過權限檢查以匹配文件的UID。 |
|
FSETID |
修改文件時，不要清除set-user-ID和set-group-ID權限位。 |
|
KILL |
繞過發送信號的權限檢查。 |
|
SETGID |
任意操作進程GID和補充GID列表。 |
|
SETUID |
任意操作進程UID。 |
|
NET_BIND_SERVICE |
將套接字綁定到Internet域特權端口（端口號小於1024）。 |
|
SYS_CHROOT |
使用chroot（2），更改根目錄。 |
|
SETFCAP |
設置文件功能。 |
下表顯示了默認情況下未授予的功能，可以添加。
|
Capability Key |
Capability Description |
|---|---|
|
SYS_MODULE |
Load and unload kernel modules. |
|
SYS_RAWIO |
Perform I/O port operations (iopl(2) and ioperm(2)). |
|
SYS_PACCT |
Use acct(2), switch process accounting on or off. |
|
SYS_ADMIN |
Perform a range of system administration operations. |
|
SYS_NICE |
Raise process nice value (nice(2), setpriority(2)) and change the nice value for arbitrary processes. |
|
SYS_RESOURCE |
Override resource Limits. |
|
SYS_TIME |
Set system clock (settimeofday(2), stime(2), adjtimex(2)); set real-time (hardware) clock. |
|
SYS_TTY_CONFIG |
Use vhangup(2); employ various privileged ioctl(2) operations on virtual terminals. |
|
AUDIT_CONTROL |
Enable and disable kernel auditing; change auditing filter rules; retrieve auditing status and filtering rules. |
|
MAC_OVERRIDE |
Allow MAC configuration or state changes. Implemented for the Smack LSM. |
|
MAC_ADMIN |
Override Mandatory Access Control (MAC). Implemented for the Smack Linux Security Module (LSM). |
|
NET_ADMIN |
Perform various network-related operations. |
|
SYSLOG |
Perform privileged syslog(2) operations. |
|
DAC_READ_SEARCH |
Bypass file read permission checks and directory read and execute permission checks. |
|
LINUX_IMMUTABLE |
Set the FS_APPEND_FL and FS_IMMUTABLE_FL i-node flags. |
|
NET_BROADCAST |
Make socket broadcasts, and listen to multicasts. |
|
IPC_LOCK |
Lock memory (mlock(2), mlockall(2), mmap(2), shmctl(2)). |
|
IPC_OWNER |
Bypass permission checks for operations on System V IPC objects. |
|
SYS_PTRACE |
Trace arbitrary processes using ptrace(2). |
|
SYS_BOOT |
Use reboot(2) and kexec_load(2), reboot and load a new kernel for later execution. |
|
LEASE |
Establish leases on arbitrary files (see fcntl(2)). |
|
WAKE_ALARM |
Trigger something that will wake up the system. |
|
BLOCK_SUSPEND |
Employ features that can block system suspend. |
Further reference information is available on the capabilities(7) - Linux man page
兩個標志都支持該值ALL，所以如果運營商想要擁有所有功能，但MKNOD可以使用：
$ docker run --cap-add=ALL --cap-drop=MKNOD ...
為了與網絡堆棧進行交互，而不是使用--privileged它們--cap-add=NET_ADMIN來修改網絡接口。
$ docker run -it --rm ubuntu:14.04 ip link add dummy0 type dummy RTNETLINK answers: Operation not permitted $ docker run -it --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)? yes sven@10.10.10.20's password:root@30aa0cfaf1b5:/# ls -la /mnt/src/docker total 1516drwxrwxr-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....
默認的 seccomp 配置文件將根據選定的功能進行調整，以便允許使用功能所允許的設施，因此，自 Docker 1.12以來，您無需對其進行調整。在 Docker 1.10和1.11中，這沒有發生，可能需要使用自定義的 seccomp 配置文件或--security-opt seccomp=unconfined在添加功能時使用。
Logging drivers (–log-driver)
容器可以具有與 Docker 守護程序不同的日志記錄驅動程序。使用--log-driver=VALUEwith docker run命令配置容器的日志記錄驅動程序。支持以下選項：
|
Driver |
Description |
|---|---|
|
none |
Disables any logging for the container. docker logs won’t be available with this driver. |
|
json-file |
Default logging driver for Docker. Writes JSON messages to file. No logging options are supported for this driver. |
|
syslog |
Syslog logging driver for Docker. Writes log messages to syslog. |
|
journald |
Journald logging driver for Docker. Writes log messages to journald. |
|
gelf |
Graylog Extended Log Format (GELF) logging driver for Docker. Writes log messages to a GELF endpoint likeGraylog or Logstash. |
|
fluentd |
Fluentd logging driver for Docker. Writes log messages to fluentd (forward input). |
|
awslogs |
Amazon CloudWatch Logs logging driver for Docker. Writes log messages to Amazon CloudWatch Logs |
|
splunk |
Splunk logging driver for Docker. Writes log messages to splunk using Event Http Collector. |
該docker logs命令僅適用於json-file和journald日志記錄驅動程序。有關使用記錄驅動程序的詳細信息，請參閱配置記錄驅動程序。
Overriding Dockerfile image defaults
當開發人員從Dockerfile構建圖像或提交時，開發人員可以設置許多默認參數，這些參數在圖像作為容器啟動時生效。
在 Dockerfile 命令的四個不能在運行時被覆蓋：FROM，MAINTAINER，RUN，和ADD。其他的都有相應的覆蓋docker run。我們將通過開發人員在每個Dockerfile指令中設置的內容以及操作員如何覆蓋該設置。
-
CMD（默認命令或選項）
-
入口點（運行時執行的默認命令）
-
EXPOSE（傳入端口）
-
ENV（環境變量）
-
HEALTHCHECK
-
VOLUME（共享文件系統）
-
USER
-
WORKDIR
CMD（默認命令或選項）
回想COMMANDDocker命令行中的可選項：
$ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]
該命令是可選的，因為創建這個命令的人IMAGE可能已經COMMAND使用 Dockerfile CMD指令提供了默認值。作為操作員（從圖像運行容器的人員），CMD只需指定一個新操作即可覆蓋該指令COMMAND。
如果圖片還指定了一個ENTRYPOINTthen，CMD或者COMMAND將其作為參數附加到ENTRYPOINT。
ENTRYPOINT（在運行時執行的默認命令）
--entrypoint="": Overwrite the default entrypoint set by the image
該ENTRYPOINT圖像是類似COMMAND，因為它指定了可執行文件運行容器啟動時，但它是（故意）更難以覆蓋。在ENTRYPOINT給出了一個容器，它的默認性質或行為，所以，當你設置一個ENTRYPOINT可以運行的容器，就好像它是二進制，完全使用默認選項，並且可以在通過更多的選擇傳球COMMAND。但是，有時操作員可能想在容器內部運行其他內容，因此可以ENTRYPOINT在運行時通過使用字符串來指定新的值來覆蓋默認值ENTRYPOINT。以下是如何在已經設置為自動運行其他內容（如/usr/bin/redis-server）的容器中運行shell的示例：
$ docker run -it --entrypoint /bin/bash example/redis
或者如何將更多參數傳遞給該入口點的兩個示例：
$ docker run -it --entrypoint /bin/bash example/redis -c ls -l $ docker run -it --entrypoint /usr/bin/redis-cli example/redis --help
您可以通過傳遞空字符串來重置容器入口點，例如：
$ docker run -it --entrypoint="" mysql bash
注意：傳遞
--entrypoint將清除圖像上設置的任何默認命令（即CMD用於構建它的Dockerfile中的任何指令）。
EXPOSE (incoming ports)
以下run命令選項適用於容器網絡：
--expose=[]: Expose a port or a range of ports inside the container. These are additional to those exposed by the `EXPOSE` instruction-P : 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選項添加到暴露的端口。
要顯示容器的內部端口，操作員可以使用-P或-p標志啟動容器。暴露的端口可以在主機上訪問，並且端口可供任何可以連接到主機的客戶端使用。
該-P選項將所有端口發布到主機接口。Docker 將每個暴露的端口綁定到主機上的隨機端口。端口范圍在由...定義的臨時端口范圍內/proc/sys/net/ipv4/ip_local_port_range。使用該-p標志來顯式映射單個端口或端口范圍。
容器（服務偵聽的地方）中的端口號不需要與容器外部（客戶端連接的地方）上公開的端口號相匹配。例如，在容器內，HTTP 服務正在端口80上進行偵聽（因此圖像開發人員EXPOSE 80在 Dockerfile 中指定）。在運行時，端口可能會綁定到主機上的42800。要找到主機端口和外露端口之間的映射，請使用docker port。
如果運營商--link在默認網橋網絡中啟動新的客戶端容器時使用，則客戶端容器可以通過專用網絡接口訪問公開的端口。如果--link在 Docker 網絡概述中描述的在用戶定義的網絡中啟動容器時使用，它將為要鏈接的容器提供一個命名別名。
ENV (environment variables)
Docker 在創建 Linux 容器時會自動設置一些環境變量。在創建 Windows 容器時，Docker 不會設置任何環境變量。
為 Linux 容器設置以下環境變量：
|
變量 |
值 |
|---|---|
|
家 |
根據USER的值進行設置 |
|
主機名 |
與容器關聯的主機名 |
|
路徑 |
包括流行的目錄，例如/ usr / local / sbin：/ usr / local / bin：/ usr / sbin：/ usr / bin：/ sbin：/ bin |
|
術語 |
xterm如果容器被分配了偽TTY |
另外，操作員可以通過使用一個或多個標志來設置容器中的任何環境變量-e，甚至覆蓋上面提到的那些標志，或者已經由開發人員用 Dockerfile 定義ENV。如果操作符命名環境變量而不指定值，則命名變量的當前值會傳播到容器的環境中：
$ export today=Wednesday $ docker run -e "deep=purple" -e today --rm alpine env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOSTNAME=d2219b854598 deep=purple today=Wednesday HOME=/root
PS C:\> docker run --rm -e "foo=bar" microsoft/nanoserver cmd /s /c setALLUSERSPROFILE=C:\ProgramData APPDATA=C:\Users\ContainerAdministrator\AppData\Roaming CommonProgramFiles=C:\Program Files\Common FilesCommonProgramFiles(x86)=C:\Program Files (x86)\Common Files CommonProgramW6432=C:\Program Files\Common Files COMPUTERNAME=C2FAEFCC8253 ComSpec=C:\Windows\system32\cmd.exe foo=bar LOCALAPPDATA=C:\Users\ContainerAdministrator\AppData\Local NUMBER_OF_PROCESSORS=8OS=Windows_NT Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Users\ContainerAdministrator\AppData\Local\Microsoft\WindowsApps PATHEXT=.COM;.EXE;.BAT;.CMD PROCESSOR_ARCHITECTURE=AMD64 PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 62 Stepping 4, GenuineIntel PROCESSOR_LEVEL=6PROCESSOR_REVISION=3e04ProgramData=C:\ProgramData ProgramFiles=C:\Program FilesProgramFiles(x86)=C:\Program Files (x86)ProgramW6432=C:\Program Files PROMPT=$P$G PUBLIC=C:\Users\Public SystemDrive=C:SystemRoot=C:\Windows TEMP=C:\Users\ContainerAdministrator\AppData\Local\Temp TMP=C:\Users\ContainerAdministrator\AppData\Local\Temp USERDOMAIN=User Manager USERNAME=ContainerAdministrator USERPROFILE=C:\Users\ContainerAdministrator windir=C:\Windows
同樣，操作員可以設置HOSTNAME（Linux）或COMPUTERNAME（Windows）-h。
健康檢查
--health-cmd Command to run to check health --health-interval Time between running the check --health-retries Consecutive failures needed to report unhealthy --health-timeout Maximum time to allow one check to run --health-start-period Start period for the container to initialize before starting health-retries countdown --no-healthcheck Disable any container-specified HEALTHCHECK
例子：
$ docker run --name=test -d \ --health-cmd='stat /etc/passwd || exit 1' \ --health-interval=2s \
busybox sleep 1d
$ sleep 2; docker inspect --format='{{.State.Health.Status}}' test
healthy
$ docker exec test rm /etc/passwd
$ sleep 2; docker inspect --format='{{json .State.Health}}' test{ "Status": "unhealthy", "FailingStreak": 3, "Log": [ { "Start": "2016-05-25T17:22:04.635478668Z", "End": "2016-05-25T17:22:04.7272552Z", "ExitCode": 0, "Output": " File: /etc/passwd\n Size: 334 \tBlocks: 8 IO Block: 4096 regular file\nDevice: 32h/50d\tInode: 12 Links: 1\nAccess: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root)\nAccess: 2015-12-05 22:05:32.000000000\nModify: 2015..." }, { "Start": "2016-05-25T17:22:06.732900633Z", "End": "2016-05-25T17:22:06.822168935Z", "ExitCode": 0, "Output": " File: /etc/passwd\n Size: 334 \tBlocks: 8 IO Block: 4096 regular file\nDevice: 32h/50d\tInode: 12 Links: 1\nAccess: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root)\nAccess: 2015-12-05 22:05:32.000000000\nModify: 2015..." }, { "Start": "2016-05-25T17:22:08.823956535Z", "End": "2016-05-25T17:22:08.897359124Z", "ExitCode": 1, "Output": "stat: can't stat '/etc/passwd': No such file or directory\n" }, { "Start": "2016-05-25T17:22:10.898802931Z", "End": "2016-05-25T17:22:10.969631866Z", "ExitCode": 1, "Output": "stat: can't stat '/etc/passwd': No such file or directory\n" }, { "Start": "2016-05-25T17:22:12.971033523Z", "End": "2016-05-25T17:22:13.082015516Z", "ExitCode": 1, "Output": "stat: can't stat '/etc/passwd': No such file or directory\n" } ]}
docker ps輸出中還顯示健康狀況。
TMPFS (mount tmpfs filesystems)
--tmpfs=[]: Create a tmpfs mount with: container-dir[:<options>], where the options are identical to the Linux 'mount -t tmpfs -o' command.
下面的例子中安裝一個空的 tmpfs 與容器rw，noexec，nosuid，和size=65536k選項。
$ docker run -d --tmpfs /run:rw,noexec,nosuid,size=65536k my_image
VOLUME (shared filesystems)
-v, --volume=[host-src:]container-dest[:<options>]: Bind mount a volume.The comma-delimited `options` are [rw|ro], [z|Z],[[r]shared|[r]slave|[r]private], and [nocopy].The 'host-src' is an absolute path or a name value.If neither 'rw' or 'ro' is specified then the volume is mounted inread-write mode.The `nocopy` modes is used to disable automatic copying requested volume path in the container to the volume storage location.For named volumes, `copy` is the default mode. Copy modes are not supportedfor bind-mounted volumes.--volumes-from="": Mount all volumes from the given container(s)
注意：當使用 systemd 管理 Docker 守護進程的啟動和停止時，在 systemd 單元文件中，有一個選項可以控制 Docker 守護進程本身的掛載傳播
MountFlags。此設置的值可能會導致 Docker 無法看到掛載點在掛載點上進行的掛載傳播更改。例如，如果此值為slave，您可能無法在卷上使用shared或rshared傳播。
卷命令足夠復雜，可以在“ 管理容器中的數據”部分中擁有自己的文檔。開發人員可以定義VOLUME與圖像關聯的一個或多個圖像，但只有操作員可以從一個容器訪問另一個容器（或從容器訪問主機上安裝的卷）。
在container-dest必須始終是絕對路徑，例如/src/docs。該host-src可以是絕對路徑或name值。如果你提供了一個絕對路徑host-dir，Docker 綁定到你指定的路徑。如果你提供一個name，Docker 通過它創建一個命名的卷name。
一個name值必須以字母數字字符，接着啟動a-z0-9，_（下划線）， .（周期）或-（連字符）。絕對路徑以/（正斜杠）開頭。
例如，您可以指定一個值/foo或foo一個host-src值。如果你提供這個/foo值，Docker 會創建一個綁定掛載。如果您提供foo規范，Docker 將創建一個命名卷。
USER
root（id = 0）是容器內的默認用戶。圖像開發人員可以創建更多用戶。這些用戶可以通過名稱訪問。在傳遞數字標識時，用戶不必在容器中存在。
開發人員可以設置默認用戶使用 Dockerfile USER指令運行第一個進程。啟動容器時，操作員可以USER通過傳遞-u選項來覆蓋指令。
-u="", --user="": Sets the username or UID used and optionally the groupname or GID for the specified command.The followings examples are all valid:--user=[ user | user:group | uid | uid:gid | user:gid | uid:group ]
注意：如果你傳遞一個數字 uid，它必須在0-2147483647的范圍內。
WORKDIR
在容器中運行二進制文件的默認工作目錄是根目錄（/），但開發人員可以使用 Dockerfile WORKDIR命令設置不同的默認值。操作員可以通過以下方式覆蓋此項：
-w="": Working directory inside the container