月份：2017年1月

上下文

Docker从Dockerfile和“上下文”构建镜像。一个构建上下文是位于特定的PATH或URL的文件。构建过程可以引用上下文中的任何文件。例如，可以使用ADD指定引用上下文中的一个文件。
URL参数可以引用三种类型的资源：Git仓库，预打包的tarball上下文和纯文本文件。

Git仓库

当URL参数指向Git仓库的位置时，这个仓库就作为此次的构建上下文。系统使用git clone –depth 1 –recursive命令递归克隆这个仓库和它的子模块。此命令运行在本地主机的临时目录下。当命令执行成功后，这个目录作为上下文发送给Docker daemon。
在Git URL上可以配置上下文，使用冒号分隔。第一部分指定了将要下载的git仓库以及分支，tag或提交的SHA。第二部分指定一个子目录作为构建上下文。
例如，下面的命令使用了container分支的docker目录作为上下文。

下面是Git URL可能的所有有效的方式：

构建语法后缀	使用的提交	使用的上下文
myrepo.git	refs/heads/master	/
myrepo.git#mytag	refs/tags/mytag	/
myrepo.git#mybranch	refs/heads/mybranch	/
myrepo.git#abcdef	sha1 = abcdef	/
myrepo.git#:myfolder	refs/heads/master	/myfolder
myrepo.git#master:myfolder	refs/heads/master	/myfolder
myrepo.git#mytag:myfolder	refs/tags/mytag	/myfolder
myrepo.git#mybranch:myfolder	refs/heads/mybranch	/myfolder
myrepo.git#abcdef:myfolder	sha1 = abcdef	/myfolder

Tarball上下文

如果指定一个远程的tarball文件URL，这个URL将发送给daemon。

daemon将在其所运行的主机完成这个URL的下载。docker daemon下载这个context.tar.gz并使用它作为构建上下文。Tarball必须是以标准的tar Unix格式打包并使用‘xz’, ‘bzip2’, ‘gzip’或可识别的格式中的其中一种压缩。

文本文件

不指定上下文的话，可以在URL中传递单个Dockerfile或通过STDIN管道传输文件。要从STDIN管道传输一个Dockerfile:

Windows使用Powershell，运行：

如果使用STDIN或指定一个URL指向纯文本文件，系统把内容放置到称为Dockerfile的文件，其中的-f,–file选项将忽略。在这种情况下没有上下文。
默认下docker build命令在构建上下文的根目录查找Dockerfile文件。使用-f,–file选项可以指定一个其它的文件。这个当同一组文件用于多个构建时会有帮助。path必须是构建上下文内的一个文件。如果指定一个相对路径，那么这个路径就是相对于上下文根目录的。
在大多数情况下，最好把每个Dockerfile放置到一个空的目录。然后只添加Dockerfile中需要用到的文件。为了提高构建性能，可以使用.dockerignore来排除用不到的文件。
如果Docker客户端与daemon断开了连接，构建就取消了。这种情况发生在使用CTRL-c中断Docker客户端或Docker客户端被kill。

示例

使用PATH构建

此示例指定PATH为.，所以将tar打包当前目录的所有文件并发送到Docker daemon。PATH用来指定构建上下文的位置。记住daemon可能运行在远程机器，在客户端侧不会解析Dockerfile(当执行docker build时)。意味着发送所有在PATH位置的文件，而不只是在Dockerfile的ADD指令中指定的文件。

使用URL构建

这将克隆GitHub的仓库并使用它作为上下文。仓库根目录的名为Dockerfile的文件作为用来构建镜像的Dockerfile。可以使用git://或git@scheme指定任意的git仓库。

这个发送了http://server/ctx.tar.gz到docker daemon，然后daemon下载并解压这个tarball。-f ctx/Dockerfile参数指定在ctx.tar.gz的用于构建镜像的Dockerfile。在这个Dockerfile中的任何ADD命令引用本地路径的必须是相对于ctx.tar.gz内的根目录。在上面的示例中，tarball包含了一个目录ctx/，所以ADD ctx/container.cfg /能正常工作。

使用-构建

