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

刀客info阅读(181)评论(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阅读(181)评论(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阅读(557)评论(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阅读(256)评论(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阅读(300)评论(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阅读(330)评论(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阅读(273)评论(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阅读(232)评论(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阅读(1558)评论(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阅读(499)评论(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阅读(338)评论(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阅读(255)评论(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阅读(1302)评论(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/

容器,你还只用Docker吗?(下)

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

作者介绍
周晖,Pivotal大中国区云计算首席架构师,有丰富的PaaS云实际建设经验,负责过国内某知名银行已经生产上线一年的PaaS云的架构设计和部分功能的实现,参与过某超算PaaS、某超市电商PaaS、某电力PaaS等项目的建设。

我们在上篇文章中谈到CaaS生态圈的公司如何应对Docker用捆绑方式从容器入侵CaaS领域,CaaS厂商通过容器抽象、标准化容器运行时RunC以及容器功能外化插件来重新定义容器。下面我们继续来看CaaS厂商的具体方案。

一、CaaS业界通过分解重组Docker技术来替代Docker的方案

1、K8s通过CRI-O取代Docker容器管理引擎架构

和Cloud Foundry的架构模式类似,K8s也发展了CRI-O来取代Docker,架构图如下:

 

20161129091506

 

CRI-O是Google的Kelsey和Docker CTO所罗门论战之后的结果。论战之后,Google就提出一个设想,要让K8s调度的容器去Docker化,虽然他们一开始说的是要分支出一个Docker的分支来做容器,但是后来考虑到这样做属于刺刀见红,杀伤力太大,所以在2016年6月先弄了一个OCID(OCI守护进程),就是RunC的守护进程,和Docker Daemon有异曲同工之妙,该项目的维护人员此地无银三百两的说“这不是Docker的分支”。

由于OCID过于和Docker Daemon类似,随后Google又把这个项目重新命名为—CRI-O(Container Runtime Interface,容器运行时接口,O表示OCI,也就是RunC的运行时接口),这也反映了Google的心态,一方面通过CRI对容器进行抽象,什么容器我都支持,另外加一个O,我重点支持OCI的RunC,显得不是那么白刀子进红刀子出,大家表面上还是和平共处,而且显得立意更高,通过容器抽象层进一步标准化容器,RunC只是标准化容器运行时,CRI把对容器的调用管理等也标准化,潜台词是Docker Daemon是非标准的、独家的。

同时,Google也在向Mesos推销其CRI-O,希望Mesos也采用其CRI-O的架构。

CRI-O对容器运行时提供基本管理功能,同时Google的K8s提供镜像管理功能(Container/Images),完全可以取代Docker的镜像仓库。K8s一方面支持容器插件技术,另一方面自己也制定实现一些容器插件,最典型的就是容器网络插件,自己定义并实现了CNM的容器网络插件。

因为K8s之前一直支持Docker,为了保持一定的兼容性,K8s继续支持Docker容器,但是不再支持Docker超出标准容器之外的特定功能,也就是把Docker的定位和RunC等同化,Docker做的再多功能也不用。

2、Mesos通过UnifiedContainer取代Docker容器管理引擎

和K8s类似,Mesos也不再只支持Docker容器,而且对容器进行了抽象,项目名字直接就叫”Unified Containerizer”—统一容器。目前还是支持 Docker 和 Mesos Containerizer 两种容器机制,未来就统一到”Unified Containerizer”。架构图如下:

 

20161129091516

 

Unified Containerizer也支持插件架构,但是和Docker的插件不是完全一样,设计的插件类型更丰富,包括三大类:

  • 第一类是进程管理,支持容器之前的进程,这也是Mesos一贯的调度管理策略。
  • 第二类是隔离器: 在容器生命周期的各个阶段提供扩展接口,保护了Docker的几类插件,如网络、磁盘、文件系统、卷插件。
  • 第三类是容器镜像管理,除了容器镜像,还将支持虚机镜像等。

Mesos的统一容器基本就包含了DockerDaemon、Docker仓库等功能。

当然,由于之前一直支持Docker容器,目前阶段Mesos还继续支持Docker,但是也有自己的Mesos Containerizer容器机制。

3、Cloud Foundry通过Garden取代Docker容器管理引擎

从RunC逐步成熟,Cloud Foundry的容器引擎Garden就采用了RunC作为容器运行时,如下图:

 

20161129091524

 

Garden取代DockerDaemon(Docker Daemon有内有Docker Server,Docker Server内有Docker引擎),直接调用RunC来生成容器运行环境,同时CFGarden也支持容器插件,容器插件是独立进程,在网络插件方面优先支持K8s的CMN插件标准。CF Diego有自己的镜像仓库管理,也可以从Docker仓库中获取Docker镜像部署。

这里,我们不得不对Garden的设计多说几句,Garden包括之前的Warden,从一开始的设计就是容器抽象,使得可以支持不同的容器运行时,而且Garden做了三层抽象,所以Garden从一开始就支持.Net应用,不是通过Windows 2016的容器机制来实现,而是在.Net运行时模拟了一个容器的实现,所以Garden支持Windows的几乎所有版本的.Net应用。

K8s CRI-O和Mesos的UnifiedContainerizer都借鉴了Garden的容器抽象设计思路,所以Garden也是第一个支持RunC的CaaS/PaaS。

从这个架构可以看出,Cloud Foundry的Garden基于RunC和容器插件,就替代了Docker的容器功能,共同的是RunC和容器插件,而Garden取代Docker Daemon的容器管理功能。

当然,Garden也支持直接部署Docker镜像。

二、容器生态的演进

1、各方以RunC为核心重新构建容器生态圈,Docker容器被弱化

在对开源Docker分支进行了反复斟酌、放风声、试探和讨论之后,各方觉得杀伤力太大的方案。而重新回到了折中方案,以RunC为核心重新构建生态圈,并且通过插件来弱化容器在CaaS生态圈的重要性。

我们来看看生态圈的演进示意:

 

20161129091532

此图标识了容器生态圈或是CaaS的演进变化

最早只有Docker和Garden两大主流容器,Mesos和Google都专注于CaaS,容器就全部采用Docker,CloudFoundry由于在Docker之前就推出了Warden(后升级到Garden)容器,CF采用自己的容器打造了PaaS平台,形成了一个和谐的生态。

在Docker捞过界了,并且确实有些不符合企业生产系统的因素,包括后向兼容性、商标问题、稳定性问题,于是各CaaS/PaaS生态厂商组建OCI联盟,打造RunC容器引擎,只需要一个简单的容器起停、管理等引擎,把Docker的容器功能一分为二,RunC作为一个简单明了的运行环境,降低复杂度,提升稳定性,适合生产系统。而对于Docker容器的其他功能,则在各自的容器抽象层,依据需要去实现,而且因为Docker本身集成了太多功能,不利于生产环境稳定性要求,各个容器抽象层都采用插件模式,维持容器的简洁性,需要什么功能再插入容器,比如需要网络就可以插入网络插件,需要存储和卷访问,就插入存储和卷的插件。

目前的形势,就形成了Docker和各个CaaS/PaaS厂商在同一层面竞争,在CaaS/PaaS平台,Docker并没有什么优势,但是Docker想把其容器的广泛使用的优势在CaaS中延续,目前看来并不容易。容器的主要用户还是个人用户、开发者用户、运维用户,而CaaS是企业系统,二者目标客户不同、技术要求不同。

随着这个生态的演进,Docker容器会更多的用于开发、测试环境,而RunC在各个CaaS厂商的推动下会在生产环境得到广泛的应用。

K8s目前基本只支持RunC容器,对于Docker超出其容器抽象层之外的功能,一概不支持。同样,Mesos也通过其Unified Containerizer只支持RunC容器,目前还支持Docker,但是未来的规划是只支持Unified Containerizer。CF也通过Garden只支持RunC,不支持Docker超出RunC之外的功能。

2、RunC生态的快速发展

由于Docker的消极抵制,RunC的发展好像并不为人所知,但是RunC的发展还是很快的,RunC本身就简单,通过版本的持续的迭代更新,目前已经达到生产可用,而且主流的PaaS/CaaS纷纷采用。Docker也从1.11开始内置RunC容器运行时。

除了RunC本身的发展,RunC的生态圈也在快速发展,这个生态圈就脱离了的Docker。比如最近的Riddler,就是一个把Docker容器转换为RunC镜像。

详见https://github.com/jfrazelle/riddler。

三、你还只用Docker吗?

Docker作为目前最热的容器开源项目,受到广泛的追捧。但是也要清醒地看到Docker和容器生态圈的种种争斗,Docker通过注册商标和在Docker中内嵌容器集群管理,挤压生态圈其他公司的生存空间,而受到生态圈联盟以RunC和相应的技术来制约Docker。

如果你是开发测试用Docker,那么基本不受影响,可以继续,这也是很多公司对Docker的定位。如果你是生产系统采用Docker(包括Swarm),你就要注意,如果是你自己定制开发基于Docker/Swarm的CaaS(Container As a Service),那问题也不大,出现漏洞或是定制可以自己打补丁,但是要意识到你的补丁不一定能合并到Docker的主干版本。如果是你采用的是第三方给你定制的基于Docker和Swarm的CaaS,你就一定要当心了,他们针对Docker做的定制要合并到Docker的后续版本有相当的难度,因为对于Docker的补丁定制合并,除了Docker公司其他公司几乎是没有什么控制力度的,还包括后向兼容性问题。

作为用户或是容器生态圈的创业公司,不能一棵树上吊死,如果在容器层面只考虑Docker,而不考虑RunC,可能会和CaaS/PaaS生态圈的标准越来越远,未来和CaaS/PaaS的标准容器差异越来越大,主流的CaaS/PaaS厂商和技术,如K8s/Mesos/CloudFoundry均不再支持Docker容器超越RunC之外的功能,而只支持插件对RunC功能的扩展。

业界更普遍的定位是Docker用于开发测试环境,而RunC用于生产环境,所以对于要在生产环境采用容器技术的,一定要研究RunC。

作为容器创业公司,很多是在Docker的风口成立的,但是由于Docker一家独大和Docker注册商标的法务问题,可能还没有在风口起飞。应当可以考虑在OCI/RunC的生态圈进行相关技术的发展,OCI/RunC的生态圈受到实力强大的几家公司的强力支持,如Google、CF基金会、Pivotal、Redhat、Mesos、CoreOS等。而且RunC的生态圈还刚刚起步,还有很大的发展空间。而且作为技术创新,对于技术的前瞻性判断非常重要,方向判断正确,一路辛苦是披荆斩棘,方向判断错误,一路辛苦也是前程堪忧。

国内的公司对RunC的贡献度越来越高,特别是华为,可能是国内公司中对RunC贡献最大的。还有EasyStack、南大索芙特等的贡献,反倒是一些著名的Docker创业公司看不到对RunC的贡献。这一方面反应了华为、EasyStack技术眼光和对社区的贡献,另外也反映了为什么华为和EasyStack在商业上也更成功一些。

四、对一些问题的提前答复

1、RunC也是Docker的,用Docker和用RunC不是一样的吗?

Docker对RunC有重大的贡献,RunC的早期也是基于DockerLibcontainer,但是RunC在OCI下独立发展,有贡献的厂商远远不止Docker。在RunC项目后,在OCI的推动下,各个厂商积极贡献,Docker的代码贡献并不占主导,更谈不上主要是Docker在维护,更准确的说Docker是RunC的重要维护力量之一。

 

20161129091542

 

上图是Git上RunC的代码贡献者排名

前10个贡献者中,Docker只占2位,不得不提国内的公司华为代码贡献排名是相当的靠前。而且RunC的代码贡献者超过100人。

除了Kubernetes/Mesos/CloudFoundry支持RunC容器运行时,Docker的容器从1.11开始也内置RunC作为容器运行时,说明RunC受到最为广泛的支持。

而K8s/Mesos/CloudFoundry明确表示在容器抽象层不再支持Docker超越RunC之外的功能。

RunC属于OCI,不再受Docker注册商标的影响,对RunC的代码贡献不再受限于Docker。

用RunC相当于给你一个干净简单的容器运行时,用Docker相当于不管你要不要,强塞给你一堆可能你不想用的东西。

对于RunC和Docker的详细技术区别,请参考《容器,你还只用Docker吗?(上)》中的4.5章的内容。

2、在Docker如日中天的时候这么说是哗众取宠

Docker现在是如日中天,但是3年前也是刚起步,也许可以说RunC就是3年前的Docker。Docker由于Docker公司自身的商业特征,对容器生态圈其他公司的生存空间的挤压,已经造成了容器生态圈的裂变。

“风起于青萍之末”,如日中天的时候可能就是走向下坡路的开始。Docker一家和其他CaaS生态圈分裂,这条路注定是不平坦的。

3. 黑Docker黑出翔来了

黑Docker的资料很多,所有资料都有出处,有参考内容链接,详见后面的引用。

Docker已经被布道师们说成”无所不能”,稍微有几个不能,我觉得大家还是能区别得出来。

4. RunC是没人管的孩子

RunC的自身发展远不如Docker那么有名气,因为RunC本身就是一个很小的容器运行时,不是针对开发者的,开发者往往是通过Docker接触到RunC,所以RunC的受众远比Docker要少。

但是对于CaaS项目来说,K8s/Mesos/CloudFoundry往往就是基于RunC容器运行时。

RunC的社区也很活跃,除了RunC本身的更新很快,各大CaaS/PaaS生态圈如Google/Pivotal/Redhat/华为/CoreOS等都有专人在贡献代码。

RunC相应的生态空间也在活跃,也有不同的项目在进行中。

RunC是CaaS/PaaS/OCI等生态圈共同的孩子,不是没人看的孩子。

5、容器不需要标准更好

业界也有一些人持这个观点。其实,标准的价值是常识,当然总会有反常识的言论出来。没有标准就没有合力,没有合力哪来的发展。如果Docker公司把闭源,那可以没有标准。既然是开源,又想要生态圈的其他公司和力量做贡献,就要让大家有合力,就要让大家在标准的基础做贡献,而不是把生态圈的其他公司当作免费打工的。

五、总结和展望

Docker和CaaS生态圈在容器上的分裂已经是现在进行时了,虽然大家都没有明说。这也将是容器和CaaS生态圈重要转折事件。让我们来看看目前正在发生的和在未来一年中很有可能发生的事情:
Cloud Foundry率先采用RunC作为容器运行时,而且刚刚做了一个25万个容器集群的测试,https://www.cloudfoundry.org/cloud-foundry-approaching-250000-containers/ 验证了PaaS+RunC的大规模集群的支持。

K8s的CRI-O也会尽快发布,等CRI-O成熟以后,内置的容器运行时就应当是RunC,而不再是Docker了。

Mesos的Unified Containerizer 也应当会在1年之内成熟,随后内置的容器应当也是RunC,而不再是Docker。

在Docker被科普以后,客户更关注的是CaaS而不是容器,再给客户去科普Docker体现不出容器创业公司的价值。

一些不适合容器的Docker应用场景的案例会被证伪,在Docker和容器鲜为人知的时候,各种各样的Docker案例层出不穷,包括一些明显和常识有违的案例,比如交易系统采用Docker, 交易极严格的延时的要求不适合Docker。有的是故意混淆概念,交易本身不在Docker容器中,交易系统相关的一些模块在Docker中,为了突出宣传效果,说交易系统采用Docker。

Docker创业公司分化,越来越多的容器创业公司给别人介绍自己的时候会说我们是K8s初创公司(或我们是Mesos创业公司),不是Docker创业公司,强调自己是CaaS厂商,突出自己不是Docker厂商。当然,也有纯Docker的创业公司,但优势会变成劣势,毕竟在CaaS领域,Docker没有优势。

Docker在容器失去了K8s/Mesos/CloudFoundry的支持之后,会更专注于Swarm,和CaaS的其他厂商的竞争将更直接,但是Docker公司一贯的对企业生产环境特性的不在乎,Swarm很难对其他CaaS形成竞争优势。

RunC的生态圈将越来越丰富,第一个就是把Docker镜像转换为RunC标准镜像(这个已经有了),其次就是各种各样的插件和RunC可以交互,中间还可以衍生出各种插件的功能,如即插即用(动态性)、自动发现之内的。

一年以后,我们再来复盘。

容器,你还只用Docker吗?(上)

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

作者介绍
周晖,Pivotal大中国区云计算首席架构师,有丰富的PaaS云实际建设经验,负责过国内某知名银行已经生产上线一年的PaaS云的架构设计和部分功能的实现,参与过某超算PaaS、某超市电商PaaS、某电力PaaS等项目的建设。

一、从一场容器的撕逼战开始说起

从2016年7月底开始,Google Kubernetes布道师 Kelsey Hightower 和Docker的CTO Solomon Hykes在Twitter上发生了一场撕逼大战,主题是要不要用RunC或其他容器来取代Docker引擎以及OCI的意义。

首先是Google的Kelsey挑事,说:“很多平台都可以跑Docker镜像,已经不再需要Docker Daemon了。哪个会成功呢?”

Docker CTO Solomon马上接招:“其他平台跑Docker镜像是假的,其中只有90%能正常工作,其余10%则随时可能会出问题。而且Docker还在演进中。”“所以嘛,声称‘可以跑Docker镜像’的都是在撒谎。”

Kelsey Hightower反讽:“好吧,那我们就没必要再提支持Docker了。我们实际支持的只是Docker的容器格式”,“Docker拥有创建和分发镜像的最佳工作流,而运行时,还是留给它的竞争者们吧。”

所罗门继续强调Docker的不兼容性:“这些都是不完整的、不兼容的支持”,“他们也并不支持镜像格式,镜像的很多信息都会丢失”。

后来,所罗门急眼了,说“OCI就是个伪标准”。

此言一出,惊诧四方,因为OCI有50多家厂商参与,而且Docker还是重要贡献者,有说“标准不是一个人可以决定对错的”,有反讽的 “我相信工程师们乐于听到他们创始人说他们做的工作是假货”。

K8s的老大Tim Hockin直接就说“不爽你就走,不要假装参与”。

所罗门不得不改口说“OCI标准的初衷是好的,只可惜扩展太早,我不认同就得走?”

有人随即反驳“只有你一个人说扩展的太早,这是明显的利益投射”。

所罗门还嘴硬“就因为我是唯一的不认同者,那我就必须离开?”

Kelsey随后则直点主题,“有两个问题在台面上,一是容器需不需要标准化,二是需不需要由Docker来领导这个标准化的工作?”

Kelsey再以嘲讽的口吻自问自答“如果是Docker来回答这些问题,对第一个肯定是说不,那干脆对第二个问题也同样说不吧,这可不是对和错的问题”。

因为事关OCI,Docker现在这么鄙视RunC,OCI不得点出Docker你也是参与者就别闹了, “Docker参与在OCI运行时和镜像规范,也参与了每周的开发会议”。

Kelsey乘胜追击,代表业界吐了个槽,“我一直相信Docker会给容器带来很多,但是我真的担心一个人想控制的太多”。Docker公司的控制欲早成为人们的吐槽点,什么都想做,把整个生态圈其他的参与者逼到墙角去了。

看业界大佬撕逼,感觉和咋人民群众撕逼没太大差别。所罗门的撕逼技巧明显略逊一筹,有点像祥林嫂反复说“其他容器就是和Docker不兼容,包括RunC”,但是没说出个哪里不兼容的道道。

二、容器撕逼之争反应了容器生态面临的问题

我们来总结这次著名的撕逼事件的来龙去脉,这会成为容器界一个关键的历史转折事件。容器之争始实际上是很早之前就起源于Docker生态面临的问题。

1、Docker商标的注册围剿了容器生态圈

从表面上看,是容器标准之争,其实,反应的是赤裸裸的利益问题。Docker从容器开始,在获得社区的热烈响应之后,就进入了圈地过程,而且第一招圈地就非常凶悍,把公司从dotCloud改名为Docker,然后注册Docker商标,商标意味着当其他公司使用未经Docker社区许可的补丁、代码或软件包的时候时可能面临法律责任。这种情况下,一个公司可能因为补丁尚未经过Docker公司许可,抑或尚未被合并到项目中,而不能为客户提供技术支持。

这不只是法务上的圈地,对于很多采用Docker名字的,Docker公司给予了实际行动—口头警告(谁叫Docker是人家注册的名字呢,就好比weibo.com就是微博),包括你建一个群名不加修饰限定的叫Docker,或是你要写本书,不加修饰的叫DockerXXX,都容易受到Docker的警告。从法务上看这确实也属于侵权,就看Docker要不要告你。

其后果就是第三方Docker生态厂商被迫忍受Docker公司任何对该开源项目作出的决定,在问题出现的时候等待Docker公司的补丁。最好的结果与Docker达成某种协议,由Docker公司来保证提供稳定的发行版本。那Docker的生态公司就沦为Docker公司的代理商了。

2、Docker携容器引擎优势进入容器集群管理,挤压了容器生态圈的其他厂商生存空间

如果只是口头撕逼,那大伙儿看看热闹就可以了,事实上这涉及到巨大的利益和整体生态环境的分歧。

在Docker获得广泛关注以后,就利用Docker容器的广泛性优势来挤压生态圈其他伙伴的生存空间。直接把Swarm内置在Docker中。和当年的Microsoft通过Windows捆绑IE来打击NetScape有异曲同工之妙。

Docker公司原来只在容器领域发展,K8s/Mesos等做容器集群管理,属于CaaS(Container as a Service),相互补充,互不竞争。等Docker容器被广泛关注以后,Docker进入容器编排市场,收购了相关的技术以后推出Swarm的容器集群管理,从容器进入CaaS市场。2016年7月发布的Docker 1.12把Swarm内置到Docker中去了,Docker Swarm作为容器集群管理软件,内置在Docker中,几乎就是Windows捆绑浏览器IE的模式,这就是用不平等的市场优势打击了Google的K8s和Mesos等,Google也不是吃素的,所以7月底马上就是和Docker CTO口头开撕。

对于Docker生态圈的集群管理软件K8s和Mesos等来说,不但是不平等的竞争,最关键的是在容器生态圈最能带来商业价值的就是容器集群管理,单单容器本身并没有太多的商业价值,容器没有集群管理是很难进入企业运行环境的。因为容器的直接商业价值并不大,CaaS厂商也没有自己做容器。容器用于生产系统,就必须有容器的集群管理,而K8s和Mesos已经进入了这个商业领域并且取得了一定的优势。现在Docker进入这个领域,就直接和容器集群管理的公司竞争,但Docker又是必须进入这个领域,如果不进入这个领域,很难取得商业成功, Docker本身又经过多轮风投,风投给Docker带来了巨大的盈利压力,如果久久不能盈利,那风头的脸色不会那么好看了。

如果是公平竞争还好,比如Docker单独发布Swarm的Docker集群管理,但是Docker直接把Swarm内置到Docker中去,安装部署Docker就带了Swarm,而Swarm的很多功能和K8s和Mesos是重叠的,K8s和Mesos再用Docker就显得功能有大量重叠,而且带来了系统的复杂性和不稳定性。

三、Docker的问题——业界对Docker的吐槽

在Google和Docker口水战之后,业界对Docker的吐槽越来越多,主要包括以下几点:

1、Docker向后兼容性问题

Docker被业界诟病最多的就是后向兼容性,Docker的新版本更关注的是革新性,而不是兼容性,但是,对于一个生产系统来说,后向兼容性至关重要,没有后向兼容性,意味着每次Docker升级都带来巨大的风险。

这也和Docker的企业文化有关,Docker更倾向于采纳新技术,实现突破性的功能,这是典型的初创公司的企业文化,不断的追加新功能,而不考虑企业级特性,更不考虑后向兼容的束缚。这个好处是能在个人粉丝中取得共鸣,这也是Docker快速流行的一个重要原因。任何特征都可能是双刃剑,这种企业文化并不适合企业级,不考虑生产运行的可用性,对企业级应用来说可能是灾难性的。

我们看看业界人士是怎么说的:“Docker不断地破坏向后的兼容性”,RackN公司的CEO Rob Hirschfeld说。RackN公司的应用程序生命周期管理平台同时使用和提供了Docker组件,因此对后端的改动将会对其支持的客户的业务造成影响。

“Docker将Docker Engine用作一个产品,而不是一个社区用来构建自有服务的组件”,Hirschfeld指责道。这种基于产品的策略意味着使用者被逼着在Docker发布新的革新特性或者合并新的组件(如Swarm)的时候去修复其破坏的向后兼容的问题。

“尽管我们会使用这些发布的特性,然而这些改动会带来一系列与稳定性、版本、迁移和后端兼容相关的问题”。

Bob Wise,一名三星SDS云工程师,也同样呼吁Docker放慢其容器创新的脚步,该公司同样提供了基于云的容器相关支持服务。

“如果你的团队在深度使用Kubernetes、Mesos或Cloud Foundry,你需要一个稳定、简单、无奇的容器实现方案,仅有最少的基本功能,由社区协商镜像的创建、命名和发布”,Wise的一篇博客中写道。“你需要使用每个都人都在使用的一个相同的、简单的、无奇的容器实现方案。作为一个社区,我们需要放缓对于基本构建组件的变更速度。唯有稳定性才能让构建其上的系统蓬勃发展。”

2、Docker容器在企业级方面还有待提高

Docker虽然一直宣称Production Ready,但是在实际的生产系统中同样受到不少诟病。

看看业界人士的说法:

Apcera技术产品经理 Phillip Tribble在个人博客中,以一种外交辞令的口吻,让Docker不要再把其新推出的特性鼓吹成一个完工的企业级可用的产品。Tribble写道:“让互联网或者大会充斥着营销材料,宣扬各种令人振奋的新特性,但实际上却不如所说那样能用,不是一个明智的做法”,Apcera的商业模式一部分是基于提供Docker容器的支持。

Tribble的帖子引发了其他人在Hacker News上表达他们的Docker经历,包括一些新版本带来的让人伤心的bug。一位读者谈到一天中启动70,000到90,000个容器,约9%左右的会因为“各种Docker bug”遇到问题,这个比例最近的一次升级后下降到了4%。

但也有一些人在称赞Docker的稳定性,“我们一直在生产中使用Docker约3年了,还没有发现什么大的问题”,另一外读者评论说,“它将一些很炫的Linux内核特性用简洁的方式封装了起来”。

当然也有不少Docker的支持者认为Docker公司的软件是稳定的。同一个产品,在不同的客户有截然相反的反应说明有的用的好,有的用的碰到不少问题,在不同的环境下缺乏一致性,这也是企业生产系统的大忌。

3、Docker捞过界了,越过了红帽的操作系统界限?

哪些功能应该有Docker来实现,哪些功能应该由底层操作系统或者技术栈中的其他组件来负责处理?

在今年的很多会议上,包括 LinuxCon North America 2016,红帽工程师 Dan Walsh 说红帽陷入了困境,一方面客户越来越多的使用 systemd 来初始化Linux系统,而另一方面Docker似乎不愿使用systemd,取而代之使用Docker Daemon来提供初始化,服务激活,安全和容器日志的相关功能。

“在过去的三年里,我们一直试图使systemd和Docker更好的整合,而我却发现,两个领导人都非常强烈的坚持己见”,Walsh说,两个领导人指 Hykes和systemd的创造者-Lennart Poettering

“所以,当机器的时候,谁来负责启动系统服务,是systemd还是Docker?”Walsh问到。一个拙劣的系统实现可能会导致systemd和Docker互相冲突。

红帽为自己的客户维护着自己的Docker版本分支,红帽分支中的补丁Docker有一天可能会合并,或者永远不。红帽也冒着巨大的风险,红帽的客户也冒着巨大的风险。所以红帽对Docker的支持其实远不如Ubuntu,因为Docker已经侵入到OS的领域了。

即使是面对以上种种吐槽,Docker也不打算折中一下,甚至也不打算照顾这些意见,而是继续我行我素。

四、容器生态圈集群管理厂商的应对

——不用Docker,把容器引擎拆解重组

撕逼只是矛盾爆发的阶段总结,后面就开始进入实质性的对抗阶段了。容器生态圈的集群管理厂商如Google/Mesos也不是吓大的,快要被Docker断了财路——— “人为财死鸟为食亡”,其反应也直取Docker命门——在其CaaS中废弃Docker,对容器进行抽象,用谁的容器都可以。容器运行时不再用Docker,而直接采用RunC,容器扩展功能通过插件来实现,基本就是全抛弃Docker了,这对Docker来说几乎是生死之战。

其实,容器技术本身的壁垒不高,Docker 2013年一开始也就是几十人的开发队伍,到现在也只有200多人,各大厂商一直没有重视这一块,因为单单容器的商业价值比较低。真正要投入做容器,也只是分分钟的事情,只不过Docker已经在容器领域形成了气候,所以要走些变通的曲折路线。

各大厂商一起做个RunC,大家再只用RunC还是轻而易举的。

我们再来看容器最主要的两个的技术来源:

  • Namespace—来源于IBM
  • cGroup—-来源于Google

其他的容器核心技术都是Linux操作系统的功能,容器的核心技术是和Linux操作系统密切相关的,Docker本身在容器核心并没有什么贡献,NameSpace和cGroup都不是Docker的,也和Docker无关。Docker也不是最早用容器技术的,Cloud Foundry比Docker更早把容器用于PaaS。

所以容器生态圈的公司撇开Docker做一个容器标准并不是什么难事。

我们再从时间线来梳理这个撕逼事件,让大家更直观的理解:

 

20161125090920

 

1、提前铺垫:先通过RunC把容器运行时分离出Docker

2012年,随着Cloud Foundry的PaaS率先引入了容器技术,容器技术发展的愈发火热,特别是Docker成为流行技术,形成了广泛的生态圈,由于Docker一贯的控制欲,让生态圈的其他大小伙伴难以参与,为破解这种状况。Google先是支持CoreOS打造了Rocket容器,在Rocket和CF容器Garden的竞争压力下,Docker终于同意容器标准化—-RunC项目成立,通过RunC对容器运行时进行标准化。

于是容器生态圈终于达到了拆解Docker技术堆栈第一个小目标—通过RunC把容器运行时独立于Docker之外。在 2015年6月成立OCI(Open Container Initiative)组织,挂在Linux基金会旗下。旨在围绕容器格式和运行时制定一个开放的工业化标准。该组织超过50家大小成员,包括谷歌、Pivotal、Docker、CoreOS、微软、亚马逊、华为等一系列云计算厂商,按照该开放容器格式标准(OCF, Open Container Format)制定的一种具体实现,当然Docker是RunC的重要贡献者。

OCI对Docker意味着什么,Docker不是不清楚, 知道RunC是来抢食的,除了会削弱自己的优势,也还会被OCI标准束缚住,限制自己的发挥,所以Docker对OCI是消极抵制,但是无法和整个生态圈抗衡,不是不接受OCI和RunC。

面对Google、RedHat或者Microsoft这样的大公司,不管从技术实力还是财务实力,以及政治关系处理上,Docker应该都很难占到太多便宜。但是技术大势所趋,Docker也无法抗拒。

2、RunC容器格式标准是什么?

制定容器格式标准的宗旨概括来说就是不受上层结构的绑定,如特定的客户端、编排栈等,同时也不受特定的供应商或项目的绑定,即不限于某种特定操作系统、硬件、CPU架构、公有云等。

最核心,是通过格式标准化来脱离Docker,有利于CaaS生态圈的公司各自发展,但是在标准层面汇聚。

3、RunC容器标准化宗旨

标准化容器的宗旨具体分为如下五条。

  • 操作标准化:容器的标准化操作包括使用标准容器感觉创建、启动、停止容器,使用标准文件系统工具复制和创建容器快照,使用标准化网络工具进行下载和上传。
  • 内容无关:内容无关指不管针对的具体容器内容是什么,容器标准操作执行后都能产生同样的效果。如容器可以用同样的方式上传、启动,不管是php应用还是mysql数据库服务。
  • 基础设施无关:无论是个人的笔记本电脑还是AWS S3,亦或是Openstack,或者其他基础设施,都应该对支持容器的各项操作。
  • 为自动化量身定制:制定容器统一标准,是的操作内容无关化、平台无关化的根本目的之一,就是为了可以使容器操作全平台自动化。
  • 工业级交付:制定容器标准一大目标,就是使软件分发可以达到工业级交付成为现实。

RunC标准化是瞄准工业级交付和运行时的,和Docker定位不一样。各个CaaS/PaaS生态厂商需要一个标准的容器运行时,然后围绕着这个标准运行时各自发挥自己的技术优势,做编排的、做集群管理的、做资源调度等等,形成真正的容器生态圈。

4、第一步:虚张声势扬言对Docker容器另起分支,废弃Docker公司对Docker的独一控制权

在和Docker撕逼之后,引起了业界的集体吐槽,然后Google进入第一步:虚张声势,先来个大杀招吓唬Docker——尝试分支开源Docker来废除Docker公司对Docker容器的独家控制权。

先是Google方放出风声,要对开源的Docker Engine重起炉灶—分支出一个容器,马上在业界引起巨大的波澜。

“在诸多正在考虑的选项之中,包括可能会将整个开源的Docker Engine一起重起炉灶(fork)。据一些接近讨论的人士透露,相关代表来自Red Hat、Google、CoreOS、华为和两家大量使用Docker的客户。”

随后大家对Docker的代码库稳定性不足表达了各自的忧虑,因为这可能会在生产环境下基于Docker构建附加服务或者向客户提供技术支持的时候招致各种麻烦。在表达各种对Docker公司在Docker Engine上管理的失望之后,没有得到Docker的正面响应,相当多的技术专家和公司是支持分支的。因为Docker也不是吓大的,对种种指责不予理会。

但是,也有很强的声音担心Docker从此支离破碎:

“目前发生的这件事情,如果处理不得当,会让让容器生态系统支零破碎,并导致单个的容器再无可能适配多种目标运行时环境。” 一位Hacker News上的观察员指出。

鉴于直接分支对整个生态会产生不可预知的影响,属于杀敌三千自损八百的,虽然Docker CTO所罗门当初说OCI是个伪标准就是“杀敌三千自损八百”的招,但是碰到猪队友不能把自己也变成猪。直接分支停留在口头上。

5、第二步:通过RunC和插件来拆解Docker技术堆栈

在和Docker撕逼之后,引起了业界的集体吐槽,然后Google和业界进入第二步:

随着RunC标准化的发展,RunC逐步成了构建容器运行隔离环境的标准,和Libcontainer的功能类似,Libcontainer对RunC也有很大的贡献。那到底RunC和Docker是什么关系,如下图:

 

20161125090946

 

Docker从1.11开始就采用了右边的架构,这其实是Docker公司折中妥协的结果,因为面对Rocket和Garden的竞争,如果不支持RunC,那么在容器马上就会进入分裂竞争状态。

而OCI业界希望能够在容器的运行环境标准化,也就是构建出一个容器运行环境的这部分能标准化,在容器运行环境下不需要Docker庞杂的功能,容器运行时这部分占Docker的整体功能比重很小,所以OCI组织很快就达成的一致,发展RunC容器运行时。

所以,理解Docker和RunC的关系,你可以理解为RunC是Docker一部分,而且是构建容器隔离运行环境的一部分,而这一部分,也恰恰是CaaS的厂商所需要的,他们只需要一个生产环境下的容器环境构建,不需要容器的镜像打包等,这属于开发测试所需。

通过RunC,也基本确定了CaaS/PaaS产品如Cloud Foundry/K8s/Mesos等只需要RunC这个容器生产时的运行环境,而Docker更多的用于开发测试时。

除了RunC,容器插件也是一个关键的公有技术,把容器的功能扩展和外部交互的功能插件化,而插件在开源社区相当活跃,插件主要是四类:安全认证、存储卷管理、网络、IP池。比如各个存储厂商都在开发或是已经开发了自己的存储插件。

而这些插件也可以和RunC交互,通过上面一层的集成,可以让RunC用到这些插件。而插件也基本外化了Docker的功能。

虽然Docker定义和开发了很多插件,但是插件可以各自开发。插件只要提供接口就可以容器运行时交互。不再局限于某个公司的插件。这里不得不提到K8s开发的网络插件CNM和Docker自身提供的CNI就不一样,虽然理论上是可以相互兼容,但是实际上是两套实现机制,而且CNM得到了CaaS/PaaS厂商更广泛的支持。

通过RunC和插件,把Docker容器引擎的功能进行了分拆,而且分拆的部分都有了替代品,只等下一步。

6、第三步:CaaS生态厂商通过容器抽象、RunC和插件来重组自己的容器技术堆栈

如下图是各个业界厂商对Docker容器技术堆栈的进一步分拆,然后进行组合,形成各自自己的容器堆栈。分拆不是目标,是手段,组成成自己的容器才是目标。和我们的国产化替代是不是有点类似?

首先把Docker的技术堆栈分解为容器运行时RunC、插件、容器管理进程和容器仓库。因为已经有了RunC的基础,而且插件可以公用,各个厂商只要做容器进程管理和容器镜像管理,既然是新的技术架构,各个厂商也考虑到容器的兼容性,大家很一致的做了一个模块,称为容器抽象,无论是Mesos还是K8s。有的把容器镜像也一起做在容器抽象层,有的是单独再做一个镜像管理。

看下图右边的重组后的技术架构,完全没有了Docker,也不需要Docker,但是很自然而然的取代了Docker的容器。这就是很典型的对Docker技术栈分解,先取代最核心的容器运行时RunC,再把功能外化到插件,然后再做一个容器抽象层,彻底肢解并取代了Docker。

 

20161125090954

 

注意红色的框架,通过RunC和插件,CaaS/PaaS业界把他们所需的容器功能从Docker中独立出来了,也就是有了RunC和插件,CaaS/PaaS完全可以不需要Docker就构建出CaaS/PaaS运行环境。

行文至此,大家应当对容器生态圈的撕逼事情的来龙去脉、各个厂商的应对、撕逼原因以及整个容器生态圈的巨大变化有个初步了解,欲知后事,且听下回分解。