Docker 1.13版本新增功能说明

前言

Docker 1.13 在 2017 年 1 月 18 日发布了。从 2016 年 7 月 29 日发布 1.12 发布以来,已经过去 5 个多月了,对于活跃的 Docker 社区来说,已经很久了,让我们看看都 1.13 都新增了什么内容吧。

1.13 有一千四百多个 issue/pull request,五千多个 commits,是 Docker 历史上最高的发布版本。这并不是一个简单的小版本变化,里面有大量的更新。

在发布之后,可以直接安装最新版本。在一个新的 Ubuntu / CentOS 系统中直接执行:

Top 10 新增功能

  • 1、正式支持服务栈 docker stack
  • 2、正式支持插件:docker plugin
  • 3、添加在 Swarm 集群环境下对密码、密钥管理的 secret 管理服务:docker secret
  • 4、增加 docker system 命令
  • 5、可以直接使用 docker-compose.yml 进行服务部署
  • 6、添加 docker service 滚动升级出故障后回滚的功能
  • 7、增加强制再发布选项 docker service update --force
  • 8、允许 docker service create 映射宿主端口,而不是边界负载均衡网络端口
  • 9、允许 docker run 连入指定的 swarm mode 的 overlay 网络
  • 10、解决中国 GFW 墙掉 docker-engine apt/yum 源的问题

让我们来详细解读一下 1.13.0 新增功能 吧。

Docker 镜像构建

从已有镜像取得缓存

https://github.com/docker/docker/pull/26839

我们都知道使用 Dockerfile 构建镜像的时候,会充分利用分层存储的特性进行缓存,之前构建过的层,如果没有变化,那么会直接使用缓存的内容,避免没有意义的重复构建。不过使用缓存的前提条件是曾经在本地构建过这个镜像。这在 CI 进行集群构建时是一个比较麻烦的问题,因为构建任务可能会被分配到不同的机器上,而该机器没有构建过该镜像,因此缓存总是用不上,因此大量的时间浪费在了重复构建已经构建过的层上了。

在 1.13 中,为 docker build 增加了一个新的参数 --cache-from,利用镜像中的 History 来判断该层是否和之前的镜像一致,从而避免重复构建。

比如我们先下载获取作为缓存的镜像:

然后我们使用更新后的 Dockerfile 构建镜像时,如果加上 --cache-from mongo:3.2 后,会发现如果是已经在mongo:3.2 中存在并没有修改的层,就会用 mongo:3.2 中的该层做缓存。

压扁(squash)镜像(实验阶段)

https://github.com/docker/docker/pull/22641

对于总是把 Dockerfile 当做 bash 文件来用的人,会发现很快由于太多的 RUN 导致镜像有特别多的层,镜像超级臃肿,而且甚至会碰到超出最大层数限制的问题。这些人往往不从自身找问题,反而去寻找旁门左道,比如导出镜像做一些特殊处理,合并为一层,然后再导入等等,这种做法是很错误的,除了导致构建缓存失败外,还导致docker history 丢失,导致镜像变为黑箱镜像。其实正确的做法是遵循 Dockerfile 最佳实践,应该把多个命令合并为一个 RUN,每一个 RUN 要精心设计,确保安装构建最后进行清理。这样才可以降低镜像体积,以及最大化的利用构建缓存。

在 Docker 1.13 中,为了应对这群用户,实验性的提供了一个 --squash 参数给 docker build,其功能就是如上所说,将 Dockerfile 中所有的操作,压缩为一层。不过,与旁门左道不同,它保留了 docker history

比如如下的 Dockerfile

如果我们正常的构建的话,比如 docker build -t my-not-squash .,其 history 是这样子的:

而如果我们用 --squash 构建:

其 history 则是这样子:

我们可以注意到,所有层的层ID都 <missing> 了,并且多了一层 merge

要注意,这并不是解决懒惰的办法,撰写 Dockerfile 的时候,依旧需要遵循最佳实践,不要试图用这种办法去压缩镜像。

构建镜像时支持用 --network 指定网络

https://github.com/docker/docker/pull/27702 https://github.com/docker/docker/issues/10324