这将从STDIN读取一个Dockerfile，没有提供上下文。由于缺少上下文，没有本地目录发送到docker daemon。因此没有上下文，所以Dockerfile ADD指令只能引用一个远程的URL。

这将从STDIN读取一个压缩文件作为上下文构建镜像。支持的格式有bzip2, gzip和xz.

Tag镜像(-t)

这个构建出来的镜像名称为vieux/apache，tag为2.0。
可以应用多个tag到一个镜像。例如，可以应用latest tag到一个新建的镜像，再添加另一个tag来关联一个特定的版本。例如tag一个镜像为whenry/fedora-jboss:latest和whenry/fedora-jboss:v2.1,使用如下命令：

默认情况下，以JSON数组格式输出所有结果。如果容器和镜像有相同的名称，当没有指定类型时将返回容器的JSON信息。如果指定了格式，给定的模式将格式化每个结果。
Go’s text/template描述了这个格式的所有细节。

示例

大多数情况，可以非常简单地从JSON取任何的字段。

获取实例IP地址

获取实例MAC地址

获取实例日志路径

获取任务镜像名称

列出所有绑定的端口

可以在结果中循环数组和映射以产生简单的文本输出：

查找一个指定的端口映射

当字段名以一个数字开头时，.Field语法就失效了，不过可以用模板语言的index函数实现。.NetworkSettings.Ports区块包含内部端口映射到外部地址/端口对象列表的映射。要获取数字公共端口，可以使用索引查找特定端口映射，然后索引0包含其中的第一个对象。 然后我们要求HostPort字段获取公共地址。

获取JSON格式的子区块

如果请求一个字段本身是一个包含其他字段的结构，默认情况下你会得到内部值的Go样式转储。Docker添加了一个模板函数json，它可以应用于以JSON格式获取结果。

这个命令显示有关docker安装的系统信息。显示的信息包括内核版本，容器和镜像的数量。镜像的数量显示的是无重复的镜像数量。使用不同名称tag同一样镜像算一个镜像。
基于使用的存储驱动，会显示额外的信息，例如存储池名称，数据文件，元数据文件，已用的数据空间，总的数据空间，已用的元数据空间和总的元数据空间。
数据文件是用来存储镜像的，元数据文件则存储关于那些存储镜像的元数据。当首次启动docker时，将在挂载到/var/lib/docker的数据卷分配数据空间和元数据空间。

示例

显示docker系统信息：
下面是运行在ubuntu的daemon输出样本，使用的是overlay存储驱动并且是两个节点集群的其中一个节点：

全局-D选项通知docker命令输出调试信息。
下面的示例显示运行在Red Hat Enterprise Linux系统的daemon的输出信息。使用的是devicemapper存储驱动。

用法：

以上选项值为[]可以指定多次。dockerd是管理容器的常驻进程。daemon和客户端使用了不同的二进制文件。直接键入dockerd执行daemon。

Daemon socket选项

docker daemon监听三个不同类型的socket:unix,tcp和fd来处理Docker Remote API请求。
默认下，unix域名套接字[或IPC套接字]创建在/var/run/docker.sock，需要root权限或用户属于docker组。
如果需要开放docker daemon远程访问，需要启用tcp套接字。请注意默认的daemon配置没有加密和验证直接就能访问daemon – 应该使用内置的HTTPS加密的socket，或在它前面放置一个安全的web代理。可以使用-H tcp://0.0.0.0:2375在所有网络接口上监听2375端口，也可以使用-H tcp://192.168.59.103:2375在指定的网络接口监听。一般约定使用端口2375来监听非加密请求，使用2376来监听加密请求。

注意：如果使用了HTTPS加密套接字，记住只支持TLS1.0和以上版本的协议。SSLv3协议和之前的版本由于安全原因不再支持。

在基于systemd的系统，可以通过systemd socket activation使用dockerd -H fd://与daemon通信。使用fd://在大多数情况工作良好，不过也可以指定一个单独的sockets:dockerd -H fd://。如果指定的socket activated文件没有找到，docker将退出。
可以指定多次-H选项来设置docker监听多个sockets:

如果docker client没有指定-H选项，它将尝试查找环境变量DOCKER_HOST。

设置环境变量DOCKER_TLS_VERIFY为任何一个非空值，等同于–tlsverify参数。如下是等效的：

