Docker 1.11 增强功能：直接在runC和containerd构建引擎

   <p>【编者的话】Docker的更新都会伴随着周围工具产品的升级，这次也不例外。1.11直接允许使用runC和containerd构建引擎，runC和containerd也跟随升级，这次还升级了Compose和Swarm，跟小编来看下大致的介绍吧</p>    <p><a href="/misc/goto?guid=4958971144570564318" rel="nofollow,noindex">@Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办，来自Rancher、携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川、腾讯游戏、数人云、点融网、华为、轻元科技、中兴通讯、中国民生银行等公司的技术负责人将带来实践经验分享，欢迎感兴趣的同学参加。</a></p>    <p>最近Docker对整个平台发布了新的版本，Docker引擎升级至 <a href="/misc/goto?guid=4959673473269109317" rel="nofollow,noindex">1.11版本</a> ，Swarm升级至1.2版本，Compose和Machine也分别升级至1.7和0.7版本。这次升级也开始支持Mac和Windows 10 Bete版的操作系统。上述还只是这个升级的“冰山一角”，不过对于用户来说还算适度更新吧。底层的引擎经过大规模的重构保证了首个兼容（ <a href="/misc/goto?guid=4958969755817827229" rel="nofollow,noindex">Open Container Initiative</a> ）OCI的运行时。更具体的说，现在用户可以直接在 <a href="/misc/goto?guid=4958969755955419276" rel="nofollow,noindex">runC</a> 和 <a href="/misc/goto?guid=4958988343647938759" rel="nofollow,noindex">containerd</a> 上构建引擎了。</p>    <p><img src="https://simg.open-open.com/show/c87e3843e68cc57913a6d8390c8c8e5b.png"></p>    <h2>OCI，runC，containerd....这是怎么了？</h2>    <h3>Open Container Initiative是什么？</h3>    <p>OCI在2015年6月宣布成立，旨在围绕容器格式和运行时制定一个开放的工业化标准。OCI的目标是为了避免容器的生态分裂为“小生态王国”，确保一个引擎上构建的容器可以运行在其他引擎之上。这是实现容器可移植性至关重要的部分。只要Docker是唯一的运行时，它就是事实上的行业标准。但是随着可用（和采纳）和其他引擎，有必要从技术的角度上定义“什么是容器”，以便不同实现上可以达成最终的一致。</p>    <h3>什么是runC？</h3>    <p>runC是一个轻量级的工具，它是用来运行容器的，只用来做这一件事，并且这一件事要做好。如果你了解过Docker引擎早期的历史，你应该知道当时启动和管理一个容器需要使用LXC工具集，然后在使用 libcontainer 。 libcontainer 就是使用类似 cgroup 和 namespace 一样的Linux内核设备接口编写的一小段代码，它是容器的基本构建模块。为了是过程更加简单，runC基本上是一个小命令行工具且它可以不用通过Docker引擎，直接就可以使用容器。这是一个独立的二进制文件，使用OCI容器就可以运行它。更多信息，请阅读 <a href="/misc/goto?guid=4959616793786224173" rel="nofollow,noindex">Solomon Hykes</a> 的 <a href="/misc/goto?guid=4959673473617181399" rel="nofollow,noindex">更多博客</a> 。</p>    <h3>什么是containerd?</h3>    <p>containerd 是一个简单的守护进程，它可以使用runC管理容器，使用gRPC暴露容器的其他功能。相比较Docker引擎，使用 gRPC ，containerd暴露出针对容器的 <a href="/misc/goto?guid=4959666029588748165" rel="nofollow,noindex">增删改查的接口</a> ，然而Docker引擎只是使用 full-blown HTTP API接口对Images，Volumes，network，builds等暴露出这些方法。获得更过的细节解释，请参考 <a href="/misc/goto?guid=4959673473724082031" rel="nofollow,noindex">Michael Crosby</a> 的 <a href="/misc/goto?guid=4958861611157525996" rel="nofollow,noindex">博客</a> 。</p>    <h3>它们之间的关联？</h3>    <p>正如上面提到的，Docker引擎可以在runC和containerd上构建。1.11之前，引擎只用于Volums,networks,containerd等。</p>    <p>现在它所有的工作分为四个部分：引擎，containerd，runC，containerd-shim，后者位于runC与containerd之间的部分。</p>    <p><img src="https://simg.open-open.com/show/efad5c0cefa6cf96ee3fa381ada75813.png"></p>    <p>Docker引擎仍然管理者images，然后移交给containerd运行，containerd再使用runC运行容器。</p>    <p>containerd只处理containers管理容器的开始，停止，暂停和销毁。由于容器运行时是孤立的引擎，引擎</p>    <p>最终能够启动和升级而无需重新启动容器。还有一些其他的好处是：</p>    <p>当linux的代码被删除和其他容器运行时的这些改变时能够保持一种统一的Docker UI命令（表面上看一切都是一样的）</p>    <p>由于现在有四个组件，以前只是一个单独的“docker”二进制文件，现在查分各自功能为四个文件： docker , docker-containerd ,</p>    <p>docker-containerd-shim ,和 docker-runc 。如果你在主机上，就可以通过 ps as grep docker 获取正在运行的进程。</p>    <p>下面是docker三周年vote app的例子正在运行中，如果想在此机器上获取所有运行的docker进程，你能看到前面提到的四个二进制进程。</p>    <p><img src="https://simg.open-open.com/show/ba38a7a92544afd6fd681001bba1eebe.png"></p>    <p><img src="https://simg.open-open.com/show/13c8f5991c36d0d41fd75f4ff3038df8.png"></p>    <p>如果在Mac或者Windows上，你可以运行 docker run -it — pid host -v /:/hostfs — net host alpine chroot /hostfs 和 ps ax | grep docker 获得容器中正在运行的进程。-pid host 获取容器用户的主机PID命名空间，类似的— net host参数获取主机UTS的命名空间。更多的信息可以参考引 <a href="/misc/goto?guid=4959673473837335408" rel="nofollow,noindex">擎使用手册</a> 。查看 /var/run/docker/libcontainerd ，你能查到所有正在运行的容器和containerd sock 文件。</p>    <p><img src="https://simg.open-open.com/show/a8013680f991ba0d9838043b64da44f2.png"></p>    <h2>其他更新</h2>    <h3>Networking</h3>    <p>Networking 在新版本中得到了改善，1.10版本的引擎新增了DNS服务器，通过IP地址允许每一个容器可以定位到容器名字和网络别名。当众多容器拥有相同的网络别名，DNS服务器将会返回一个状态记录。在1.11版本的引擎中，DNS服务器按照随机的顺序返回所有的记录。这允许您使用DNS轮循作为基本的负载平衡和故障转移机制。如果多次ping网络别名，你会得到不同的结果。不管是均衡还是不均衡，你都会在一个容器中得到所有的随机变化结果。请记住:容器名称的解析只能在Custom networks（使用docker network create创建的networks）上工作。请看下面关于创建network的例子，使用两个Nginx的容器，运行在同一个别名的网络上。</p>    <p><img src="https://simg.open-open.com/show/79c6683a37449f8ec4d8cb287e797b10.png"></p>    <p>此处之外，networks（还有volumes）现在可以有影像似的标签了。</p>    <h3>Compose 1.7</h3>    <p>新版本Compose有好几个改善的地方包括不在通过命令行传递参数读取，而是直接读取环境变量中的参数。</p>    <p>接下来，秉承 docker-compose up ，在可能和依赖秩序上，compose仍旧受尊敬。</p>    <p>例如，如果你在redis中查看一个Docker compose文件，你可以在database层次或者前端，一旦redis开始启动，他们就可以同时进行。</p>    <p>另外还有几处变化，新版本增加了 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 自动添加它们的日志到流中。</p>    <h3>Swarm 1.2</h3>    <p>Swarm1.1新增了容器调度的试验支持，在1.2中不再是试验版了。在swarm1.1之前，如果使用swarm启动10台服务器，开始100个前端网页进程，其中一个服务中断掉，什么也不会发生。现在容器能针对运行失败的节点自动重启。这可以通过设置一个环境变量或者标签容器，这样容器启动时就可以被监控到。</p>    <pre>  <code class="language-bash">`docker run -d -e reschedule:on-node-failure <image>`    `docker run -d -l ‘com.docker.swarm.reschedule-policy=[“on-node-failure”]’ <image>`  </code></pre>    <p>Swarm管理员可以设置追踪到每一个节点，它会持续向每一个节点检测心跳包，而且检测到反应迟钝的请求就会尝试重启这个节点。如果这个节点运行容器接收到重新安排的策略，这个容器将会重新安排到其他地方。swarm的状态可以通过查询日志文件获取，可以有很多管理员。</p>    <p>Registry</p>    <p>在以前，如果你在自己的registry删除镜像，结果是逻辑删除这个镜像。但是这个镜像的数据文件还在。数据文件失去引用而已。如果考虑到程序，当你删除一个变量时，并不能立即删除这个数据。这里有一个内存的管理，我们后续可以手动删除或者垃圾回收机制自动处理。现在这些全部都有registry做了。</p>    <p>Docker for Mac and Windows</p>    <p>上个月，Docker放出一个测试版本，宣布开始支持Mac和Windows。Mac和Windows上的Docker不用做任何的更改，但是提高了用户体验度。它们提供一个在linux上运行原生Docker非常相似的体验，除非你想运行多个主机环境，这都不需要借助virtualBox。我在Mac上运行了Docker，然后写了这边博客， <a href="/misc/goto?guid=4959673473929464528" rel="nofollow,noindex">“Say Hello to Docker for Mac”.</a></p>    <p>自从Docker1.1发布，现在Docker引入很多新的功能。Mac版本的Docker作为Beta9,localhost 用来做端口转发，而不是使用有本地linux感觉的docker.local。Beta10版本支持令牌验证通道HTTPS。Beta11版本更新了内核和Compose。通过发布日志可以看到所有的新特性，更新还有一些关于Mac和Windows众所周知的问题。</p>    <p> </p>    <p>来自： <a href="/misc/goto?guid=4959673474008195069" rel="nofollow">http://dockone.io/article/1327</a></p>    <p> </p>