Docker 1.11 增强功能：直接在runC和containerd构建引擎-低调大师

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

2017-09-24 610

本文讲的是Docker 1.11 增强功能：直接在runC和containerd构建引擎，【编者的话】Docker的更新都会伴随着周围工具产品的升级，这次也不例外。1.11直接允许使用runC和containerd构建引擎，runC和containerd也跟随升级，这次还升级了Compose和Swarm，跟小编来看下大致的介绍吧

最近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容器就可以运行它。更多信息，请阅读 Solomon Hykes 的更多博客。

什么是Containerd?

Containerd是一个简单的守护进程，它可以使用runC管理容器，使用gRPC暴露容器的其他功能。相比较Docker引擎，使用 gRPC ，containerd暴露出针对容器的增删改查的接口，然而Docker引擎只是使用 full-blown HTTP API接口对Images、Volumes、network、builds等暴露出这些方法。获得更过的细节解释，请参考 Michael Crosby 的博客。

它们之间的关联？

正如上面提到的，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众所周知的问题。

更多关于Docker1.1

原文链接：Docker 1.11 et plus: Engine is now built on runC and containerd（翻译：ylzhang）

原文发布时间为：2016-05-20

本文作者：ylzhang

本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。

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

微信关注我们

原文链接：https://yq.aliyun.com/articles/225595

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Docker容器的持久存储模式

本文讲的是Docker容器的持久存储模式，【编者的话】本文讨论了Docker容器的持久存储模式，包括默认模式、数据卷模式、只含数据的容器、从主机映射而得的数据卷、从主机映射而得的数据卷且存储后端是共享存储以及 Convoy 存储插件，其中第 2-4 种支持容器持久性，即升级容器也不会移除数据；第 5-6 种支持主机持久性，即主机失效也不会引起数据丢失。简介说到Docker，持久存储是一个需要小心处理的问题。通常一个服务的升级流程是关停旧版本容器，然后拉取并启动新版本容器。默认情况下，旧版容器包含的所有数据都会被消除，我们当然不想这样。本文将讨论保证数据持久性的几种模式：默认模式：不支持任何持久性数据卷：容器持久性仅含数据的容器：容器持久性从主机映射而得的卷：容器持久性从主机映射而得的卷，存储后端是共享存储：主机持久性 Convoy 卷插件：主机持久性上述几种持久性（我自己发明的）是什么意思呢？容器持久性：升级容器并不会移除数据主机持久性：主机失效也不会引起数据丢失下面一一解释这些持久存储模式。默认模式这是最基本的一种持久存储模式。创建容器时没有指定任何与卷...

2017-09-25

522

摘要：为了满足直播、游戏、Hadoop、消息中间件等对网络转发能力有非常高要求的用户场景，主流的云计算厂商都推出了针对网络性能优化的虚拟机实例。如何实现高性能、低延迟、少抖动的虚拟机网络性能，一直都是非常有挑战的问题，业界的有多种实现的方法，但是都各有利弊。在云栖社区和阿里云网络团队联合主办的2017阿里云网络技术在线高峰论坛，阿里云高级技术专家李星就为大家分享了阿里云的网络增强型的解决方案和思考。本文内容根据演讲嘉宾分享视频以及PPT整理而成。一、传统虚拟化网络所面对的挑战和瓶颈在传统虚拟化网络领域的用户痛点在虚拟机领域中，CPU性能、内存性能以及IO性能早就都有了很多比较成熟的技术方案，但是网络性能的方案上却始终存在一些差距。这里面的原因其实是多方面的，比如网络性能的吞吐速率比正常的存储IO速率要快很多，甚至有可能很多用户

2017-09-25

665

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。