Docker客户端将遵守HTTP_PROXY，HTTPS_PROXY和NO_PROXY环境变量（或其小写版本）。 HTTPS_PROXY优先于HTTP_PROXY。

绑定docker到另一个host/port或unix socket

警告：更改默认的docker daemon绑定到一个TCP端口或Unix docker用户组会允许非root用户获取daemon的root访问权限，这将增加安全风险。确保仔细控制docker的访问权限。如果绑定到一个TCP端口，那么能够访问此端口的用户将对docker的完全的访问权限；所以不建议在一个开放的网络绑定端口。

使用-H参数可以使docker daemon监听在指定IP和端口。默认监听unix:///var/run/docker.sock只允许root用户在本地连接。可以设置0.0.0.0:2375或指定一个主机IP来给所有人访问权限，不过这不推荐因为这非常不安全。
类似的，docker客户端可以使用-H连接到一个自定义端口。Linux上docker客户端默认连接到unix:///var/run/docker.sock，windows连接到tcp://127.0.0.1:2376。
-H接受如下的格式：

例如：

tcp:// -> 监听tcp的127.0.0.1，当TLS加密启用时使用2376端口，否则使用2375端口。

tcp://host:2375 -> 监听在tcp的host:2375

tcp://host:2375/path -> 监听在tcp的host:2375并添加前缀路径到所有请求。

unix://path/to/socket -> 监听unix socket，路径为path/to/socket。

当-H为空时，与没有指定-H选项时的默认值一样。
-H也接受TCP绑定的简短格式：host: 或 host:port 或 :port
以daemon模式运行docker:

下载ubuntu镜像：

可以使用多个-H，例如，既监听TCP也监听unix socket

daemon DNS选项

为所有docker容器设置DNS服务器，使用:

为所有docker容器设置DNS search domain，使用:

Insecure registries

Docker把私有的registry分为安全或不安全的。下面章节，我们用registry表示私有的registry，myregistry:5000作为私有的registry的示例。
一个安全的registry使用TLS且它的CA证书副本在docker主机的/etc/docker/certs.d/myregistry:5000/ca.crt。一个不安全的registry不使用TLS或使用了TLS，但其CA证书没有在docker daemon指定的路径或是错误的CA。
默认下，docker假设所有的，除了本地的，registry是安全的。如果Docker假设这个registry是安全的，那与一个不安全的registry通信是不可能的。为了与一个不安全的registry通信，docker daemon要求以下面两种格式其中一种指定–insecure-registry：

–insecure-registry myregistry:5000 告诉docker daemon myregistry:5000是不安全的registry。

–insecure-registry 10.1.0.0/16 告诉docker daemon所有的registry域名解析出的IP地址在这个IP范围的registry是不安全的。

这个参数可以使用多次来指定多个不安全的registry。
如果一个不安全的registry没有标记为不安全的，docker pull,docker push和docker search将会得到一个错误来提示用户使用安全的registry或在daemon设置–insecure-registry参数。
本地的registry，那么解析出来的IP在127.0.0.0/8范围的，从Docker 1.3.2起就自动标记为不安全的registry。不推荐依赖这个，因为未来版本可能会更改。
启用–insecure-registry，允许非加密或不被信任的通信，在运行一个本地registry会有用。不过，因为这会产生安全漏洞，它只应该作为测试目的。 为了提高安全性，用户应该将CA添加到其系统的受信任CA列表中，而不是启用–insecure-registry。

daemon配置文件

–config-file允许设置JSON格式的daemon配置文件。这个文件使用与选项一样的名称作为key，除了那么允许多个值的选项，那就使用这个选项名称的复数，如label选项，使用labels作为key。
在配置文件的选项设置不能与命令行的选项设置冲突。如果一个选项在配置文件和命令行设置了，docker daemon将会启动失败。我们这样做是为了避免在配置文件重载时，会静默忽略对此选项的修改。

要列出可用的命令，运行不带参数的docker或执行docker help:

取决于你的docker系统配置，可能需要在每个docker命令前加sudo。要避免docker使用sudo，可以创建一个unix组，称为docker，并添加用户到这个组。

环境变量

