设为首页收藏本站

LUPA开源社区

 找回密码
 注册
文章 帖子 博客

深度解析Docker 1.6.0

2015-4-19 11:17| 发布者: joejoe0332| 查看: 2985| 评论: 0|原作者: dockerone.com|来自: dockerone.com

摘要: Docker 1.6.0的发布,绝对是Docker圈的重磅炸弹。表面上看,这些改动大大完善了Docker的功能,然而细看这些特性,笔者倒是感受到Docker在酝酿着什么惊人的大招。本文详细介绍了Docker 1.6.0中一些新的特性。 ...
  【编者的话】Docker 1.6.0的发布,绝对是Docker圈的重磅炸弹。表面上看,这些改动大大完善了Docker的功能,然而细看这些特性,笔者倒是感受到Docker在酝酿着什么惊人的大招。本文详细介绍了Docker 1.6.0中一些新的特性。


  Docker 1.6.0的发布,绝对是Docker圈的重磅炸弹。表面上看,这些改动大大完善了Docker的功能,然而细看这些特性,笔者倒是感受到Docker在酝酿着什么惊人的大招。

未标题-11-1024x713.jpg


  首先,来看一下笔者对Docker 1.6.0新特性的理解。

一.Builder方面

  1. 允许从一个镜像ID开始build新镜像

  换言之,Dockerfile中的FROM命令后面可以紧跟一个镜像ID。好处是Dockerfile的书写变得灵活,在熟悉Docker镜像原理的情况下,可以大大提高Docker镜像build的效率。简单场景如下,Dockerfile中有两条RUN命令,第一条命令非常耗时,且运行成功了,而第二条命令失败。此情形下,完全可以借助前者完成的镜像继续build。当然有人会提到本地image cache的问题同样可以解决该问题,但是image cache的弊端就是只能本地有效。
  1. Build镜像时允许添加限制参数

  这个改动,笔者的感受是:久旱逢甘露,但是仅仅是几滴。Docker对于docker run命令的限制,即启动容器时做的资源等种种限制,目前看来还是差强人意。但需要清楚的是,docker build流程中对于RUN命令,Docker Daemon本身也会启动一个容器,并通过commit容器打成镜像。此时,如果对于运行RUN命令的容器没有限制,后果可想而知。为什么说“甘露”仅仅是几滴,原因是:docker run命令的限制参数目前还没有全部集成至docker build,而通过Docker Daemon来统一化配置又缺乏灵活。

二.Client方面:支持Windows


  考虑到广大的Windows用户群体,这肯定是好事一桩,但笔者窃以为Docker官方对Win粉的爱也只能到这里了。

三. Runtime方面


1.容器label与镜像label

  Label的概念,不知道大家对她是否似曾相识。早在很早之前,Docker Daemon就支持添加label,用于记录Docker Daemon的角色。Label使得Docker Daemon带有角色,从而Swarm可以方便的通过角色进行Docker的管理。而如今,label可以添加到容器和镜像,原来由Docker外的软件或者人脑记录的容器角色,现在可以显性的放在容器的label中了,大大环节容器角色的管理。更大的好处是,label可以在逻辑上关联容器,会不会在逻辑上有“组”的概念?

2.容器的–cgroup-parent参数

  将容器A的cgroup指定到容器B的cgroup内,从而嵌套情况下,A、B的受限效果将建立管理。容器host网络模式或者other container模式使得容器的隔离留有选择余地,为Docker场景模式的探索带来更大的可能性。如今cgroup都嵌套之后,容器与容器间的粘性再一次被放到台面上,毕竟不是所有容器从逻辑上讲是完全隔离的。这一点,绝对是可挖掘性巨大的特性。

3.logging driver

  Docker接管了容器的日志管理。从实现的角度来说,貌似不难,这个需求应该也是巨大的。只是苦了那些立志占领Docker容器日志市场的小厂商,如logspout就被Docker很礼貌的请出了游戏。

4.通过镜像ID下载镜像

  这一特性的推出,也许在Private Registry中发挥的效果更大。熟悉了镜像原理之后,你会发现,公有的环境下,很少有人会去关注repo下tag化镜像的某个parent镜像包含哪些内容,这一点也很不现实。私有registry就不一样了,私有镜像的制作,环节、内容自己应该都清楚,如此一来,通过镜像ID下载镜像,意义会逐渐体现出来。
  1. –ulimit参数–default-ulimit

  千呼万唤等出来,安全利器。先来看看两者的区别吧,简单来讲,–ulimit的使用仅仅与docker run命令;若不指定–ulimit,–default-ulimit才会在docker run的情况下有效。再看这俩参数的作用:限制容器的资源使用情况,那就不是简单的CPU、Mem了。相信大家肯定一直听说,容器技术有一点弊病就是容器和宿主机共享内核,CPU、Mem等的隔离度有缺陷,其实共享内核的缺陷远不仅如此,内核的资源是否还应该包括,文件数、进程数、信号数、管道数、系统调用等?那么问题出现了,namespace和cgroup并没有考虑到所有的情况,而ulimit可以站出来暂时让Docker的安全避避风声。简单的测试如下:若调小–default-ulimit的文件数参数之后,进入容器查看ulimit –a,open files参数就变小了,大家可以测试一番。

  容器粘性关于调度,容器安全牵扯内核,镜像的灵活,如果您还不知道镜像是什么原理,就out啦。

有关Docker 1.6的详细介绍,请参考官方博客:

http://blog.docker.com/2015/04/docker-release-1-6/

作者简介

  孙宏亮,DaoCloud初创团队成员,软件工程师,浙江大学VLIS实验室应届研究生。读研期间活跃在PaaS和Docker开源社区,对Cloud Foundry有深入研究和丰富实践,擅长底层平台代码分析,对分布式平台的架构有一定经验,撰写了大量有深度的技术博客。2014年末以合伙人身份加入DaoCloud团队,致力于传播以Docker为主的容器的技术,推动互联网应用的容器化步伐。邮箱:allen.sun@daocloud.io

酷毙

雷人

鲜花

鸡蛋

漂亮
  • 快毕业了,没工作经验,
    找份工作好难啊?
    赶紧去人才芯片公司磨练吧!!

最新评论

关于LUPA|人才芯片工程|人才招聘|LUPA认证|LUPA教育|LUPA开源社区 ( 浙B2-20090187 浙公网安备 33010602006705号   

返回顶部