在一些网络环境中,我们可能需要定制 /etc/hosts 文件来提供特定的主机和 IP 地址映射关系,无论是应对 GFW,还是公司内部 Git 服务器,都有可能有这种需求,这个时候构建时修改 /etc/hosts 是一个比较麻烦的事情。使用内部 DNS 虽然是一种解决办法,但是这将是全引擎范围的,而且并非所有环境都会有内部 DNS。更好地做法是使用宿主网络进行构建。另外,有的时候,或许这个构建所需 Git 服务器位于容器内网络,我们需要指定某个 overlay 网络来给镜像构建所需。

在 1.13 中,为 docker build 提供了 --network 参数,可以指定构建时的网络。

比如,我们有一个 Dockerfile 内容为:

内容很简单,就是看看构建时的 /etc/hosts 的内容是什么。假设我们宿主的 /etc/hosts 中包含了一条 1.2.3.4 到example.com 的映射关系。

如果我们如同以往,使用默认网络进行构建。那么结果会是这样:

可以注意到,这次构建所看到的是容器默认网络的 /etc/hosts,其内没有宿主上添加的条目 1.2.3.4 example.com

然后我们使用 docker build --network=host 来使用宿主网络构建:

这次由于使用了 --network=host 参数,于是使用的是宿主的网络命名空间,因此 /etc/hosts 也是宿主的内容。我们可以在其中看到 1.2.3.4 example.com 条目。

开始允许 docker build 中定义 Dockerfile 未使用的参数(ARG)

https://github.com/docker/docker/pull/27412

我们都知道镜像构建时可以用 --build-arg 来定义参数,这样 Dockerfile 就会使用这个参数的值来进行构建。这对于 CI/CD 系统很重要,我们可以使用一套 Dockerfile 来构建不同条件下的镜像。

但在 1.13 以前,这里有个问题,在 CI 系统中,我们有时希望用一套构建命令、脚本,通过给入不同的 Dockerfile来构建不同的镜像,而 --build-arg 的目的是定义一些有可能会用到的全局变量,但是如果有的 Dockerfile 中没用这个变量,那么构建就会失败。#26249

其背后的思想是,如果 --build-arg 指定了,但是没用,那么很可能是因为拼写错误、或者忘记了应该使用这个变量而出现的问题。最初 docker build 对于这类情况的处理,是直接报错退出,构建失败。

但是在上面的 CI 的案例中,--build-arg 只是定义一些可能用到的环境变量,并不强制使用,这种情况下,如果因为Dockerfile没有使用可能用到的变量就报错就有些过了。因此在 1.13 中,将其降为警告,并不终止构建,只是提醒用户有些变量未使用。

安装

解决 GFW 影响 Docker 安装问题

https://github.com/docker/docker/pull/27005

官方的 apt/yum 源使用的是 AWS 的服务,并且为了确保安全使用了 HTTPS,因此伟大的墙很乐于干扰大家使用。没办法的情况下,各个云服务商纷纷建立自己官方源镜像,阿里云、DaoCloud、Azura 等等,并且自己做了个修订版的https://get.docker.com 的脚本来进行安装。

现在这个发生改变了,官方的 https://get.docker.com 将支持 --mirror 参数,你可以用这个参数指定国内镜像源,目前支持微软的 Azure 云,(或阿里云?(更新:由于阿里云镜像源不支持 HTTPS,所以不会支持阿里云))。使用方法如下,将原来官网安装命令:

替换为:

增加更多的系统支持

在这次发布中,增加了 Ubuntu 16.10 的安装包,而且对 Ubuntu 系统增加了 PPC64LE 和 s390x 构架的安装包。此外,还正式支持了 VMWare Photon OS 系统的 RPM 安装包,以及在 https://get.docker.com 的支持。并且支持了Fedora 25,甚至开始支持 arm64。同时也由于一些系统生命周期的结束,而被移除支持,比如Ubuntu 15.10Fedora 22都不在支持了。

网络

允许 docker run 连入指定的 swarm mode 的网络

https://github.com/docker/docker/pull/25962

在 Docker 1.12 发布新的 Swarm Mode 之后,很多人都问过这样的问题,怎么才能让 docker run 的容器连入 Swarm Mode 服务的 overlay 网络中去?答案是不可以,因为 swarm 的 overlay网络是为了 swarm mode service 准备的,相对更健壮,而直接使用 docker run,会破坏了这里面的安全模型。