docker命令行支持以下环境变量：

DOCKER_API_VERSION 使用的API版本[如1.19]

DOCKER_CONFIG 客户端配置文件路径

DOCKER_CERT_PATH 验证密钥文件路径

DOCKER_DRIVER 使用的驱动

DOCKER_HOST 连接到的Daemon socket

DOCKER_NOWARN_KERNEL_VERSION 避免Linux内核不适合Docker的警告。

DOCKER_RAMDISK 设置这个将禁用pivot_root

DOCKER_TLS_VERIFY 当设置时Docker使用TLS并验证远程。

DOCKER_CONTENT_TRUST 设置时Docker使用notary来签名和验证镜像。

DOCKER_CONTENT_TRUST_SERVER Notary server的URL。

DOCKER_TMPDIR docker临时文件路径。

由于docker使用Go开发，你也可以使用Go运行时使用的环境变量。特别是，下面这些会有用：

HTTP_PROXY

HTTPS_PROXY

NO_PROXY

这些Go环境变量是区分大小写的。

配置文件

默认下，docker命令行把它的配置文件存储到你的$HOME目录下的.docker文件中。不过你可以通过DOCKER_CONFIG环境变量或–config命令行选项来指定一个不同的路径。如果两个都指定了，那么–config选项将覆盖DOCKER_CONFIG环境变量。例如：

指示当docker执行ps命令时使用在~/testconfigs/目录下的配置文件。
Docker管理配置目录中的大多数文件，建议不要修改它们。不过可以修改config.json文件来控制docker命令行为的某些方面。
目前可以使用环境变量或命令行选项来更改docker命令行为。也可以使用config.json中的选项来修改一些相同的行为。当使用这些机制时，必须记住它们的优先级。命令行选项覆盖环境变量，环境变量覆盖在config.json文件中的属性。
config.json文件存储几个以JSON编码的属性：
HttpHeaders属性指定一些请求头，来包括在从Docker客户端发送到daemon的消息中。Docker不会尝试解析或理解这些请求头；它仅仅把它们放置在消息中。Docker不会允许这些请求头修改已经存在的请求头。
psFormat属性指定docker ps的默认输出格式。当docker ps没有指定–format选项时，Docker客户端使用这个属性。如果这个属性没有设置，客户端恢复为默认表格式。

下面是可用于限制容器资源使用的选项：

限制指定设备读取速率(每秒IO操作数)[格式::]。number为正整数。

选项	描述
-m, –memory=””	内存限制[格式：[]]。number是正整数。unit可以是b,k,m或g。最小4M。
–memory-swap=””	总内存限制[memory+swap,格式:[]]。number是正整数。unit可以是b,k,m或g。
–memory-reservation=””	内存软限制[格式：[]]。number是正整数。unit可以是b,k,m或g。
–kernel-memory=””	内核内存限制[格式：[]]。number是正整数。unit可以是b,k,m或g。
-c, –cpu-shares=0	CPU share（相对权重）
–cpu-period=0	限制CPU CFS（完全公平调度程序）周期
–cpuset-cpus=””	允许执行的CPU（0-3，0,1）
–cpuset-mems=””	允许执行的内存节点（MEMs）（0-3,0,1）。 仅在NUMA系统上有效。
–cpu-quota=0	限制CPU CFS（完全公平调度程序）配额
–blkio-weight=0	块IO权重（相对权重）接受10和1000之间的权重值。
–blkio-weight-device=””	块IO权重（相对设备权重，格式：DEVICE_NAME：WEIGHT）
–device-read-bps=””	限制指定设备的读取速率[格式::[]]。number是一个正整数。unit可以是kb,mb或gb。
–device-write-bps=””	限制指定设备的写入速率[格式::[]]。number是一个正整数。unit可以是kb,mb或gb。
–device-read-iops=””
–device-write-iops=””	限制指定设备写入速率(每秒IO操作数)[格式::]。number为正整数。
–oom-kill-disable=false	是否禁用容器的OOM Killer
–oom-score-adj=0	调整容器的OOM偏好 (-1000 to 1000)
–memory-swappiness=””	调整容器的内存swappiness行为。 接受介于0和100之间的整数。
–shm-size=””	/dev/shm的大小。格式为:。number必须大于0。unit可选，可以是b,k,m或g。如果不指定unit，系统默认使用字节。如果此参数不指定，默认使用64m。

