最近Docker对整个平台发布了新的版本，Docker引擎升级至1.11版本，Swarm升级至1.2版本，Compose和Machine也分别升级至1.7和0.7版本。这次升级也开始支持Mac和Windows 10 Bete版的操作系统。上述还只是这个升级的“冰山一角”，不过对于用户来说还算适度更新吧。底层的引擎经过大规模的重构保证了首个兼容Open Container Initiative（OCI）的运行时。更具体的说，现在用户可以直接在runC和containerd上构建引擎了。
OCI、runC、containerd……这是怎么了？
Open Container Initiative是什么？
OCI在2015年6月宣布成立，旨在围绕容器格式和运行时制定一个开放的工业化标准。OCI的目标是为了避免容器的生态分裂为“小生态王国”，确保一个引擎上构建的容器可以运行在其他引擎之上。这是实现容器可移植性至关重要的部分。只要Docker是唯一的运行时，它就是事实上的行业标准。但是随着可用（和采纳）和其他引擎，有必要从技术的角度上定义“什么是容器”，以便不同实现上可以达成最终的一致。
什么是runC？
runC是一个轻量级的工具，它是用来运行容器的，只用来做这一件事，并且这一件事要做好。如果你了解过Docker引擎早期的历史，你应该知道当时启动和管理一个容器需要使用LXC工具集，然后在使用libcontainer。libcontainer就是使用类似cgroup和namespace一样的Linux内核设备接口编写的一小段代码，它是容器的基本构建模块。为了是过程更加简单，runC基本上是一个小命令行工具且它可以不用通过Docker引擎，直接就可以使用容器。这是一个独立的二进制文件，使用OCI容器就可以运行它。
什么是Containerd?
Containerd是一个简单的守护进程，它可以使用runC管理容器，使用gRPC暴露容器的其他功能。相比较Docker引擎，使用gRPC，containerd暴露出针对容器的增删改查的接口，然而Docker引擎只是使用full-blown HTTP API接口对Images、Volumes、network、builds等暴露出这些方法。
它们之间的关联？
正如上面提到的，Docker引擎可以在runC和containerd上构建。1.11之前，引擎只用于Volums、networks、containerd等。现在它所有的工作分为四个部分：引擎、containerd、runC、containerd-shim，后者位于runC与containerd之间的部分。
Docker引擎仍然管理者images，然后移交给containerd运行，containerd再使用runC运行容器。
Containerd只处理containers管理容器的开始，停止，暂停和销毁。由于容器运行时是孤立的引擎，引擎最终能够启动和升级而无需重新启动容器。还有一些其他的好处是：当linux的代码被删除和其他容器运行时的这些改变时能够保持一种统一的Docker UI命令（表面上看一切都是一样的）。
由于现在有四个组件，以前只是一个单独的“docker”二进制文件，现在查分各自功能为四个文件：docker,docker-containerd,
docker-containerd-shim,和docker-runc。如果你在主机上，就可以通过ps as grep docker获取正在运行的进程。下面是Docker三周岁vote app的例子正在运行中，如果想在此机器上获取所有运行的docker进程，你能看到前面提到的四个二进制进程。
如果在Mac或者Windows上，你可以运行docker run -it — pid host -v /:/hostfs — net host alpine chroot /hostfs 和 ps ax | grep docker获得容器中正在运行的进程。-pid host 获取容器用户的主机PID命名空间，类似的— net host参数获取主机UTS的命名空间。更多的信息可以参考引擎使用手册。查看/var/run/docker/libcontainerd，你能查到所有正在运行的容器和containerd sock 文件。
其他更新
Networking
Networking 在新版本中得到了改善，1.10版本的引擎新增了DNS服务器，通过IP地址允许每一个容器可以定位到容器名字和网络别名。当众多容器拥有相同的网络别名，DNS服务器将会返回一个状态记录。在1.11版本的引擎中，DNS服务器按照随机的顺序返回所有的记录。这允许您使用DNS轮循作为基本的负载平衡和故障转移机制。如果多次ping网络别名，你会得到不同的结果。不管是均衡还是不均衡，你都会在一个容器中得到所有的随机变化结果。请记住:容器名称的解析只能在Custom networks（使用docker network create创建的networks）上工作。请看下面关于创建network的例子，使用两个Nginx的容器，运行在同一个别名的网络上。
此处之外，networks（还有volumes）现在可以有影像似的标签了。
Compose 1.7
新版本Compose有好几个改善的地方包括不在通过命令行传递参数读取，而是直接读取环境变量中的参数。
接下来，秉承docker-compose up，在可能和依赖秩序上，compose仍旧受尊敬。
例如，如果你在redis中查看一个Docker compose文件，你可以在database层次或者前端，一旦redis开始启动，他们就可以同时进行。
另外还有几处变化，新版本增加了docker-compose命令。还有两个新的命令新增：docker-compose up — build 和docker-compose exec。用户经常运行docker-compose build然后运行docker-compose up,在编辑Dockerfile时，增加了跟build类似的up参数。另外一个exec命令也有相同的功能。除此之外，docker-compose logs模仿docker logs命令不再列举整个容器的日志而且流处理日志，而是只会展示日志。你可以使用 docker-compose logs -f命令像docker logs一样查看流式日志。docker-compose logs目前可以检测到你什么时间添加新的容器到应用程序，而且使用docker-compose logs -f自动添加它们的日志到流中。
Swarm 1.2
Swarm1.1新增了容器调度的试验支持，在1.2中不再是试验版了。在swarm1.1之前，如果使用swarm启动10台服务器，开始100个前端网页进程，其中一个服务中断掉，什么也不会发生。现在容器能针对运行失败的节点自动重启。这可以通过设置一个环境变量或者标签容器，这样容器启动时就可以被监控到。
`docker run -d -e reschedule:on-node-failure <image>` `docker run -d -l ‘com.docker.swarm.reschedule-policy=[“on-node-failure”]’ <image>`
Swarm管理员可以设置追踪到每一个节点，它会持续向每一个节点检测心跳包，而且检测到反应迟钝的请求就会尝试重启这个节点。如果这个节点运行容器接收到重新安排的策略，这个容器将会重新安排到其他地方。Swarm的状态可以通过查询日志文件获取，可以有很多管理员。
Registry
在以前，如果你在自己的registry删除镜像，结果是逻辑删除这个镜像。但是这个镜像的数据文件还在。数据文件失去引用而已。如果考虑到程序，当你删除一个变量时，并不能立即删除这个数据。这里有一个内存的管理，我们后续可以手动删除或者垃圾回收机制自动处理。现在这些全部都有Registry做了。
Docker for Mac and Windows
上个月，Docker放出一个测试版本，宣布开始支持Mac和Windows。Mac和Windows上的Docker不用做任何的更改，但是提高了用户体验度。它们提供一个在linux上运行原生Docker非常相似的体验，除非你想运行多个主机环境，这都不需要借助virtualBox。我在Mac上运行了Docker，然后写了这篇博客，“Say Hello to Docker for Mac”。
自从Docker 1.1发布，现在Docker引入很多新的功能。Mac版本的Docker作为Beta9，localhost 用来做端口转发，而不是使用有本地Linux感觉的docker.local。Beta 10版本支持令牌验证通道HTTPS。Beta 11版本更新了内核和Compose。通过发布日志可以看到所有的新特性，更新还有一些关于Mac和Windows众所周知的问题。
原文链接：http://dockone.io/article/1327
本文链接：https://www.yunweipai.com/7373.html
网友评论comments