转载

Docker1.11增强功能:直接在runC和Containerd上构建引擎new

最近Docker对整个平台发布了新的版本,Docker引擎升级至1.11版本,Swarm升级至1.2版本,Compose和Machine也分别升级至1.7和0.7版本。这次升级也开始支持Mac和Windows 10 Bete版的操作系统。上述还只是这个升级的“冰山一角”,不过对于用户来说还算适度更新吧。底层的引擎经过大规模的重构保证了首个兼容Open Container Initiative(OCI)的运行时。更具体的说,现在用户可以直接在runC和containerd上构建引擎了。

Docker1.11增强功能:直接在runC和Containerd上构建引擎new

OCI、runC、containerd……这是怎么了?

Open Container Initiative是什么?

OCI在2015年6月宣布成立,旨在围绕容器格式和运行时制定一个开放的工业化标准。OCI的目标是为了避免容器的生态分裂为“小生态王国”,确保一个引擎上构建的容器可以运行在其他引擎之上。这是实现容器可移植性至关重要的部分。只要Docker是唯一的运行时,它就是事实上的行业标准。但是随着可用(和采纳)和其他引擎,有必要从技术的角度上定义“什么是容器”,以便不同实现上可以达成最终的一致。

什么是runC?

runC是一个轻量级的工具,它是用来运行容器的,只用来做这一件事,并且这一件事要做好。如果你了解过Docker引擎早期的历史,你应该知道当时启动和管理一个容器需要使用LXC工具集,然后在使用 libcontainerlibcontainer 就是使用类似 cgroupnamespace 一样的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之间的部分。

Docker1.11增强功能:直接在runC和Containerd上构建引擎new

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进程,你能看到前面提到的四个二进制进程。

Docker1.11增强功能:直接在runC和Containerd上构建引擎new

Docker1.11增强功能:直接在runC和Containerd上构建引擎new

如果在Mac或者Windows上,你可以运行 docker run -it — pid host -v /:/hostfs — net host alpine chroot /hostfsps ax | grep docker 获得容器中正在运行的进程。-pid host 获取容器用户的主机PID命名空间,类似的— net host参数获取主机UTS的命名空间。更多的信息可以参考引擎使用手册。查看 /var/run/docker/libcontainerd ,你能查到所有正在运行的容器和containerd sock 文件。

Docker1.11增强功能:直接在runC和Containerd上构建引擎new

其他更新

Networking

Networking 在新版本中得到了改善,1.10版本的引擎新增了DNS服务器,通过IP地址允许每一个容器可以定位到容器名字和网络别名。当众多容器拥有相同的网络别名,DNS服务器将会返回一个状态记录。在1.11版本的引擎中,DNS服务器按照随机的顺序返回所有的记录。这允许您使用DNS轮循作为基本的负载平衡和故障转移机制。如果多次ping网络别名,你会得到不同的结果。不管是均衡还是不均衡,你都会在一个容器中得到所有的随机变化结果。请记住:容器名称的解析只能在Custom networks(使用docker network create创建的networks)上工作。请看下面关于创建network的例子,使用两个Nginx的容器,运行在同一个别名的网络上。

Docker1.11增强功能:直接在runC和Containerd上构建引擎new

此处之外,networks(还有volumes)现在可以有影像似的标签了。

Compose 1.7

新版本Compose有好几个改善的地方包括不在通过命令行传递参数读取,而是直接读取环境变量中的参数。

接下来,秉承 docker-compose up ,在可能和依赖秩序上,compose仍旧受尊敬。

例如,如果你在redis中查看一个Docker compose文件,你可以在database层次或者前端,一旦redis开始启动,他们就可以同时进行。

另外还有几处变化,新版本增加了 docker-compose 命令。还有两个新的命令新增: docker-compose up — builddocker-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

原文  http://www.yunweipai.com/archives/7373.html
正文到此结束
Loading...