用户内存约束

有四种方式来设置用户内存使用:

选项	结果
memory=inf, memory-swap=inf (default)	对容器内存使用无限制。容器可以根据需要使用尽可能多的内存。
memory=L<inf, memory-swap=inf	[设置memory为正整数并设置memory-swap为-1]容器不允许使用超过L字节的内存，不过可以根据需要使用尽可能多的swap[如果主机支持swap内存]
memory=L<inf, memory-swap=2*L	[只设置memory，不设置memory-swap]容器不允许使用超过L字节内存，swap加上memory总共不超过两倍L。
memory=L<inf, memory-swap=S<inf, L<=S	[memory和memory-swap都设置]容器不允许使用超过L字节内存，swap加上memory不能超过S。

示例:

这个示例我们没有设置内存限制，意味着容器进程可以根据需要使用尽可能多的内存和swap。

我们设置了memory限制，取消了swap内存限制，意味着容器进程可以使用300M内存，且可以按需使用尽可能多的swap[如果主机支持swap内存]。

我们只设置memory限制，意味着容器进程可以使用300M内存和300M swap，默认下，虚拟内存总共大小[-memory-swap]将设置为memory的两倍大小，所以在这种情况下，memory+swap将是2*300M，所以进程能使用300M swap内存。

memory和swap内存都设置了，所以容器进程能使用300M内存和700M swap内存。
内存预留(Memory reservation)是一种内存软限制，允许更大的内存共享。正常情况下，容器可以根据需要使用尽可能多的内存，且仅被硬限制-m/–memory限制。当设置了内存预留，Docker检测内存争用或低内存，并强制容器将其内存消耗限制为预留限制。
始终设置内存预留小于硬限制，否则硬限制优先触发。设置reservation为0表示不做限制。默认下[没有设置预留]，内存预留与内存硬限制一样。
内存预留是一个软限制功能，不能保证不会超过限制。而是，这个功能尝试确保的是，当内存争用严重时，内存就按预留设置分配。
以下示例限制内存[-m]为500M，内存软限制200M。

在这个配置下，当容器消耗内存超过200M，小于500M时，下一个系统内存回收将尝试缩减容器内存到200M以下。
以下示例设置内存软限制为1G，没有设置内存硬限制。

容器可以按需使用尽可能多的内存。这个内存软限制设置只是确保容器不会长时间消耗过多内存，因为每次内存回收就缩减容器内存消耗到软限制。默认下，如果out-of-memory[OOM]错误发生，内核将杀死容器的进程。要更改这个行为，使用–oom-kill-disable选项。这个只在容器设置了-m/–memory选项时才禁止OOM killer。如果-m没有设置，这会导致消耗完主机内存，然后需要杀掉主机系统进程来释放内存。
以下示例限制内存为100M并禁止容器的OOM killer：

以下示例说明了使用这个选项的一种危险方式：

这个容器可以无限制使用内存，这会导致主机消耗完内存，然后需要杀掉系统进程来释放内存。–oom-score-adj参数可以设置当系统内存不足时哪些容器将被杀死的优先级，数字越大越容易被杀死。

内核内存约束

内核内存不同于用户内存，因为内核内存不能交换到硬盘。内核内存无法swap可能会当容器消耗过多的内核内存时导致其阻塞系统服务。内核内存包括：

stack pages

slab pages

sockets memory pressure

tcp memory pressure

可以设置内核内存限制来约束这些类型的内存。例如，每个进程都会消耗一些stack pages。通过限制内核内存，当内核内存使用过多时，阻止新进程的创建。
内核内存不会完全独立用户内存。而是，在用户内存限制的上下文中限制内核内存。假设”U”是用户内存限制，”K”是内核限制。有三种可能的方式设置限制：