但是由于大家需求很多,于是提供了一种折衷的办法。1.13 允许建立网络的时候,设定该网络为 attachable,允许之后的 docker run 的容器连接到该网络上。

我们创建一个默认的、不允许之后 attach 的网络:

然后再创建一个允许 attach 的网络,这里会使用 1.13 新加入的 --attachable 参数:

然后我们启动一个 web 服务,连入这两个网络:

现在我们用 docker run 启动一个容器连入第一个网络:

由于 mynet1 不允许手动 attach 所以这里报错了。

在 1.12 的情况下,会报告该网络无法给 docker run 使用:

不过,--attachable 实际上是将网络的安全模型打开了一个缺口,因此这不是默认设置,而且并不推荐使用。用户在使用这个选项建立网络的时候,一定要知道自己在做什么。

允许 docker service create 映射宿主端口,而不是边界负载均衡网络端口

https://github.com/docker/docker/pull/27917 https://github.com/docker/docker/pull/28943

docker service create 中的 --publish 格式有进一步的变化。(在 1.13 的 RC 期间,曾经去掉 --publish,改为--port,经过讨论后,决定保持一致性,继续使用 --publish,不使用新的 --port 选项。)

在 1.12 中,docker service create 允许使用参数 --publish 80:80 这类形式映射边界(ingress)网络的端口,这样的映射会享受边界负载均衡,以及 routing mesh。

从 1.13 开始,增加另一种映射模式,被称为 host 模式,也就是说,用这种模式映射的端口,只会映射于容器所运行的主机上。这就和一代 Swarm 中一样了。虽然失去了边界负载均衡,但是确定了映射点,在有的时候这种情况是需要的。

现在 --publish 的新的参数形式和 --mount 差不多。参数值为 , 逗号分隔的键值对,键值间以 = 等号分隔。目前支持 4 项内容:

  • protocol: 支持 tcp 或者 udp
  • mode: 支持 ingress 或者 host
  • target: 容器的端口号
  • published: 映射到宿主的端口号

比如,与 -p 8080:80 等效的 --publish 新格式选项为:

当然我们可以继续使用 -p 8080:80,但是新的选项格式增加了更多的可能。比如,使用 1.13 开始加入的 host 映射模式:

运行成功后,查看一下服务容器运行的节点:

我们可以看到,集群有3个节点,而服务就一个副本,跑到了 d3上。如果这是以前的使用边界负载均衡的网络 ingress的话,那么我们访问任意节点的 80 端口都会看到页面。

但是,host 模式不同,它只映射容器所在宿主的端口。因此,如果我们 curl d1 的话,应该什么看不到网页,而curl d3 的话就会看到页面:

iptables 的转发规则将默认拒绝

https://github.com/docker/docker/pull/28257

从默认 FORWARD 改为 DROP,从而避免容器外露的安全问题

在 docker network inspect 里显示连入的节点

我们都是知道,在 swarm mode 中创建的 overlay 网络,并不是一下子就在集群中的每个节点上 docker network ls就可以看到这个网络,这完全没有必要。只有当使用该网络的容器调度到某个节点上后,才会将该节点连入此 overlay网络。在网络排障过程中,经常会有这种需求,需要得知现在连入该 overlay 网络中的节点到底有哪些,这在 1.13之前不容易做到。

从 1.13 开始,docker network inspect 将显示连接到了这个网络的节点(宿主)有哪些。

从上面的例子可以看出,一共有两个宿主连入了这个 mynet 的 overlay 网络,分别为 138.197.213.116 和138.197.221.47

允许 service VIP 可以被 ping

https://github.com/docker/docker/pull/28019

在 1.12 的二代 Swarm 排障过程中,常见的一个问题就是跨节点的服务 VIP 不可以 ping,所以很多时候很多时候搞不懂是 overlay 网络不通呢?还是服务没起来?还是服务发现有问题?这个问题在 1.13 解决了,VIP 可以随便ping,跨宿主也没关系。

插件

插件功能正式启用

https://github.com/docker/docker/pull/28226

在 1.12 引入了插件概念后,作为试验特性得到了很多关注。包括 Docker Store 开始准备上线,以及第三方的插件的开发。现在 1.13 插件作为正式功能提供了。

相比于 1.12 的试验版本而言,最重要的是增加了 docker plugin create 命令,可以指定一个包含有 config.json 文件和 rootfs 目录的目录来创建插件。