Docker的秘密:费电!

刀客info阅读(9465)评论(0)

不过,用Docker容器来处理耗电量更大的冗长任务很划算。

Docker也许是开发运维(DevOps)界的宠儿,不过说到能耗或耗电方面,这多少未免有点夸大其辞了。

隶属加拿大阿尔伯塔大学的计算机科学研究人员近期花了一段时间,特意比较了在Docker容器中运行应用软件的耗电量和在裸机Linux服务器上运行同一应用软件的耗电量。

在一篇题为《Docker如何影响耗电量?评估使用/不用Docker容器的工作负载》的学术论文(https://arxiv.org/pdf/1705.01176.pdf)中,艾布拉姆·欣德尔(Abram Hindle)教授和三位研究同事埃迪·安东尼奥·桑托斯(Eddie Antonio Santos)、卡尔森·麦克莱恩(Carson McLean)和克里斯托弗·索利纳斯(Christopher Solinas)撰文表示,虽然Docker具有使用方便的优点,但这是有代价的。

这篇论文声称:“这番研究工作表明,容器化技术在耗电量方面没有所谓的免费午餐。容器化技术意味着耗电量与可管理性方面需要作一番取舍;至于在特定的使用场景下,更偏重哪个方面,那就取决于负责具体部署的个人或团队了。”

欣德尔在接受英国IT网站The Register的电话采访时解释,如果是I/O密集型任务,在Docker容器中运行的应用软件其耗电量超过同样那些应用软件在裸机系统上运行的耗电量,原因是它们要花费更长的时间。虽然大家承认这是个明显的问题,但可以量化这个问题总归是件好事。

能耗是指以瓦特为单位的功率乘以完成任务所需要的时间。

欣德尔说:“我们在使用Docker时发现,它要耗费更多的电量来处理同样的任务,因为它在I/O方面效率要低一点。基本上来说,使用抽象机制,效率难免要受到影响。”

Docker本身效率要低一点,原因是dockerd进程即便处于闲置状态也耗电,这归因于Docker的一些Go进程,比如废料收集进程。

该论文解释:“单单在闲置状态下运行dockerd就会使平均功率相差2瓦特,因而时间一长,就会增加耗电量。然而,耗电量的增加可能主要还是归因于运行时的性能。”

如果是CPU密集型任务,比如内存中Redis处理,欣德尔表示,这种耗电量的差异可忽略不计。真正重要的是频繁访问文件、磁盘或网络的情况下,尤其是在大规模环境下,比如说处理PostgreSQL数据库时。

据欣德尔声称,就PostgreSQL而言,使用容器化技术和启动TLS/SSL之间在耗电量方面的影响大致相当。

欣德尔强调,Docker容器确实具有诸多优点,这些优点可能对许多企业组织来说比裸机服务器的效率来得更重要。他说:“如果你的支出主要是人力这一块,那么可能还是值得为Docker多掏一点电费。”

全面解读Moby和LinuxKit,Docker称沟通不善招致误解

刀客info阅读(9494)评论(0)

开源圈的一股怒火

这段时间,开源圈子有一股怒火, Docker公司发表声明称会将原有的Docker开源项目停掉,另起炉灶开了Moby项目。

这番声明居然的正面反馈(280票)和负面反馈(1198),好评率居然仅有18.9%。大家纷纷谴责“Docker直接把原Docker项目改名成Moby,开源突然商业化”的行为。

而另一方面,Docker公司又在解释:Moby并不是Docker的替代品,它的本意是希望帮助系统工程师使用Moby这个工具集去构建类似于Docker的平台。(Moby is not a replacement for Docker: it’s a framework to help system engineers build platforms like Docker out of many components.)

Docker的CTO Solomon Hykes称此举是为了更好地打造并丰富开放容器生态,并不是走向封闭;圈内的误解都是公司沟通不善的锅。

面对争执,Docker表示很无辜。

不是走向封闭,而是更开放

一位michaelfavia网友表示Docker项目的今天是社区努力的共同结果;同时,他所在的公司目前重度使用Docker项目,转变技术栈为时已晚。虽然从Docker的商业利益角度而言,这无可厚非;但是他不赞同这种做法。

Docker的CTO Solomon Hykes则回复到其实项目并没有走向闭源,所有过去开源的会继续开源,甚至会有更多的开源出来。事实上,如果某家公司业务是基于此,Moby的变化反而是好事;Docker公司会更多地致力场景的定制化。

Moby的定位

Solomon表示Moby项目是产品链路中的一环,从上游到下游的项目依次为:

上游组件(containerd,linuxkit等)-> Moby -> Docker CE -> Docker EE

短期内, Docker CE和EE的用户不会受到影响

随后一位frekele的网友表示感谢后续的解释,但是希望可以读到docker to moby的指导指南,这样大家在下一个发布版本之前可以更清楚地了解发生了什么,会有哪些影响。

Solomon Hykes表示短期内Docker CE和EE的用户不会受到影响,下一个二进制发行版本不会发生变化。Moby会有自己的发布流程,会在后续讨论。

求证,Moby项目究竟意欲何为?

那么不如,摆事实讲道理,看看究竟是怎样一回事。

Docker声明1Moby并不是Docker的替代品。将引擎拆分为更多开放组件,对我们用于组装Docker产品的各新型工具与组件进行开源并供技术社区使用。

事实1:

  • 分解Docker工作已经进行一段时间了,比如已经完成的runC和containerd。其中containerd已经捐献给了CNCF。

  • Docker 1.11版本起,即2016年5月,Engine开始基于containerd、runC,可看作Moby项目缘起。而再往前追溯,OCI协会于2015年6月,呼吁业界制定容器运行时和格式的规范。

判断1DIY式工具集——Docker公司将原来大家熟知的Docker开源项目的拆分成不同模块,然后形成一个乐高式的容器化工具集。Moby并不完全等同于原来的Docker项目,Docker公司不是强取豪夺,它确实还付出了一番努力的。

Docker声明2:本意是希望帮助系统工程师使用Moby这个工具集去构建类似于Docker的平台。

事实2:

  • Moby项目包含三大元素:一款用于对系统进行组装、实验与测试的工具链框架; 一套包含约80种容器化组件的库(适用平台包括裸机,如x86与ARM; Linux、Mac与Windows可执行文件; 面向各主流云及虚拟化供应商产品的虚拟机镜像); 以及一份“参考蓝图”,即提供细节信息以帮助用户了解如何利用众多组件片段组合系统方案。其中部分组件片段可同时用于容器化应用堆栈以及Linux发行版——例如Redis或Nginx。其中亦包括Docker公司过去几个月间向开源社区贡献的部分成果,包括containerd及LinuxKit。
  • 还有一个事情注意的是,除了Moby项目之外,Docker还同期发布了另外一个新项目LinuxKit。LinuxKit可以对多款工具进行绑定以构架定制化Linux子系统。此前由Docker公司与芯片合作伙伴ARM、HPE等多家基础设施供应商以及微软与IBM等云厂商协作开发。作为成果,LinuxKit作为开源项目由Linux基金会负责管理,同时遵循其开放治理实践。
  • LinuxKit中运行软件的唯一方式即为使用容器。(这或将意味着系统的攻击面将大幅减小,用户可更轻松地根据安全需求对任意软件进行更换)

判断2:以往Docker公司对Linux强依赖,但是现在Docker决定利用容器元素组成新的Linux发行版。诚如Docker公司市场营销与技术社区高级副总裁David Messina所说表示目标受众为要求以Linux作为产品运行基础

Docker声明3:受Fedora项目启发定义一整套开放、以社区为中心的治理政策(Fedora项目在平衡社区需求与主要企业赞助商要求之间获得了巨大成功)。

事实3:

  • Moby项目的设计原则包括:
    • 内置组件并允许替换:Moby中包含大量组件选项以构建全功能容器系统,但其模块化架构亦可确保大部分组件可通过其它不同实现方案进行替换。
    • 实用性与安全性齐备:Moby项目提供安全默认选项,且不会对实用性产生负面影响。
    • 以容器为核心:Moby项目利用容器构建,且用于运行容器。
  • Moby项目利用containerd作为默认容器运行时。
  • Moby项目中的全部组件皆以容器形式存在,因此新组件的创建难度等同于构建新的OCI兼容型容器。

判断3DIY式社区——利用Moby项目可以构建分布式应用程序中的组件,不论是配置文件还是底层内核。Docker公司希望凭借Moby项目降低内部的重复工作量,而此项目在理论上也允许其他使用者达成同样的效果。 同时,建立Moby项目的另一大潜在动机,或许是借此利用来自Docker或者其它贡献方的组件片段建立起各类可用实例,并为

经过上面的介绍,想必大家对Moby都已经有所了解了。那么LinuxKit呢?

还有一个LinuxKit:DIY式工具集

LinuxKit是用来构建安全、可移植、精益的专门为容器服务的操作系统的工具集。

作为Docker公司长久以来用于创建Docker Desktop与Cloud的内部方案,LinuxKit利用容器作为基础构建块以组合定制化Linux发行版。其拥有极为苗条的身材——最小体积仅为35 MB,且确保全部系统守护程序皆以容器化方式存在。其系统组件与所发 布之软件皆以容器形式进行交付。

Docker公司指出,该项目的目标受众为“要求以Linux作为产品运行基础”的开发者。Docker公司市场营销与技术社区高级副总裁David Messina在电话采访中亦确认了这一定位。

LinuxKit的一大适用用例类型源自物联网。由于物联网平台要求所使用之Linux拥有小巧且安全的特性,因此其它Linux供应商皆据此推出了类似的项目,包括Canonical的Ubuntu Core以及Suse的JeOS。

Docker公司首席开发者布道师Patrick Chanezon援引了多家大型工业企业的实例,其曾尝试构建基于Linux的物联网解决方案,但却因现有技术选项的弊端而遭遇失败。他认为LinuxKit的出现有可能给此类场景带来福音。

不过Chanezon与Messina亦同时指出,LinuxKit除适用于高端工业用例之外,亦能够吸引来自Gentoo、Linux From Scratch或者Slackware的高水平个人用户——即帮助其推出定制化发行版并将其部署在特定硬件设备之上。Messina表示,“LinuxKit非常灵活且可供技术爱好者加以尝试。”

在DockerCon 2017大会上,微软公司Azure架构师John Gossman讲解了一项以Azure为基础平台的LinuxKit用例。Hyper-V隔离通常仅适用于Windows容器,但如今其已经获得了支持Linux容器的能力。用户可以自行选择Linux内核,而LinuxKit将作为其中一种可用选项。

Moby + LinuxKit的组合拳

LinuxKit负责提供用于创建容器类Linux发行版的各类工具,而Moby项目则可帮助用户整合Docker发布至技术社区的各容器元素。

Moby项目之于容器生态系统,正如LinuxKit之于Linux发行版。

这两个项目的核心在于利用可互换的容器组件打造各类新型系统,Docker公司希望提供一种构建定制化容器系统的新途径。

Docker公司Partick Chanezon称:Linux只是Docker的一个组件。所以Docker公司的愿景是想打造横跨Linux,Windows,iOS及至嵌入式等系统平台的大生态体系。

国外和国内有哪些声音?

GitHub、HackerNews、知乎论坛上广大网友们的正面声音并不多,除了一位绅士喵的网友认为更名完全不会造成麻烦,并相信Docker代码依然是完全开源并且会一直存在下去。

有趣的是,实名接受采访的一些业界专家大多数表示了对Docker此番举措的认同。

在外媒中的采访中,Pund-IT公司首席分析师Charles King指出:这一新型协作模式将带来更为方便快捷的部署途径。两个项目的核心目标在于简化容器环境部署与支持工作中的各大关键性流程。

Scality公司CTO Giorgio Regni表示“这亦意味着我们能够利用同样的工具以统一化方式构建自有虚拟机镜像、裸机镜像以及公有云镜像。”

爱奇艺技术总监余珂称他倒是希望Docker能够商业化成功,这样对社区是好事。否则类比Openstack,没有公司盈利的支撑,社区运营也会比较艰难。

京东基础平台部技术总监鲍永成表示:京东在容器技术具有定制开发经验和积累。京东目前运行的Docker版本是经过自己定制,对于Docker更改名称和项目,对京东没有影响。

阿里云资深专家易立认为更名是为了限制Docker名称的使用范围,Docker作为Docker公司的注册商标,只能被用于Docker的产品(比如社区版、企业版、Docker Hub、Docker Store等)。Docker此举对最终用户没有影响,或将影响到开发者和厂商。但是其实Moby项目是将控制权交给社区,并且最终有益于整个容器生态圈的发展。

Pivotal大中国区云计算首席架构师周晖同样表达了观点:

Moby是Docker公司在继推出Docker商业版之后的又一个重要的商业举措,就是把Docker的开源部分比如源码剥离到Moby项目,而Docker则作为纯商业化平台。有些Docker粉丝颇有微词,因为之前对Docker的关注是基于开源,现在Docker不算开源部分,那些给Docker做生日蛋糕的下次要改成给Moby了。

对Docker公司而言,我倒是觉得这次剥离有利于Docker的商业和开源的发展,没有商业成功的开源很难走的很远,如果Docker一直不能盈利导致Docker公司运营艰难,很难想象Docker会继续发展。

对于客户而言,如何做选择会有更多的依据:第一是继续用Moby开源自己定制,第二是选择商业版的Docker,第三是选择Moby创业公司(之前大家习惯称为Docker创业公司)的定制版。

Moby的剥离对曾经的Moby生态圈创业公司而言又是一次打击,因为Moby创业公司不能再混淆概念了,不能再自称是Docker中国区代理之类的,其次,围绕着Moby的创业区域越来越小了,因为Docker在Moby上增加的商业功能越来越多,如果继续和Docker功能重叠,那客户做的选择就简单,与其用Moby创业公司的定制Docker,远不如用原生的商业Docker。

不过……

Docker公司明确指出开发者共享的任何代码皆不属于贡献——意味着开发者仍对相关成果保留全部控制权。Docker在其官方声明《Moby and Docker》中声明,Docker现在是,将来也会是开源的产品,可供容器build,ship,run。Moby项目之后,用户使用上没有任何差异,用户们可以从docker.com网站下载Docker。(其官方声明的词汇搭配是Docker Product和Moby Project。)

不过,Moby项目有不适用人群:

  • 对于希望寻求便捷方式在容器中运行应用程序的应用开发者,建议使用Docker CE。
  • 对于希望寻求可直接使用的商用支持型容器平台的企业IT与开发团队,建议您使用Docker EE。
  • 对于希望了解容器技术并寻求简单学习方法的朋友,推荐docker.com网站。

Docker公司走过了怎样的路?

一步一步,构建生态之心

第一阶段 :(2013-2014)开源容器技术早期阶段

先驱者们开始率先使用容器技术,并通过开源代码库、Docker以及其它相关项目进行协作以推动相关工具发展成熟。

第二阶段:(2015-2016)进入云原生程序的生产环境

在这一阶段,用户社区开始成长并立足数百个生态系统项目与成千上万贡献者支持其大规模部署活动。与此同时,Docker亦将其基本生产模式转变为基于开放组件的形式,旨在增加创新能力并进一步拓展合作范畴。

提取Docker代码库中的组件并进行快速创新,以帮助系统开发商在构建自有容器系统时对其进行单独复用,具体包括:runc、HyperKit、VPNKIt、SwarmKit、InfraKit以及containerd等等。

第三阶段:2017 构建容器生态

Docker认为容器化将成为市场主流,并逐步扩展至各类计算环境当中——包括服务器、数据中心、云计算、桌面、物联网乃至移动端。各个行业与垂直市场、金融、医疗卫生、政府、旅行以及制造业亦参与其中。同样的,包括现代Web应用、传统服务器应用、机器学习、工业控制系统以及机器人等层面亦成为其具体用例形式。作为一大共性,刚刚加入容器生态系统的参与者往往会建立与特定基础设施、行业或者用例相适配的专用系统。

Docker会利用开源体系作为产品的创新实验环境,并与整个生态系统开展密切合作。目前,Docker公司称针对Mac、Windows桌面、Windows Server以及AWS、Azure和Google Cloud Platform等发布了十余种特定Docker版本。

Docker公司称为了能够在短期内通过小型团队以可扩展的方式有效复用既有开发成果,非常需要一种新的方法开发各种专用型版本。Docker团队不仅需要有能力组合各类组件,同时亦应借鉴汽车行业的运营思路,即在不同车型(或者说版本)当中复用同样的组件。

第四阶段:未来在路上

Docker认为将容器生态系统推向下一个发展阶段以实现容器主流化的最佳途径,在于立足生态系统层面实现通力协作。

正是基于此,Docker公司正式公布Moby项目——全新开源项目,提供数十款“乐高”形式的组件,用户可将其组装至基于容器的定制化系统框架当中,并立足于此进行实验并与其他容器技术参与者交流思路。Docker公司解释称不妨将Moby项目视为容器系统版本的“乐高俱乐部”。

Moby项目专为系统构建者(而非主要使用Docker或者其它容器平台的应用程序开发者)设计,旨在帮助其打造自有基于容器技术的系统。Moby项目的参与者可以从Docker提供的组件库中选择自己需要的选项,亦可通过“自带组件(简称BYOC)”机制利用更多其它组件创建与众不同的定制化容器系统。

Docker将Moby项目作为开放性研发实验室,供各位生态系统参与者立足未来容器技术发展构思进行实验、新组件开发以及协作。我们的全部开源协作成果还将逐步被引入Moby项目之内。Docker公司称其诚挚邀请社区人士加入以推动软件容器主流化运动,并共同将生态系统与用户群体规模扩展至更高层次。

更名是因为Docker已经成为了注册商标;将项目模块化是为了更易用。

Docker一定知道社区的重要性,其目标也是建立更大的容器生态;同时,它也希望更多的行业应用场景,不然不会布局为物联网做准备。

面对投资人压力,Docker公司在戴着脚铐跳舞;也许后来,它会成为下一个RedHat。

参考文章

https://thenewstack.io/docker-seeds-two-new-projects-building-containerized-infrastructure/

http://www.infoworld.com/article/3190611/open-source-tools/docker-debuts-containerized-construction-kit-for-building-linux-distros.html

http://www.linuxinsider.com/story/84474.html

https://blog.docker.com/2017/04/introducing-the-moby-project/

https://yq.aliyun.com/articles/74440

https://yq.aliyun.com/articles/74437

附文:Moby项目的官方声明

Moby项目——面向容器生态系统以建立组合式容器系统的协作项目

Moby是Docker公司开发的全新开源项目,旨在进一步推动软件容器化运动的前进步伐。其以“乐高式”思路提供数十款组件选项,配合一款能够将各组件组合为定制化容器系统的框架,同时亦可作为容器技术参与者们实验灵感并交流思路的协作平台。

Moby项目概述

Moby项目的核心是一套用于组装定制化容器系统的框架,其具体特性包括:

  • 一套涵盖各类容器系统组成元素的容器化组件库,具体包括操作系统、容器运行时、编排、基础设施管理、网络、存储、安全、构建以及镜像发布等等。
  • 将各组件组装为面向多种平台及架构之可运行元素的工具,适用平台包括裸机(x86与ARM); Linux、Mac与Windows可执行文件; 面向各主流云及虚拟化供应商产品的虚拟机镜像。
  • 一组参考组合方案,可用于直接使用、修改或者启发您创建自己的容器系统。

Moby项目中的全部组件皆以容器形式存在,因此新组件的创建难度等同于构建新的OCI兼容型容器。

设计原则

Moby为基于明确原则指导的开放项目,但同时亦拥有模块化、高度灵活性且无硬性使用方式规定等优势,因此容器技术社区可充分参与并为其设定下一步发展方向。Moby项目的设计原则包括:

  • 内置组件并允许替换:Moby中包含大量组件选项以构建全功能容器系统,但其模块化架构亦可确保大部分组件可通过其它不同实现方案进行替换。
  • 实用性与安全性齐备:Moby项目提供安全默认选项,且不会对实用性产生负面影响。
  • 以容器为核心:Moby项目利用容器构建,且用于运行容器。

利用Moby项目,您将能够描述分布式应用程序中的全部组件——包括高级配置文件到底层内核——并利用其轻松构建并部署应用成果。

Moby项目利用containerd作为默认容器运行时。

受众

Moby项目适用于任何希望利用现有或定制化组件组装容器系统的用户,具体包括:

  • 希望对其Docker构建方案进行定制或者调整的技术爱好者
  • 负责构建容器系统的系统工程师或者集成商
  • 希望将现有容器系统与其实际环境进行适配的基础设施供应商
  • 希望体验最新容器技术的容器技术爱好者
  • 希望立足多种不同系统测试其项目的开源开发人员
  • 任何希望了解Docker内部架构及构建方式的朋友

Moby项目不推荐以下用户使用:

  • 对于希望寻求便捷方式在容器中运行应用程序的应用开发者,我们建议您使用Docker      CE。
  • 对于希望寻求可直接使用的商用支持型容器平台的企业IT与开发团队,我们建议您使用Docker EE。
  • 对于希望了解容器技术并寻求简单学习方法的朋友,我们向您推荐docker.com网站。

过渡至Moby项目

Docker公司正在将全部开源协作成果逐步引入Moby项目。在这一过渡期间,全部开源贡献活动皆可照常进行。

以下为具体变更说明:

  • 将引擎拆分为更多开放组件
  • 移除docker UI及SDK等,并将其转入Docker内部进行保留
  • 强调此项目不仅限于此引擎,亦适用于Docker平台之上各独立组件的组合
  • 对我们用于组装Docker产品的各新型工具与组件进行开源并供技术社区使用
  • 受Fedora项目启发定义一整套开放、以社区为中心的治理政策(Fedora项目在平衡社区需求与主要企业赞助商要求之间获得了巨大成功)

法律问题

若您有任何相关疑问,请与我们的法律顾问联系。欲获取更多背景信息,请参阅本资源库中的NOTICE文档。Moby项目的使用与转让可能受到美国及其它政府某些法律条款之限制。您有责任确保您的Moby项目使用及/或转让行为遵循适用法律之具体要求。欲了解更多信息,请参阅:https://www.bis.doc.gov。

许可Moby项目基于Apache License v2.0许可。欲了解完整许可内容,请参阅LICENSE。原文链接:https://github.com/moby/moby

Google自家容器操作系统正式于GCP上线

刀客info阅读(5238)评论(0)

去年9月,Google利用自家开源Chromium OS作为基础,推出了一套为执行容器应用程序所生的操作系统Container-VM Image。Google表示,当今有许多为执行容器而生的操作系统,「而许多用户表示,希望可以导入Google自家使用的映像档,让运作在Google上的服务可以得到更好的改善。」

而近日这一款操作系统正式在GCP上线,并且改名为Container-Optimized OS,许多Google在正式环境运行的服务,例如Google Cloud SQL、Google容器引擎,也都是以这个操作系统为基础。Google解释,现在使用GCP的企业用户,透过Container-Optimized OS,在建立VM的同时,系统也随即会建立一个Docker容器。

Google也列出这款操作系统的几大特色,首先,Container-Optimized OS从开发、测试到发布都由Google全权主导,每当有新版本推出,GCP用户随即就可以使用。再者,除了内建Docker容器Runtime,为了应付大规模应用,也兼容于自家的容器调度工具Kubernetes。

另外,Google也将Root文件系统设定为只读,藉此加强Container-Optimized OS的安全性。

容器标准化之道

刀客info阅读(6868)评论(0)

本课程内容精选自 DaoCloud Docker Meetup 系列线下活动。本期内容整理自马士淼老师 2 月 25 日在 “New version, New vision” Docker Meetup 中的精彩分享。

马士淼

OCI Maintainer

富士通南大软件技术有限公司软件工程师,目前是 OCI runtime-tools 的 maintainer。从事 Linux 周边的开发工作。热爱开源软件,近几年主要从事 container 相关的开源开发工作。

以下为演讲实录:

今天主要是想和大家分享容器标准化,希望更多对容器化感兴趣的朋友可以参与到 OCI  社区之中。

我来自南京富士通南大软件有限公司,是一名工程师,Libstoragemgmt 的 Maintainer。同时由于工作关系,我对 Docker 接触比较早,目前也是 Docker 的使用者和贡献者。同时,我个人也是开源软件和免费软件的拥趸。

在今天的演讲中,我首先会对 container 的基础知识进行简短的介绍,延伸出目前我们所面临的问题,与大家探讨为什么需要进行容器标准化以及容器标准化的目标。在谈到容器标准化时,不可避免地需要谈及 OCI 社区。我会对 OCI 社区目前的状态,OCI 社区下面的开源项目进行简要地介绍,并且会针对当前面临的现状分享未来的开发计划。

/  关  于  容  器  /

容器技术是最近几年的热门话题,目前越来越多的公司都提出基于容器的解决方案。我个人理解,容器是系统级的轻量化的虚拟化技术。容器技术和虚拟机技术相比,天生有很明显的优势:节省资源。由于没有 guest OS,容器比虚拟机启动的速度更快,同时,占有的资源更少。 从这方面来说,容器比虚拟机,在资源方面有很大的优势。

20170315212157

但是,从我们对容器技术的了解来说,容器技术并不是最新的技术。它有很长的演进历史,从下图可以看到:容器技术可以追溯到 1979 年的很老的 chroot 。但是,容器技术一直没有像最近几年突然之间火爆起来。

20170315212203

➤ 为什么 Docker 带动了容器技术的火爆?

过去的容器技术,例如 Linux container 并不适合在不同主机和不同平台之间进行迁移。同时,它使用起来也不够方便。在这种情况下,催生了 Docker 的出现。

但随着越来越多公司的参与,每个厂商都提出自己的技术解决方案。例如比较热门的 Docker、Rocket/rkt 、OpenVZ/Odin、Hyper 等,他们都有自己的技术标准。没有统一的工业标准,每个厂商各自发展自己的容器标准,不可避免地会形成技术壁垒。这就导致整个容器生态看起来比较碎片化。所以容器标准化是为了更好地解决问题。

➤ 为什么我们需要容器标准化?

对于用户来说,他们不知道采用什么样的标准来选择适合他们的容器技术。不同厂商依赖不同的系统或云平台,导致用户也被迫过度依赖某厂商的云服务。用户想在云平台上进行迁移,会比较困难。

容器标准化,实际上就是为了解决上述问题。容器标准化的目标,就是规范容器技术,引导不同厂商向同一方向发展,同时引导用户选择对自己有利的技术,或提供评价的标准。

 

/  OCI  技  术  /

谈到容器化的标准化,不可避免的要讨论一下 OCI 技术。OCI 的全称是 Open Container Initiative,这是 2015 年 6 月 22 号发起的开源组织,目前,在 Linux 基金会之下运作。它的主要目的是希望能够为容器和运行格式提供统一的标准。目前大概有 47 个 IT 厂商或者云服务商参与其中。

OCI 社区的主要工作,首先是创建容器运行时的 spec,容器的运行时标准,以及 image 的标准。同时,负责接收管理和提高与这些标准相关的开源项目。同时,OCI 社区也负责与其它标准之间的协调性工作。更多的关于OCI 社区的这种介绍,大家可以去 www.opencontainers.org 官方网站进行了解。

我今天主要会分享 OCI 社区下面几个主要的开源项目,向大家介绍一下目前容器标准化的开源状态。大家现在看到的,是 Docker 运行一个 container 的基本流程。为什么以 Docker 为例?因为 Docker 当时提出的口号是:build ship run。一次编译能够跨平台的创建运行。

20170315212209

上图中可以看到,Docker 首先需要加载一个 image,image 当中包含了运行所需的根目录,同时接收用户的请求,生成容器运行时的配置文件。根据配置文件用户的请求,以及 root MS 来运行生成容器。 Docker 在没有 OCI 社区之前是一个实时性的容器标准,OCI 社区就借鉴 Docker 的标准,将其规范为从上层运行的基本流程,把它简化为以下几个概念。

20170315212215

如上图所示,容器的执行需要 bundle,bundle 中包含了容器需要的根目录以及容器运行时需要的配置文件,然后通过 runtime,解析 config 配置文件的内容。挂载根目录生成 container,来运行配置文件中需要执行的程序。同时为了便于容器在不同的平台或者架构上进行兼容性地转移,提出了 image 的标准,image 和 bundle 之间可以进行互换。

 

/ 五  个  开  源  项  目  /

runtime-spec 容器运行所需要的 runtime 标准,以及了解容器运行时需要的 config 配置文件,需要哪些内容的标准。

image-spec 负责管理开源的容器镜像的标准。

20170315212224

△ image-spec

 

runC 是基于 runtime 的实现,通过 runC 大家可以创建运行删除容器,它是容器的运营工具。

20170315212231

△ runC

runtime-tools: 是我目前贡献比较多的项目,是根据 runtime-spec 的标准来验证。首先验证工作,第一是验证一个 bundle 是否符合 runtime-spec 的要求。其次是验证一个 runtime 是不是兼容 runtime spec。

20170315212237

△ runtime-tools

image-tools: 和 runtime-tools 的功能比较相似,也是验证性工具。因为 OCI 社区的目的不仅仅是定义这种容器的开源工业标准,同时希望能够提供验证的程序,帮助大家能够通过 OCI 的这种程序,让更多人了解和接受,这是符合开放性标准的 runtime。

20170315212246

△ image-tools

/ 目  前  社  区  状  态  /

Runtime-spec 从以下几个方面对标准进行了规范runtime-spec 定义一个 bundle 应该包含哪些内容,比如说要有 container config 配置文件。同时对容器的生命周期以及 runtime 应该做哪些操作,进行了标准化的规范;对容器运行所需要的配置文件当中,需要包含哪些配置项进行规范。

目前,runtime-spec 对于 Linux, Solaris, Windows 三个平台都进行了支持。同时,提供了 specs-go package,方便大家可以通过调用包来完成符合 runtime spec 的编写和创建,同时提供了 json schema 的应用包,帮助大家验证自己的config 是不是符合 runtime-spec 的要求。目前已经发行了 9 个版本,最新版本是 v1.0.0-rc4 版本。在 1 到 2 个月内,1.0 版本即将通过。

Image-spec 对容器的镜像的 layout 和镜像的配置、货品清单进行了规范。通过标准对容器镜像的标准化,我们规范容器镜像的基准格式,和镜像包中应该包含哪些内容。这样,镜像可以在不同云平台和不同云厂商之间兼容性地运行,不会过度依赖某个厂商的平台或架构。image-spec 也提供了 specs-go package 和 json schema 的验证包。

目前 image-spec 发布了 10 个版本,最新的 v1.0.0-rc5 版本。目前还有很大一部分工作需要做。也欢迎对 image container 感兴趣的各位朋友多多参与。

Runc 是基于 runtime-spec 的一个实现,目前支持容器的创建删除等基本操作。而且,runC 在 Docker,Kubernetes,亚马逊云服务等平台已经获得支持。执行 Docker,底层是 runC 进行容器的创建和状态查询。目前,runC 也已经发布了 14 个版本,也是出现 RC 版本的状态。以我对 runC 的了解来说,目前主要面临的问题是底层仅仅支持 cgroupsv1 ,而对某些系统上已使用的 cgroupv2 目前还不支持。

➤ runtime-tools 三大功能

目前,runtime-tools 主要有以下 3 个功能。

  • 第一个功能是帮助用户生成 container 运行时的配置文件。社区认为,container 配置文件是一个 json 文件,里面包含了很多项目。如果用户自己进行编写的话,首先需要自己学习 runtime-spec,要对 Linux 配置项特别熟悉,还要会写 json。这会比较困难。我们希望自己提供 json 命令行工具和一个接口,用户只需要根据命令行参数,可以自动生成 runtime config 配置文件。
  • 另外,我们目前也提供了对 OCI bundle 的验证。因为在 OCI 运行里面 bundle 是必须的,image 只是存储不是运营所需要的。我们希望在支持 OCI 标准的云厂商中,能够支持用户上传自己的 bundle 包。这样以来,我们首先对用户的 bundle 进行检证,检验它是否能够在符合 OCI 标准的 runtime 上正常运行。目前已经完成了大概有 70% 的验证工作,只剩下 30% 需要验证的项目还没有进行。
  • 第三种功能是对 runtime 进行验证,这也是 runtime-tool 的主要方向。我们希望提供验证机制,帮助用户分辨一个 runtime 是否符合 OCI 标准。Runtime-tools 的验证目前分为两部分:一个是内部的验证,runtime test,一个是外部的 cgroup 和 lifecycle 的验证。内部的验证工作,目前已经完成。但是,cgroups 和 lifecycle 的验证目前还没有完成。我们正在对 runtime-tools 外部验证进行改造,希望实现自动化验证结果。

➤ image tools 主要功能

  • 对 image 的验证,基本开发功能已经完成。对于 image 的验证,主要工作也比较简单,因为 image spec 的要求,image 每一层需要有一个哈希值,配置文件同时有哈希值,这为我们的验证提供了很方便的途径。image-validation 也是根据文件的配置项当中的哈希值来验证是否被篡改,所以说目前工作量不是很大的情况下,基本验证工作已经完成了。
  • 另外的功能,是帮助用户把一个 image unpack 成一个 bundle,提供帮助用户 image 转换成 bundle 的过程、功能。具体每一个项目的进度,大家可以在 github 上进行查看。

/ 社 区 开 源 项 目 未 来 计 划  /

对于 runtime-spec 和 image-spec,目前关注的不是太多,所以说我们目前只是期望 v1.0 能够尽快发布,重点参与对一些 json schema 的验证包修正。

对于 runC,我们目前的工作重点是,对于 runC 支持的 cgroupv2 的开发。同时,需要完成对 runtime-spec 要求的一些配置,目前 runC 还不支持这部分的开发,希望尽快提升 runC的品质。

对于 runtime-tools,我们未来的计划,完成对于 Linux cgroups 配置的验证,以及对 runtime validation 的改造。还有一个重点,完成这种验证结果输出的可能性。目前的可能性比较差。将来还计划完成 runtime 的兼容性工作。目前 runtime-tools 过度依赖于底层的 go 源包。目前仅仅完成的工作,比如说在 Linux 系统上,验证面向 Linux 的 bundle。我们希望将来在 Linux 平台能够对不同的,比如说面向 Windows 的包,完成这种验证工作。

Image tools 主要的问题,是目前它的功能都是分散的,我们希望它能像 runtime-tools,对其做统一的改造。同时也希望 image tools 也能像 runtime-tools 一样,实现在跨平台的验证工作。

Docker容器的自动化监控实现

刀客info阅读(15130)评论(0)

2016年对于网易杭州研究院(以下简称“杭研”)而言是重要的,成立十周年之际,杭研正式推出了网易云。“十年•杭研技术秀”系列文章,由杭研研发团队倾情奉献,为您展示杭研那些有用、有趣的技术实践经验,涵盖云计算、大前端、信息安全、运维、QA、大数据、人工智能等领域,涉及前沿的分布式、容器、深度学习等技术。正是这些宝贵的实践经验,造就了今天高品质的网易云产品。今天的转载来自网易杭州研究院运维团队,提出了一种模型化容器监控方案,并描述了该方案的主要实现方法。

近年来容器技术不断成熟并得到应用。Docker作为容器技术的一个代表,目前也在快速发展中,基于 Docker的各种应用也正在普及,与此同时 Docker对传统的运维体系也带来了冲击。我们在建设运维平台的过程中,也需要去面对和解决容器相关的问题。

Docker的运维是一个体系,而监控系统作为运维体系中重要组成部分,在 Docker运维过程中需要重点考虑。本文介绍了一种针对 Docker容器的自动化监控实现方法,旨在给 Docker运维体系的建立提供相关的解决方案。

容器

谈到容器,有人首先会想到 LXC(Linux Container)。它是一种内核虚拟化技术,是一种操作系统层次上的资源的虚拟化。在 Docker出现之前,就已经有一些公司在使用 LXC技术。容器技术的使用,大大提升了资源利用率,降低了成本。

直接使用 LXC稍显复杂,企业拥抱容器技术具有一定的门槛,可以说 Docker的出现改变了这一局面。Docker对容器底层的复杂技术做了一个封装,大大降低了使用复杂性,从而降低了使用容器技术的门槛。Docker给出了一些基本的规范和接口,用户只要熟悉 Docker的接口,就能够轻松玩转容器技术。可以说,Docker大大加快了容器技术的使用普及度,甚至被看做业界容器规范。

容器的监控

容器与通常的虚拟机在虚拟化程度上存在着差异,在监控手段上也有不同。一台虚拟机,我们可以当做一个物理机对待,而容器虽然也可以当做虚拟机,但这不符合容器的使用理念。在监控的实现过程中,我们更倾向于把容器看做是宿主机上的一系列进程树。

主流的监控系统实现过程中,一般需要在目标机器上部署 agent模块,通过 agent模块来做数据采集。而根据容器的使用理念,一般不建议在容器镜像里面捆绑 agent。当然这并不意味着数据没法采集,针对容器的虚拟化技术特点,在容器的宿主机上对容器进行数据采集是完全可行的,而且能够做到更加高效。

当然,如果把容器当做虚拟机对待,上面部署上 agent模块来采集监控数据,也是一种方法,但这不是推荐的做法。我们可以看到业界已经出现的一些 Docker监控方案,如 Docker Stats、CAdvisor、Scout等,也都是在宿主机上对容器进行监控的。本文提出的监控方案,也将会从宿主机上着手。

 

20170314220016

 

常见容器监控存在的问题

随着 Docker的应用,业界也出现了很多的监控工具,这些工具实际上也都能对 Docker容器进行一些监控。利用这些工具搭建一套监控系统来使用,也是基本能够解决一些需求的。但是分析这些监控工具,主要存在两方面的问题。

1. 与运维体系的结合度

这些工具基本都是独立的,很难与运维体系中其他系统整合打通。在运维自动化不断发展的今天,往往更加注重的是整个体系的集成度。所以需要有一个更好的模型化的思路,便于系统间的数据打通。

2. 监控的层次

这些工具的监控一般都只停留在单个容器的层面,例如对容器的 CPU,磁盘 IO等的监控。而大多数应用设计架构都具备一定的节点容错能力,单个节点的问题,往往不能够反映出应用的真实问题。所以监控需要覆盖到更多的层次。

模型化容器监控方案

这里我们从整体上提出一种模型化监控方案。这一方案有利于和运维基础的 CMDB系统打通,同时能兼顾到更多层次上的监控。

监控系统一般会涉及:数据采集、数据存储、数据分析和报警、数据展示等几个部分。本文将讲述一种模型化监控方法,主要提出了以下五种模型:

1、监控对象模型

这里我们将使用一种产品树的结构来建模监控对象。把监控对象分为四类,分别是产品、应用、集群、节点。

  • 产品:一般是一个高层次的概念,一个产品一般可以独立输出,对外提供服务。
  • 应用:是产品下的模块组成,多个应用共同形成一个产品。
  • 集群:是应用的存在形式。同一个应用,一般会根据环境,地域等,部署多个集群。
  • 节点:集群内承载服务的资源,包括前文提到的服务器,虚拟机,容器等。

 

20170314220023

 

这样,我们的监控数据采集,和视图展示,就可以基于产品树这个层次化的监控对象来做。每种监控对象上都可以有自定义的监控项,也可以继承上层的监控项。同时,分层次的监控对象,在很好地组织监控结构的时候,又可以从多种层次角度来反映出系统的运行状态和问题。

例如我们一个基于 Docker的应用需要监控,应用名称为 myDocker。我们可以建立如下监控模型:

  • 产品:my_Docker_product
  • 应用:my_Docker_app
  • 集群:my_Docker_cluster
  • 节点:my_Docker_container

2、采集器模型

主要用于采集数据的模块,同时满足数据输出规范,为了便于解析,同时具备较好的数据结构展示,我们可以采用 Json格式作为数据规范。在数据的语义上需要匹配对应的数据模型。例如针对节点模型的采集器,可以是一个脚本,通过捕获脚本执行输出来获取相应数据模型的数据。而上层节点的采集器,则一般是基于节点数据模型的一些计算,这些计算一般包括 sum,avg,max,min等,一般反映的是整个集群下节点的一些聚合数据。

例如,一个简单的采集器模型如下:

 

23170314220031

 

3、数据模型

用来定义监控数据格式,模型包括数据项和指标项。一个数据项一般包含一个或者多个指标项。数据模型中的数据来自于对应的采集器。

 

20170314220040

 

  • 例如,针对 CPU可以监控如下模型:
  • 数据项:cpu
  • 指标项:usr,sys,idle

4、报警规则模型

在数据模型的基础上,针对每个数据指标项目,可以设置报警模型。例如,空闲 CPU少于 50%的时候触发报警,则可以建立如下规则:cpu.idle < 50

5、视图模型

这个模型将数据模型和视图关联起来了。包含数据展示方式定义,例如可以是趋势图,表格等。可以结合数据模型中的数据项与指标项,描述具体数据指标的视图展示方式。不同监控对象上的视图,一般都能从不同层次体现出监控。

用 XML格式描述视图模型如下:

<?xml version=”1.0″ encoding=”UTF-8″?>

<view id=”cpu” title=”CPU” type=”trend” modelName=”cpu”>

<dataItem function=”usr” as=”usr” />

<dataItem function=”sys” as=”sys” />

</view>

这个模型表示 CPU趋势图,且根据 usr,sys两个指标项画图。示例如下:

 

20170314220048

 

6、监控项模型

监控项模型,包含了采集器模型,数据模型,报警规则模型,视图模型等的组合。通过将监控项运用于监控对象上。从而可以对监控对象进行自定义模型化的监控。

容器监控整体架构

在模型完备后,整个监控项需要解决监控项下发,数据采集,数据分析报警,存储等问题。这里我们介绍一种分布式监控框架来将整个模型串通起来。

框架图示如下:

 

20170314220055

 

各模块的基本功能简要描述如下:

  • agent:节点监控数据采集
  • master:agent的管控中心,负责将监控项配置下发给agent。
  • monitor:接收agent采集的监控数据,并统一存放到Kafka消息队列中。
  • analyser:订阅Kafka对列消息,进行数据的分析处理,存储和报警。(实际实现过程中,可以视情况对该模块进行适度的功能扩展和模块拆分)
  • web: 监控模型的各种管理,视图的展示。
  • kafka: 消息队列,缓存采集数据,共其他模块订阅使用。
  • DB/HBase:存储模型配置,监控数据等。

这个架构是一个常见的监控模型架构,而且比较容易和运维体系打通。在我们实现容器监控的过程中,就可以采用这个模型。

容器监控数据采集

数据采集是 Docker监控和一般监控系统实现过程中最有差异的地方。因为在 Docker容器内部,没有数据采集的 agent模块将不能直接依赖 agent来采集。

1. 节点数据

在容器宿主机上,我们可以获取到容器的很多基础数据。一般有以下几种方法。

通过 Docker命令

docker stats 这一方法比较简单,但是数据并不全面,我们可以看到如下效果。

 

20170314220101

 

基于 Linux文件系统

这个是比较推荐,且性能较好的数据采集方法。Linux的 /proc,/sys等系统目录下,记录了非常有用的监控数据。在这里,我们可以拿到大多数系统级,进程级别的运行数据,包括 CPU、磁盘 IO等。

例如我们要获取某个进程的 CPU占用,则可以采用以下方式计算出来。

 

20170314220107

 

2. 数据采集

集群的数据,是根据每个节点上的原始数据计算得到。是一种聚合运算,一般会有 sum,avg等运算场景。

3. 应用和产品数据

同理,应用和产品的数据则可以通过子节点的数据来计算得到。

监控的自动化

由于容器的自身特性,容器的销毁,创建等是一个很常见的场景。一个容器启动后,监控系统怎么察觉,同时需要对其做哪些数据模型的采集,这些问题就是监控自动化过程需要解决的。

1. 容器的自发现

容器新创建,停止,或者销毁,在宿主机上可以感知到。一般可以从如下目录获取。由于 Docker安装配置不同,或者 Docker采用的文件系统的差异,可能部分目录会有不一致,但实际获取策略都类似。

 

20170314220114

 

2. 容器与监控对象的自动关联

容器作为节点,是需要关联到集群下面才能融入监控系统。这里我们可以采用镜像名称与集群名称的映射匹配来自动关联容器到集群。

通过如下容器目录下的配置文件,我们可以获取到容器的详情,其中包含的 Image即为容器所采用的镜像名称。

20170314220126

当容器关联到集群后,则可以自动监控项配置。通过 master将配置下发到容器宿主机上的 agent后,则可以开始对容器进行数据采集和上报,从而对容器进行自动监控。

总结

本文提出了一种模型化容器监控方案。通过对监控对象、监控过程进行建模,基于模型来驱动整个监控场景,同时描述了该方案的主要实现方法。

这套方案相比现有的容器监控实现,具有更好的灵活性和扩展性。通过模型的改进和扩展,能够方便地将 Docker容器的监控融入到现有的监控和运维体系中去。

监控系统本身是一个非常复杂的体系。本文描述的方案很多地方细节上还没有充分展开,模型的建立上可能也有一些局限和考虑不周的地方,需要后续逐步完善。希望本文思路能给读者在开发监控系统、建设运维体系的过程中提供一些参考。

——周宇
网易杭州研究院运维部

商业化战略再进一步,企业版Docker EE终于来了

刀客info阅读(5557)评论(0)

目前最被广为使用的容器技术主导厂商Docker发表了Docker Enterprise Edition(EE),这是Docker第一个专供企业的Docker套装软件产品,而不像原有Docker Commercially Supported(CS)版本只是同一套Docker软件,多加上官方技术支援而已,旧有CS版也同时取消。同时,Docker也将开放原始码的免费版Docker Engine,更名为Docker社群版(Community Edition,CE)。

Docker Enterprise Edition可支援多种作业系统,也可部署在不同云端平台上,从CentOS、Red Hat Enterprise Linux、Ubuntu、SUSE Linux Enterprise Server、Oracle Linux及Windows Server 2016到AWS与Azure。至于Docker CE版,在本机端作业环境除支援Mac、Windows、Debian及Ubuntu等作业系统,公有云平台也同步支援AWS及Azure。

Docker亦祭出认证项目(Docker Certification Program),以协助用户辨识可支援Docker EE的架构、其他容器及外挂程序。

新版Docker包括了4种计费方案,分别是免费社群版、EE基本版、EE标准版,以及EE进阶版。所有版本皆内建容器调度功能、网络与安全的容器引擎,而EE基本版则额外提供认证能力,标准版增添映像档管理与Docker资料中心功能,进阶版则进一步强化安全,提供映像档安全扫描服务,售价采订阅制,年费依序是750美元、1,500美元与2,000美元。

Docker表示,不论是CE版或EE版都会每季更新,当前最新版本为17.03,但CE版另外还可选择每月更新(Edge选项),让开发人员可以率先测试新功能。

谁是 Docker 公司背后的神秘推手?

刀客info阅读(8464)评论(0)

道客船长「译见」系列,关注国外云计算领域的技术和前沿趋势,每周为开发者提供精选译文。

前言:诞生四年以来,Docker 技术日渐崛起,如今已呈现蓬勃景象。Docker 公司的发展,除了技术的更新迭代和社区参与的驱使,同样也得益于行业内“神秘”力量的推动。本文将为您解读 CNCF(云原生计算基金会,Cloud Native Computing Foundation)在 Docker 公司发展过程中有哪些重要的推动作用。

CNCF 成立于 2015 年 7 月,最初的成员包括 Docker、Intel、Red Hat、IBM 等国际知名云计算、互联网公司。CNCF 的建立是围绕 “云原生” 服务云计算,致力于维护和集成开源技术,支持编排容器化微服务架构应用,推动基于容器技术的云计算的发展。

“缘起:Docker 公司加入 CNCF

Docker 一直以来关注的焦点就是确保应用的可移植性

Docker 作为一项热门的容器技术,正受到越来越多的开发者和面临 IT 转型的大型企业的青睐。关于 Docker 公司 2015 年 7 月即加入 CNCF,Docker 创始人兼 CTO Solomon Hykes 在博客中是这样写道的,“ Docker 的使命就是为了大众的创新提供工具。为了实现这一目标,近年来,Docker 与全球顶尖的开发者、开源项目和机构(包括 CNCF、OCI 等)合作,为容器化提供了各个方面的解决方案。”

Docker 公司一直以来关注的焦点就是确保应用在任何基础架构和整个开发周期都能实现 100% 的可移植,这一点与 CNCF 基金会的目标相一致。可移植性意味着用户可以利用 Docker toolbox 中的解决方案开发应用,但是在接下来的开发过程中,他们可以自由选择所需要的生态系统工具。CNCF 为技术栈的验证和认证提供了模型,方便用户进行自由选择,以获得最佳的组合方案。

Solomon Hykes 同时于 2016 年 3 月正式宣布加入 CNCF 技术监管董事会(TOB),旨在为用户带来基于包括 Docker Swarm 等容器编排技术栈的多容器、跨主机的 “云原生” 分布式应用提供可互操作的参考技术栈实现。

Solomon Hykes

Solomon Hykes

“CNCF 推动作用:建立合作模式,促进互操作性

为基于容器的各类技术的集成确立参考架构

CNCF 的一项重要承诺,就是为基于容器的各类技术的集成确立参考架构。曾就职于微软、VMware、谷歌,现任 Docker 技术专家的 Patrick Chanezon 表示, CNCF 的核心任务是决定建立 OCI 之上的各类技术之间的互操作性状态。他认为从 IT 运维团队技术部署的角度来看,CNCF 不仅致力于提高互操作性,同时也防止 IT 机构受困于单一的技术。CNCF 专注于为不同的项目搭建桥梁,将着力于编排引擎。更确切地说,CNCF 将会成立一种合作机制,致力于 Docker 编配引擎之上的互操作性层面。

CNCF 所建立的合作模式会进一步完善工程师之间的协作方式,为多容器、跨主机的 “云原生” 分布式应用提供可互操作的参考技术栈实现。CNCF 为用户提供了三种 Docker 编排方案,分别是——容器生态的三驾马车:Docker Machine,Docker Compose 以及 Docker Swarm。这些解决方案从最初就重点关注多容器、跨主机分布式应用的创建和可移植性,通过 “batteries included but swappable(可插拔式的架构)” 的方式来实现可移植的应用程序。

与此同时,这些参考技术栈是否真的具备可移植性、是否可用于主要的云提供商和常见的内部的基础结构,将直接检验 CNCF 是否成功。由于这些参考技术栈所利用的组建都托管在其他机构,因此 CNCF 托管的项目和 Docker Swarm 等托管的项目之间的互操作性变得非常重要。

“Docker 时代已经到来

Docker 的出现究竟是昙花一现还是大势所趋?

随着 Docker 相关项目几何倍速度的增长,CNCF 会帮助简化各类可相互协作的 Docker 容器服务参考技术栈的部署。很多 Docker 应用和服务最终将由上千个分散在数据中心环境中的 Docker 容器组成,CNCF 对已确立的参考架构的推动,会缩短部署 Docker 应用和服务的时间,减少人力和金钱的投入。

Docker 自诞生至今已有四年时间,2013 年 Docker 发布之初,一些人将 Docker 视为一时兴起的技术,认为它只是昙花一现。但自此之后 Docker 技术日渐崛起,通过社区的持续建设,以及近年来 Docker 在开源项目和开源机构的深度合作,都让 Docker 发展到了前所未有的蓬勃景象。

20170310221155

数据来源:Datadog

截至 2014 年底,Docker 镜像下载量高达 1 亿;到 2017 年初,这一数量超过 80 亿。Datadog 于 2016 年中期针对客户的一项调查显示,在过去一年,Docker 技术的采用率从 2015 年 5 月的 8.2% 增长至 10.7%,增幅为 30%。这样的增长速度是惊人的。

Docker 已经发展到了全新的阶段:基于 Docker 交付快捷、使用简单灵活,生态开放的特点,越来越多的企业和科技巨头们正在选择拥抱 Docker。

数据库容器化的价值——反驳数据库不适合容器化的错误观点

刀客info阅读(5353)评论(0)

前几天高可用架构文章《数据库不适合Docker及容器化的7大原因》(后面简称7文),在群里引起一些讨论,我个人是有一些不同的观点,不过争论未必能说得非常清楚透彻,后来我说写文章回应。于是有了这篇文章。

这篇文章不仅仅是反驳该文,同时也想说说应用容器化以及云化的价值。阅读本文时建议先阅读一下本人上周发的《2016年容器技术思考: Docker, Kubernetes, Mesos将走向何方?》(后面简称容文),本文中会直接引用该文的一些观点。

《7文》虽然列举了7大原因,总结一下其实主要是两点:

  1. 容器化数据库没有带来太多额外价值,数据库不需要经常构建和部署,也不需要经常升级,数据库实例的环境也不需要经常变,用 Ansible 也可以轻松部署和设置。
  2. 引入容器带来的,安全,IO,网络等方面的技术成本和风险,如非必要,勿增实体。

本文主要也从这两点开始,逐个分析。因为该文其实本质上是在分析一项通用技术的价值,所以我们先聊下如何对一项通用技术做价值评估。

如何对一项通用技术做价值评估

任何通用的技术,都承载着一定的技术使命,有其历史背景和最终目标。评价其价值是要思考它的使命和目标,不能单纯的从自己的个例出发。

比如以该文中提到的 Ansible 来说,一次我给一技术负责人推荐 Ansible 的时候,他说 Ansible 的功能我们自己用 shell 写的一套框架已经搞定了,完全没必要引入额外的工具增加复杂度。我说 Ansible 可以屏蔽操作系统的细节,容易些写出跨操作系统的通用配置脚本,他说我们的操作系统都是 ubuntu ,这个功能对我们没价值。我说 Ansible 可以把变量和配置脚本分离,提高脚本的复用程度,他说我们的脚本也一定程度上做了变量分离,我们只分离必要的,满足我们当前的项目了。我说 Ansible 文档详细,学习成本低,他说 shell 脚本看看源码就会了,并且改起来也容易。最后这个争论没有任何结果,谁都没说服谁。

后来我也一直在思考,到底问题在哪儿?其实每种技术的推广时,无论是工具,框架还是语言,都会遇到类似的争论。后来我想明白了,任何通用的技术的最重要的目标其实是增加软件的复用能力,无论是该技术本身还是由该技术衍生出来的产物,但如果不考虑复用,应用到具体的场景时效果都会打折,所以不能只用具体的场景去评估通用技术的价值。

再拿前面的 Ansible 为例,Ansible 本身是一个服务器配置管理工具,它的目标是让服务器的配置变更代码化(Configuration management Infrastructure as Code),然后让应用的安装以及配置的能力组件化,它称之为 Playbook,然后可以共享复用。所以你可以在网上搜索到各种 Ansible 的 Playbook,比如数据库集群的安装配置等。它为了实现这个目标,抽象了一套配置语法,通过声明式的配置来定义服务器上的基础设施状态,也一定程度上屏蔽了操作系统细节(实在屏蔽不了的,也可以通过简单的配置规则来适配),同时做了变量和配置的分离,避免和具体的环境的耦合。也就是说,只有能接受它的核心思想 —- 服务器基础设施变更代码化,然后考虑到复用价值,复用别人的 Playbook 或者将自己的 Playbook 复用到更多的项目或者团队,Ansible 的价值才会体现出来。比如前面争论的那个案例,如果考虑到以后会有更复杂的操作系统环境,可能有更多的,更复杂的项目需要管理,避免运维手动操作引入不预期的变更,导致无法追踪,才值得引入 Ansible。

所以,不要仅仅从自己当前的业务需求来断定一个通用技术的价值,比如该文章的标题如果改成《我们当前的数据库不适合 Docker 以及容器化的 7 大原因》,争议就小很多。看一个文章要搞清楚它是在做具体的选型分析还是通用的价值判断。

数据库容器化的目标和价值

我们再从数据库容器化这个场景分析一下。

当前我们开发出的任何软件,到用户部署运行变成一个服务,之间是有巨大的鸿沟的。比如以数据库(MySQL/PostgreSQL)为例,厂商交付给用户的是一个安装包,而用户期望得到的是一个主从的数据库集群,能支持故障主从切换,自动迁移恢复,自动备份,还要能监控报警,当然要是有个 dashboard 来通过界面操作,实现自动升级,就更好了,更复杂的需求可能还需要支持读写分离和自动数据库切分。可以看出,二者之间是有巨大的鸿沟的,而这个鸿沟当前是靠用户的运维人员来填充的。

运维人员怎么填充呢?先从网上找到一些技术资料,怎么做 MySQL 主从复制,怎么做高可用(keepalived,虚 IP 等),怎么做双主,怎么通过代理做读写分离,然后将这些组件用脚本粘结起来,部署到服务器上。当然这还是运维实例比较强的,如果运维实力不够(大多数创业公司不可能在这种基础设施上投入研发精力的)可能连主从和备份都做不好,即便是自己用脚本写了一些简单的工具,由于测试不够充分,环境异常考虑不周,正式用的时候可能就出错了,比如前一段时间的 gitlab 删库事件。

简单回顾下 gitlab 事件,本来单节点的数据删除是不应该影响整个集群的,但因为从库数据同步不完备(所以可以推断从库应该是没有启用过,没有做读写分离),不能直接升级从库为主库,而其他的多种备份工具都没生效。

这大概是大多数公司的现状,有一些基础设施工具,但基本都是和环境耦合的脚本,也正如《7文》中所说,数据库等基础服务部署后很少需要去做变动,并且随着数据越来越多,越来越不敢动,每次变更,比如升级等,就是一个复杂的工程,差不多要发起一场战役,但一旦出现预期外的故障,就缺少必要的工具和经验去应对。那如何避免这种问题呢?左耳朵耗子的文章《从GITLAB误删除数据库想到的 [1]》提出了一个建议:『设计出一个高可用的系统,通过自动化的方式去处理问题』。

但是这个基础设施的自动化高可用系统,有那么容易设计么?一方面大多数公司受限于研发实力,没时间和精力做这种系统,另外一方面即便是有研发实力,这种系统并不能直接产生价值,如何得到高层的支持?能得到多大资源支持?数据库厂商或者其他商业公司能否提供这样一个数据库服务,再或者能否通过开源项目打造出一个数据库服务,用户可以一键部署?这样就能将各公司的运维经验沉淀成具体的工具和组件。而不是像现在,运维经验的沉淀和传播基本都只能通过技术分享或者人员流动,这对业界是一种很大的浪费。

那我们设想一下,如果要做前面描述的这样一个系统,都需要什么条件?

  • 首先,得有一种应用的安装包的环境无关的封装,如果要适配不同的操作系统,解决不同的环境异构问题,就很难了。
  • 其次,基础环境可编程化,可以在程序中实现网络,存储等环境的动态适配。再次,要有一个调度层,可以做动态迁移。
  • 最后,需要一个编排文件来定义各种组件,以及一种打包格式,将多个组件封装到同一个包中做分发。

Ansible/Puppet 等配置管理工具一直想做这个事情,并想封装成可复用的组件,可惜由于基础设施的环境不统一,不可编程化,而配置管理工具只能一定程度解决部署时的复杂性,应对不了动态的故障,基本很难达到这个目标。

IaaS 云实现了基础设施的标准化,可编程化,可动态调度。所以现在 IaaS 云基本都有 RDS(Relational Database Service),功能和前面的描述的用户需求非常类似。但 IaaS 的问题是当前 IaaS 的 API 基本都是指令式的,是面向资源的,不是面向应用的,第三方很难通过这种 API 来调度应用,所以这种服务第三方很难实现,基本都是云厂商自己定制(IaaS 上也有镜像市场,但只能是单个镜像的应用,不能实现复杂的应用),同时 IaaS 的镜像都是 VM,很难实现跨云的分发。

于是,Docker 出现了。Docker 的镜像,几乎完美实现了前面提到的安装包的环境无关的封装,也就是大家说的集装箱能力,又通过镜像仓库提供了分发机制。上面封装一层编排调度系统(Swarm,Kubernetes,Mesos),再加上标准化的网络和存储,于是基本达到了我们上面所描述的条件。

我在《容文》中也论述了

容器平台的最终目标其实是屏蔽分布式系统的资源管理细节,提供分布式应用的标准运行环境,同时定义一种分布式应用的 package,对开发者来说降低分布式系统的开发成本,对用户来说降低分布式应用的维护成本,对厂商来说降低分布式应用的分发成本,也就是 DataCenter OS 或 Distributed OS,可简称 DCOS。

也就是说,仅仅把数据库弄成容器镜像,这仅仅是第一步,是为了后面的目的服务的。有了这一步,才有可能依托容器编排调度系统封装更高级的通用服务。

有了这种能力后,运维的经验就可以沉淀成代码,积累成具体的工具和服务。软件的价值在于复用,可复用的频次越高范围越广,产生的价值越大,越值得投入。比如 RDS 这种服务,研发本身的复杂度本来不高,关键在对各种异常情况的处理方案的经验积累。一个公司遇到的异常状况肯定有限,只有放在社区中逐渐积累改进才会逐渐完备。IaaS 云的 RDS 的优势其实也是这一点,积累了云上的各种用户的各种使用场景和异常处理经验,无论是业务增长还是错误使用带来的异常。前两天 Instapaper 由于MySQL数据文件过大、达到 ext3 的 2TB 文件大小限制,而导致其数据库故障,业务中断31个小时,用的就是 AWS 上的 RDS 。虽然使用 RDS 并不能避免故障,但经过这次故障之后,AWS 肯定会改进 RDS, 将这种故障的应对经验沉淀到产品中去,其他用户就可以避免再次踩坑了。

当然还会有人问,我们当前没有任何精力做更高级的封装,只是把数据库简单的用容器镜像跑起来,还有意义么?也正如我在 《容文》中说的,对容器技术可以做渐进式的接纳,第一步先当做安装包使用,第二步考虑隔离,引入网络解决混合部署带来的网络冲突,第三步再考虑调度编排系统。《7文》中也承认了容器在开发测试环境中的意义,既然开发测试环境中可以接纳容器,保持环境的一致性不更好么?我在文章《基础设施服务的微服务化 [2]》中分析了为什么应该将基础服务也作为微服务的组件,一体化管理。只有将数据库等基础设施作为微服务的一个组件,和业务应用的微服务互相可以感知,才能实现最终意义上的全自动化。

当然,只是有了标准化的运行环境,并不一定能带来丰富的应用,还得依赖商业模式。这种基础设施服务原来的商业模式基本只能是 on-premise 私有部署模式,销售和实施成本非常高。企业应用领域是否可能出现一个类似于 Apple 的 AppStore 的市场来降低销售和实施成本? 这方面很多厂商都在尝试,各容器平台都在尝试推出自己的应用规范,IaaS 厂商也在考虑提供声明式的编排 API,让渡出基础设施服务,由第三方实现(比如 QingCloud 即将发布的 AppCenter)。如果这个商业模式成熟,不仅独立的基础设施服务以及中间件公司会涌现出来,同时各公司的基础研发部门可能会从原来的支撑部门,变为 2B 业务的营收部门。

引入容器带来的技术成本和风险

引入任何技术都会带来技术成本和风险,当然容器也不例外。但成本和风险是可以评估的。

  1. 安全 经常有人拿容器和虚拟机的安全做比较,然后说明容器的安全有问题。但实际上,大多数场景下容器并不是用来替代虚拟机的。如果用户只是用容器来封装原来直接运行在宿主机上的服务进程,那安全系数是增加了呢还是降低了?肯定是增加了啊,因为容器多了一层基于 cgroup 和 namespace 的隔离,最差的情况是这层隔离没有生效,那也和进程直接运行在宿主机上的安全效果一样。容器也并没有额外对外暴露端口等增加网络接触面,如果不是将容器直接暴露出去让第三方用户当虚拟机一样部署应用程序,容器并没有额外增加安全性问题。
  2. IO 性能影响 容器默认情况下一般都不会对 IO 进行限制,并且经过很多测试,基本上容器中的 IO 和宿主机基本没有差距,影响甚微,基本可以忽略。至于 《7文》中所说的丢数据的影响,明显是一个错误的表述,Docker 中持久化数据,一般是通过 volume 或者和宿主机目录映射,并不会直接直接写到镜像的 AUFS 上。
  3. 网络性能影响 首先不确定《7文》中所说的 Docker 1.9 版本中依然存在的网络问题是什么问题,该文也没给出 issue 链接。即便是容器的网络方案不成熟, 但 Docker 的网络标准 libnetwork 以及 Kubernetes 的容器网络标准 CNI,都是插件式的,用户可以选择更成熟的。如果服务已经运行在云上,容器一般都是可以复用云的 SDN 来实现网络的,比如 AWS 上的基于 VPC 路由的容器网络方案,QingCloud 上的 SDN 网络直通(SDN Passthrough)方案,和直接使用宿主机网络效果差距很小或者基本一样。再退一步说,如果网络性能真那么重要,并且一台服务器只运行一个服务,那可以直接用 host 模式么。
  4. 成本 容器的接纳成本已经非常小了,即便是复杂一些的 Kubernetes,相对于 OpenStack 也简单许多,所以才有人通过 Kubernetes 去部署 OpenStack 么。

所以说,容器引入的成本和风险相对于收益来说,绝对是可以接受的,即便是它现在存在着许多问题,但绝对是一个潜力股,值得投入。

总结下,对技术的接纳很多情况下其实是纯粹的观念问题。最初 IaaS 出来的时候,不也有很多人说,数据库服务不适合跑在虚拟机上了,大数据服务不适合跑在虚拟机上了,现在不也有很多用户用的很好。合适不合适,脱离具体的业务场景和需求,是说不清楚的,对于大多数用户和产品来说,数据库的易用性,易维护性,可用性,要大于性能等其他方面的要求的,对另外一部分用户来说,数据库肯定要跑到物理机上,甚至 PC 服务器都不能满足。所以还是不要仅仅从自己的当前的业务需求来断定一个技术通用价值。

【有容云干货-容器系列】补脑专用,容器生态圈脑图大放送

liu, yu阅读(3128)评论(0)

容器技术是操作系统层面的一种虚拟化技术。在Linux系统下,容器能够利用Namespaces、AppArmor、SELinux配置、Chroot以及CGroups等内核功能,交付一套类似于虚拟机的隔离性环境。经过不断的发展,容器技术所带来的轻量级、隔离性、标准化以及可大规模部署的特性促生了微服务和云原生应用的普及和发展。

Docker容器

毫无疑问,Docker是目前最具人气且应用最为广泛的容器技术。为什么呢?作者总结了以下主要的两个原因。

1、和早期容器技术不同,Docker不只是针对了应用对主机资源的共享和隔离,它更加关注应用的微服务化,大规模部署和管理自动化。微服务和云原生应用的发展极大的提高了Docker技术的大众接受程度。

  • Docker所采用的分层镜像模型让Docker对应用环境的封装更加轻量级和标准化,让镜像更加容易的共享和分发,极大的简化了大规模部署和运维的难度。
  • Docker镜像模型的Copyon Write机制和Volume机制合理的满足和促进了应用的无状态化和微服务化。
  • Docker提倡一个应用(进程)一个容器,符合微服务的理念。

2、Docker不只是一个工具包,围绕它的是一整套生态系统。包括镜像库、容器管理调度、网络、存储、安全。这一整套生态系统让应用采用容器技术进行大规模的封装,部署,运维,管理成为可能。

容器的特性如何在生产环境中发挥所长,还需要其生态圈中一系列的工具、产品和方案作以支撑。以下我们会对Docker以及它代表的容器技术生态系统做进一步的介绍。

容器生态圈

下图中的内容就是容器生态圈中的各个组件,我们将会从下至上逐一分层解析。

%e5%ae%b9%e5%99%a8%e7%94%9f%e6%80%81%e5%9c%8820170221%e5%be%ae%e4%bf%a1%e7%89%88

1、容器OS

容器OS并不是运行容器的必要条件,容器也可以运行在通用Linux中。大部分的容器OS即为Linux OS的精简版。相比大而全的Linux OS,容器OS如RancherOS、CoreOS、Redhat Atomic、Ubuntu Core、VMware Photon具有更加轻量,占有资源更少的特征,适合于更加标准化的数据中心和IOT的一些领域。同时,Microsoft也于2015年推出Windows Nano Server,并将其作为Windows2016的安装选项,其大小相比完整的Windows2016部署缩小了90%以上。

2、容器引擎

容器引擎负责容器应用的隔离和资源共享。它驱动和管理主机上所有的容器,并且包括了容器卷管理、容器网络管理、容器配置、镜像管理以及容器日志。容器生态圈中容器引擎主要有两个标准OCI和AppC,两个引擎Docker和RKT。 以下是一张对比表:

2

3、容器存储

容器中一般运行是无状态应用。对于有状态应用,应用的数据持久化就需要容器存储的支持。Docker为了支持第三方存储方案,在1.8版本引入Volume Plugin机制。Flocker作为Volume Plugin,需要和第三方外部存储结合使用为容器提供持久化存储,同时也屏蔽掉第三方存储系统的差异,类似Cinder在OpenStack中的位置。而Torus (项目已于2017年2月停止开发,“Developmenton Torus at CoreOS stopped as of Feb 2017”引用自Github Torus项目说明)和Comet(有容云)作为独立的分布式存储系统,可直接为容器提供完整的数据存储服务。

Comet存储系统作为国内少有的自主研发分布式系统,除了针对容器特性进行性能优化外,也提供了多级数据保护,应用感知等企业级存储特性。

3

4、容器网络

容器网络解决容器在大规模部署后的互联互通的问题。主要有Docker原生的CNM容器网络模型和CoreOS支持的CNI容器网络模型。除了Docker原生的Libnetwork网络方案,在容器网络生态圈中,有以下几种商业容器网络方案。

  • Flannel是CoreOS为Kubernetes设计的基于CNI模型的网络方案。它让各个容器采用UDP Overlay或者Vxlan的方式互联,并且让集群中的不同节点主机创建的容器都具有全集群唯一的虚拟IP地址。
  • Weaver和Flannel在很多方面比较类似。但是Weaver采用Name Service的方式来进行IP分配管理,不需要一个全局的Kv Store。
  • Calico是一个纯三层网络,采用BGP的技术来进行路由交换。由于不像其他几个网络模型一样需要封包,它的性能相对最优。

4

5、镜像仓库

镜像仓库提供了镜像的存储、及pull/push的服务。仓库分为公有仓库(如Docker Hub、Quay)和私有仓库(如AppHouse、Harbor)两种形式。最大的公有仓库是Docker Hub,即Docker官方的镜像仓库。由于网络访问限制的原因,或企业用户对数据安全性考虑的原因,也可以在企业私有数据中心建立私有镜像仓库,可通过部署AppHouse(有容云)或者Harbor来实现。

部署镜像仓库需要考虑的是镜像存储的安全性和系统的容错性。可分别通过搭建企业级存储系统或分布式存储系统来保障镜像数据的完整性,并选择具有高可用特性的镜像仓库进行实施和部署。

6、容器安全

容器缺少一个像虚拟机所拥有的安全边界。容器的快速迁移,升级和部署的特性也带来了新的安全隐患。容器安全可分为镜像安全和容器运行时安全。

  • 镜像安全:使用互联网来历不明的镜像、或是从互联网下载不明镜像作为基础镜像、或是制作镜像时对端口和服务开启没有严格的限制和把控、DockerFile中恶意程序等,都将会导致生成高危漏洞的镜像。对于镜像的安全建议在两阶段进行控制,一是镜像提交到镜像仓库时;一是进行周期的镜像扫描;同时,对于已发布或发现的漏洞风险,进行及时更新。
  • 容器运行时风险:容器运行时风险来自于多方面,对外提供服务的容器会收到DDOS攻击,从而导致主机上的所有容器出现资源不足;容器使用不当会导致主机Root权限泄漏;使用者权限过高会通过容器对主机文件修改导致系统崩溃;数据卷共享导致主机上容器对数据篡改等。目前已有用户开始关注容器安全的问题,同时也有不少厂商也推出了针对容器运行时安全的商业化方案。

Clair是CoreOS开源的容器镜像安全分析器,具有镜像安全扫描和提供修复建议的功能,目前也已有多个厂家将其集成在自身的容器平台中。

TwistLock在镜像扫描和容器运行时都有防护方案。Aqua的CSP在2017年2月也发布了2.0版本,官方表示将和Kubernetes会有更好的结合。

AppSafe是国内容器厂家有容云推出的容器安全产品,针对容器进行智能安全策略配置,并可根据配置策略进行实时防护。

7、容器编排

容器平台是容器应用大规模部署,升级和运维的管理平台。容器的编排和资源调度是容器平台的核心功能。容器平台也提供服务发现、运行监控、扩容缩容、负载均衡、灰度升级、故障冗余等功能。

  • Swarm是Docker的原生集群工具,Swarm使用标准的Docker API来管理容器集群。
  • Kubernetes 是一个以Google Borg 为原型的开源项目。可实现大规模、分布式、高可用的容器集群。目前国内大部分容器厂家产品都是基于Kubernetes进行二次开发和方案封装,这里暂不赘述。
  • Mesos是Apache下的开源分布式资源管理框架。基于Mesos之上可以运行不同的分布式计算平台,如Spark、Storm、Hadoop、Marathon。Mesos+Marathon可以用来管理大规模的容器集群。

8、运维

容器平台运行和管理着成千上万的容器及应用。如何能从资源(主机、容器)纬度和应用的纬度来及时监控和日志收集,也成为容器进入生产环境绕不开的话题。目前容器的监控和日志方案分为开源方案和SaaS服务两种:

  • CAdvisor 是针对单主机的免费且开源的容器监控工具,可用于监控容器当前的资源使用率及性能情况。CAdvisor简单易用,但容器平台中需要和其他开源工具或产品结合使用,且自身无报警功能。CAdvisor已集成在Kubernetes中。
  • Data Dog提供基于容器监控的SaaS服务,在被监控主机上运行Agent即可接受Data Dog的监控,视图简单、使用方便,其Monitors提供可自定义阈值的告警服务,但成本较高。
  • Prometheus是一款开源的监控工具,也是在容器平台中使用较多的一种监控方案,相对于Heapster,Prometheus提供的查询API功能更加强大,可以基于Label来实现复杂查询,适合有一定技术能力的团队使用。
  • Zabbix是一个较成熟的开源分布式监控系统。在非容器场景中已被大量使用,Zabbix由服务器端的Server和被监控端的Agent组成,通过丰富的模板可自定义需要收集的数据和展示形式。基于容器的Zabbix监控方案需要考虑到Agent的部署方式及容器的视图展示方式。
  • Heapster是一个开源的容器集群监控和性能分析工具,原生支持Kubernetes和CoreOS。一般通过Heapster+InfluxDB+Grafana来实现基于Kubernetes的监控方案,来完成数据收集、存储及展示的功能。
  • ELK日志分析系统由三个开源工具Elasticsearch+Logstash+Kibana组成,分别对应搜索、数据采集和展示的功能,是一套较成熟的日志方案,有公司基于此方案提供日志SaaS服务。基于容器的日志监控通常为EFK(Elasticsearch+Fluentd+Kibana),通过占用内存较少的Fluentd替代Logstash,来满足容器平台更大规模更密集的日志收集需求。

在以后的文章里我们会对容器调度和编排做重点的介绍,容器生态还有哪些组件和专注于某一领域的厂家、技术或产品,欢迎小伙伴们回复和讨论。

附: 容器历史发展:http://www.youruncloud.com/blog/114.html

900x525_2%e5%89%af%e6%9c%ac

线上微信群分享

本次分享主要是介绍我公司如何使用jenkins pipeline, container 和 kubernetes deployment的能力, 通过增加使用文本模版引擎, 扩展kubernetes config能力, 完成公司产品开发ci工作流的建立。

线上微信群分享参与方式:

扫描下方二维码,发送名片

城市+姓名+公司

联系群助手加群

555841263537057630

IBM 居然把私有的 Docker Swarm 密钥泄露给了公共容器

刀客info阅读(3236)评论(0)

巨人也会犯大错误:IBM不小心将数据科学服务器的root访问权授予了用户!

IBM居然将私有密钥泄露给了随手可得的容器里面的数据科学体验(Data Science Experience)服务中的Docker主机环境。

这有可能将访问托管容器的底层机器的root访问权授予云服务的用户,进而可能访问蓝色巨人的Spark计算集群中的其他机器。实际上,蓝色巨人将可能指挥和控制其服务的众多计算机需要的钥匙公然交给了云服务。

IBM在今年1月31日搞了一次以数据科学技术为主题的活动,技术顾问Wayne Chang密切关注此活动后,发现了权限升级这个缺陷,并在第二天就报告给了蓝色巨人。

两星期后的2月15日――这段时间在安全漏洞披露领域可以说非常短,IBM纠正了错误。

Chang在周二发表的一篇博文(https://wycd.net/posts/2017-02-21-ibm-whole-cluster-privilege-escalation-disclosure.html)中表示,他在注册免费演示版试用服务后发现了这个缺陷。

Chang写道:“这是一个配置不当的安全漏洞,后果非常严重。简而言之,IBM任由所有的Docker TLS密钥留在容器里面,这道理就跟任由牢房的钥匙留在牢房里面一样。”

Docker TLS密钥用于为Docker Swarm主机API确保安全。

Chang表示,通过IBM提供的RStudio Web Environment,钻这个安全漏洞的空子只需要下载和提取Docker……

system(“wget https://test.docker.com/builds/Linux/x86_64/docker-1.13.1-rc1.tgz”)

system(“tar -xvzf docker*.tgz”)

然后,使用Docker二进制代码以及其证书,即可使用卷挂载,获得相当于主机root访问权的权限:

system(“DOCKER_API_VERSION=1.22 ./docker/docker -H 172.17.0.1 \

–tlscacert /certs/ca.pem –tlscert /certs/cert.pem \

–tlskey /certs/key.pem \

run -v /:/host debian cat /host/etc/shadow”)

如果有人钻了该缺陷的空子,IBM的客户数据就可能岌岌可危。

Chang已建议,IBM应该对其安全架构进行诸多改进。他还建议,IBM应该为所有受影响的机器重新创建镜像,以防有人早先发现了这个缺陷,并安装了rootkit或其他恶意软件。

IBM没有立即回应置评请求。

Chang在一封写给英国IT网站The Register的电子邮件中表示,他认为可以安全、可靠地实施Docker和容器,这些技术有望增强安全性。但是他责备IBM没有发现这个缺陷。

Chang说:“我认为,IBM已经拥有一些出色的信息安全人员,而且真正致力于保护其服务;说到底,这个问题关乎向整个企业组织灌输安全文化和流程。话虽如此,凡是自身产品允许用户运行不可信代码的公司都应该认真仔细地考虑系统架构。”

Chang表示,由于许多公司竞相开发新技术,安全常常是事后才想到的环节。

Chang说:“这倒不是暗示容器设计得很差劲(我不这么认为),主要是容器是新技术,所以其使用方面的最佳实践仍在积极完善中。”

“不妨比较一下更新款式的桌锯和几十年前的桌锯:由于文化和标准不断完善,加上认识加深,新桌锯配备了大量的安全装置,包括紧急停止装置、劈刀和推杆等。”

巧合的是,最近推出的Docker Datacenter包括了密钥连同容器如何加以管理方面的一些改进。

时隔半年,Docker 再发重大版本 1.13!

刀客info阅读(8763)评论(0)

作者王涛,就职于悉尼一家数据分析公司。喜欢开源,对 Docker 有较深入的研究和实践。2017 年 1 月 18 日 Docker 1.13 新版本发布,他于第一时间发布了新版本的功能解读。道客船长授权转载,本文列出 1.13 版本的 top 10 新增功能,详情请点击 https://github.com/docker/docker/releases/tag/v1.13.0http://blog.lab99.org/post/docker-2016-11-14-what-is-new-in-docker-1-13.html#top-10-xin-zeng-gong-neng 了解 Docker 1.13 新增功能。

Docker 1.13 在 2017 年 1 月 18 日发布了。从 2016 年 7 月 29 日发布 1.12 以来,已经过去 5 个多月了,对于活跃的 Docker 社区来说,已经很久了,让我们看看都 1.13 都新增了什么内容吧。

1.13 有一千四百多个 issue/pull request,五千多个 commits,是 Docker 历史上最高的发布版本。这并不是一个简单的小版本变化,里面有大量的更新。

Top 10 新增功能 | New Features

  1. 正式支持服务栈: docker stack
  2. 正式支持插件:docker plugin
  3. 添加在 Swarm 集群环境下对密码、密钥管理的 secret 管理服务:docker secret
  4. 增加 docker system 命令
  5. 可以直接使用 docker-compose.yml 进行服务部署
  6. 添加 docker service 滚动升级出故障后回滚的功能
  7. 增加强制再发布选项 docker service update –force
  8. 允许 docker service create 映射宿主端口,而不是边界负载均衡网络端口
  9. 允许 docker run 连入指定的 swarm mode 的 overlay 网络
  10. 解决中国 GFW 墙掉 docker-engine apt/yum源的问题

新增功能解读

Docker 镜像构建

  • 从已有镜像取得缓存
  • 压扁 (squash) 镜像(实验阶段)
  • 构建镜像时支持用 –network 指定网络
  • 开始允许 docker build 中定义 Dockerfile 未使用的参数(ARG)

安装

  • 解决 GFW 影响 Docker 安装问题
  • 增加更多的系统支持

网络

  • 允许 docker run 连入指定的 swarm mode 的网络
  • 允许 docker service create 映射宿主端口,而不是边界负载均衡网络端口
  • iptables 的转发规则将默认拒绝
  • 在 docker network inspect 里显示连入的节点
  • 允许 service VIP 可以被 ping

插件

  • 插件功能正式启用

命令行

  • checkpoint 功能(试验功能)
    – 准备工作
    – 创建 Checkpoint 及恢复
  • docker stats 终于可以显示容器名了
  • 给 docker ps 增加 is-task 过滤器
  • docker inspect 将可以查看任何 docker 对象

运行时

  • 不在分别构建试验可执行文件,直接使用 –experimental 参数
  • 在 overlay2 存储驱动使用于 xfs 时可以添加磁盘配额
  • 增加 docker system 命令
  • 提升 overlay2 的优先级
  • docker exec -t 自动添加 TERM 环境变量
  • Windows 内置的运行 Windows 程序的 Docker on Windows 的改进

Swarm Mode

  • 正式支持 docker stack
  • 添加 secret 管理
  • 添加负载均衡和DNS记录对新增的健康检查的支持
  • 添加滚动升级回滚的功能
  • 补充了一些 docker service create 所缺失的参数
  • 添加命令 docker service logs 以查看服务日志(试验功能)
  • 增加强制再发布选项 docker service update –force

➤ 欢迎关注王涛的个人博客:http://blog.lab99.org/,阅读更多 Docker 干货及最新动态。

Docker迈入稳定成长期,大型云端企业比新创更爱用

刀客info阅读(4239)评论(0)

Container战场已从厂商技术拉锯战,走入企业,大型云端企业采用率更破2成,若加上小规模试用者更是过半数,大型云端企业比新创小公司更爱用Docker

 

20170111143704

根据基础架构监控服务业者Datadog的Docker导入率普查结果显示,在2015年5月到2016年5月这一年间,使用私有云或公有云技术的企业,Docker导入率成长幅度超过30%。

 

容器风潮火热,大型公有云厂商Google、AWS及Azure都纷纷推出容器服务,在私有环境中,VMware也得支持Docker满足企业需求。不过令人好奇的是,容器究竟有多热?提供基础架构监控服务的Datadog,以1万家导入公有云、私有云技术的企业用户为母体,根据其搜集在线运行的一手资料,展开一场全球最大规模的Docker导入率普查。

 

20170111143726

 

在2015年5月时,研究显示仅有8.2%的云端企业开始导入Docker,仅经过1年,2016年同期,Docker使用率已经突破一成,上升至10.7%。

针对这一成使用Docker的企业,Datadog也更深入地进行分析,发现Docker采用率与基础架构规模大小,两者呈现正相关。基础架构规模超过500台服务器的公司,Docker的导入率则超过20%,加上正尝试使用的企业,其比例就超过一半,剩下只有不到4成的大型云端企业从未使用过Docker。

反之,基础架构规模小于100台服务器的中小企业,Docker导入率则低于20%,超过80%从未使用过Docker。

Datadog所进行的研究显示,容器技术虽不如Docker宣称的火爆,但的确能看见企业导入率逐渐上升的趋势。同时,Docker的使用率,随着基础架构规模成长,也能瞥见企业对于这门技术抱持一定信心。不过,如此状况,也可能出于大型企业拥有更多研发资源,因此较敢放手尝试新技术。

掀起这波狂潮的Docker技术长Solomon Hykes,在去年度DockerCon中也大喊:「现在没人关心Container了,因为应用程序才要紧」,更点出Container的重点战场,已经从各容器厂商间的技术拉锯战,开始走入各家企业的数据中心,在正式环境中,扮演运行应用程序的角色,而Docker化应用程序也已经超过了46万个。

因此,容器调度工具也是今年度的重要战场。除了KubernetesDocker Swarm以及Mesos外,去年底连AWS也推出了自家的调度工具Blox。而Google看上有8成企业在Linux环境中运行Java应用程序,或是Windows环境执行.NET应用程序,更在Kubernetes 1.5版大举支持Windows Server Container以及Hyper-V Container,使它成为目前唯一通吃Linux、Windows容器调度的利器。挟如此优势,Kubernetes应会稳坐2017年容器调度工具的龙头。

20170111143745 20170111143754 20170111143803

容器就像监狱,让我们来构造一个监狱吧!

刀客info阅读(4429)评论(1)

前言

容器,近年来最火的话题,在后端的开发中,容器的运用已经是主流技术了。今天,我们就来说说容器技术。首先,虽然目前Docker技术如此火爆,但其实容器技术本质上并不是什么高大上的东西,总的来讲,就是对目前的Linux底层的几个API的封装,然后围绕着这几个API开发出了一套周边的环境。

目前来说,普遍讨论关于容器的文章,一开始都会讲到UTC隔离、PID隔离、IPC隔离、文件系统隔离、CGroups系统,今天这一篇,我们换一个视角,从以下几个方面来聊一下容器技术。

  • 第一部分,从容器和虚拟机说起,都说容器是非常轻量级的,那么和虚拟机比起来,到底轻在哪里?
  • 第二部分,通过构造一个监狱,来说明如何建立一个简单的容器,会涉及到容器的各种技术,当然还有一些没有涉及到的,我认为不影响理解。
  • 第三部分,通过代码实战一把,看看如何一步一步按照第二部分的说明启动一个容器并运行自己的代码,这一部分的全部代码都在github上。
  • 最后,我会再说一下Docker技术,因为Docker从代码来看,容器技术只是他的一小部分,完整的Docker远比单纯的容器要复杂,我会简单的说一下我对Docker的理解,包括Docker使用的其他技术点。

容器和虚拟机

要说容器,跑不了和虚拟机进行比较,虚拟机是比较古老的技术了,虚拟机的架构图如下所示。

虚拟机核心是什么?是模拟硬件,让虚拟机的操作系统以为自己跑在一个真实的物理机器上,用软件模拟出来CPU、内存、硬盘、网卡,让虚拟机里面的操作系统觉得自己是在操作真实的硬件,所以虚拟机里面的CPU啊,内存啊都是假的,都是软件模拟出来的(现在有硬件虚拟化技术了,比纯软件模拟要高级一些,但操作系统不管这些),既然操作系统都骗过去了,当然跑在操作系统上的进程同样也骗过去了呗,所以这些进程都完全感知不到底层硬件的区别,还以为自己很欢乐的跑在一台真实的物理机上了。

那么容器又是什么鬼?容器的架构图如下(图片来源于网络):

和虚拟机一个很明显的区别就是容器其实并没有模拟硬件,还是那个硬件,还是那个操作系统,只不过是在操作系统上做了一点文章【这张图中就是Docker Engine了】,让进程以为自己运行在了一个全新的操作系统上,有一个很形象的词来描述他就是软禁!就是把进程软禁在一个环境中,让进程觉得自己很happy,其实一切尽在操作系统的掌控之中,其实虚拟机也是,虚拟机是把操作系统软禁起来了,让操作系统觉得很happy,容器是把进程软禁起来,你看,一个是软禁操作系统,一个是软禁进程,这两个明显不是一个级别的东西,谁轻谁重不用说了吧。

既然容器和虚拟机的区别在于一个是通过模拟硬件来软禁操作系统,一个是通过做做操作系统的手脚来软禁进程,那么他们能达到的效果也是不一样的。

  • 对于虚拟机来说,既然是模拟的硬件,那么就可以在windows上装linux虚拟机了,因为反正是模拟硬件嘛,虚拟机内部的操作系统也不知道外面的宿主机是什么系统。
  • 容器就不一样了,因为是在操作系统上做文章,所以不可能在linux上装windows了,并且还有一点就是,容器内的操作系统其实就是外面宿主机的操作系统,两者其实是一个,你在容器内用uname -a看到的内核版本和外面看到的是一样的。本质上容器就是一个进程,他和宿主机上任何其他进程没什么本质的区别。

建造容器监狱

如何来做一个容器呢?或者说容器是怎么实现的呢?我们从几个方面来说一下容器的实现,一是最小系统,二是网络系统,三是进程隔离技术,四是资源分配。最小系统告诉你软禁进程所需要的那个舒适的监狱环境,网络系统告诉你软禁的进程如何和外界交互,进程隔离技术告诉你如果把进程关到这个舒适的监狱中去,资源分配告诉你监狱里的进程如何给他分配资源让他不能胡来。

建设基本监狱【最小系统打造】

要软禁一个进程,当然需要有个监狱了,在说监狱之前,我们先看看操作系统的结构,一个完整的操作系统【Linux/Unix操作系统】分成三部分,如下图所示【本图也是网上找的,侵权马上删,这个图是四个部分,包括一个boot参数部分,这不是重点】。

 

20170106102720

 

首先是bootloader,这部分启动部分是汇编代码,CPU从一个固定位置读取第一行汇编代码开始运行,bootloader先会初始化CPU,内存,网卡(如果需要),然后这部分的主要作用是把操作系统的kernel代码从硬盘加载到内存中,然后bootloader使命完成了,跳转到kernel的main函数入口开始执行kernel代码,kernel就是我们熟悉的Linux的内核代码了,大家说的看内核代码就是看的这个部分了,kernel代码启动以后,会重新初始化CPU,内存,网卡等设备,然后开始运行内核代码,最后,启动上帝进程(init),开始正常运行kernel,然后kernel会挂载文件系统。

好了,到这里,对进程来说都是无意义的,因为进程不关心这些,进程产生的时候这些工作已经做完了,进程能看到的就是这个文件系统了,对进程来说,内存空间,CPU核心数,网络资源,文件系统是他唯一能看得见使用得到的东西,所以我们的监狱环境就是这么几项核心的东西了。

kernel和文件系统是可以分离的,比如我们熟悉的ubuntu操作系统,可能用的是3.18的Linux Kernel,再加上一个自己的文件系统,也可以用2.6的Kernel加上同样的操作系统。每个Linux的发行版都是这样的,底层的Kernel可能都是同一个,不同的只是文件系统不同,所以,可以简单的认为,Linux的各种发行版就是kernel内核加上一个独特的文件系统,这个文件系统上有各种各样的工具软件。

既然是这样,那么我们要软禁一个进程,最基础的当然要给他一个文件系统啦,文件系统简单的说就是一堆文件夹加上一堆文件组成的,我们先来生成一个文件系统,我之前是做嵌入式的,嵌入式的Linux系统生成文件系统一般用busybox,只需要在在ubuntu上执行下面的命令,就能生成一个文件系统:

apt-get install busybox-static
mkdir rootfs;cd rootfs
mkdir dev etc lib usr var proc tmp home root mnt sys
/bin/busybox –install -s bin

大概这么几步就制作完成了一个文件系统,也就是监狱的基本环境已经有了,记得把lib文件夹的内容拷过去。制作完了以后,文件系统就这样了。

 

20170106102737

 

还有一种方式,就是使用debootstap这个工具来做,也是几行命令就做完了一个debian的文件系统了,里面连apt-get都有,Docker的基础文件系统也是这个。

apt-get install qemu-user-static debootstrap binfmt-support
mkdir rootfs
debootstrap –foreign wheezy rootfs //wheezy是debian的版本
cp /usr/bin/qemu-arm-static rootfs/usr/bin/

完成以后,这个wheezy的文件系统就是一个标准的debian的文件系统了,里面的基本工具一应俱全。OK,基本的监狱环境已经搭建好了,进程住进去以后就跟在外面一样,啥都能干,但就是跑不出来。

要测试这个环境,可以使用Linux的chroot命令,chroot ./rootfs就进入了这个制作好的文件系统了,你可以试试,看不到外面的东西了哦。

打造探视系统【网络系统】

刚刚只建立了一个基本的监狱环境,对于现代的监狱,只有个房子不能上网怎么行?所以对于监狱环境,还需要建立一个网络环境,好让里面的进程们可以很方便的和监狱外的亲友们联系啊,不然谁愿意一个人呆在里面啊。

如何来建立一个网络呢?对于容器而言,很多地方是可配置的,这里说可配置,其实意思就是可配置也可以不配置,对于网络就是这样,一般的容器技术,对网络的支持有以下几个方式。

  • 无网络模式,就是不配置模式了,不给他网络,只有文件系统,适合单机版的程序。
  • 直接和宿主机使用同一套网络,也是不配置模式,但是这个不配置是不进行网络隔离,直接使用宿主机的网卡、ip、协议栈,这是最奔放的模式,各个容器如果启动的是同一套程序,那么需要配置不同的端口了,比如有3个容器,都是Redis程序,那么需要启动三个各不同的端口来提供服务,这样各个容器没有做到完全的隔离,但是这也有个好处,就是网络的吞吐量比较高,不用进行转发之类的操作。
  • 网桥模式,也是Docker默认使用的模式,我们安装完Docker以后会多一个Docker0的网卡,其实这是一个网桥,一个网桥有两个端口,两个端口是两个不同的网络,可以对接两块网卡,从A网卡进去的数据会从B网卡出来,就像黑洞和白洞一样,我们建立好网桥以后,在容器内建一块虚拟网卡,把他和网桥对接,在容器外的宿主机上也建立一块虚拟网卡,和网桥对接,这样容器里面的进程就可以通过网桥这个探视系统和监狱外联系了。

我们可以直接使用第二种不配置模式,直接使用宿主机的网络,这也是最容易最方便的,但是我们在这里说的时候稍微说一下第三种的网桥模式吧。

网桥最开始的作用主要是用来连接两个不同的局域网的,更具体的应用,一般是用来连接两个不同的mac层的局域网的,比如有线电视网和以太网,一般网桥只做数据的过滤和转发,也可以适当的做一些限流的工作,没有路由器那么复杂,实现起来也比较简单,对高层协议透明,他能操作的都是mac报文,也就是在ip层以下的报文。

对于容器而言,使用网桥的方式是在宿主机上使用brctl命令建立一个网桥,作为容器和外界交互的渠道,也就是大家使用Docker的时候,用ifconfig命令看到的Docker0网卡,这实际上就是一个网桥,然后每启动一个容器,就用brctl命令建立一对虚拟网卡,一块给容器,一块连到网桥上。这样操作下来,容器中发给虚拟网卡的数据都会发给网桥,而网桥是宿主机上的,是能连接外网的,所以这样来做到了容器内的进程能访问外网。

容器的网络我没有深入研究,感觉不是特别复杂,最复杂的方式就是网桥的方式了,这些网络配置都可以通过命令行来进行,但是Docker的源码中是自己通过系统调用实现的,说实话我没怎么看明白,功力还是不够啊。我使用的就是最最简单的不隔离,和宿主机共用网卡,只能通过端口来区分不同容器中的服务。

监禁皮卡丘【隔离进程】

好了,监狱已经建好了,探视系统也有了,得抓人了来软禁了,把进程抓进来吧。我们以一个最最基本的进程/bin/bash为例,把这个进程抓进监狱吧。

说到抓进程,这时候就需要来聊聊容器的底层技术了,Linux提供几项基础技术来进行轻量级的系统隔离,这些个隔离技术组成了我们熟悉的Docker的基础。本篇不会大段的描述这些技术,文章后面我会给出一些参考链接,因为这类文章到处都可以找到,本篇只是让大家对容器本身有个了解。

下面所说的所有基础技术,其实就是一条系统调用,包括Docker的基础技术,也是这么一条系统调用(当然,Docker还有很多其他的,但是就容器来说,这条是核心的了)

clone(进程函数, 进程栈空间, CLONE_NEWUTS | CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWNET |CLONE_NEWUSER | CLONE_NEWIPC , NULL

这是一条C语言的clone系统调用,实际上就是启动一个新的进程,后面的参数就是各种隔离了,包括UTS隔离、PID隔离、文件系统隔离、网络隔离、用户隔离、IPC通讯隔离。

在go语言中,没有clone这个系统调用(不知道为什么不做这个系统调用,可能是为了多平台的兼容吧),必须使用exec.Cmd这个对象来启动进程,在linux环境下,可以设置Cmd的attr属性,其中有个属性叫CloneFlags,可以把上面那些个隔离信息设置进去,这样,启动的进程就是我们需要的了,我们可以这么来启动这个进程。

cmd := exec.Command(“./container”, args…)
cmd.SysProcAttr = &syscall.SysProcAttr{
Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWPID | syscall.CLONE_NEWNS | syscall.CLONE_NEWNET,
}
cmd.Run()

这样,通过这个cmd命令启动的./container进程就是一个隔离进程了,也就是我们把这个进程给关起来了,他已经看不到其他东西了,是不是很简单?但是你要是就直接这么运行,还是看不到什么特别的地方。

在这个之后,我们需要按照上面所说的,把监狱先建立好,监狱的建立在./container中进行,建立监狱也比较简单,基本上也是一堆系统调用,比如文件系统的软禁,就像下面的一样。

syscall.Mount(rootfs, tmpMountPoint, “”, syscall.MS_BIND, “”) //挂载根文件系统
syscall.Mount(rootfs+”/proc”, tmpMountPoint+”/proc”, “proc”, 0, “”); //挂载proc文件夹
syscall.PivotRoot(tmpMountPoint, pivotDir) //把进程软禁到根文件系统中

关于上面proc文件夹,做了特殊处理,在Linux中,proc文件夹的地位比较特殊,具体作用可以自行查文档,简单的说就是保存系统信息的文件夹。在这里,dev和sys这两个特殊文件夹也需要做特殊处理的,这里没有写出来而已。

这些都做完了以后,就可以启动真正需要执行的进程了,比如/bin/bash,或者你自己的程序,这样启动的/bin/bash或者你自己的程序就是在监狱中启动的了,那么他看到的所有东西都是监狱中的了,外面宿主机的一切对他来说都是屏蔽的了,这样,一个Docker的雏形就产生了。

这里多说一下,通过clone系统调用启动的进程,它自己看到自己的PID是1,也就是上帝进程了,这个上帝进程可以来造基础监狱【文件系统】,打造放风系统【网络系统】,然后再通过它来生成新的进程,这些进程出来就在监狱中了,我们使用Docker的时候,自己的服务实际上就是这些个在监狱中出生的进程【可能我的描述不太正确啊,我没有仔细看Docker的源码,我自己感觉是这样的】。

至此,我们来总结一下,启动一个最简单的容器并运行你自己的进程,需要几步。

  • 建立一个监狱【文件系统】,使用busybox或者debootstrap建立。
  • 建立一个放风系统【网络系统】,使用网桥或者不隔离网络,直接使用宿主机的网卡。
  • 抓一个皮卡丘【启动上帝进程】并放到监狱中【挂载文件系统,初始化网络】,配置Cloneflags的值,并通过exec.Cmd来进行上帝进程的启动。
  • 让皮卡丘生个孩子【启动你自己的程序】,直接调用exec.Cmd的run方法启动你自己的进程。
  • 完成。

通过上面几步,最简容器就完成了,是不是很简单?但是容器仅仅有这些是不够的,我们还有三个隔离没有讲,这里稍微提一下吧。

  • 一个是UTS隔离,主要是用来隔离hostname和域名的。
  • 一个是User隔离,这样容器里面的用户和宿主机用户可以做映射,意思就是里面虽然看到的是root用户,但是实际上并不是root,不能够瞎搞系统,这样容器的安全性会有保障。
  • 一个是IPC隔离,这个是进程通讯的隔离,这样容器里面的进程和容器外面的进程就不能进行进程间通讯了,保证了比较强的隔离性。

给犯人分配食物【资源配置】

我们知道,一般的监狱中的食物是定量的,毕竟不是每个监狱都可以吃自助餐的,容器也一样,要是我们就启个容器啥都不限制,里面要是有个牛逼的程序员写的牛逼程序,瞬间就把你的内存和CPU给干没了。比如像下面这个fork炸弹。【下面程序请不要尝试!!】

int main(){
while(fork());
}

在容器技术中,Cgroups【control groups】就是干这个事情的,cgroups负责给监狱设定资源,比如能用几个cpu啊,cpu能给你多少百分比的使用量啊,内存能用多少啊,磁盘能用多少啊,磁盘的速度能给你多少啊,各种资源都可以从cgroups来进行配置,把这些东西配置给容器以后,就算容器里面运行一个fork炸弹也不怕了,反正影响不到外面的宿主机,到这里,容器已经越来越像虚拟机了。

cgroups是linux内核提供的API,虽然是API,但它的整个实现完美满足了Linux两大设计哲学之一:一切皆文件(还有一个哲学是通讯全管道),对API的调用实际上是操作文件。

我们以cpu的核心数看看如何来做一个cgroups的资源管理。假设我们的物理机是个8核的cpu,而我们刚刚启动的容器我只想让他使用其中的两个核,很简单,我们用命令行直接操作sys/fs/cgroups文件夹下的文件来进行。这个配置我们可以在启动的上帝进程中进行,也可以在容器外部进行,都是直接操作文件。

关于cgroups这个东西很复杂也很强大,其实在容器出来之前,好的运维工程师就已经把这个玩得很溜了。Docker也只是把这些个文件操作封装了一下,变成了docker的启动和配置参数而已。

亲自抓一次进程吧

好了,该说的都说了,我们来实战一把,自己启一个容器吧,并且启动以后为了更直观的看到效果,我们启动一个ssh服务,打开22332端口,然后外面就可以通过ssh连到容器内部了,这时候你爱干什么干什么了。

制作文件系统

文件系统制作我们直接使用debootstrap进行制作,在/root/目录下建立一个rootfs的文件夹,然后使用debootstrap –foreign wheezy rootfs制作文件系统,制作完了以后,文件系统就是下面这个样子

 

20170106102749

 

制作初始化脚本

初始化脚本就做两件事情,一是启动ssh服务,一是启动一个shell,提前先把/etc/ssh/sshd_config中的端口改成23322。

#!/bin/bash
service ssh start
/bin/bash

然后把这个脚本放到制作的文件系统的root目录下,加上执行权限。

启动上帝进程

文件系统制作完成了,启动脚本也做完了,我们看看我们这个容器的架构,架构很简单,整个容器分为两个独立的进程,两份独立的代码。

  • 一个是主进程【wocker.go】,这个进程本身就是一个http的服务,通过get方法接收参数,参数有rootfs的地址,容器的hostname,需要监禁的进程名称(这里就是我们的第二个进程【startContainer.go】),然后通过exec.Cmd这个包启动这个进程。
  • 第二个进程启动就是以隔离方式启动的了,就是容器的上帝进程了,这个进程中进行文件系统挂载,hostname设置,权限系统的设定,然后启动正式的服务进程(也就是我们的启动脚本/root/start_container.sh)

挂载文件系统

第二个进程是容器的上帝进程,在这里进行文件系统的挂载,最重要的代码如下

syscall.Mount(rootfs, tmpMountPoint, “”, syscall.MS_BIND, “”) //挂载根文件系统
syscall.Mount(procpath, tmpMountPointProc, “proc”, 0, “”) //挂载proc文件夹,用来看系统信息的
syscall.Mount(syspath, tmpMountPointSys, “sysfs”, 0, “”) //挂载sys文件夹,用来做权限控制的
syscall.Mount(“udev”, tmpMountPointDev, “devtmpfs”, 0, “”) //挂载dev,用来使用设备的
syscall.PivotRoot(tmpMountPoint, pivotDir)//进入到文件系统中

具体代码可以看github上的文件,这样,根文件系统就挂载完了,已经进入了基本监狱中了。

启动初始化脚本

文件系统挂载完了以后,然后启动初始化脚本,这个就比较简单了,一个exec.Cmd的Run方法调用就搞定了。

cmd := exec.Command(“/root/start_container.sh”)

这样,ssh服务就在容器中启动了,可以看到一行Starting OpenBSD Secure Shell server: sshd.的打印信息,容器启动完成,这时候,我们可以通过ssh root@127.0.0.1 -p 23322这个命令登录进我们的容器了,然后你就可以为所欲为了。

 

20170106102759

 

上面那个图,我们看到登录进来以后,hostname已经显示为我们设定的hello了,这时这个会话已经在容器里面了,我们ps一下看看进程们。

 

20170106102806

 

看到pid为1的进程了么,那个就是启动这个容器的上帝进程了。恩,到这里,我们已经在容器中了,这里启动的任何东西都和我们知道的Docker中的进程没什么太大区别了。但在这里,我缺失了权限的部分,大家可以自己加上去,主要是各种文件操作比较麻烦……

关于Docker的思考

Docker这门最近两年非常火的技术,光从容器的角度来看的话,也不算什么新的牛逼技术了,和虚拟机比起来还是要简单不少,当然,Docker本身可完全不止容器技术本身,还有AUFS文件分层技术,还有etcd集群技术,最关键的是Docker通过自己的整个生态把容器包裹在里面了,提供了一整套的容器管理套件,这样让容器的使用变得异常简单,所以Docker才能这么流行吧。和虚拟机比起来,Docker的优点实在是太多了。

  • 首先,从易用性的角度来说,管理一个虚拟机的集群,有一整套软件系统,比如openstack这种,光熟悉这个openstack就够喝一壶的了,而且openstack的网络管理异常复杂,哦,不对,是变态级的复杂,要把网络调通不是那么容易的事情。
  • 第二,从性能上来看看,我们刚刚说了容器的原理,所以实际上容器不管是对cpu的利用,还是内存的操作或者外部设备的操作,对一切硬件的操作实际上都是直接操作的,并没有经过一个中间层进行过度,但是虚拟机就不一样了,虚拟机是先操作假的硬件,然后假硬件再操作真硬件,利用率从理论上就会比容器的要差,虽然现在有硬件虚拟化的技术了能提升一部分性能,但从理论上来说性能还是没有容器好,这部分我没有实际测试过啊,只是从理论上这么觉得的,如果有不对的欢迎拍砖啊。
  • 第三,从部署的易用性上和启动时间上,容器就完全可以秒了虚拟机了,这个不用多说吧,一个是启动一台假电脑,一个是启动一个进程。

那么,Docker和虚拟机比起来,缺点在哪里呢?我自己想了半天,除了资源隔离性没有虚拟机好以外,我实在是想不出还有什么缺点,因为cgroups的隔离技术只能设定一个上限,比如在一台4核4G的机器上,你可能启动两个Docker,给他们的资源都是4核4G,如果有个Docker跑偏了,一个人就干掉了4G内存,那么另外一个Docker可能申请不到资源了。

而虚拟机就不存在这个问题,但是这也是个双刃剑,Docker的这种做法可以更多的榨干系统资源,而虚拟机的做法很可能在浪费系统资源。除了这个,我实在是想不出还有其他缺点。网上也有说权限管理没有虚拟机好,但我觉得权限这东西,还是得靠人,靠软件永远靠不住。

最后,代码都在github上,只有非常非常简单的三个文件【一个Container.go是容器类,一个wocker.go没内容,一个startContainer.go启动容器】,那个http服务留着没写,后面写http服务的时候在用一下。嗯,Docker确实是个好东西。

参考链接:
rootfs:https://olimex.wordpress.com/2014/07/21/how-to-create-bare-minimum-debian-wheezy-rootfs-from-scratch/
Cgroups:http://tech.meituan.com/cgroups.html
namespace:http://man7.org/linux/man-pages/man7/namespaces.7.html

作者:西加加语言 订阅号(ID:XJJ267)吴坚

2017容器发展趋势预测:更快速的采纳和创新

刀客info阅读(3044)评论(0)

容器编排框架的快速采用

随着越来越多的公司开始在生产环境中使用容器,编排框架(Kubernetes、Mesoscale、Cattle和Docker Swarm)的采用量将会大大增加。这些项目在稳定性、社区和合作伙伴生态系统方面发展迅速,对于未来企业更广泛地将容器应用于生产环境,这些项目将成为必要的、有利的技术。

容器基础架构服务的更大创新

尽管目前市场上已有一套强大的容器存储和网络解决方案,但在明年将出现更多的相关产品,来支持生产环境中的容器的工作负载的增长和规模,特别是随着Kubernetes使用的CNI的规格的继续成熟。 StorageOS、Portworx和Quobyte等公司的产品将会被更多地采用。

基础架构集群将以代码形式大量涌现

为了强化“一次编写,随处运行”的能力,编排集群将越来越多地从蓝图变得模板化和实例化,就像将容器化应用程序以Docker Compose文件的形式被部署一样。用户将自行定义他们需要的Kubernetes、Swarm或Mesos部署配置,以及他们需要的任何基础架构服务,然后将其部署到任何他们选择的云或虚拟化基础架构上。用户已经要求这个功能一年多了,最新版本的Rancher采取措施实现这一愿景,使用户能够以模块化、可定制的模板的形式,搭建完整的、container-ready的环境。

Docker将加速ARM服务器的采用

我们可能离真正的“ARM Server之年”有点距离,但容器肯定会加快在数据中心采用ARM的速度。容器在ARM服务器上运行的方式与在英特尔服务器上的运行方式相同,但具有大幅降低成本的潜力。像Packet这样的托管公司现在可以按小时增量提供ARM服务器;在某些特定情况之下,容器和像RancherOS这样的轻量级Linux分发版可以利用这些托管解决方案,让ARM服务器成为工作负载的值得考虑的选项之一。

2016国外容器使用调查报告:走向生产环境,工具与系统排名谁是赢家?

刀客info阅读(4944)评论(0)

眨眼2016就到了尾巴,年底是总结与展望的好时机,小数为大家带来一篇来自Anchore的国外容器技术调查报告,帮助大家全面了解这一年国外容器发展和使用情况。

本次报告数据的采集来自各个领域和方向,包括容器计划和使用、管理工具、操作系统、CI工具和安全。其中,报告重点关注容器和CI的数据。

使用者分布

我们的受调查人口中,有60%工作在100人以上的公司,并且在各个职位都有分布。

 

qq%e6%88%aa%e5%9b%be20161208100451

 

容器技术使用分类

和其他使用场景相比,大约有三分之一的用户将容器技术应用于生产环境,开发使用则更高一些。

 

qq%e6%88%aa%e5%9b%be20161208100502

 

安全成为问题

本次调查最有趣的发现之一就是大家对于安全的关注。特别是生产环境和非生产环境下企业选择安全策略的对比,差别非常显著。

 

qq%e6%88%aa%e5%9b%be20161208100629

 

有自定义适当安全策略的公司更有可能运行在生产环境。有很多潜在的方面需要深入,但是最高级别的开发者很少会将热情投入到安全方面,而且几乎从不考虑一些合规的细节,这些恰是企业必须考虑的。

安全成为了一个壁垒,延缓保守派接受新的技术。

CI/CD

CI/CD在云原生上的重要性不言而喻,Jenkins在众工具之上遥遥领先。数据上Jenkins和CloudBees(商业版Jenkins)占据了50%。

 

qq%e6%88%aa%e5%9b%be20161208100634

 

如我们预期的那样,受调查者中CI/CD的使用水平比其他领域高很多。

 

qq%e6%88%aa%e5%9b%be20161208100640

 

容器编排工具

现在说编排工具市场很火热都只是轻描淡写。出于分析的目的, Kubernetes我们选择了红帽的OpenShift和CoreOs Tectonic,Mesos则选择了Apache Mesos和Mesosphere。

 

qq%e6%88%aa%e5%9b%be20161208100646

 

我们可以看到Kubernetes和Docker Swarm在市场占有率上位居前两位,前者比后者略微领先。
重要的是Mesos在架构上依然功能强大。我们经常会看到架构师在大数据环境下选择Mesos,并且试图为他们的容器策略寻找一个通用的方法,这表明整个技术市场依然充满了变化。

 

qq%e6%88%aa%e5%9b%be20161208100651

 

容器操作系统

主机操作系统

意料之中,Ubuntu在容器主机操作系统中位居首位,但是其他两个方面的数据也值得讨论。首先,Amazon Linux的高使用率反映了ECS的增长,而Alpine Linux则反映了Docker在Mac的应用。

 

qq%e6%88%aa%e5%9b%be20161208100657

 

观察前五名的主机操作系统的用户属性,可以发现Ubuntu在开发者和架构师上占据主导地位。

 

qq%e6%88%aa%e5%9b%be20161208100702

 

专业操作系统的使用也在增长,但是达到了一个分叉点。在专业操作系统中,CoreOS位于第一,Alpine持续增长,反映了Docker在Mac上应用。

 

qq%e6%88%aa%e5%9b%be20161208100707

 

容器镜像操作系统

容器的好处之一就是简化应用堆栈,把它们捆绑在一起,或者把应用的组件打成一个简单的包。然而在容器和更简单的VM二选一中,人们还是经常会有困惑。数据也表明了这种情况,我们可以看到受调查者中选择完整操作系统镜像的占大多数。

 

qq%e6%88%aa%e5%9b%be20161208100715

 

镜像的选择中,Ubuntu再次第一,CentOS和RHEL分别在二三位。

 

qq%e6%88%aa%e5%9b%be20161208100720

qq%e6%88%aa%e5%9b%be20161208100727

 

这些增长带来了教育认知上的普遍问题。对于大多数应用来说其实并不需要一个完整的OS镜像。然而,现实是许多应用仍然被构建在这种镜像之上,理由各种各样——开发简单的选择,操作的原因例如要符合程序,安全策略等等。

也就是说,搭建完整OS镜像容器的想法,引发了运维、安全、部署等角度的多重问题。基于容器应用的微服务带来的快速变化也引发了一系列有趣的挑战——从一个开发者的角度,滚动和发布新版本变得非常方便。

这就给我们带来了一个非常困难的操作难题——我们如何确保安全性,以及在开发加速的同时理解应用的构成。在安全面前,我们看到开发者把CVE分数视为足够的安全——然而那只是一个有用的底线,却远远不够。

本文作者:fryan
原文链接:http://redmonk.com/fryan/2016/12/01/containers-in-production-is-security-a-barrier-a-dataset-from-anchore/