选项	结果
U != 0, K = inf (default)	这个是在使用内核内存已经存在了的标准内存限制机制。内核内存是完全忽略的。
U != 0, K < U	内核内存是用户内存的一个子集。这个设置适合用在每个cgroup的内存总量已经过度使用的部署中。不建议过度使用内核内存限制，因为这样仍然会消耗完不可回收的内存。在这种情况下，可以配置K以便所有的groups总数不会超过总内存。然后，以系统的服务质量为代价自由设置U。
U != 0, K > U	因为内核内存的消耗也会反馈到用户计数器中，且容器的两种类型的内存也触发回收。这个配置给了管理员一个内存的统一视图。对仅仅想要追踪内核内存使用情况的用户也有帮助。

示例：

memory和内核memory都设置了，所以容器进程可以使用总共500M的内存，在500M内存中，可以使用最高50M内核内存。

这里只设置了内核内存限制，所以容器进程可以使用尽可能多的内存，不过只可以使用50M的内核内存。

Swappiness约束

默认下，容器内核可以设置交换指定百分比的匿名页面。要设置这个百分比，可以设置–memory-swappiness为0-100的值。0表示关闭匿名页面交换。100表示设置所有匿名页面可交换。默认下，如果没有设置memory-swappiness，内存swappiness的值将从父级继承。
例如，设置：

当希望保留容器的工作集并避免交换性能损失时，设置–memory-swappiness选项非常有用。

CPU share限制

默认下，所有的容器都得到相同比例的CPU周期。这个比例可以通过改变容器的CPU share权重来更改，这个权重是相对于所有其它运行中的容器。
要更改默认的1024比例，使用-c或–cpu-shares设置权限为2或更高。如果为0，系统将忽略这个值并使用默认的1024。
这个比例只在当CPU密集型进程运行时应用。当一个容器空闲时，其它容器可以使用剩余CPU时间。实际的CPU时间总数根据运行在系统上的容器数量不同。
例如，有三个容器，一个的cpu-share为1024，其它两个cpu-share为512。当所有三个容器进程尝试使用100%的CPU时，第一个容器将得到50%的CPU时间。如果添加一个cpu-share为1024的容器，第一个容器只得到33%的CPU。其余的容器得到16.5%, 16.5%和 33%的CPU时间。
在一个多核系统，CPU时间的份额分布在所有CPU内核上。即使一个容器限制为小于100%的CPU，它也能使用每个单独CPU核的100%时间。
例如，有一个越过3核的系统。如果启动一个容器{C0}，-c=512，只运行一个进程，另一个容器{C1}，-c=1024，运行两个进程，cpu shares分配如下：

CPU周期约束

默认的CPU CFS(完全公平调度器)周期为100ms。我们可以使用–cpu-period来设置CPU周期来限制容器CPU的使用。通常–cpu-period和–cpu-quota配合使用。
示例：

如果只有1个CPU，这意味着容器可以每50ms获得50％的CPU运行时间。
更多信息，参考CFS有关带宽限制的文档

Cpuset约束

我们可以设置允许容器在哪个CPU执行。
示例：

这个示例意思是容器可以在cpu1和cpu3执行。

意思是容器可以在cpu 0, cpu 1和 cpu 2执行。
我们可以设置允许容器在哪个mems执行。只在NUMA系统有效。
示例：

这个示例限制容器进程只能使用在memory节点1和3的内存。

这个示例限制容器进程只能使用在memory节点0，1和2的内存。

CPU配额约束

–cpu-quota标志限制容器的CPU使用率。默认值0允许容器占用100％的CPU资源（1个CPU）。CFS（完全公平调度器）处理执行进程的资源分配，并且是内核使用的默认Linux调度程序。将此值设置为50000，以将容器限制为CPU资源的50％。对于多个CPU，必要时调整–cpu-quota。更多信息，参考CFS有关带宽限制的文档

块IO带宽（Blkio）约束

默认下，所有的容器获得相同比例的块IO带宽[bokio]。这个比例是500。要更改这个比例，使用–bokio-weight参数。

注意：bokio目前只支持直接IO。缓冲IO目前不支持。

–blkio-weight参数可以设置10到100的值。例如，下面的命令创建两个容器不同的bokio权重：

如果同时在这两个容器执行块IO操作，例如：

你会发现这两个容器执行块操作所需的时间的比例与bokio权重的比较一样。
–blkio-weight-device=”DEVICE_NAME:WEIGHT”设置一个指定设备的权重。DEVICE_NAME:WEIGHT是一个包含设备名称与权重，冒号分隔的字符串。例如，要设置/dev/sda设备权重为200:

如果–blkio-weight和–blkio-weight-device两个都设置了，docker使用–blkio-weight作为默认权重，并使用–blkio-weight-device来用指定设备的新权重覆盖这个默认值。以下示例使用默认的权重值300，并覆盖在/dev/sda的默认值设置为200：

–device-read-bps参数限制指定设备的读取速率[字节/秒]。例如，以下命令创建一个容器，并限制在/dev/sda的读取速率为每秒1mb:

–device-write-bps参数限制指定设备的写入速率[字节/秒]。例如，以下命令创建一个容器并限制在/dev/sda的写入速率为每秒1mb:

两个参数以:[unit]格式作限制。两个的读取和写入速率必须是一个正整数。可以在指定速率时使用kb,mb或gb。
–device-read-iops参数限制指定设备读取速率[IO/秒]。例如，以下命令创建一个容器并限制在/dev/sda的读取速率为每秒10000IO:

–device-write-iops参数限制指定设备的写入速率[IO/秒]。例如，以下命令创建一个容器并限制在/dev/sda的写入速率为每秒1000IO:

两个参数以:[unit]格式作限制。两个的读取和写入速率必须是一个正整数。

默认下，即使容器退出后，容器的文件系统仍然存在。这使得调度更加容易[因此你能查看最后的状态]，且默认保存了容器所有的数据。不过如果你运行大量短暂时的前台进程，这些容器文件系统将堆积非常多。想让容器退出时自动清理容器和删除它的文件系统，可以使用–rm选项：

当设置–rm参数，docker也会在容器退出时删除与它关联的数据卷。这个与运行docker rm -v my-container类似。不过只删除没有指定名称的数据卷。例如docker run –rm -v /foo -v awesome:/bar busybox top，/foo数据卷将会删除，不过/bar数据卷不会。通过–volumes-from继承的数据卷也会使用同样的逻辑删除 – 如果原始的数据卷指定了一个名称，那么将不会删除。

docker run的退出码给出了关于为什么容器运行失败或者为什么它退出了的信息。当docker run以非零代码退出时，退出代码遵循chroot标准，如下所示：
125 – 如果是docker daemon本身的错误

126 – 如果无法调用容器命令

127 – 如果容器命令不存在

否则，容器命令的退出码

运行容器时使用–restart参数可以指定一个restart策略，来指示在退出时容器应该如何重启或不应该重启。
当容器启用restart策略时，将会在docker ps显示Up或者Restarting状态。也可以使用docker events命令来生效中的restart策略。
docker支持如下restart策略：

no – 容器退出时不要自动重启。这个是默认值。

on-failure[:max-retries] – 只在容器以非0状态码退出时重启。可选的，可以退出docker daemon尝试重启容器的次数。

always – 不管退出状态码是什么始终重启容器。当指定always时，docker daemon将无限次数地重启容器。容器也会在daemon启动时尝试重启，不管容器当时的状态如何。

unless-stopped – 不管退出状态码是什么始终重启容器，不过当daemon启动时，如果容器之前已经为停止状态，不要尝试启动它。

在每次重启容器之前，不断地增加重启延迟[上一次重启的双倍延迟，从100毫秒开始]来防止影响服务器。这意味着daemon将等待100ms,然后200 ms, 400, 800, 1600等等，直到超过on-failure限制，或执行docker stop或docker rm -f。
如果容器重启成功[容器启动后并运行至少10秒]，然后delay重置为默认的100ms。
你可以使用on-failure策略指定docker尝试重启容器的最大次数。默认下docker将无限次数重启容器。可以通过docker inspect来查看已经尝试重启容器了多少次。例如，获取容器“my-container”的重启次数:

或者获取上一次容器重启时间：

示例

这运行了一个restart策略为always的redis容器，以使得容器退出时,docker将重启它。

这个运行了一个restart策略为on-failure,最大重启次数为10的redis容器。如果redis以非0状态退出连续退出超过10次，那么docker将中断尝试重启这个容器。只有on-failure策略支持设置最大重启次数限制。

默认下，所有容器都启用了网络并且能够访问外部网络。使用docker run –network none能够完全地禁用网络，这将禁止所有的入站和出站连接。在这个情况下，你只能能够文件或STDIN和STDOUT完成I/O通信。
发布端口和链接到其它容器只在默认的bridge工作。链接功能是一个旧的功能。你应该始终首选Docker网络驱动的链接功能。
容器默认使用与主机相同的DNS服务器，不过可以使用–dns覆盖它。
默认情况下，使用分配给容器的IP地址生成MAC地址。你可以通过–mac-address参数[格式：12:34:56:78:9a:bc]设置一个指定的容器MAC地址。要注意如果你手动指定MAC地址，docker不会检查地址是否唯一。

支持的网络

none – 不使用网络

bridge[默认] – 通过veth接口连接容器到bridge

host – 在容器内使用主机的网络堆栈

container: – 使用其它容器的网络堆栈，通过name或id指定

NETWORK – 连接容器到一个用户创建的网络 [使用docker network create命令]

Network: none

设置网络为none容器将无法与外部通信。容器仍然会有一个loopback接口，不过没有外部流量的路由。

Network: bridge

设置网络为bridge，容器将使用docker默认的网络设置。主机创建有一个bridge，名为docker0，并为容器创建一对veth接口。其中一个vetch在主机上附着到bridge,而另一个将设置到容器的命名空间内，除了loopback接口。容器在bridge网络分配到一个IP地址，且流量通过这个bridge路由到容器。
容器默认能够通过它们的IP地址通信。如果要通过名称通信，并且使用链接功能。

Network: host

设置网络为host，容器将共享主机的网络堆栈，主机的所有接口将对容器可用。容器的主机名将与主机系统上的主机名匹配。注意–mac-address在host模式时无效。即使在host网络模式下容器默认有它自己的UTS命名空间。因此–hostname在host网络中是允许的，且只更改容器内的hostname。与–hostname类似的–add-host,–dns,–dns-search和–dns-opt选项可用于host网络模式中。这些选项将更新容器内的/etc/hosts或/etc/resolv.conff。不会更改主机中的/etc/hosts和/etc/resolv.conf。
与默认的bridge模式对比，host模式有更好的网络性能，因为它使用了主机的本地网络堆栈，而bridge必须通过docker deamon进行一级虚拟化。当网络性能要求非常高时，推荐使用这个模式运行容器，例如，生产环境的负载均衡或高性能web server。

注意：–network=”host”给了容器对本地系统服务全部的访问权限，如D-bus，因此此模式认为是不安全的。

Network: container

设置网络为container时，容器将共享另一个容器的网络堆栈。需要以–network container:的格式提供另一个容器的名称。–add-host –hostname –dns –dns-search –dns-opt和–mac-address 在container网络模式中是无效的，–publish –publish-all –expose在container网络模式同样无效。
如下示例，启动了一个redis容器，绑定在localhost，然后运行另一个容器执行redis-cli命令通过localhost接口连接redis服务器。

User-defined network

使用docker网络驱动或外部网络驱动插件可以创建一个自己的网络。之后可以连接多个容器到这个网络。一旦连接到用户自定义网络，容器将可以只使用另一个容器的IP地址或名称来通信。
对于支持多主机网络通信的overlay网络或自定义插件，连接到相同的多主机网络但是从不同主机启动的容器能以这种方式互相通信。
如下示例使用docker内置的bridge网络驱动创建了一个网络，并在这个网络运行一个容器。

管理/etc/hosts

容器将会在/etc/hosts添加容器自身主机名条目，localhost和其它一些常见的条目。–add-host参数可以用来在/etc/hosts添加额外的条目。

如果一个容器连接到默认的bridge网络且链接到其它容器，那么这个容器的/etc/hosts文件将添加被链接容器的名称条目。
如果容器连接到用户定义的网络，容器的/etc/hosts文件将添加在这个网络的所有其它容器的名称条目。

注意：因此docker会实时更新容器的/etc/hosts文件，可能会出现当容器内的进程读取到空的或不完整的/etc/hosts文件。大多数情况下，重新读取应该能解决这个问题。