数人云

数人云

数人云官网
用户手册

用户手册

数人云用户手册
Mesos中文文档

Mesos中文文档

开源, 欢迎大家修改优化

实录分享 | IBM马达:Kubernetes/Swarm on Mesos

宁静胡同 发表了文章 • 0 个评论 • 452 次浏览 • 2016-04-22 18:09 • 来自相关话题

4月17日,Mesos爱好者在北京P2联合创业办公社迎来了第四次Mesos User Group约会,下面是来自IBM马达的分享实录。

作者介绍:马达,IBM 高级软件工程师,Kubernetes/Mesos代码贡献者。

很高兴参加这次活动,之前我一直从事分布式计算;从硕士阶段就开始在做分布式资源的调度及优化这一块,当时是基于Globus做跨机群的资源调度。毕业时加入了百度,后来进入了Platform Computing公司;Platform Computing是一家有着20多年分布式经验的公司;2012年Platform Computing被IBM收购,现在做为IBM一个子部门继续从事分布式相关的工作。凭借我们在分布式方面非常丰富的经验,我们在与分布式相关的开源项目都有比较多的贡献,这次主要讲与Mesos, Kubernetes,Swarm相关,还有其它团队在做Spark相关的项目。我会介绍一下Kubernetes和Swarm与Mesos的集成;比如说在公司的选型上谈一下我自己的想法,大家可以一起交流,如果有一些其他的想法,大家也可以一起讨论。







我先简单介绍一下这三个产品,然后讲一讲为什么要把Kubernetes和Swarm集成到Mesos上;然后介绍一些集成的细节,后面还有一些遇到的Challenge。最后,我们已经有一款自己的产品,叫EGO,和Mesos比较像。后续会逐渐将我们的经验及想法贡献到社区,我们做的主要是资源的调度,提高云和集群中资源的使用效率。







首先介绍一下三个产品;Kubernetes是Google推出的,参考Google Borg的开源实现,现在支持它的有红帽、惠普、华为等企业。Swarm是Docker下的项目,Swarm的目标是100%兼容Docker API,现在已经达到90%多;有些API在分布式环境中比较难处理,后面会有介绍。Mesos是这次演讲的重点,Mesos由Mesosphere公司来支持,第二大的commiter是Twitter,第三大的社区贡献者是IBM。IBM上个季度贡献了200多代码。Mesos主要是为了将资源抽象出来,尤其是CPU这些资源抽象出来,使整个集群看起来就像一台机器;用户只要关心他使用什么样的资源就可以了,这是Mesos的作用,也就是进行资源的调度和编排,提高整个资源的使用率,减少IO,最终降低开发和运维的成本。

我原来在百度的时候,百度的运维团队非常庞大,研发要给他写一个脚本,也就是上线步骤,告诉他第一步怎么办,第二步怎么办,第三步怎么办,运维人员按照这个脚本来执行。业务上线以后,通知研发检查有没有问题。现在跟原来的同事聊,有了很大的变化,很多东西都有自动化的脚本,包括资源的利用,大概需要什么样的资源,它会自动的支撑脚本。Mesos就是做这件事,把整个资源的运维用机器做起来,减少手动。







说一下为什么集成到Mesos上,Kubernetes和Swarm最主要的目标是Container,我们希望对资源可以共享,比如说双十一,会有峰值的时候;系统在平时会有一个估值,提供基本的服务资源;剩下的机器做一些线下的分析。Mesos为这样的需求提供了一种解决方案。


“Auto-Scaling”和“不依赖于特殊网络”;这两种个原因说服力不强:网络自己用脚本就可以做了,Auto-Scaling用脚本也差不多;主要优势还是资源共享,在DCOS上资源共享相对来说比较重要。现在大部分的公司还在专注于网络和存储,可以将容器连接进来并可以访问共享数据;但是过一段时间你会发现,网络和存储不是大的问题以后,大家会关心资源的利用率;如果10台机器的资源利用率提高10%,带来的好处并不明显,但如果是1万台机器能提高10%的利用率,那集群相当于多了1000台机,带来的效果还是很明显的。







这是Kubernetes在Mesos的一个结构图,Kubernetes最左边这个地方就是Kubernetes自己本身的一些Master的东西,其实在Master最主要的是资源调度Scheduler这一块,Scheduler的资源是Mesos Master分出来的,所以在Kubernetes对Mesos来说只是其中的一个framework,Kubernetes和Spark可以共享资源。Kubernetes提供的CloudProvide很多,它可以跟其他的云厂商可以进行集成。在调度资源里面,Kubernetes还会遵循现有的调度策略。但是有一个问题,就是Scheduler在计算的时候,分配的资源只是基于Mesos给它的东西,比如Mesos分给Scheduler机器A,但是可能机器B上有一个更优的资源,它其实是拿不到的。

Scheduler拿到资源以后还是通过Mesos来启动计算节点,Kubernetes的Master相当于Mesos的一个Framework。这个计算节点的executor其实这个做的还是蛮不错的。在Kubernetes 中提供了一个Kubelet的库用于容器的管理,这个集成项目把Kubernetes和mesos的Executor做了集成,两边做的都是蛮好的。最开始以为是Slave再去起一个Kubernetes 的 Agent,那样计算节点的开销会很大。现在的解决方案相当于是把Kubernetes集中到Mesos的Executor。Kubernetes On Mesos,自己做了Executor,改了Scheduler,基本上还保持了Kubernetes原有的功能,对原来的支持还是蛮不错的。







集成的问题,其实从总体架构来看,大家都是提供了集成的方法,但彼此的集成方案很难统一。而且在概念和功能上也有很大的区别,比如说Namespace和Quota,这是Kubernetes自己的功能,这两个彼此的资源都看不到。但是这个集成方案中,他并没有映射到Mesos自己的Role,整个Kubernetes映射成一个Role,这个Role能拿到多少Quota,就是Kubernetes 的资源。


另外就是刚才说的关于Optimistic Offer、Revocable resources。所谓资源共享,是Mesos上的一个Framework可以把自己不用的资源借出去,但是当我要的时候,我应该可以把资源抢占回来。而且当资源被抢占的时候需要给出一定的时间进行清理。Optimistic Offer现在会直接把资源抢回来,而且没有一个接口通知相应的作业进行后续的清理工作。比如说我要删某一个进程我应该告诉你怎么删,我要做一些东西。Kubernetes没有对Revocable resources做这些相应的处理。

另外,Mesos自己对Revocable Resources的支持力度也不是特别大。现在支持一种Revocable Resource:当机器分出去的Resources,但是没有用,也可以做Revocable resources。现在和Committer交流,我们经常提这个功能,他们并没有意识到资源的使用率对整个集群有多重要。集成的时候,Unified Container,把镜像下下来去解析。作为Unified Container,它并没有提供API, Kubernetes要用Docker的API完成这些工作,如果想把这些引到你的Unified Container,就意味着你的Unified Container要支持Docker的API,这对Mesos来说是很重要的。Docker的API最大问题是并没有一个统一的标准,它的镜像是可以下载下来的执行,但是Docker本身的API没有标准,Mesos的Unified Container要去兼容它的API是一件很繁重的工作。

另外就是Persistent Volume,Mesos自己提供了Persistent Volume,这个作业在机器上重启以后,这个资源所使用的文件会被留下来;如果没有Persistent Volume,则沙箱里的数据都会被删掉,这一块并没有跟Kubernetes自己的Persistent Volume集成在一块,Kubernetes自己的Persistent Volume做的事情是把Volume做成一种资源,比如说是1G或者2G,然后可以请求和作用这些资源;其实跟Mesos的功能是从想法上是完全一致的。但这里有一个效率的问题,Kubernetes自己Persistent Volume能够拿到全局所有的资源,但是如果基于Mesos的话,只能拿到Mesos固定的一些资源,所以这个Kubernetes只能基于不是最优集成拿到最好。其实最主要的大家都有自己的概念和想法,是没有一个人去做两边的集成,大家都认为应该跟随,到底谁应该跟随谁。






Swarm相对来说还简单一点,Swarm对于资源还好,最开始的时候其实Swarm他会去发一个请求,这个请求还是自己Mesos的系统,他会自己做一个Schedule,告诉Master。因为Swarm运行Docker UPS,有一个路径,所以这个东西资源分配给Swarm Cluster,这个资源分到Swarm,资源分到这,Swarm会告诉他在哪一台机器上,然后Swarm会连这台机器上的Container。再取那个信息,整个的过程是达到Swarm拿到这个机器以后会告诉Master,Run就基于Mesos自己对Docker的支持。透过这个信息也会告诉你连这个Docker,把这个信息盖了,这个集成会比较简单一点。

Swarm这一块相对来说做的稍微好一些,它会抽象成一个集群,它跟Mesos相对来说关系比较好的。但是Swarm本身的功能相对来说比较少,需要依赖于Docker,才能搭一个大的环境。集成的时候,我们有相似的这些东西,也有相似的问题,尤其是Docker API,比如说我先推一个,等我Run的时候,如果那个资源一直留在那儿的时候,这个资源一直留着,因为也不知道什么时候开始,不知道什么时候把容器起起来,这个CPU有可能闲了两天,还是用Mesos其他的功能来弥补。后面有Role和Quota,Swarm在很早的时候不支持Role,Swarm提供了基于Mesos的Role的支持。

现在Mesos和Swarm有一个集成,你经常会看到Kubernetes发一个新的版本,Mesos过两天就说我支持这个版本,最明显的是Kubernetes 1.1,Mesos马上跳出来说我支持1.1了。而Kubernetes最近发了1.2,但是Mesos却没有动静了。

Swarm最新版本我记不住了,Swarm现在还是以Docker为主。其实后面Unified Container对它来说是比较麻烦的一件事情。刚才我们说了Swarm会连机器,如果你用Unifed Container,最后Swarm就没有办法集成。我个人猜,过一段时间Mesos如果这个集成还再继续往前走,Docker Executor有可能会跟Swarm集成放在一块去,不用Unifed Container。其实Kubernetes、Swarm这些都是依赖于Docker镜像做出来的。这一块现在有压力,现在没有一个人跳出来说这个事情到底应该怎么办。

Pesistent Volume包括有一些Role,不知道它后续想怎么去做这些新的东西,因为Swarm现在它们的集成也不是特别的安全。

Challenges这部分,对新的东西的集成,其实这种集成现在跟的特别紧。包括像Security是集成的挑战。Mesos告诉你自己想做什么样的Security就去做,你加一个用户或者改一个权限的话,它俩的集成这一块现在其实还在调查之中,自己玩一玩还好。

Multi-Tenant我刚才也说的,该怎么做决定,尤其是多层级的资源调度。比如说有一个部门,这个部门下面有三个人,每个人用到的资源我们也是在这里做,其实这种role就是一层,如果是三级部门去做这种资源分配还是很好做的。集成我们现在两个在一起做,Mesos我们会推这些资源容器,Kubernetes这一块现在是还在做的一个事情。新的集成这个只能说有新功能找新的解决方案,按案例来做。另外,集成的时候,大家都会用到Kubernetes有自己的UI,这些都是社区的,都是分开的。所以你做Monitoring要自己去做,包括集成的时候,把它的信息全都抓起来观察整个集群的信息,不能单看一个,要把所有的东西全抓住,分析整个系统资源和环境资源,是不是使用率最高的,就是说有没有错误,或者说不是按照小范围来分的。这些都是Mesosphere自己来做的。现在在社区里面其实主要支持这张PPT的上面这三个。







IBM我们自己在做分布相关的产品,我们做了Mesos on EGO,在资源调度、分配、共享等方面有很大的优势。我们在做了Mesos on EGO以后,我们会有一个统一的资源管理系统提供资源计划,资源抢占等;其实我们在EGO里面其实已经做出来了。还有资源的分配,我们原来做企业级的产品,当时最大的客户应该有300多个Role来进行资源的分配和共享。我们现在做这种Policy,我们自己的产品跟Mesos集成,另外一个也会做一些相关的通用的功能。我主要讲的内容就是这么多。谢谢大家! 查看全部
4月17日,Mesos爱好者在北京P2联合创业办公社迎来了第四次Mesos User Group约会,下面是来自IBM马达的分享实录。

作者介绍:马达,IBM 高级软件工程师,Kubernetes/Mesos代码贡献者。

很高兴参加这次活动,之前我一直从事分布式计算;从硕士阶段就开始在做分布式资源的调度及优化这一块,当时是基于Globus做跨机群的资源调度。毕业时加入了百度,后来进入了Platform Computing公司;Platform Computing是一家有着20多年分布式经验的公司;2012年Platform Computing被IBM收购,现在做为IBM一个子部门继续从事分布式相关的工作。凭借我们在分布式方面非常丰富的经验,我们在与分布式相关的开源项目都有比较多的贡献,这次主要讲与Mesos, Kubernetes,Swarm相关,还有其它团队在做Spark相关的项目。我会介绍一下Kubernetes和Swarm与Mesos的集成;比如说在公司的选型上谈一下我自己的想法,大家可以一起交流,如果有一些其他的想法,大家也可以一起讨论。

yanse马达_k8s_mesos0001.jpg



我先简单介绍一下这三个产品,然后讲一讲为什么要把Kubernetes和Swarm集成到Mesos上;然后介绍一些集成的细节,后面还有一些遇到的Challenge。最后,我们已经有一款自己的产品,叫EGO,和Mesos比较像。后续会逐渐将我们的经验及想法贡献到社区,我们做的主要是资源的调度,提高云和集群中资源的使用效率。


yanse马达_k8s_mesos0002.jpg


首先介绍一下三个产品;Kubernetes是Google推出的,参考Google Borg的开源实现,现在支持它的有红帽、惠普、华为等企业。Swarm是Docker下的项目,Swarm的目标是100%兼容Docker API,现在已经达到90%多;有些API在分布式环境中比较难处理,后面会有介绍。Mesos是这次演讲的重点,Mesos由Mesosphere公司来支持,第二大的commiter是Twitter,第三大的社区贡献者是IBM。IBM上个季度贡献了200多代码。Mesos主要是为了将资源抽象出来,尤其是CPU这些资源抽象出来,使整个集群看起来就像一台机器;用户只要关心他使用什么样的资源就可以了,这是Mesos的作用,也就是进行资源的调度和编排,提高整个资源的使用率,减少IO,最终降低开发和运维的成本。

我原来在百度的时候,百度的运维团队非常庞大,研发要给他写一个脚本,也就是上线步骤,告诉他第一步怎么办,第二步怎么办,第三步怎么办,运维人员按照这个脚本来执行。业务上线以后,通知研发检查有没有问题。现在跟原来的同事聊,有了很大的变化,很多东西都有自动化的脚本,包括资源的利用,大概需要什么样的资源,它会自动的支撑脚本。Mesos就是做这件事,把整个资源的运维用机器做起来,减少手动。


yanse马达_k8s_mesos0003.jpg


说一下为什么集成到Mesos上,Kubernetes和Swarm最主要的目标是Container,我们希望对资源可以共享,比如说双十一,会有峰值的时候;系统在平时会有一个估值,提供基本的服务资源;剩下的机器做一些线下的分析。Mesos为这样的需求提供了一种解决方案。


“Auto-Scaling”和“不依赖于特殊网络”;这两种个原因说服力不强:网络自己用脚本就可以做了,Auto-Scaling用脚本也差不多;主要优势还是资源共享,在DCOS上资源共享相对来说比较重要。现在大部分的公司还在专注于网络和存储,可以将容器连接进来并可以访问共享数据;但是过一段时间你会发现,网络和存储不是大的问题以后,大家会关心资源的利用率;如果10台机器的资源利用率提高10%,带来的好处并不明显,但如果是1万台机器能提高10%的利用率,那集群相当于多了1000台机,带来的效果还是很明显的。


yanse马达_k8s_mesos0004.jpg


这是Kubernetes在Mesos的一个结构图,Kubernetes最左边这个地方就是Kubernetes自己本身的一些Master的东西,其实在Master最主要的是资源调度Scheduler这一块,Scheduler的资源是Mesos Master分出来的,所以在Kubernetes对Mesos来说只是其中的一个framework,Kubernetes和Spark可以共享资源。Kubernetes提供的CloudProvide很多,它可以跟其他的云厂商可以进行集成。在调度资源里面,Kubernetes还会遵循现有的调度策略。但是有一个问题,就是Scheduler在计算的时候,分配的资源只是基于Mesos给它的东西,比如Mesos分给Scheduler机器A,但是可能机器B上有一个更优的资源,它其实是拿不到的。

Scheduler拿到资源以后还是通过Mesos来启动计算节点,Kubernetes的Master相当于Mesos的一个Framework。这个计算节点的executor其实这个做的还是蛮不错的。在Kubernetes 中提供了一个Kubelet的库用于容器的管理,这个集成项目把Kubernetes和mesos的Executor做了集成,两边做的都是蛮好的。最开始以为是Slave再去起一个Kubernetes 的 Agent,那样计算节点的开销会很大。现在的解决方案相当于是把Kubernetes集中到Mesos的Executor。Kubernetes On Mesos,自己做了Executor,改了Scheduler,基本上还保持了Kubernetes原有的功能,对原来的支持还是蛮不错的。


yanse马达_k8s_mesos0005.jpg


集成的问题,其实从总体架构来看,大家都是提供了集成的方法,但彼此的集成方案很难统一。而且在概念和功能上也有很大的区别,比如说Namespace和Quota,这是Kubernetes自己的功能,这两个彼此的资源都看不到。但是这个集成方案中,他并没有映射到Mesos自己的Role,整个Kubernetes映射成一个Role,这个Role能拿到多少Quota,就是Kubernetes 的资源。


另外就是刚才说的关于Optimistic Offer、Revocable resources。所谓资源共享,是Mesos上的一个Framework可以把自己不用的资源借出去,但是当我要的时候,我应该可以把资源抢占回来。而且当资源被抢占的时候需要给出一定的时间进行清理。Optimistic Offer现在会直接把资源抢回来,而且没有一个接口通知相应的作业进行后续的清理工作。比如说我要删某一个进程我应该告诉你怎么删,我要做一些东西。Kubernetes没有对Revocable resources做这些相应的处理。

另外,Mesos自己对Revocable Resources的支持力度也不是特别大。现在支持一种Revocable Resource:当机器分出去的Resources,但是没有用,也可以做Revocable resources。现在和Committer交流,我们经常提这个功能,他们并没有意识到资源的使用率对整个集群有多重要。集成的时候,Unified Container,把镜像下下来去解析。作为Unified Container,它并没有提供API, Kubernetes要用Docker的API完成这些工作,如果想把这些引到你的Unified Container,就意味着你的Unified Container要支持Docker的API,这对Mesos来说是很重要的。Docker的API最大问题是并没有一个统一的标准,它的镜像是可以下载下来的执行,但是Docker本身的API没有标准,Mesos的Unified Container要去兼容它的API是一件很繁重的工作。

另外就是Persistent Volume,Mesos自己提供了Persistent Volume,这个作业在机器上重启以后,这个资源所使用的文件会被留下来;如果没有Persistent Volume,则沙箱里的数据都会被删掉,这一块并没有跟Kubernetes自己的Persistent Volume集成在一块,Kubernetes自己的Persistent Volume做的事情是把Volume做成一种资源,比如说是1G或者2G,然后可以请求和作用这些资源;其实跟Mesos的功能是从想法上是完全一致的。但这里有一个效率的问题,Kubernetes自己Persistent Volume能够拿到全局所有的资源,但是如果基于Mesos的话,只能拿到Mesos固定的一些资源,所以这个Kubernetes只能基于不是最优集成拿到最好。其实最主要的大家都有自己的概念和想法,是没有一个人去做两边的集成,大家都认为应该跟随,到底谁应该跟随谁。

yanse马达_k8s_mesos0006.jpg


Swarm相对来说还简单一点,Swarm对于资源还好,最开始的时候其实Swarm他会去发一个请求,这个请求还是自己Mesos的系统,他会自己做一个Schedule,告诉Master。因为Swarm运行Docker UPS,有一个路径,所以这个东西资源分配给Swarm Cluster,这个资源分到Swarm,资源分到这,Swarm会告诉他在哪一台机器上,然后Swarm会连这台机器上的Container。再取那个信息,整个的过程是达到Swarm拿到这个机器以后会告诉Master,Run就基于Mesos自己对Docker的支持。透过这个信息也会告诉你连这个Docker,把这个信息盖了,这个集成会比较简单一点。

Swarm这一块相对来说做的稍微好一些,它会抽象成一个集群,它跟Mesos相对来说关系比较好的。但是Swarm本身的功能相对来说比较少,需要依赖于Docker,才能搭一个大的环境。集成的时候,我们有相似的这些东西,也有相似的问题,尤其是Docker API,比如说我先推一个,等我Run的时候,如果那个资源一直留在那儿的时候,这个资源一直留着,因为也不知道什么时候开始,不知道什么时候把容器起起来,这个CPU有可能闲了两天,还是用Mesos其他的功能来弥补。后面有Role和Quota,Swarm在很早的时候不支持Role,Swarm提供了基于Mesos的Role的支持。

现在Mesos和Swarm有一个集成,你经常会看到Kubernetes发一个新的版本,Mesos过两天就说我支持这个版本,最明显的是Kubernetes 1.1,Mesos马上跳出来说我支持1.1了。而Kubernetes最近发了1.2,但是Mesos却没有动静了。

Swarm最新版本我记不住了,Swarm现在还是以Docker为主。其实后面Unified Container对它来说是比较麻烦的一件事情。刚才我们说了Swarm会连机器,如果你用Unifed Container,最后Swarm就没有办法集成。我个人猜,过一段时间Mesos如果这个集成还再继续往前走,Docker Executor有可能会跟Swarm集成放在一块去,不用Unifed Container。其实Kubernetes、Swarm这些都是依赖于Docker镜像做出来的。这一块现在有压力,现在没有一个人跳出来说这个事情到底应该怎么办。

Pesistent Volume包括有一些Role,不知道它后续想怎么去做这些新的东西,因为Swarm现在它们的集成也不是特别的安全。

Challenges这部分,对新的东西的集成,其实这种集成现在跟的特别紧。包括像Security是集成的挑战。Mesos告诉你自己想做什么样的Security就去做,你加一个用户或者改一个权限的话,它俩的集成这一块现在其实还在调查之中,自己玩一玩还好。

Multi-Tenant我刚才也说的,该怎么做决定,尤其是多层级的资源调度。比如说有一个部门,这个部门下面有三个人,每个人用到的资源我们也是在这里做,其实这种role就是一层,如果是三级部门去做这种资源分配还是很好做的。集成我们现在两个在一起做,Mesos我们会推这些资源容器,Kubernetes这一块现在是还在做的一个事情。新的集成这个只能说有新功能找新的解决方案,按案例来做。另外,集成的时候,大家都会用到Kubernetes有自己的UI,这些都是社区的,都是分开的。所以你做Monitoring要自己去做,包括集成的时候,把它的信息全都抓起来观察整个集群的信息,不能单看一个,要把所有的东西全抓住,分析整个系统资源和环境资源,是不是使用率最高的,就是说有没有错误,或者说不是按照小范围来分的。这些都是Mesosphere自己来做的。现在在社区里面其实主要支持这张PPT的上面这三个。


yanse马达_k8s_mesos0010.jpg


IBM我们自己在做分布相关的产品,我们做了Mesos on EGO,在资源调度、分配、共享等方面有很大的优势。我们在做了Mesos on EGO以后,我们会有一个统一的资源管理系统提供资源计划,资源抢占等;其实我们在EGO里面其实已经做出来了。还有资源的分配,我们原来做企业级的产品,当时最大的客户应该有300多个Role来进行资源的分配和共享。我们现在做这种Policy,我们自己的产品跟Mesos集成,另外一个也会做一些相关的通用的功能。我主要讲的内容就是这么多。谢谢大家!

centos7 搭建Docker Registry

zhaoshaolin 发表了文章 • 0 个评论 • 1106 次浏览 • 2016-04-22 15:47 • 来自相关话题

registry2.x版本比1版本的速度快而且加了认证

环境规划:

192.168.0.167 Registry
192.168.0.168 client

192.168.0.167

1.安装并启动docker

1
2
3
4
5
6
7
8
9
10
11
12
13
#添加yum源
[root@Registry ~]# sudo tee /etc/yum.repos.d/docker.repo <<-'EOF'
[dockerrepo]
name=Docker Repository
baseurl=
enabled=1
gpgcheck=1 
gpgkey=
 EOF
#安装Docker
[root@Registry ~]# yum install docker-engine
#启动Dcoekr
[root@Registry ~]# service docker start

2.拉取本地私有仓库registry    #registry:2.1.1是2版本

1
[root@Registry ~]# docker pull registry:2.1.1

3.基于私有仓库镜像运行容器

1
[root@Registry ~]# docker run -d -v /opt/registry:/var/lib/registry -p 5000:5000 --restart=always --name registry registry:2.1.1

5.访问私有仓库

1
2
[root@Registry ~]# curl 127.0.0.1:5000/v2
{"num_results": 0, "query": "", "results": []}    #私有仓库为空,没有提交新镜像到仓库中

6.从Docker HUB 上拉取一个镜像测试

1
[root@Registry ~]# docker pull busybox

7.创建镜像链接为基础镜像打个标签

1
[root@Registry ~]#  docker tag busybox 192.168.0.167:5000/busybox

8.修改docker配置文件,指定私有仓库url

1
2
3
4
5
#修改配置文件
[root@Registry ~]#  vim /lib/systemd/system/docker.service 
ExecStart=/usr/bin/docker daemon -H fd://  --insecure-registry 192.168.0.98:5000
#重启Docker
[root@Registry ~]# systemctl daemon-reload  && systemctl restart docker

9.上传镜像到本地私有仓库

1
docker push 192.168.0.167:5000/busybox

10.查看私有仓库是否有对应的镜像

1
浏览器访问 192.168.0.167:5000/v2/_catalog

192.168.0.168

1.安装并启动docker

····省略

2.修改docker配置文件,指定私有仓库url

1
2
3
4
[root@localhost ~]# vim /lib/systemd/system/docker.service 
修改此行
ExecStart=/usr/bin/docker daemon -H fd://  --insecure-registry 192.168.0.98:5000'
[root@localhost ~]# systemctl daemon-reload  && systemctl restart docker

3.测试,下载刚才上传的镜像

1
[root@localhost ~]# docker pull 192.168.0.167:5000/busybox 查看全部
registry2.x版本比1版本的速度快而且加了认证

环境规划:

192.168.0.167 Registry
192.168.0.168 client

192.168.0.167

1.安装并启动docker

1
2
3
4
5
6
7
8
9
10
11
12
13
#添加yum源
[root@Registry ~]# sudo tee /etc/yum.repos.d/docker.repo <<-'EOF'
[dockerrepo]
name=Docker Repository
baseurl=
enabled=1
gpgcheck=1 
gpgkey=
 EOF
#安装Docker
[root@Registry ~]# yum install docker-engine
#启动Dcoekr
[root@Registry ~]# service docker start

2.拉取本地私有仓库registry    #registry:2.1.1是2版本

1
[root@Registry ~]# docker pull registry:2.1.1

3.基于私有仓库镜像运行容器

1
[root@Registry ~]# docker run -d -v /opt/registry:/var/lib/registry -p 5000:5000 --restart=always --name registry registry:2.1.1

5.访问私有仓库

1
2
[root@Registry ~]# curl 127.0.0.1:5000/v2
{"num_results": 0, "query": "", "results": []}    #私有仓库为空,没有提交新镜像到仓库中

6.从Docker HUB 上拉取一个镜像测试

1
[root@Registry ~]# docker pull busybox

7.创建镜像链接为基础镜像打个标签

1
[root@Registry ~]#  docker tag busybox 192.168.0.167:5000/busybox

8.修改docker配置文件,指定私有仓库url

1
2
3
4
5
#修改配置文件
[root@Registry ~]#  vim /lib/systemd/system/docker.service 
ExecStart=/usr/bin/docker daemon -H fd://  --insecure-registry 192.168.0.98:5000
#重启Docker
[root@Registry ~]# systemctl daemon-reload  && systemctl restart docker

9.上传镜像到本地私有仓库

1
docker push 192.168.0.167:5000/busybox

10.查看私有仓库是否有对应的镜像

1
浏览器访问 192.168.0.167:5000/v2/_catalog

192.168.0.168

1.安装并启动docker

····省略

2.修改docker配置文件,指定私有仓库url

1
2
3
4
[root@localhost ~]# vim /lib/systemd/system/docker.service 
修改此行
ExecStart=/usr/bin/docker daemon -H fd://  --insecure-registry 192.168.0.98:5000'
[root@localhost ~]# systemctl daemon-reload  && systemctl restart docker

3.测试,下载刚才上传的镜像

1
[root@localhost ~]# docker pull 192.168.0.167:5000/busybox

数人云 | 分布式架构实践的深圳之约,不负春光不负卿

宁静胡同 发表了文章 • 0 个评论 • 348 次浏览 • 2016-04-14 13:02 • 来自相关话题

数人云技术分享课从第一期的 “ Hold 住高并发,唯架构与运维不可辜负” 到第二期的 “ 进阶百万并发背后的架构实践 ”,邀请了一线互联网金融、电商的架构、运维大牛来分享实践经验,旨在为开发者提供最接地气的观点和干货。

世界那么大,小数决定出去看看那些未曾谋面的技术小伙伴,不能让友谊的小船说翻就翻:) 4月23日,数人云技术分享课将来到深圳,邀请了平安科技、Coding 的技术大牛以及运维界大拿老王(王津银)一起聊聊分布式架构实践的那些事儿。

 与大牛面对面  

王津银,优维科技创始人
07 年进入腾讯公司接触运维,经历服务器从百到万的运维历程,先后在 YY 和 UC 参与不同业务形态的运维,期间带过前端运维、数据存储运维、YY 语音、游戏 运维、运维研发等多种运维团队,对运维有着全面的理解。极力倡导互联网价值运维理念,即面向用户的价值是由自动化平台交付传递,同时由数据化来提炼和衡量。现创办优维科技公司,旨在缩短企业到达互联网运维的路径。

陈秋浩,平安科技资深中间件工程师
Padis 平安分布式平台项目经理,2011年加入平安科技,先后活跃于基础架构部的服务交付和事件处理一线。平时喜欢钻研工作中遇到的技术难题,也爱好学习开源技术,开发自动化小工具。

孙宇聪,Coding CTO
现负责 Coding.net 平台的技术方案与架构。 曾任 Google  SeniorSiteReliblity  Engineer (2007-2014)  就职于 Moutain View 总部,  曾参与设计维护 Youtube 视频转码/存储/直播管理系统(系统吞吐量超过1Peta bytes/月), 参与研发管理全球 Youtube CDN 网络(峰值流量~10Tbps), 后就职于 Google 内部云计算部门开发维护全球百万台服务器生命周期管理系统及任务管理系统。

谢乐冰,数人云 COO   
在德国工作十年,回国后加入惠普电信运营商部门,拥有多年项目经验和创业公司工作经验。在数人云负责产品售前和运营,专注行业的技术应用领域,为金融、电信、电商等行业提供服务。

 议程安排  
13:30 - 14:00    签到
14:00 - 14:15    开场
14:15 - 14:55  《Mesos在传统金融企业的实践——平安科技 Padis 平台的成长史》陈秋浩
14:55 - 15:35  《基于 Mesos+Docker 的分布式架构实践》谢乐冰 
15:35 - 16:15  《Google Borg 系统 与 Coding Docker 实践》孙宇聪
16:15 - 16:45  《DevOps 全栈运维平台的设计与实现 》王津银
 
时间:4月23日(周六) 13:00 - 17:00
 
深圳 3W 咖啡源兴店
深圳市南山区科技园北区松坪山路 1 号源兴科技大厦东座 1 层(北环大道与松坪山路交汇口)





 
活动报名链接:http://www.huodongxing.com/event/9330304410200#rd 查看全部

数人云技术分享课从第一期的 “ Hold 住高并发,唯架构与运维不可辜负” 到第二期的 “ 进阶百万并发背后的架构实践 ”,邀请了一线互联网金融、电商的架构、运维大牛来分享实践经验,旨在为开发者提供最接地气的观点和干货。

世界那么大,小数决定出去看看那些未曾谋面的技术小伙伴,不能让友谊的小船说翻就翻:) 4月23日,数人云技术分享课将来到深圳,邀请了平安科技、Coding 的技术大牛以及运维界大拿老王(王津银)一起聊聊分布式架构实践的那些事儿。

 与大牛面对面  

王津银,优维科技创始人
07 年进入腾讯公司接触运维,经历服务器从百到万的运维历程,先后在 YY 和 UC 参与不同业务形态的运维,期间带过前端运维、数据存储运维、YY 语音、游戏 运维、运维研发等多种运维团队,对运维有着全面的理解。极力倡导互联网价值运维理念,即面向用户的价值是由自动化平台交付传递,同时由数据化来提炼和衡量。现创办优维科技公司,旨在缩短企业到达互联网运维的路径。

陈秋浩,平安科技资深中间件工程师
Padis 平安分布式平台项目经理,2011年加入平安科技,先后活跃于基础架构部的服务交付和事件处理一线。平时喜欢钻研工作中遇到的技术难题,也爱好学习开源技术,开发自动化小工具。

孙宇聪,Coding CTO
现负责 Coding.net 平台的技术方案与架构。 曾任 Google  SeniorSiteReliblity  Engineer (2007-2014)  就职于 Moutain View 总部,  曾参与设计维护 Youtube 视频转码/存储/直播管理系统(系统吞吐量超过1Peta bytes/月), 参与研发管理全球 Youtube CDN 网络(峰值流量~10Tbps), 后就职于 Google 内部云计算部门开发维护全球百万台服务器生命周期管理系统及任务管理系统。

谢乐冰,数人云 COO   
在德国工作十年,回国后加入惠普电信运营商部门,拥有多年项目经验和创业公司工作经验。在数人云负责产品售前和运营,专注行业的技术应用领域,为金融、电信、电商等行业提供服务。

 议程安排  
13:30 - 14:00    签到
14:00 - 14:15    开场
14:15 - 14:55  《Mesos在传统金融企业的实践——平安科技 Padis 平台的成长史》陈秋浩
14:55 - 15:35  《基于 Mesos+Docker 的分布式架构实践》谢乐冰 
15:35 - 16:15  《Google Borg 系统 与 Coding Docker 实践》孙宇聪
16:15 - 16:45  《DevOps 全栈运维平台的设计与实现 》王津银
 
时间:4月23日(周六) 13:00 - 17:00
 
深圳 3W 咖啡源兴店
深圳市南山区科技园北区松坪山路 1 号源兴科技大厦东座 1 层(北环大道与松坪山路交汇口)

793055168495142026.jpg

 
活动报名链接:http://www.huodongxing.com/event/9330304410200#rd

报名倒计时 | 北京 Mesos User Group No.4 聚会

宁静胡同 发表了文章 • 0 个评论 • 311 次浏览 • 2016-04-14 13:01 • 来自相关话题

Hello,北京的 Mesos 爱好者们,时隔 4 个月,让我们愉快的进行第四次聚会吧,生活不止眼前的苟且,还有诗和远方的代码......
活动全程由老肖(肖德时,前红帽 Engineering Service 部门内部工具组 Team Leader,Docker/Mesos 社区代码贡献者,现数人云 CTO)主持并分享实战经验,约下老肖?就在北京 Mesos User Group No.4 聚会:)

看看谁带来了分享

马达,IBM 工程师,Mesos 代码贡献者

Agenda

K8S/Swarm/Mesos Introduction

Why integrates with Mesos?

Architecture Overview

K8S/Swarm on Mesos

Challenges

IBM Mesos on EGO

庞铮,数人云运维负责人

15 年以上运维工作经验。就职过宏碁戏谷、第三波、SQUARE ENIX CO., LTD.等。2015年加入数人云,从事数人云平台运维管理。

徐磊,去哪儿网高级运维开发工程师

负责实时日志平台的建设和维护工作,对 Mesos 有深入研究,参与《Mesos 中文文档》的翻译和整理工作,曾任职于Red Hat。

张晓光,OneAPM软件工程师

目前就职于公司基础架构部从事 Java、Scala 开发,负责公司公共服务研发以及DevOps实践。之前在业务部门带领团队完成了公司多条产品线,积累了丰富的研发和运维经验。


议程安排

13:30 - 14:00    签到
14:00 - 14:15    开场
14:15 - 14:55   《Kubernetes/Swarm on Mesos》马达
14:55 - 15:35   《基于Mesos+Docker的分布式百万并发测试实践》庞铮 
15:35 - 16:15   《从运维角度思考Mesos Framework的部署方式》徐磊
16:15 - 16:45    《基于 Marathon Event Bus 的服务发现组件》 张晓光
16:45 - 17:15    《老肖有话说》肖德时



时间:4月17日 14:00 - 17:15
地点:P2 联合创业办公社 • 北京市海淀区中关村 e 世界 A 座 B2
点击链接进入活动报名页面:
http://www.huodongxing.com/event/7329683300200#rd 查看全部

Hello,北京的 Mesos 爱好者们,时隔 4 个月,让我们愉快的进行第四次聚会吧,生活不止眼前的苟且,还有诗和远方的代码......
活动全程由老肖(肖德时,前红帽 Engineering Service 部门内部工具组 Team Leader,Docker/Mesos 社区代码贡献者,现数人云 CTO)主持并分享实战经验,约下老肖?就在北京 Mesos User Group No.4 聚会:)

看看谁带来了分享

马达,IBM 工程师,Mesos 代码贡献者

Agenda

K8S/Swarm/Mesos Introduction

Why integrates with Mesos?

Architecture Overview

K8S/Swarm on Mesos

Challenges

IBM Mesos on EGO

庞铮,数人云运维负责人

15 年以上运维工作经验。就职过宏碁戏谷、第三波、SQUARE ENIX CO., LTD.等。2015年加入数人云,从事数人云平台运维管理。

徐磊,去哪儿网高级运维开发工程师

负责实时日志平台的建设和维护工作,对 Mesos 有深入研究,参与《Mesos 中文文档》的翻译和整理工作,曾任职于Red Hat。

张晓光,OneAPM软件工程师

目前就职于公司基础架构部从事 Java、Scala 开发,负责公司公共服务研发以及DevOps实践。之前在业务部门带领团队完成了公司多条产品线,积累了丰富的研发和运维经验。


议程安排

13:30 - 14:00    签到
14:00 - 14:15    开场
14:15 - 14:55   《Kubernetes/Swarm on Mesos》马达
14:55 - 15:35   《基于Mesos+Docker的分布式百万并发测试实践》庞铮 
15:35 - 16:15   《从运维角度思考Mesos Framework的部署方式》徐磊
16:15 - 16:45    《基于 Marathon Event Bus 的服务发现组件》 张晓光
16:45 - 17:15    《老肖有话说》肖德时



时间:4月17日 14:00 - 17:15
地点:P2 联合创业办公社 • 北京市海淀区中关村 e 世界 A 座 B2
点击链接进入活动报名页面:
http://www.huodongxing.com/event/7329683300200#rd

创业技术联盟 | 【北京】公有云(O2O、电商、社交平台)案例分享会,CTO,纯技术,硬通货,成员募集中

gyo629 发表了文章 • 0 个评论 • 337 次浏览 • 2016-04-01 17:52 • 来自相关话题

【街区活动】
活动主题:公有云实践沙龙
活动时间:4月9日 14:00-17:00(13:30开始签到)
活动地点:Binggo Cafe一层大厅
活动介绍:爱大厨、tutu、家居在线CTO,分享公有云选型实战经验
参会请联系QQ:3383070003
 
【街区活动】
活动主题:公有云实践沙龙
活动时间:4月9日 14:00-17:00(13:30开始签到)
活动地点:Binggo Cafe一层大厅
活动介绍:爱大厨、tutu、家居在线CTO,分享公有云选型实战经验
参会请联系QQ:3383070003
 

PPT分享 | 数人云“百万并发” 背后的架构实践

宁静胡同 发表了文章 • 0 个评论 • 617 次浏览 • 2016-03-28 19:13 • 来自相关话题

3 月 27 日,“百万并发” 升级 2.0 讨论,数人云邀请小米、唯品会、云智慧的资深工程师一起分享支撑 “百万并发” 背后的架构实践。更加精彩的议题,更加干货的内容,依旧座无虚席的现场,小数邀你共享这场技术的盛宴——


PPT下载地址:http://pan.baidu.com/s/1pLIfWSV













嘉宾分享

《小米:OpenFalcon 应对并发的一些手段》






秦晓辉,小米运维研发技术负责人

互联网公司监控解决方案  OpenFalcon 主程,国内第一套开源 PaaS 平台 DINP 主程,企业级业务监控 Minos 作者,Gopher,现负责小米运维平台的搭建。关注运维自动化、PaaS 领域。

内容框架:

* OpenFalcon简介
* OpenFalcon中的并发场景及应对手段
* 数据采集的推拉抉择
* 中间节点快速转发与容错
* 一致性哈希分片提高吞吐容量
* 监控数据与报警策略的快速匹配
* 数据延迟写入减少rrd文件打开次数
* 报警事件按优先级入队列缓冲
* 通过限制worker数目保护后端发送接口
* 小总结

《数人云:分布式百万并发测试实践》








庞铮,数人云运维负责人

15 年以上运维工作经验。就职过宏碁戏谷、第三波、SQUARE ENIX CO., LTD.等。2015年加入数人云,从事数人云平台运维管理,在 Mesos+Docker 应用实践方面有深入研究。

内容框架:

* 什么是OCP
* 为什么要做百万压测
* 基础部署
* 发布压测应用
* 资源不够百万压测怎么办
* HA单机非超线程
* HA单机超线程
* HA超线程非 Docker 化
* 单机 Nginx + Lua NAT 模式
* 向百万继续前进

《唯品会:分布式服务框架实践与容器化演进》








邱戈川,唯品会分布式架构平台产品经理

16 个年头的 IT 老兵,除了销售和老板角色,做过 IT 中的各种角色,游走于架构与产品间。关注 Docker,  Mesos 等容器化技术领域的实践。主导的分布式服务框架已经广泛用于唯品会各大核心业务系统,以高性能、低延迟广受好评。现任唯品会( VIP.COM )基础架构部分布式服务框架、定时任务调度系统以及容器化管理平台产品经理。

内容框架:

* Part I: 分布式服务框架实践
* 什么是服务化/微服务
* 开源RPC/REST框架与服务化框架的Gap
* 注册与发现
* VIP服务化实践心得
* Binary RPC Vs. HTTP/JSON
* 调优“黑科技”
* Zookeeper的大规模部署
* Part II: 容器化演进
* VIP容器化平台概貌
* 容器化流程

《云智慧:应用系统“承压”测试实践》








陈书德,云智慧技术中心(Technical Center)资深技术咨询经理

在加入云智慧之前,拥有超过 6 年的 IT 行业咨询和项目管理经验,企业级方案顾问。拥有政企、旅游、医疗、教育和电商行业咨询经验,是资深的行业IT、云计算和应用性能解决方案顾问。现负责云智慧技术咨询的工作。

内容框架:

* 背景
* “双11 电商压力测试”
* 基于云的压力测试
* 新模式下的产品测试及发布过程
* 20用户并发性能指标汇总
* 单个请求的平均响应时间和带宽流量
* 测试指标分析-错误详情
* 典型案例分析
* 统计交易失败的种类和数量



 
活动花絮













大家提问积极踊跃








茶歇讨论依然火热










数人云CEO王璞(左)与唯品会嘉宾进行交流

另外,嘉宾演讲实录也将在近期陆续放出,敬请关注! 查看全部


3 月 27 日,“百万并发” 升级 2.0 讨论,数人云邀请小米、唯品会、云智慧的资深工程师一起分享支撑 “百万并发” 背后的架构实践。更加精彩的议题,更加干货的内容,依旧座无虚席的现场,小数邀你共享这场技术的盛宴——



PPT下载地址:http://pan.baidu.com/s/1pLIfWSV



现场总1.JPG


现场总2.JPG


嘉宾分享

《小米:OpenFalcon 应对并发的一些手段》

嘉宾1.JPG


秦晓辉,小米运维研发技术负责人

互联网公司监控解决方案  OpenFalcon 主程,国内第一套开源 PaaS 平台 DINP 主程,企业级业务监控 Minos 作者,Gopher,现负责小米运维平台的搭建。关注运维自动化、PaaS 领域。

内容框架:

* OpenFalcon简介
* OpenFalcon中的并发场景及应对手段
* 数据采集的推拉抉择
* 中间节点快速转发与容错
* 一致性哈希分片提高吞吐容量
* 监控数据与报警策略的快速匹配
* 数据延迟写入减少rrd文件打开次数
* 报警事件按优先级入队列缓冲
* 通过限制worker数目保护后端发送接口
* 小总结

《数人云:分布式百万并发测试实践》


嘉宾2.JPG



庞铮,数人云运维负责人

15 年以上运维工作经验。就职过宏碁戏谷、第三波、SQUARE ENIX CO., LTD.等。2015年加入数人云,从事数人云平台运维管理,在 Mesos+Docker 应用实践方面有深入研究。

内容框架:

* 什么是OCP
* 为什么要做百万压测
* 基础部署
* 发布压测应用
* 资源不够百万压测怎么办
* HA单机非超线程
* HA单机超线程
* HA超线程非 Docker 化
* 单机 Nginx + Lua NAT 模式
* 向百万继续前进

《唯品会:分布式服务框架实践与容器化演进》


嘉宾4.JPG



邱戈川,唯品会分布式架构平台产品经理

16 个年头的 IT 老兵,除了销售和老板角色,做过 IT 中的各种角色,游走于架构与产品间。关注 Docker,  Mesos 等容器化技术领域的实践。主导的分布式服务框架已经广泛用于唯品会各大核心业务系统,以高性能、低延迟广受好评。现任唯品会( VIP.COM )基础架构部分布式服务框架、定时任务调度系统以及容器化管理平台产品经理。

内容框架:

* Part I: 分布式服务框架实践
* 什么是服务化/微服务
* 开源RPC/REST框架与服务化框架的Gap
* 注册与发现
* VIP服务化实践心得
* Binary RPC Vs. HTTP/JSON
* 调优“黑科技”
* Zookeeper的大规模部署
* Part II: 容器化演进
* VIP容器化平台概貌
* 容器化流程

《云智慧:应用系统“承压”测试实践》


嘉宾3.JPG



陈书德,云智慧技术中心(Technical Center)资深技术咨询经理

在加入云智慧之前,拥有超过 6 年的 IT 行业咨询和项目管理经验,企业级方案顾问。拥有政企、旅游、医疗、教育和电商行业咨询经验,是资深的行业IT、云计算和应用性能解决方案顾问。现负责云智慧技术咨询的工作。

内容框架:

* 背景
* “双11 电商压力测试”
* 基于云的压力测试
* 新模式下的产品测试及发布过程
* 20用户并发性能指标汇总
* 单个请求的平均响应时间和带宽流量
* 测试指标分析-错误详情
* 典型案例分析
* 统计交易失败的种类和数量



 
活动花絮


提问2.JPG


提问1.JPG



大家提问积极踊跃



交流2.JPG


茶歇讨论依然火热



交流1.JPG




数人云CEO王璞(左)与唯品会嘉宾进行交流

另外,嘉宾演讲实录也将在近期陆续放出,敬请关注!

致产品经理: 持续集成、持续交付、持续部署和DevOps

宁静胡同 发表了文章 • 8 个评论 • 510 次浏览 • 2016-03-28 14:34 • 来自相关话题

即使产品经理每周都在与开发团队讨论新功能,团队协作紧密无间,在不断的PUSH下,新功能比以往看起来上线和更新速度快多了。但换个角度,从用户层面,其实仍然是一个缓慢的过程。那对比Flickr 和 Google这样的公司能够现在一天实现100次的更新迭代频率,这到底是怎么做到的呢?

毋庸置疑,这就是通过CI/CD在实际生产环境下带来的好处和便利,作为产品经理, 对于CI/CD概念已经并不陌生,但即使想要通过它们来给现有产品更新带来改变,仍然充满担忧顾虑和担心。 那么下面的内容,将帮助产品经理打消疑虑。

持续集成(Continuous Integration ,CI)

在传统软件开发过程中,集成通常发生在每个人都完成了各自的工作之后。在项目尾声阶段,通常集成还要痛苦的花费数周或者数月的时间来完成。持续集成是一个将集成提前至开发周期的早期阶段的实践方式,让构建、测试和集成代码更经常反复地发生。

持续集成意味着一个在家用笔记本编写代码的开发人员(嘿,史蒂夫)和另一个在办公室编程的开发人员(嘿,安妮)可以为同样的产品分别地编写软件,将其改动整合在一个叫做源存储库的地方。他们可以从各自编写的部分构建出组合的软件,并且按照他们期望的方式来测试软件。

开发人员通常使用一种叫做IC Server 的工具来做构建和集成。持续集成要求史蒂夫和安妮能够自测代码。分别测试各自代码来保证它能够正常工作,这些测试通常被称为单元测试(Unit tests)。

代码集成以后,当所有的单元测试通过,史蒂夫和安妮就得到了一个绿色构建(green build)。这表明他们已经成功地集成在一起,代码正按照测试预期地在工作。然而,尽管集成代码能够成功地一起工作了,它仍未为生产做好准备,因为它没有在类似生产的环境中测试和工作。在下面持续交付部分你可以了解到持续集成后面发生了什么。






考虑到实践持续集成,史蒂夫和安妮必须频繁地登记主代码仓库、集成和测试他们的代码。通常一小时很多次,并且每天最少一次。

持续集成的好处是,集成不再是个头疼事。软件在一直被编写和集成。在持续集成之前,集成发生在创建过程的结尾阶段,一次性完成,并且不知道要耗时多久。而现在持续集成,每天都融入到了工作方式当中。

持续交付(Continuous Delivery,CD)

让我们说回到我们的两位开发人员,史蒂夫和安妮。持续交付意味着每次史蒂夫或安妮修改、整合和构建代码时,也同时在类似于生产环境中自动测试了这段代码。我们通常将这个在不同环境发布和测试的过程叫做部署流水线。通常部署流水线有一个开发环境,一个测试环境,一个准生产环境,但是这些阶段会根据不同的团队、产品和组织而变化。例如,Mingle团队有一个阶段叫做“纸杯蛋糕”的准生产环境,而Etsy的准生产环境叫做“公主”。






在不同的环境下,安妮和史蒂夫写的代码被分别进行测试。当代码部署到生产环境它就开始了工作,这给予了他们更多的信心。并且只有当代码通过前一个环境的测试才会进入到下一个部署流水线的环境当中去。通过这种方式,安妮和史蒂夫将会从每个环境中测试并得到新的反馈,如果有失败,他们也可以在代码被应用到生产环境之前更加容易地发现问题并且修正它。

持续学习

这个过程对于业务决策者来说非常重要。它意味着如果安妮的代码通过了所有环境的测试,并将准备投入生产当中。你需要决定你的用户是否立即能够用上它。我们是否希望这个绿色构建现在投入生产?是的!一旦你的开发者完成了构建,那么一个全新的、充分测试的、可以工作的应用已经为你的用户准备好了。

持续部署(Continuous Deployment)

史蒂夫或者安妮所做的每个改动,都是通过测试环节,然后自动投入生产的实践过程。关于这个概念这个PDF有一个很棒的阐释:(http://www.paulhammond.org/201 ... k.pdf)。为了达成持续部署,你首先需要持续交付,所以这不是决定哪个优先级更高的二选一。无论如何,持续交付对于业务的决策带来更大的敏捷性,这才是真正实现业务导向的捷径。






开发运维(DevOps)

 “DevOps”这个词是“development”和“operations”的组合。DevOps已经上升为一种文化,它促使开发人员(史蒂夫和安妮你们快回来)和其他运维人员协同工作。具体地说,在软件交付和部署的过程中沟通合作,为了能够更快速更可靠地发布质量更好的应用。

拥有DevOps文化的团队通常有一个共同的特征:熟练的多技能团队(史蒂夫,安妮和乔伊都在同一团队里),高水平的测试和自动发布(按持续交付的方式)以及团队成员之间共同的目标。






一种方式是我们的开发朋友史蒂夫和安妮将同运维人员乔伊一起工作将应用交付给生产,而不是只将他们的代码“移交”给乔伊来发布。同样地,史蒂夫、安妮和乔伊都将作为共同负责所有产品支持和维护的服务团体的一部分,而不是仅由运维团队负责支持。

你还将看到自动化的实践对于持续交付和DevOps越来越重要。这是为了从持续交付和DevOps中实现可重复的、固定的和成功的应用发布流程,来避免人工处理非常容易出错、而且效率低下的问题。






DevOps文化通常和持续交付关联起来,因为他们的目标都是为了提升开发团队和运维团队之间的协作效率,都使用自动化进程来更快速、更频繁、更可靠地构建、测试和发布应用。这正是我们想要的。

接下来呢?

产品经理们已经逐步看到持续集成、持续交付和DevOps的诸多好处,那么拥抱DevOps吧,祝大家周末愉快,下周见:)


原文链接:https://wanqu.co/amp/p/2862 查看全部
即使产品经理每周都在与开发团队讨论新功能,团队协作紧密无间,在不断的PUSH下,新功能比以往看起来上线和更新速度快多了。但换个角度,从用户层面,其实仍然是一个缓慢的过程。那对比Flickr 和 Google这样的公司能够现在一天实现100次的更新迭代频率,这到底是怎么做到的呢?

毋庸置疑,这就是通过CI/CD在实际生产环境下带来的好处和便利,作为产品经理, 对于CI/CD概念已经并不陌生,但即使想要通过它们来给现有产品更新带来改变,仍然充满担忧顾虑和担心。 那么下面的内容,将帮助产品经理打消疑虑。

持续集成(Continuous Integration ,CI)

在传统软件开发过程中,集成通常发生在每个人都完成了各自的工作之后。在项目尾声阶段,通常集成还要痛苦的花费数周或者数月的时间来完成。持续集成是一个将集成提前至开发周期的早期阶段的实践方式,让构建、测试和集成代码更经常反复地发生。

持续集成意味着一个在家用笔记本编写代码的开发人员(嘿,史蒂夫)和另一个在办公室编程的开发人员(嘿,安妮)可以为同样的产品分别地编写软件,将其改动整合在一个叫做源存储库的地方。他们可以从各自编写的部分构建出组合的软件,并且按照他们期望的方式来测试软件。

开发人员通常使用一种叫做IC Server 的工具来做构建和集成。持续集成要求史蒂夫和安妮能够自测代码。分别测试各自代码来保证它能够正常工作,这些测试通常被称为单元测试(Unit tests)。

代码集成以后,当所有的单元测试通过,史蒂夫和安妮就得到了一个绿色构建(green build)。这表明他们已经成功地集成在一起,代码正按照测试预期地在工作。然而,尽管集成代码能够成功地一起工作了,它仍未为生产做好准备,因为它没有在类似生产的环境中测试和工作。在下面持续交付部分你可以了解到持续集成后面发生了什么。

1.jpg


考虑到实践持续集成,史蒂夫和安妮必须频繁地登记主代码仓库、集成和测试他们的代码。通常一小时很多次,并且每天最少一次。

持续集成的好处是,集成不再是个头疼事。软件在一直被编写和集成。在持续集成之前,集成发生在创建过程的结尾阶段,一次性完成,并且不知道要耗时多久。而现在持续集成,每天都融入到了工作方式当中。

持续交付(Continuous Delivery,CD)

让我们说回到我们的两位开发人员,史蒂夫和安妮。持续交付意味着每次史蒂夫或安妮修改、整合和构建代码时,也同时在类似于生产环境中自动测试了这段代码。我们通常将这个在不同环境发布和测试的过程叫做部署流水线。通常部署流水线有一个开发环境,一个测试环境,一个准生产环境,但是这些阶段会根据不同的团队、产品和组织而变化。例如,Mingle团队有一个阶段叫做“纸杯蛋糕”的准生产环境,而Etsy的准生产环境叫做“公主”。

2.jpg


在不同的环境下,安妮和史蒂夫写的代码被分别进行测试。当代码部署到生产环境它就开始了工作,这给予了他们更多的信心。并且只有当代码通过前一个环境的测试才会进入到下一个部署流水线的环境当中去。通过这种方式,安妮和史蒂夫将会从每个环境中测试并得到新的反馈,如果有失败,他们也可以在代码被应用到生产环境之前更加容易地发现问题并且修正它。

持续学习

这个过程对于业务决策者来说非常重要。它意味着如果安妮的代码通过了所有环境的测试,并将准备投入生产当中。你需要决定你的用户是否立即能够用上它。我们是否希望这个绿色构建现在投入生产?是的!一旦你的开发者完成了构建,那么一个全新的、充分测试的、可以工作的应用已经为你的用户准备好了。

持续部署(Continuous Deployment)

史蒂夫或者安妮所做的每个改动,都是通过测试环节,然后自动投入生产的实践过程。关于这个概念这个PDF有一个很棒的阐释:(http://www.paulhammond.org/201 ... k.pdf)。为了达成持续部署,你首先需要持续交付,所以这不是决定哪个优先级更高的二选一。无论如何,持续交付对于业务的决策带来更大的敏捷性,这才是真正实现业务导向的捷径。

3.jpg


开发运维(DevOps)

 “DevOps”这个词是“development”和“operations”的组合。DevOps已经上升为一种文化,它促使开发人员(史蒂夫和安妮你们快回来)和其他运维人员协同工作。具体地说,在软件交付和部署的过程中沟通合作,为了能够更快速更可靠地发布质量更好的应用。

拥有DevOps文化的团队通常有一个共同的特征:熟练的多技能团队(史蒂夫,安妮和乔伊都在同一团队里),高水平的测试和自动发布(按持续交付的方式)以及团队成员之间共同的目标。

4.jpg


一种方式是我们的开发朋友史蒂夫和安妮将同运维人员乔伊一起工作将应用交付给生产,而不是只将他们的代码“移交”给乔伊来发布。同样地,史蒂夫、安妮和乔伊都将作为共同负责所有产品支持和维护的服务团体的一部分,而不是仅由运维团队负责支持。

你还将看到自动化的实践对于持续交付和DevOps越来越重要。这是为了从持续交付和DevOps中实现可重复的、固定的和成功的应用发布流程,来避免人工处理非常容易出错、而且效率低下的问题。

5.jpg


DevOps文化通常和持续交付关联起来,因为他们的目标都是为了提升开发团队和运维团队之间的协作效率,都使用自动化进程来更快速、更频繁、更可靠地构建、测试和发布应用。这正是我们想要的。

接下来呢?

产品经理们已经逐步看到持续集成、持续交付和DevOps的诸多好处,那么拥抱DevOps吧,祝大家周末愉快,下周见:)


原文链接:https://wanqu.co/amp/p/2862

并存共生or相爱相杀?容器、虚拟机与Docker概念全解析

宁静胡同 发表了文章 • 2 个评论 • 426 次浏览 • 2016-03-24 19:02 • 来自相关话题

当小数看到这篇文章时内心是激动的,因为或许介绍Docker容器的文章有无数,但是如此清晰易懂、对小白如此友好的却不多见。本文立足于新手,从容器和虚拟机两个大的概念入手,由浅入深,由宏转微,为我们解析了Docker的方方面面。来吧朋友们,理解它,热爱它,然后更好地使用它。

作为程序员或者技术人员,大家肯定听说过Docker的鼎鼎大名——这款工具能够帮助我们高效打包、发布及运行承载着应用程序的“容器”系统。其发展如火如荼——从开发者到运维人员,每个人都在关注着这位技术新贵。即使是像谷歌、VMware与Amazon这样的技术巨擘也在构建相关服务为其提供支持。

无论大家是否有意立即使用Docker,我们都应当对其基础概念加以了解,并明确区分容器与虚拟机之间的差异所在。目前网络上已经存在大量对二者关联与区别的阐述性文章,不过在今天的综述中,我们将立足于新手对其加以剖析。

下面首先聊聊虚拟机与容器究竟是什么。

容器与虚拟机究竟是什么?

容器与虚拟机拥有着类似的使命:对应用程序及其关联性进行隔离,从而构建起一套能够随处运行的自容纳单元。

此外,容器与虚拟机还摆脱了对物理硬件的需求,允许我们更为高效地使用计算资源,从而提升能源效率与成本效益。

容器与虚拟机之间的核心差异在于其架构方法。下面一起进行深入了解。

虚拟机

虚拟机在本质上就是在模拟一台真实的计算机设备,同时遵循同样的程序执行方式。虚拟机能够利用“虚拟机管理程序”运行在物理设备之上。反过来,虚拟机管理程序则可运行在主机设备或者“裸机”之上。

下面用更直白的表达来说明:

虚拟机管理程序可表现为软件、固件或者硬件,并作为虚拟机的运行基础。虚拟机管理程序本身运行在物理计算机之上,我们也将这种底层硬件称为“主机设备”。主机设备为虚拟机提供资源,包括内存与CPU。这些资源由不同虚拟机共享,并根据需要进行随意分配。因此如果一套虚拟机运行有需求大量资源的高强度应用程序,那么我们可以在同一主机设备上为其分配远高于其它虚拟机的资源配额。

运行在主机设备上的虚拟机(当然,需要配合虚拟机管理程序)通常被称为一套“客户机”。这套客户机容纳有应用程序及其运行所必需的各类组件(例如系统二进制文件及库)。它同时还包含有完整的虚拟硬件堆栈,其中包括虚拟网络适配器、存储以及CPU——这意味着它也拥有自己的完整访客操作系统。着眼于内部,这套客户机自成体系并拥有专用资源。而从外部来看,这套虚拟机使用的则是由主机设备提供的共享资源。

如上所述,客户机可以运行主机虚拟机管理程序或者裸机虚拟机管理程序。二者之间存在着多种重要区别。

首先,主机虚拟机管理程序运行在主机设备的操作系统之上。举例来说,一台运行有OS X的计算机可以在操作系统之上安装虚拟机(例如VirtualBox或者VMware Workstation 8)。该虚拟机并不会直接访问硬件,因此其需要经由主机操作系统(也就是Mac OS X)实现资源获取。

主机虚拟机管理程序的优势在于,其基本摆脱了对底层硬件的要求。该主机操作系统负责提供硬件驱动程序,而非由虚拟机管理程序自身提供,因此我们认为其具备更理想的“硬件兼容性”。在另一方面,这种介于硬件与虚拟机管理程序之间的额外层会带来更多资源消耗,进而降低虚拟机性能表现。

裸机虚拟机管理程序则将虚拟机直接安装并运行在主机设备硬件之上以改善性能表现。由于其直接接入底层硬件,因此我们不再需要主机操作系统作为辅助。在这种情况下,我们可以直接在硬件上安装虚拟机管理程序并将其作为操作系统。与主机虚拟机管理程序不同,裸机虚拟机管理程序拥有自己的设备驱动程序及接口,从而直接支持各类I/O、处理或者操作系统特定任务相关组件。这种方式能够带来更理想的性能水平、可扩展性以及稳定性。但代价是其硬件兼容性比较有限,因为虚拟机管理程序只能包含一部分设备驱动程序。

说到这里,大家可能提出疑问:为什么我们非得在虚拟机与主机设备之间添加“虚拟机管理程序”呢?

这个嘛,因为虚拟机本身拥有一套虚拟操作系统,而虚拟机管理程序则负责为虚拟机提供平台以管理并运行这套访客操作系统。如此一来,主机计算机就能够为运行于其上的各虚拟机分配共享资源了。







虚拟机原理示意图

如大家所见,虚拟机会将虚拟硬件、内核(即操作系统)以及用户空间打包在新虚拟机当中。

容器
与提供硬件虚拟化机制的虚拟机不同,容器通过对“用户空间”的抽象化处理提供操作系统层级的虚拟化机制。通过对容器进行分解,大家将可以非常清晰地理解其中含义。

出于各种考量与需求,容器在外观上与虚拟机非常相似。举例来说,二者皆拥有专有处理空间、能够作为root执行命令、提供专有网络接口与IP地址、允许定制化路由及iptable规则,且可启动文件系统等等。

容器与虚拟机间的最大区别在于,各容器系统*共享*主机系统的内核。
 






容器原理示意图

以上示意图显示了容器如何对用户空间进行打包,而不像虚拟机那样同样对内核或者虚拟硬件进行打包。每套容器都拥有自己的隔离化用户空间,从而使得多套容器能够运行在同一主机系统之上。我们可以看到全部操作系统层级的架构都可实现跨容器共享。惟一需要独立构建的就是二进制文件与库。正因为如此,容器才拥有极为出色的轻量化特性。

Docker的功能定位

Docker为基于Linux容器的开源项目,其利用Linux内核中的各项功能——例如命名空间与控制组——以在操作系统之上创建容器。

容器概念并不是什么新鲜事物; 谷歌公司多年来一直在使用自己开发的容器技术。其它Linux容器技术方案还包括Solaris Zones、BSD jails以及LXC,且其都已经拥有多年的发展历史。

那么为什么Docker的出现会快速吸引到技术业界的注意?
易用性: Docker能够为潜在受众带来出色的易用性——开发者、系统管理员以及架构师等等——从而帮助其充分利用容器技术优势以快速构建并测试可移植应用程序。每个人都可以在自己的笔记本上打包应用程序,并将其直接运行在任何公有云、私有云甚至是裸机之上。其座右铭是:一次构建,随处运行。速度: Docker容器具备轻量化与高速特性。由于容器本身属于运行在内核之上的沙箱环境,因为其对资源的需求量极低。大家可以在数秒钟内完成容器的创建与运行,而虚拟机则由于需要引导完整的虚拟操作系统而耗费更多时间。Docker Hub: Docker用户还能够享受由Docker Hub带来的丰富生态系统支持,我们可以将其理解成“Docker镜像的应用商店”。Docker Hub提供成千上万由社区开发的公共镜像,且可立即加以使用。我们可以轻松根据需要搜索到合适的镜像,将其提取并稍加修改即加以使用。 模块性与可扩展性: Docker允许我们轻松将应用程序的功能拆分成多个独立容器。举例来说,我们可以将自己的Postgres数据库运行在一套容器当中,并将Redis服务器运行在另一容器内,而Node.js也拥有自己的容器系统。在Docker的帮助上,大家能够轻松将这些容器对接起来以创建完整的应用程序,这就让未来的规模伸缩或者组件更新得以通过相互独立的方式完成。

最后但同样重要的是,Docker鲸鱼实在是太惹人喜爱了~
 






Docker基本概念
现在我们对Docker有了宏观印象,下面具体对其组件进行解读:
 






Docker Engine

Docker Engine属于Docker的运行层。这是一套轻量化运行时及工具组合,负责管理容器、镜像、构建 等等。它以原生方式运行在Linux系统之上,并由以下元素构成:

Docker Daemon,运行在主机计算机之上。
Docker Client,负责与Docker Daemon通信以执行命令。
REST API,用于同Docker Daemon远程交互。

Docker Client

Docker Client正是我们作为最终用户的通信对象。我们可以将其视为Docker的UI。






我们进行的一切操作都将直接接入Docker Client,再由其将指令传递至Docker Daemon。

Docker Daemon

Docker Daemon直接将执行命令发送至Docker Client——例如构建、运行以及分发等等。Docker Daemon运行在主机设备之上,但作为用户,我们永远不会直接与该Daemon进行通信。Docker Client也可以运行在主机设备上,但并非必需。它亦能够运行在另一台设备上,并与运行在目标主机上的Docker Daemon进行远程通信。

Dockerfile

Dockerfile是我们编写指令以构建Docker镜像的载体。这些指令包括:
RUN apt-get y install some-package:安装某软件包
EXPOSE 8000: 开放端口
ENV ANT_HOME /usr/local/apache-ant:传递环境变量

类似的指令还有很多。一旦设置了Dockerfile,大家就可以利用docker build命令来构建镜像了。下面来看Dockerfile示例:







示例Dockerfile

Docker镜像

镜像属于只读模板,大家可以借此配合Dockerfile中的编写指令集进行容器构建。镜像定义了打包的应用程序以及其相关依赖。这些依赖就好像是其启动时需要运行的进程。

Docker镜像利用Dockerfile实现构建。Dockerfile中的每条指令都会在镜像中添加一个新的“层”,这些层则表现为镜像文件系统中的一个分区——我们可以对其进行添加或者替换。层概念正是Docker轻量化的基础。Docker利用一套Union File System建立起这套强大的结构:

Union File System

Docker利用Union File System以构建镜像。大家可以将Union File System视为一套可堆叠文件系统,这意味着各文件系统中的文件与目录(在Docker中被称为分支)可以透明方式覆盖并构成单一文件系统。

覆盖分支内的各目录内容拥有同样的路径,并将被视为单一合并目录,这就避免了需要为每个层分别创建副本的麻烦。相反,这些目录可调用特定指针以指向同样的资源; 当特定层需要进行修改时,其会分别创建修改前与修改后的本地副本。通过这种方式,文件系统*表现*出可写入特性,但其实际上并未接受任何写入操作。(换言之,这是一套‘写入即复制’系统。)

分层系统拥有两大核心优势:

无重复数据: 分层机制使得我们在使用镜像创建并运行新容器时无需复制完整的文件集,从而保证Docker容器实例拥有良好的运行速度与低廉的资源成本。
层隔离: 变更操作速度很快——当我们对镜像进行变更时,Docker只需要对进行了变更的层进行广播。

Volumes

Volumes属于容器中的“数据”部分,会在容器创建时进行初始化。Volumes机制允许我们持久保留并共享容器数据。数据卷 独立于默认Union File System之外,且作为普通目录及文件存在于主机文件系统当中。因此即使是在对容器进行销毁、更新或者重构时,数据卷仍然不受影响。当我们需要对某一数据卷进行更新时,直接加以变更即可。(作为另一项优势,数据卷还能够在不同容器之间进行共享与复用。)

Docker容器
如上所述,Docker容器将一款应用程序的软件打包在单一环境当中,同时包含全部运行必需的要素。其中包括操作系统、应用程序代码、运行时、系统工具、系统库等等。Docker容器由Docker镜像构建而成。由于镜像存在只读属性,因此Docker会在镜像在只读文件系统之上添加一套读取-写入文件系统以实现容器创建。
 






另外,在创建容器时,Docker还会创建一套网络接口以帮助容器同本地主机通信、对接可用IP地址并执行用户在定义镜像时所执行的进程以运行应用程序。
在成功创建了一套容器之后,我们随后可以将其运行在任何环境当中,而不必再做任何变更。

“容器”探秘

打开容器,我们会发现其中包含大量活动组件。容器的实现机制一直令我感到惊讶而好奇,特别是考虑到容器不存在任何抽象的基础设施边界。在阅读了大量材料之后,我将结合自己的理解为大家进行讲解:)

“容器”这一术语其实只是个抽象概念,用于表述多种不同的相关特性,而其与原词“container”的另一含义“集装箱”有着千丝万缕的联系。下面就来一起了解:

1) 命名空间

命名空间为容器提供对应的底层Linux系统视图,即限制容器的查看与访问范畴。当我们运行一套容器时,Docker会创建多个命名空间供特定容器使用。
Docker会在内核中使用多种不同类型的命名空间,例如:
NET: 为容器提供独特的系统网络堆栈视图(例如自有网络设备、IP地址、IP路由表、/proc/net目录、端口编号等等)。PID: PID代表进程ID。如果大家曾经在命令行中运行过ps aux以检查当前系统正在运行的进程,就会发现其中一栏名为“PID”。PID命名空间为容器提供其能够查看与交互的进程范围,其中包括独立的init(PID 1),其属于“所有进程的元祖”。MNT: 为容器提供独特的系统“mounts”视图。这样不同mount命名空间内的进程就将拥有彼此不同的文件系统结构。UTS: UTS代表UNIX分时系统。它允许某一进程识别系统身份(例如主机名称或者域名等)。UTS允许容器拥有不同于其它容器以及主机系统的主机名称与NIS域名。IPC: IPC代表进程间通信。IPC命名空间负责对运行在每套容器内的进程进行IPC资源隔离。USER: 此命名空间用于对每套容器内的用户进行隔离。其允许各容器拥有不同的uid(即用户ID)与gid(组ID)视图区间,并将其与主机系统进行比对。这样一来,某一进程的uid与gid在用户命名空间之内与之外即有所不同,这也使得该进程能够在不影响容器内root权限的情况下,撤销同一用户在容器外的权限。

Docker将这些命名空间结合起来以隔离并创建容器。下面要讲的则是控制组。

2) 控制组

控制组(也被称为cgroups)属于Linux内核中的一项功能,用于对一组进程的资源使用量(包括CPU、内存、磁盘I/O以及网络等)进行隔离、排序与计数。这意味着cgroup能够确保Docker容器只使用其必需的资源——并在必要情况下设置其所能使用的资源上限。另外,cgroups还能够确保单一容器不至于占用太多资源并导致整体系统陷入瘫痪。

最后要说明的是Union文件系统:

3) 隔离化Union file system:

我们在之前的Docker镜像章节中已经解释过了:)

这就是关于Docker容器的全部内容了(当然,实现细节才是最麻烦的环节——例如如何管理不同组件间的交互)。

Docker的未来:Docker与虚拟机将并生共存

尽管Docker已经开始逐步成为主流,但我认为它不太可能对虚拟机造成真正的威胁。容器将继续发展壮大,但虚拟机也仍然拥有适合自己的生存空间。

举例来说,如果我们需要在多台服务器上运行多款应用程序,那么最理想的办法就是使用虚拟机。在另一方面,如果我们需要运行同一应用程序的多套*副本*,那么Docker则拥有更多具体优势。

另外,尽管容器允许我们将应用程序拆分成多个功能组件,但这种分散化趋势意味着我们需要管理更多功能部件,即带来更为复杂的控制与协调任务。

安全同时也是Docker容器需要解决的一大难题——由于各容器共享同一套内核,因此不同容器之间的屏障非常薄弱。与只需要调用主机虚拟机管理程序的虚拟机方案不同,Docker容器需要向主机内核发出系统调用,而这会带来更庞大的攻击面。出于安全性的考量,很多开发人员可能更倾向于选择虚拟机——其由抽象化硬件进行隔离,从而显著提升了彼此交互的难度。

当然,安全性与管理等难题必将随着容器在生产环境下的进一步普及而得到解决。就目前来讲,关于容器与虚拟机孰优孰劣的议题已经成为开发人员与运维人员间的日常争论素材。

最后

到这里,希望大家已经拥有了关于Docker的必要知识,也祝愿各位早日将Docker引入自己的日常工作。

当然,如果大家在文章中发现了什么谬误,也欢迎在评论栏中做出说明。感谢大家,小数与你下次再见!

原文链接:
https://medium.freecodecamp.com/a-beginner-friendly-introduction-to-containers-vms-and-docker-79a9e3e119b#.sl2xp8tiv 查看全部

当小数看到这篇文章时内心是激动的,因为或许介绍Docker容器的文章有无数,但是如此清晰易懂、对小白如此友好的却不多见。本文立足于新手,从容器和虚拟机两个大的概念入手,由浅入深,由宏转微,为我们解析了Docker的方方面面。来吧朋友们,理解它,热爱它,然后更好地使用它。



作为程序员或者技术人员,大家肯定听说过Docker的鼎鼎大名——这款工具能够帮助我们高效打包、发布及运行承载着应用程序的“容器”系统。其发展如火如荼——从开发者到运维人员,每个人都在关注着这位技术新贵。即使是像谷歌、VMware与Amazon这样的技术巨擘也在构建相关服务为其提供支持。

无论大家是否有意立即使用Docker,我们都应当对其基础概念加以了解,并明确区分容器与虚拟机之间的差异所在。目前网络上已经存在大量对二者关联与区别的阐述性文章,不过在今天的综述中,我们将立足于新手对其加以剖析。

下面首先聊聊虚拟机与容器究竟是什么。

容器与虚拟机究竟是什么?

容器与虚拟机拥有着类似的使命:对应用程序及其关联性进行隔离,从而构建起一套能够随处运行的自容纳单元。

此外,容器与虚拟机还摆脱了对物理硬件的需求,允许我们更为高效地使用计算资源,从而提升能源效率与成本效益。

容器与虚拟机之间的核心差异在于其架构方法。下面一起进行深入了解。

虚拟机

虚拟机在本质上就是在模拟一台真实的计算机设备,同时遵循同样的程序执行方式。虚拟机能够利用“虚拟机管理程序”运行在物理设备之上。反过来,虚拟机管理程序则可运行在主机设备或者“裸机”之上。

下面用更直白的表达来说明:

虚拟机管理程序可表现为软件、固件或者硬件,并作为虚拟机的运行基础。虚拟机管理程序本身运行在物理计算机之上,我们也将这种底层硬件称为“主机设备”。主机设备为虚拟机提供资源,包括内存与CPU。这些资源由不同虚拟机共享,并根据需要进行随意分配。因此如果一套虚拟机运行有需求大量资源的高强度应用程序,那么我们可以在同一主机设备上为其分配远高于其它虚拟机的资源配额。

运行在主机设备上的虚拟机(当然,需要配合虚拟机管理程序)通常被称为一套“客户机”。这套客户机容纳有应用程序及其运行所必需的各类组件(例如系统二进制文件及库)。它同时还包含有完整的虚拟硬件堆栈,其中包括虚拟网络适配器、存储以及CPU——这意味着它也拥有自己的完整访客操作系统。着眼于内部,这套客户机自成体系并拥有专用资源。而从外部来看,这套虚拟机使用的则是由主机设备提供的共享资源。

如上所述,客户机可以运行主机虚拟机管理程序或者裸机虚拟机管理程序。二者之间存在着多种重要区别。

首先,主机虚拟机管理程序运行在主机设备的操作系统之上。举例来说,一台运行有OS X的计算机可以在操作系统之上安装虚拟机(例如VirtualBox或者VMware Workstation 8)。该虚拟机并不会直接访问硬件,因此其需要经由主机操作系统(也就是Mac OS X)实现资源获取。

主机虚拟机管理程序的优势在于,其基本摆脱了对底层硬件的要求。该主机操作系统负责提供硬件驱动程序,而非由虚拟机管理程序自身提供,因此我们认为其具备更理想的“硬件兼容性”。在另一方面,这种介于硬件与虚拟机管理程序之间的额外层会带来更多资源消耗,进而降低虚拟机性能表现。

裸机虚拟机管理程序则将虚拟机直接安装并运行在主机设备硬件之上以改善性能表现。由于其直接接入底层硬件,因此我们不再需要主机操作系统作为辅助。在这种情况下,我们可以直接在硬件上安装虚拟机管理程序并将其作为操作系统。与主机虚拟机管理程序不同,裸机虚拟机管理程序拥有自己的设备驱动程序及接口,从而直接支持各类I/O、处理或者操作系统特定任务相关组件。这种方式能够带来更理想的性能水平、可扩展性以及稳定性。但代价是其硬件兼容性比较有限,因为虚拟机管理程序只能包含一部分设备驱动程序。

说到这里,大家可能提出疑问:为什么我们非得在虚拟机与主机设备之间添加“虚拟机管理程序”呢?

这个嘛,因为虚拟机本身拥有一套虚拟操作系统,而虚拟机管理程序则负责为虚拟机提供平台以管理并运行这套访客操作系统。如此一来,主机计算机就能够为运行于其上的各虚拟机分配共享资源了。


1.png


虚拟机原理示意图

如大家所见,虚拟机会将虚拟硬件、内核(即操作系统)以及用户空间打包在新虚拟机当中。

容器
与提供硬件虚拟化机制的虚拟机不同,容器通过对“用户空间”的抽象化处理提供操作系统层级的虚拟化机制。通过对容器进行分解,大家将可以非常清晰地理解其中含义。

出于各种考量与需求,容器在外观上与虚拟机非常相似。举例来说,二者皆拥有专有处理空间、能够作为root执行命令、提供专有网络接口与IP地址、允许定制化路由及iptable规则,且可启动文件系统等等。

容器与虚拟机间的最大区别在于,各容器系统*共享*主机系统的内核。
 

2.png


容器原理示意图

以上示意图显示了容器如何对用户空间进行打包,而不像虚拟机那样同样对内核或者虚拟硬件进行打包。每套容器都拥有自己的隔离化用户空间,从而使得多套容器能够运行在同一主机系统之上。我们可以看到全部操作系统层级的架构都可实现跨容器共享。惟一需要独立构建的就是二进制文件与库。正因为如此,容器才拥有极为出色的轻量化特性。

Docker的功能定位

Docker为基于Linux容器的开源项目,其利用Linux内核中的各项功能——例如命名空间与控制组——以在操作系统之上创建容器。

容器概念并不是什么新鲜事物; 谷歌公司多年来一直在使用自己开发的容器技术。其它Linux容器技术方案还包括Solaris Zones、BSD jails以及LXC,且其都已经拥有多年的发展历史。

那么为什么Docker的出现会快速吸引到技术业界的注意?
  • 易用性: Docker能够为潜在受众带来出色的易用性——开发者、系统管理员以及架构师等等——从而帮助其充分利用容器技术优势以快速构建并测试可移植应用程序。每个人都可以在自己的笔记本上打包应用程序,并将其直接运行在任何公有云、私有云甚至是裸机之上。其座右铭是:一次构建,随处运行。
  • 速度: Docker容器具备轻量化与高速特性。由于容器本身属于运行在内核之上的沙箱环境,因为其对资源的需求量极低。大家可以在数秒钟内完成容器的创建与运行,而虚拟机则由于需要引导完整的虚拟操作系统而耗费更多时间。
  • Docker Hub: Docker用户还能够享受由Docker Hub带来的丰富生态系统支持,我们可以将其理解成“Docker镜像的应用商店”。Docker Hub提供成千上万由社区开发的公共镜像,且可立即加以使用。我们可以轻松根据需要搜索到合适的镜像,将其提取并稍加修改即加以使用。
  •  模块性与可扩展性: Docker允许我们轻松将应用程序的功能拆分成多个独立容器。举例来说,我们可以将自己的Postgres数据库运行在一套容器当中,并将Redis服务器运行在另一容器内,而Node.js也拥有自己的容器系统。在Docker的帮助上,大家能够轻松将这些容器对接起来以创建完整的应用程序,这就让未来的规模伸缩或者组件更新得以通过相互独立的方式完成。


最后但同样重要的是,Docker鲸鱼实在是太惹人喜爱了~
 

3.png


Docker基本概念
现在我们对Docker有了宏观印象,下面具体对其组件进行解读:
 

4.png


Docker Engine

Docker Engine属于Docker的运行层。这是一套轻量化运行时及工具组合,负责管理容器、镜像、构建 等等。它以原生方式运行在Linux系统之上,并由以下元素构成:

Docker Daemon,运行在主机计算机之上。
Docker Client,负责与Docker Daemon通信以执行命令。
REST API,用于同Docker Daemon远程交互。

Docker Client

Docker Client正是我们作为最终用户的通信对象。我们可以将其视为Docker的UI。

4.4_.png


我们进行的一切操作都将直接接入Docker Client,再由其将指令传递至Docker Daemon。

Docker Daemon

Docker Daemon直接将执行命令发送至Docker Client——例如构建、运行以及分发等等。Docker Daemon运行在主机设备之上,但作为用户,我们永远不会直接与该Daemon进行通信。Docker Client也可以运行在主机设备上,但并非必需。它亦能够运行在另一台设备上,并与运行在目标主机上的Docker Daemon进行远程通信。

Dockerfile

Dockerfile是我们编写指令以构建Docker镜像的载体。这些指令包括:
RUN apt-get y install some-package:安装某软件包
EXPOSE 8000: 开放端口
ENV ANT_HOME /usr/local/apache-ant:传递环境变量

类似的指令还有很多。一旦设置了Dockerfile,大家就可以利用docker build命令来构建镜像了。下面来看Dockerfile示例:


sample.jpg


示例Dockerfile

Docker镜像

镜像属于只读模板,大家可以借此配合Dockerfile中的编写指令集进行容器构建。镜像定义了打包的应用程序以及其相关依赖。这些依赖就好像是其启动时需要运行的进程。

Docker镜像利用Dockerfile实现构建。Dockerfile中的每条指令都会在镜像中添加一个新的“层”,这些层则表现为镜像文件系统中的一个分区——我们可以对其进行添加或者替换。层概念正是Docker轻量化的基础。Docker利用一套Union File System建立起这套强大的结构:

Union File System

Docker利用Union File System以构建镜像。大家可以将Union File System视为一套可堆叠文件系统,这意味着各文件系统中的文件与目录(在Docker中被称为分支)可以透明方式覆盖并构成单一文件系统。

覆盖分支内的各目录内容拥有同样的路径,并将被视为单一合并目录,这就避免了需要为每个层分别创建副本的麻烦。相反,这些目录可调用特定指针以指向同样的资源; 当特定层需要进行修改时,其会分别创建修改前与修改后的本地副本。通过这种方式,文件系统*表现*出可写入特性,但其实际上并未接受任何写入操作。(换言之,这是一套‘写入即复制’系统。)

分层系统拥有两大核心优势:

无重复数据: 分层机制使得我们在使用镜像创建并运行新容器时无需复制完整的文件集,从而保证Docker容器实例拥有良好的运行速度与低廉的资源成本。
层隔离: 变更操作速度很快——当我们对镜像进行变更时,Docker只需要对进行了变更的层进行广播。

Volumes

Volumes属于容器中的“数据”部分,会在容器创建时进行初始化。Volumes机制允许我们持久保留并共享容器数据。数据卷 独立于默认Union File System之外,且作为普通目录及文件存在于主机文件系统当中。因此即使是在对容器进行销毁、更新或者重构时,数据卷仍然不受影响。当我们需要对某一数据卷进行更新时,直接加以变更即可。(作为另一项优势,数据卷还能够在不同容器之间进行共享与复用。)

Docker容器
如上所述,Docker容器将一款应用程序的软件打包在单一环境当中,同时包含全部运行必需的要素。其中包括操作系统、应用程序代码、运行时、系统工具、系统库等等。Docker容器由Docker镜像构建而成。由于镜像存在只读属性,因此Docker会在镜像在只读文件系统之上添加一套读取-写入文件系统以实现容器创建。
 

5.png


另外,在创建容器时,Docker还会创建一套网络接口以帮助容器同本地主机通信、对接可用IP地址并执行用户在定义镜像时所执行的进程以运行应用程序。
在成功创建了一套容器之后,我们随后可以将其运行在任何环境当中,而不必再做任何变更。

“容器”探秘

打开容器,我们会发现其中包含大量活动组件。容器的实现机制一直令我感到惊讶而好奇,特别是考虑到容器不存在任何抽象的基础设施边界。在阅读了大量材料之后,我将结合自己的理解为大家进行讲解:)

“容器”这一术语其实只是个抽象概念,用于表述多种不同的相关特性,而其与原词“container”的另一含义“集装箱”有着千丝万缕的联系。下面就来一起了解:

1) 命名空间

命名空间为容器提供对应的底层Linux系统视图,即限制容器的查看与访问范畴。当我们运行一套容器时,Docker会创建多个命名空间供特定容器使用。
Docker会在内核中使用多种不同类型的命名空间,例如:
  • NET: 为容器提供独特的系统网络堆栈视图(例如自有网络设备、IP地址、IP路由表、/proc/net目录、端口编号等等)。
  • PID: PID代表进程ID。如果大家曾经在命令行中运行过ps aux以检查当前系统正在运行的进程,就会发现其中一栏名为“PID”。PID命名空间为容器提供其能够查看与交互的进程范围,其中包括独立的init(PID 1),其属于“所有进程的元祖”。
  • MNT: 为容器提供独特的系统“mounts”视图。这样不同mount命名空间内的进程就将拥有彼此不同的文件系统结构。
  • UTS: UTS代表UNIX分时系统。它允许某一进程识别系统身份(例如主机名称或者域名等)。UTS允许容器拥有不同于其它容器以及主机系统的主机名称与NIS域名。
  • IPC: IPC代表进程间通信。IPC命名空间负责对运行在每套容器内的进程进行IPC资源隔离。
  • USER: 此命名空间用于对每套容器内的用户进行隔离。其允许各容器拥有不同的uid(即用户ID)与gid(组ID)视图区间,并将其与主机系统进行比对。这样一来,某一进程的uid与gid在用户命名空间之内与之外即有所不同,这也使得该进程能够在不影响容器内root权限的情况下,撤销同一用户在容器外的权限。


Docker将这些命名空间结合起来以隔离并创建容器。下面要讲的则是控制组。

2) 控制组

控制组(也被称为cgroups)属于Linux内核中的一项功能,用于对一组进程的资源使用量(包括CPU、内存、磁盘I/O以及网络等)进行隔离、排序与计数。这意味着cgroup能够确保Docker容器只使用其必需的资源——并在必要情况下设置其所能使用的资源上限。另外,cgroups还能够确保单一容器不至于占用太多资源并导致整体系统陷入瘫痪。

最后要说明的是Union文件系统:

3) 隔离化Union file system:

我们在之前的Docker镜像章节中已经解释过了:)

这就是关于Docker容器的全部内容了(当然,实现细节才是最麻烦的环节——例如如何管理不同组件间的交互)。

Docker的未来:Docker与虚拟机将并生共存

尽管Docker已经开始逐步成为主流,但我认为它不太可能对虚拟机造成真正的威胁。容器将继续发展壮大,但虚拟机也仍然拥有适合自己的生存空间。

举例来说,如果我们需要在多台服务器上运行多款应用程序,那么最理想的办法就是使用虚拟机。在另一方面,如果我们需要运行同一应用程序的多套*副本*,那么Docker则拥有更多具体优势。

另外,尽管容器允许我们将应用程序拆分成多个功能组件,但这种分散化趋势意味着我们需要管理更多功能部件,即带来更为复杂的控制与协调任务。

安全同时也是Docker容器需要解决的一大难题——由于各容器共享同一套内核,因此不同容器之间的屏障非常薄弱。与只需要调用主机虚拟机管理程序的虚拟机方案不同,Docker容器需要向主机内核发出系统调用,而这会带来更庞大的攻击面。出于安全性的考量,很多开发人员可能更倾向于选择虚拟机——其由抽象化硬件进行隔离,从而显著提升了彼此交互的难度。

当然,安全性与管理等难题必将随着容器在生产环境下的进一步普及而得到解决。就目前来讲,关于容器与虚拟机孰优孰劣的议题已经成为开发人员与运维人员间的日常争论素材。

最后

到这里,希望大家已经拥有了关于Docker的必要知识,也祝愿各位早日将Docker引入自己的日常工作。

当然,如果大家在文章中发现了什么谬误,也欢迎在评论栏中做出说明。感谢大家,小数与你下次再见!

原文链接:
https://medium.freecodecamp.com/a-beginner-friendly-introduction-to-containers-vms-and-docker-79a9e3e119b#.sl2xp8tiv

回顾Java 发展,看 Docker 与Mesos

宁静胡同 发表了文章 • 2 个评论 • 775 次浏览 • 2016-03-22 17:24 • 来自相关话题

演讲嘉宾

数人云COO 谢乐冰

在德国工作十年,回国后加入惠普电信运营商部门,拥有多年项目经验和创业公司工作经验。在数人云负责产品售前和运营,专注行业的技术应用领域,为金融、电信、电商等行业提供服务。



回顾Java的发展轨迹看容器技术

因为我自己写了十几年的Java,经常把容器和十年前的Java做比较。一个公司说自己是做“Java”的,实际上涵义是背后一整套企业IT基础架构。软件一般都是各个集成商(东软、文思)大量码农兄弟们开发,主要还是用Windows。打成了WAR、EAR包之后交付给甲方,就可以在Linux环境下跑起来。同样Weblogic WAS这些中间件在底层计算集群之上,实现了企业服务的大规模运行。

中间件之下是IOE昂贵的高性能硬件,虽然也是集群化,主要依靠Scale up来提升性能。虽然中间件理论上实现了应用和硬件资源解耦,但实际上依然对硬件有非常苛刻的要求,特别是跑数据库的部分。

整个架构为了向上实现SOA的架构,虽然现实中90%以上顶多做到了“面向对象”,但并不妨碍Java(J2EE)作为企业服务交付的“通用”形式,成为了开发单位和运行单位共同接受的标准。所以Java背后代表的不仅仅是一个语言,还是一个完整的IT基础架构和产业链 —— 昂贵的高性能硬件、闭源的中间件软件、Java作为交付接口、SOA架构和开发与运维分离的模式。

背后还有两个隐性的英雄,一个是北大青鸟这样的培训机构,大量产出Java程序员。另外就是Oracle数据库,当然这些年轻程序员写的代码效率不太高的时候,全靠数据库来救场了。当然这一切还是传统的企业业务决定的,例如ERP、CRM等等,并发较低、强事物性和强一致性、逻辑和关联关系复杂。








如今时代发展到了蓝色的部分,云计算时代的IT架构底层不再是几台小机或者一堆刀片,更多的是企业私有云甚至是公有云,IaaS实现了资源层管理的自动化和标准化。

容器就像当年的Java一样,成为了开发和运维共同认可的接口。容器成为了应用上“云”的标准交付方式,不管是Java、Python还是C,只要用Docker打包,就可以丢到这个那个“云”上跑起来。

当然在底层各种计算资源(公有云、私有云甚至物理机)之间,也需要一个中间件来作为容器的大规模运行环境。下面是成千上万的主机,上面是乌央央的容器,中间的云计算中间件实现了两者的解耦。上面支撑的软件架构是“微服务”架构,就像当年的SOA。整体上也是实践了Devops一套运维开发方式。就像传统中间件包括了运行环境、消息队列、ESB(服务发现)和数据抽象等等,云计算中间件也都有类似的服务,例如Mesos、K8s这些容器运行环境,就对应着跑EJB的Weblogic Application Server。

总之,“容器”背后不是单个技术,而是完整的以开源软件为主的云计算IT基础架构和相应的开发和运维流程。当年虚拟机出现让大家尝到一点点云的滋味,但是毕竟局限于资源层,对开发、业务和软件架构没有影响。如今容器影响这么大,大家终于成为了应用上云的突破口,将对大家未来的职业生涯产生巨大的影响。就像今天很难招聘到懂EJB的大学毕业生,过两年很快容器和背后的互联网开源技术栈就会成为主流。

有关Mesos与K8s的老生常谈

言归正传,下面我来一步一步地介绍Mesos的实战。说起Mesos,大家往往第一个问题是Mesos和K8s有啥区别,哪个更好。我觉得这两个就像iOS和安卓,已经成为了新一代轻量调度框架的主流。两者都是源于Google的Borg,但Google自己没有使用任何一个。K8s胜在开发者多,用Go语言开发,社区活跃。Mesos是Apache项目,已经诞生了7年,目前有过超过万台规模的部署。总体上我们认为Mesos比较适合目前阶段的大规模生产环境部署,K8s目前还处于快速更新的阶段,两者都有很好的未来。当然Mesos也能兼容大数据等框架,未来目标是逐步把各种集群化的应用(Kafka集群例如)都搬到Mesos上来,实现一键安装和自动扩展。

下面是一点点Mesos的科普,其实市面上类似的文章已经不少,这里我特别推荐平安科技余何老师的《PaaS实现与运维管理:基于Mesos +Docker+ELK的实战指南》,内容非常详细。

用两句俗话说Mesos和K8s的原理,就是像使用一台电脑一样使用整个集群,类似集群的操作系统。单机的操作系统是管理单机的计算、存储和IO,集群操作系统是管理管理一堆机器的资源。目前聚焦在计算和内存之上,存储部分需要单独的分布式存储(例如Ceph和GlusterFS),网络需要SDN的支持。不过传统上IOE也是各管一摊了。







原理看起来也不复杂,Mesos 在每台Slave主机上安装一个Agent,不断地把剩余资源上报到Master。报告内容类似 { (node1, <2 CPUs, 4 GB>),(node2, <3 CPUs, 2 GB>) },这样Master就知道各个机器的剩余资源情况了,非常简单。

Master上面有很多框架Framework,例如Docker和Spark。你就可以把他们理解为Linux里面安装的JRE和Golang、C的运行类库。你想在Mesos上跑啥“语言”,就要部署个框架,例如跑Docker的框架就是Marathon。Mesos会把整个集群的资源按照一定的算法分配给各个框架,这个就是所谓资源调度的过程。因为Slave上报资源情况是不断更新的,所以就是所谓动态资源调度。







每个框架收到分配的资源之后,会自行决定将任务和资源匹配,然后通过Master将任务下发到Slave上执行。Slave上面有每种任务的执行器(Executor),就是运行环境。例如Docker任务的执行器是Mesos预装,其他类型任务执行器可能会实时下载。所以通过安装不同的框架+执行器,就可以支持各种“分布式”的任务系统。请注意这里说的一定是集群化的系统,如果是单点部署一个MySQL之类的就意义有限了。

以管理Docker任务的Marathon框架为例,它收到了Master提供的资源之后,一个是负责进行任务调度,而且还能够通过Health Check监控任务是否还活着,发现失败就重新下发任务。

这些都是常规性的解释,下面我们看看Mesos集群,看看如何一步步搭建。初始一般需要准备3台主机承载Master节点,任意多的Slave,这里建议也是3台。还有几台机器存放log等等。下面的一些图片来自前两天数人云公众号(dmesos)翻译的文章《初次微服务体验:从Docker容器农场说起》。








第一步 部署Zookeeper,负责整个集群的分布式一致性,例如Master领导选举








第二步,部署Mesos本身。我们的分布部署了3个Master,管理3个Slave节点。大家注意到,配置Mesos的时候最重要的参数就是Zookeeper,不但Master要通过ZK来进行领导选举,而且Slave也可以通过ZK来知道谁是活跃的Master.








到这一步,理论上已经可以用Mesos来管理集群下发任务了,大家看见下图里面资源(Slave)、任务(正在执行的已经介绍的)。 
 







甚至还能看到该任务的Stdout输出,就和SSH进去操作一样。
 






不过仅仅有Mesos,还要自己来编写框架调用接口发布任务,非常不方便。所以需要一个框架来跑容器任务,那就是马拉松(Marathon)。顾名思义用来跑各种长时间运行的服务,类似Linux里面的Inti.d,例如各种网站服务。马拉松是用Scala编写的,本身提供自己的Web管理界面,通过这个界面我们可以“遥控”Mesos来下发并保证Docker任务长久稳定执行。








马拉松的界面也非常直接,大家看看发布Docker任务的界面,基本就是填入Docker Run后面的那些参数,然后告诉马拉松要发布多少份。马拉松会匹配每个Task和Mesos提供的资源,然后通过Mesos将任务下发下去。








结果
 







服务发现

服务发现是个比较晦涩的翻译(Service Discovery),大概不妨粗略地理解成负载均衡算了。例如马拉松下发了100个网站的容器,每个容器有自己IP(一般是宿主机)和端口。显然前面需要挡一个负载均衡来分配流量。对外暴露的就是负载均衡的某个服务URL,后面自动将流量转发到某个容器的IP+端口上。








我们这里用HAProxy来做负载均衡,有个服务叫Bamboo会不断从ZK读出Mesos状态并且更新HAProxy的配置文件。这样新发下来的Docker会自动添加上HAProxy,而死掉的会被移除。

还有一直办法是用内网的DNS,这个DNS会维护现有的容器列表(IP+端口),并且返回任意一个的IP+端口,页实现了负载均衡和服务发现功能。不过目前Mesos DNS还不太成熟,我们一般用HAProxy。








几百个Docker撒出去,绝对不可能再登到主机上去找看日志。日志必须集中收集,并且提供检索功能,才能有效的Debug。解法也不新奇,无非是ELK。请注意Docker日志可以直接从API读出,另外需要增加一些应用、主机和容器有关的Meta Data。
 







此外分布式系统不能没有监控,黑盒子等于无法运行,所以监控要分为如下三个层面。

* 主机监控:这个并非Mesos的关注点,因为主机是资源层,本身也有自己的监控体系
* 容器层面的监控,主要是用cAdvisor,包括CPU、内存和IO
* 最最重要的是应用层监控,因为PaaS本身对外提供服务,所以监控的关注点应该是全局最终结果和逻辑正确性,而不是太纠结于个别主机和容器的

这个是分布式系统和传统系统最大的区别,关注点不再是个别容器和主机,而是业务本身。这种系统设计本来就是希望软件脱离对特定和单点硬件的依赖,通过集群化实现大规模系统的高性能和高可用。所以监控不再是着眼于“源头”,而是看重效果。很多时候平台的自愈机制甚至“埋没”了底层的一些故障,那么就让他被埋没了,只要最后效果能够得到保证。

分布式系统在应用层监控要求远远大于普通的IT系统,例如下面是一个HTTP返回状态吗的直方图,这样能很快发现是否出现大规模异常,并且通过日志系统来定位问题。








分布式系统和传统IT区别,就像市场经济和计划经济一样,不是要处处完全可控有计划,在最终结果保持可控情况下,突出灵活性、自由度和弹性,支持业务多变和快速发展。








这样一个基本的分布式系统就搭建完毕,当然如果是生产级别还需要有大规模集群运行调优、集群化HAProxy,监控和报警对接、多租户管理、F5的对接、和Openstack等等的IaaS对接等,这样就需要数人云这样的商业化开源方案来支持了。

此外经常有用户问到,啥样的应用可以上云呢,下面的表格回答了这个问题。








可以看到,这个问题的回答并不是黑白分明。最理想的当然是完全的微服务架构,可以发挥全部的作用。当然90%应用目前还是有状态应用,所以可以快速扩张,但是无法收缩,需要实现Graceful Stop功能,慢慢地收缩。所谓的无状态化改造,无非就是很标准互联网架构,不要用J2EE内置的Session就好。

 









本来今天还要展示一个我们的客户案例,如何将一个分布式系统迁移到Mesos之上,因为时间关系,下次再分享吧。

精彩问答


QQ群 

Q1:当初刚接触Linux的时候,最开始是在Virtualbox等虚拟机这种模拟环境里面摸索 Linux,代价低,比较容易动手和入门。对有一定基础的运维人员(但刚接触容器集群),你建议用什么配置的环境测试做 方便入门(比如测试  Mesos+ZooKeeper+Marathon+Docker)
A1:虚拟机就可以,VARGANT 

Q2:Docker的数据持久存储采用何种存储,用Ceph之类?
A2:对,各种分布式存储,例如Glusterfs 

Q3:我想问一下K8s+Docker 现在用作生产的话够成熟吗? K8s能达到高可用了吗?
A3:小集群的话可以倒腾倒腾,K8s的源码有浙大张磊老师的书 

Q4:还有就是Mesos能否和Openstack结合起来,生产环境有没有Docker和Openstack结合的案例
A4:必须可以,我们就和Openstack厂商一起合做生产系统部署了。可以这么说,完整的DCOS是包括IaaS+PaaS,如果企业要对底层资源严格管理,就需要IaaS 

Q5:我想问下Docker的性能,尤其是网络部分,比物理机和普通虚拟机差很多么,用集群性能会不会好些呢
A5:如何是Host模式,Docker网络性能和物理机一样,具体可以看  这里有一篇IBM的论文,讨论了差别:
http://domino.research.ibm.com ... 1E7B/$File/rc25482.pdf 

微信群|云实名

Q1:一直想问Doceker会不会一定成为下一代虚拟化。 
A1:反正Docker已经基本成为了开发和运维和厂商都比较接受的上云交付形式。 

Q2:容器算不算虚拟化的一种,一台服务器,上边跑很多虚拟机怎么更好的提升性能。
A2:最好不要把容器当成虚拟机,虚拟机的意思是和特定IP或者宿主机绑定,而容器特点是在云上飘来飘去。例如经常有需求是给容器分配IP,其实就是当虚拟机了 

Q3:有开源版供学习吗?     
A3:Mesos这些都是开源的,可以参考平安余何老师的著作,数人云管理平台本身是不开源的。 

微信群|运维前线

Q1:ELK本身也是Docker来部署么?  
A1:目前有状态的服务很多都有Mesos框架,但是在生产环境中产品化还不多。我们目前不建议客户数据库等应用放上来。背后逻辑也是这些服务,一般还不太需要动态扩展和更新,就算实在互联网公司里面。下一步我们也会推出企业应用商店,会把一些经过测试已经产品化的集群化组件放出来,这个还需要一些时间。 

Q2:首先说一下我还没有完全拜读完,这个话题很热,我也很感兴趣。我想问的问题,不是具体的技术问题。我是想问一下:传统的数据中心和传统的企业业务,如何在这场技术大潮中转移到新的技术架构。例如我们现在的数据中心怎样转移到您今天分享的这种架构上来?
A2:四个字“业务驱动”,不上云就宕机,或者看着满地黄金捡不起来,就自然有动力了。
一般说来是7个字,新业务上新平台。互联网的成功在于不是顶层设计,而是消费者的业务驱动。
当然,对于技术水平较高的大型企业,未来交付形式普遍容器化之下。他们引入容器的核心目的是推进自身架构云化改造。 

Q3:你们回答的是什么应用适合上云还是容器云?    
A3:首先“容器”是应用上云的Gateway,所以可以说泛指上云的应用,云端应用最好都符合Cloud Native架构。当然IaaS也是云,传统有状态应用理论上无需改造也能上虚拟机。不过传统应用强烈和底层硬件特定能力绑定,而虚拟机网络IO不一定满足需要,所以上云的过程同样需要改造。例如数据库分片来减少单节点压力等等。 

Q4:安全性呢,公司有的业务不敢轻易放上去,这方面的问题如何解决
A4:适合内部私有云,公有云需要底层IaaS协助网络和虚拟机层面隔离  查看全部


演讲嘉宾

数人云COO 谢乐冰

在德国工作十年,回国后加入惠普电信运营商部门,拥有多年项目经验和创业公司工作经验。在数人云负责产品售前和运营,专注行业的技术应用领域,为金融、电信、电商等行业提供服务。




回顾Java的发展轨迹看容器技术

因为我自己写了十几年的Java,经常把容器和十年前的Java做比较。一个公司说自己是做“Java”的,实际上涵义是背后一整套企业IT基础架构。软件一般都是各个集成商(东软、文思)大量码农兄弟们开发,主要还是用Windows。打成了WAR、EAR包之后交付给甲方,就可以在Linux环境下跑起来。同样Weblogic WAS这些中间件在底层计算集群之上,实现了企业服务的大规模运行。

中间件之下是IOE昂贵的高性能硬件,虽然也是集群化,主要依靠Scale up来提升性能。虽然中间件理论上实现了应用和硬件资源解耦,但实际上依然对硬件有非常苛刻的要求,特别是跑数据库的部分。

整个架构为了向上实现SOA的架构,虽然现实中90%以上顶多做到了“面向对象”,但并不妨碍Java(J2EE)作为企业服务交付的“通用”形式,成为了开发单位和运行单位共同接受的标准。所以Java背后代表的不仅仅是一个语言,还是一个完整的IT基础架构和产业链 —— 昂贵的高性能硬件、闭源的中间件软件、Java作为交付接口、SOA架构和开发与运维分离的模式。

背后还有两个隐性的英雄,一个是北大青鸟这样的培训机构,大量产出Java程序员。另外就是Oracle数据库,当然这些年轻程序员写的代码效率不太高的时候,全靠数据库来救场了。当然这一切还是传统的企业业务决定的,例如ERP、CRM等等,并发较低、强事物性和强一致性、逻辑和关联关系复杂。


图片1.png



如今时代发展到了蓝色的部分,云计算时代的IT架构底层不再是几台小机或者一堆刀片,更多的是企业私有云甚至是公有云,IaaS实现了资源层管理的自动化和标准化。

容器就像当年的Java一样,成为了开发和运维共同认可的接口。容器成为了应用上“云”的标准交付方式,不管是Java、Python还是C,只要用Docker打包,就可以丢到这个那个“云”上跑起来。

当然在底层各种计算资源(公有云、私有云甚至物理机)之间,也需要一个中间件来作为容器的大规模运行环境。下面是成千上万的主机,上面是乌央央的容器,中间的云计算中间件实现了两者的解耦。上面支撑的软件架构是“微服务”架构,就像当年的SOA。整体上也是实践了Devops一套运维开发方式。就像传统中间件包括了运行环境、消息队列、ESB(服务发现)和数据抽象等等,云计算中间件也都有类似的服务,例如Mesos、K8s这些容器运行环境,就对应着跑EJB的Weblogic Application Server。

总之,“容器”背后不是单个技术,而是完整的以开源软件为主的云计算IT基础架构和相应的开发和运维流程。当年虚拟机出现让大家尝到一点点云的滋味,但是毕竟局限于资源层,对开发、业务和软件架构没有影响。如今容器影响这么大,大家终于成为了应用上云的突破口,将对大家未来的职业生涯产生巨大的影响。就像今天很难招聘到懂EJB的大学毕业生,过两年很快容器和背后的互联网开源技术栈就会成为主流。

有关Mesos与K8s的老生常谈

言归正传,下面我来一步一步地介绍Mesos的实战。说起Mesos,大家往往第一个问题是Mesos和K8s有啥区别,哪个更好。我觉得这两个就像iOS和安卓,已经成为了新一代轻量调度框架的主流。两者都是源于Google的Borg,但Google自己没有使用任何一个。K8s胜在开发者多,用Go语言开发,社区活跃。Mesos是Apache项目,已经诞生了7年,目前有过超过万台规模的部署。总体上我们认为Mesos比较适合目前阶段的大规模生产环境部署,K8s目前还处于快速更新的阶段,两者都有很好的未来。当然Mesos也能兼容大数据等框架,未来目标是逐步把各种集群化的应用(Kafka集群例如)都搬到Mesos上来,实现一键安装和自动扩展。

下面是一点点Mesos的科普,其实市面上类似的文章已经不少,这里我特别推荐平安科技余何老师的《PaaS实现与运维管理:基于Mesos +Docker+ELK的实战指南》,内容非常详细。

用两句俗话说Mesos和K8s的原理,就是像使用一台电脑一样使用整个集群,类似集群的操作系统。单机的操作系统是管理单机的计算、存储和IO,集群操作系统是管理管理一堆机器的资源。目前聚焦在计算和内存之上,存储部分需要单独的分布式存储(例如Ceph和GlusterFS),网络需要SDN的支持。不过传统上IOE也是各管一摊了。


图片2.png


原理看起来也不复杂,Mesos 在每台Slave主机上安装一个Agent,不断地把剩余资源上报到Master。报告内容类似 { (node1, <2 CPUs, 4 GB>),(node2, <3 CPUs, 2 GB>) },这样Master就知道各个机器的剩余资源情况了,非常简单。

Master上面有很多框架Framework,例如Docker和Spark。你就可以把他们理解为Linux里面安装的JRE和Golang、C的运行类库。你想在Mesos上跑啥“语言”,就要部署个框架,例如跑Docker的框架就是Marathon。Mesos会把整个集群的资源按照一定的算法分配给各个框架,这个就是所谓资源调度的过程。因为Slave上报资源情况是不断更新的,所以就是所谓动态资源调度。


图片3.png


每个框架收到分配的资源之后,会自行决定将任务和资源匹配,然后通过Master将任务下发到Slave上执行。Slave上面有每种任务的执行器(Executor),就是运行环境。例如Docker任务的执行器是Mesos预装,其他类型任务执行器可能会实时下载。所以通过安装不同的框架+执行器,就可以支持各种“分布式”的任务系统。请注意这里说的一定是集群化的系统,如果是单点部署一个MySQL之类的就意义有限了。

以管理Docker任务的Marathon框架为例,它收到了Master提供的资源之后,一个是负责进行任务调度,而且还能够通过Health Check监控任务是否还活着,发现失败就重新下发任务。

这些都是常规性的解释,下面我们看看Mesos集群,看看如何一步步搭建。初始一般需要准备3台主机承载Master节点,任意多的Slave,这里建议也是3台。还有几台机器存放log等等。下面的一些图片来自前两天数人云公众号(dmesos)翻译的文章《初次微服务体验:从Docker容器农场说起》。



图片4.png


第一步 部署Zookeeper,负责整个集群的分布式一致性,例如Master领导选举



图片5.png


第二步,部署Mesos本身。我们的分布部署了3个Master,管理3个Slave节点。大家注意到,配置Mesos的时候最重要的参数就是Zookeeper,不但Master要通过ZK来进行领导选举,而且Slave也可以通过ZK来知道谁是活跃的Master.


图片6.png



到这一步,理论上已经可以用Mesos来管理集群下发任务了,大家看见下图里面资源(Slave)、任务(正在执行的已经介绍的)。 
 


图片7.png


甚至还能看到该任务的Stdout输出,就和SSH进去操作一样。
 

图片8.png


不过仅仅有Mesos,还要自己来编写框架调用接口发布任务,非常不方便。所以需要一个框架来跑容器任务,那就是马拉松(Marathon)。顾名思义用来跑各种长时间运行的服务,类似Linux里面的Inti.d,例如各种网站服务。马拉松是用Scala编写的,本身提供自己的Web管理界面,通过这个界面我们可以“遥控”Mesos来下发并保证Docker任务长久稳定执行。


图片9.jpg



马拉松的界面也非常直接,大家看看发布Docker任务的界面,基本就是填入Docker Run后面的那些参数,然后告诉马拉松要发布多少份。马拉松会匹配每个Task和Mesos提供的资源,然后通过Mesos将任务下发下去。


图片10.png



结果
 

图片11.png



服务发现

服务发现是个比较晦涩的翻译(Service Discovery),大概不妨粗略地理解成负载均衡算了。例如马拉松下发了100个网站的容器,每个容器有自己IP(一般是宿主机)和端口。显然前面需要挡一个负载均衡来分配流量。对外暴露的就是负载均衡的某个服务URL,后面自动将流量转发到某个容器的IP+端口上。


图片12.png



我们这里用HAProxy来做负载均衡,有个服务叫Bamboo会不断从ZK读出Mesos状态并且更新HAProxy的配置文件。这样新发下来的Docker会自动添加上HAProxy,而死掉的会被移除。

还有一直办法是用内网的DNS,这个DNS会维护现有的容器列表(IP+端口),并且返回任意一个的IP+端口,页实现了负载均衡和服务发现功能。不过目前Mesos DNS还不太成熟,我们一般用HAProxy。


图片13.png



几百个Docker撒出去,绝对不可能再登到主机上去找看日志。日志必须集中收集,并且提供检索功能,才能有效的Debug。解法也不新奇,无非是ELK。请注意Docker日志可以直接从API读出,另外需要增加一些应用、主机和容器有关的Meta Data。
 

图片14.png



此外分布式系统不能没有监控,黑盒子等于无法运行,所以监控要分为如下三个层面。

* 主机监控:这个并非Mesos的关注点,因为主机是资源层,本身也有自己的监控体系
* 容器层面的监控,主要是用cAdvisor,包括CPU、内存和IO
* 最最重要的是应用层监控,因为PaaS本身对外提供服务,所以监控的关注点应该是全局最终结果和逻辑正确性,而不是太纠结于个别主机和容器的

这个是分布式系统和传统系统最大的区别,关注点不再是个别容器和主机,而是业务本身。这种系统设计本来就是希望软件脱离对特定和单点硬件的依赖,通过集群化实现大规模系统的高性能和高可用。所以监控不再是着眼于“源头”,而是看重效果。很多时候平台的自愈机制甚至“埋没”了底层的一些故障,那么就让他被埋没了,只要最后效果能够得到保证。

分布式系统在应用层监控要求远远大于普通的IT系统,例如下面是一个HTTP返回状态吗的直方图,这样能很快发现是否出现大规模异常,并且通过日志系统来定位问题。


图片15.png



分布式系统和传统IT区别,就像市场经济和计划经济一样,不是要处处完全可控有计划,在最终结果保持可控情况下,突出灵活性、自由度和弹性,支持业务多变和快速发展。


图片16.jpg



这样一个基本的分布式系统就搭建完毕,当然如果是生产级别还需要有大规模集群运行调优、集群化HAProxy,监控和报警对接、多租户管理、F5的对接、和Openstack等等的IaaS对接等,这样就需要数人云这样的商业化开源方案来支持了。

此外经常有用户问到,啥样的应用可以上云呢,下面的表格回答了这个问题。


图片17.png



可以看到,这个问题的回答并不是黑白分明。最理想的当然是完全的微服务架构,可以发挥全部的作用。当然90%应用目前还是有状态应用,所以可以快速扩张,但是无法收缩,需要实现Graceful Stop功能,慢慢地收缩。所谓的无状态化改造,无非就是很标准互联网架构,不要用J2EE内置的Session就好。

 



图片18.png



本来今天还要展示一个我们的客户案例,如何将一个分布式系统迁移到Mesos之上,因为时间关系,下次再分享吧。

精彩问答


QQ群 

Q1:当初刚接触Linux的时候,最开始是在Virtualbox等虚拟机这种模拟环境里面摸索 Linux,代价低,比较容易动手和入门。对有一定基础的运维人员(但刚接触容器集群),你建议用什么配置的环境测试做 方便入门(比如测试  Mesos+ZooKeeper+Marathon+Docker)
A1:虚拟机就可以,VARGANT 

Q2:Docker的数据持久存储采用何种存储,用Ceph之类?
A2:对,各种分布式存储,例如Glusterfs 

Q3:我想问一下K8s+Docker 现在用作生产的话够成熟吗? K8s能达到高可用了吗?
A3:小集群的话可以倒腾倒腾,K8s的源码有浙大张磊老师的书 

Q4:还有就是Mesos能否和Openstack结合起来,生产环境有没有Docker和Openstack结合的案例
A4:必须可以,我们就和Openstack厂商一起合做生产系统部署了。可以这么说,完整的DCOS是包括IaaS+PaaS,如果企业要对底层资源严格管理,就需要IaaS 

Q5:我想问下Docker的性能,尤其是网络部分,比物理机和普通虚拟机差很多么,用集群性能会不会好些呢
A5:如何是Host模式,Docker网络性能和物理机一样,具体可以看  这里有一篇IBM的论文,讨论了差别:
http://domino.research.ibm.com ... 1E7B/$File/rc25482.pdf 

微信群|云实名

Q1:一直想问Doceker会不会一定成为下一代虚拟化。 
A1:反正Docker已经基本成为了开发和运维和厂商都比较接受的上云交付形式。 

Q2:容器算不算虚拟化的一种,一台服务器,上边跑很多虚拟机怎么更好的提升性能。
A2:最好不要把容器当成虚拟机,虚拟机的意思是和特定IP或者宿主机绑定,而容器特点是在云上飘来飘去。例如经常有需求是给容器分配IP,其实就是当虚拟机了 

Q3:有开源版供学习吗?     
A3:Mesos这些都是开源的,可以参考平安余何老师的著作,数人云管理平台本身是不开源的。 

微信群|运维前线

Q1:ELK本身也是Docker来部署么?  
A1:目前有状态的服务很多都有Mesos框架,但是在生产环境中产品化还不多。我们目前不建议客户数据库等应用放上来。背后逻辑也是这些服务,一般还不太需要动态扩展和更新,就算实在互联网公司里面。下一步我们也会推出企业应用商店,会把一些经过测试已经产品化的集群化组件放出来,这个还需要一些时间。 

Q2:首先说一下我还没有完全拜读完,这个话题很热,我也很感兴趣。我想问的问题,不是具体的技术问题。我是想问一下:传统的数据中心和传统的企业业务,如何在这场技术大潮中转移到新的技术架构。例如我们现在的数据中心怎样转移到您今天分享的这种架构上来?
A2:四个字“业务驱动”,不上云就宕机,或者看着满地黄金捡不起来,就自然有动力了。
一般说来是7个字,新业务上新平台。互联网的成功在于不是顶层设计,而是消费者的业务驱动。
当然,对于技术水平较高的大型企业,未来交付形式普遍容器化之下。他们引入容器的核心目的是推进自身架构云化改造。 

Q3:你们回答的是什么应用适合上云还是容器云?    
A3:首先“容器”是应用上云的Gateway,所以可以说泛指上云的应用,云端应用最好都符合Cloud Native架构。当然IaaS也是云,传统有状态应用理论上无需改造也能上虚拟机。不过传统应用强烈和底层硬件特定能力绑定,而虚拟机网络IO不一定满足需要,所以上云的过程同样需要改造。例如数据库分片来减少单节点压力等等。 

Q4:安全性呢,公司有的业务不敢轻易放上去,这方面的问题如何解决
A4:适合内部私有云,公有云需要底层IaaS协助网络和虚拟机层面隔离 




新视界 | 也许这才是大规模分发容器镜像的正确姿势

宁静胡同 发表了文章 • 0 个评论 • 387 次浏览 • 2016-03-18 19:04 • 来自相关话题

随着Docker技术的日渐火热,一些容器相关的问题也浮出水面。本文就容器数量激增后造成的分发效率低下问题进行了探讨,并提出了一种新的解决方法。发现问题,解决问题,正是IT技术不断进步的真谛,小数深以为然。

容器技术令应用程序的配置与部署工作效率极大提高,但在不同IT运维领域的具体提升效果却又不尽相同。举例来说,其在利用数据中心存储与网络容量进行容器镜像的大规模分发时往往表现得比较不尽如人意。

这确实有点反直觉:容器技术一直以高效的服务运行能力与相较于虚拟机的可观资源节约水平为人们所称道,为什么也会存在效率低下问题?答案出在Docker镜像的存储与下载方式上。从传统角度讲,存储在库中的每套镜像都必须拥有与其各层相关的全部文件,这意味着对任意主机设备上的Docker镜像进行更新,我们就需要从该库中下载完整的镜像。

在面对小型Web应用中的少量容器时,这种机制似乎构不成什么大问题。然而我们可以设想一旦容器系统数量增长至数百、数千乃至数百万之巨时,那么库的体积就会随着容器系统的增加而不断攀升,而每一次更新所需要下载的数据量也会越来越大。与此同时,获取Docker镜像的下载流量也将提升至数GB,这显然是我们所无法接受的。

像Twitter这样的企业无疑运行有大量容器系统,自然也经历过上述困扰。这种状况会随着更多企业采用容器技术而变得愈发普遍,并导致大型容器库的规模不断向外扩展。

我们认为解决容器臃肿难题的可行方案之一正是名为CernVM文件系统(简称CernVM-FS)的技术成果。其由CERN(欧洲核子研究中心)开发而成,同时囊括了来自世界各地的高能物理学领域、特别是费米实验室的辛勤贡献。

CernVM-FS的作用在于帮助科学家分发每年开发出的高达2TB的软件数据——其中一部分软件甚至每周都需要面向数十万台计算机进行多次分发与上传。CernVM-FS采用一整套独特的索引、重复数据删除、缓存与地理分布机制,旨在最大程度降低与每次下载相关的组件数量,同时尽可能加快必要的下载数据量。

Mesosphere与CERN目前正在探索如何将CernVM-FS同Apache Mesos加以结合,从而了解其在容器下载工作中的实际效果以及我们在大型容器环境下的处理效率。

CernVM-FS工作原理深度解析

CernVM-FS的基本构想诞生于2008年,当时CERN的研究人员与现在的人们一样因为底层硬件虚拟化的需求而开始审视容器技术,即寻求新的应用程序部署机制。相较于创建镜像或者软件包,他们想到使用一套全局分布式文件系统帮助科学家们将自己的软件一次性安装在一台Web服务器上,而后立足世界任意位置对其进行访问。

作为一套分布式文件系统,其首要原则就是在任意时间段之内,全部可用文件都只有一小部分接受实际访问。举例来说,要运行一台Web服务器,大家只需要使用操作系统(例如glibc与OpenSSL)中的一部分库。负责承载操作系统的分布式文件系统只需要使用必要的文件,而且事实上CVMFS只需要下载并在本地缓存这部分必要数据。当时研究人员们选择了HTTP作为下载协议,从而接入其它可用Web缓存基础设施(例如Akamai、CloudFront、Squid以及NGINX代理服务器等等)。

而第二项原则在于元数据(即与文件存在相关的信息,而非文件内容)被优先对待。一般来讲,文件系统所承载的软件会受到“libssl.so是否存在于lib32当中?抑或是存在于/lib64目录当中?还是存在于/usr/lib32当中?”这类请求所困扰。在处理这些请求时,通用型分布式文件系统往往表现得很差。CernVM-FS则将全部元数据保存在SQlite文件当中,并将其作为常规文件进行下载与缓存。在这种情况下,数百万计的元数据请求就能够以本地方式进行解析,使得CernVM-FS在速度表现上几乎与本地POSIX文件系统保持一致。

第三项原则在于,软件只能够在发布点处进行修改——其他一切客户都只能在高可用性水平下实现只读操作。多数此前存在的文件系统在设计中都无法处理CAP定理提到的权衡难题,因为这类系统会假定客户的目标始终是读取最新的可用数据版本。在这种情况下,软件必须在应用或者容器运行的同时保持即时性,这意味着运行过程中该文件系统必须交付单一快照。

有鉴于此,CERN决定使用内容可寻址存储与梅克尔树状结构。与git类似,各文件会在内部根据其(惟一的)加密内容散列进行命名。存在于不同目录内的同一文件的多套副本(例如不同Ubuntu镜像当中的“ls”实体)会被合并为单一文件。SQlite文件目录取决于其中文件的内容散列值。如此一来,其root散列值(一个160位整数)将最终确定整套文件系统快照。要关闭信任链,系统会提供一个经过加密的root散列值,每个客户端则对接收到的数据的每一位进行验证,从而确保其来自预期来源且未被篡改。

如今,CernVM-FS负责为分布在全球各地的约十万台计算机交付来自大型强子对撞机实验软件的数百万个文件与目录。

Mesos中的容器化器

Mesos通过所谓“容器化器(containerizer)”利用多种实现手段提供任务容器化能力。容器化器负责对运行当中的各个任务加以隔离,同时限定各个任务可以使用的资源量(例如CPU、内存、磁盘以及网络)。Mesos容器化器的作用可以通过所谓“隔离器(isolator)”轻松得到扩展,后者可被视为一种执行特定任务的插件(举例来说,在容器当中启动外部分卷)。

最后但同样重要的是,容器化器还能够为任务提供一套运行时环境。它允许用户将全部关联性同任务本体一道预打包至文件系统镜像当中。这套镜像随后可进行任意分发,并被用于启动该项任务。

Mesos目前已经拥有多种类型的容器化器。其默认选项为Mesos容器化器——这款工具采用Linux命名空间与cgropus以实现任务隔离同资源使用量控制,同时配合一整套隔离器实现外部功能交付。另外还有一套Docker容器化器,其利用Docker工具以提取镜像并启动Docker容器。

Mesos容器化器目前已通过扩展实现了多种镜像格式的支持能力,其中包括Docker与AppC,旨在建立一套“统一容器化器”。这套方案令新镜像格式的支持变得非常轻松:利用统一容器化器,我们只需要为新的镜像格式构建一款所谓“配置器(provisioner)”,并复用全部现有隔离代码即可。举例来说,Mesos用户可以继续使用Docker镜像,但全部提取、隔离与其它任务都通过Mesos而非Docker工具实现。

集成CernVM-FS与Mesos以实现容器镜像分发

内容可寻址存储的介入、出色的安全水平以及久经考验的扩展能力使得CernVM-FS成为一款极具吸引力的容器镜像分发处理工具。为了测试其实际效果,我们创建了一套新的CernVM-FS库,并将其添加到一套Ubuntu安装软件包当中。在此之后,我们立足于CVMFS构建了一款Mesos容器镜像配置器。相较于直接下载完整镜像,它能够利用CernVM-FS客户端以本地方式远程启动镜像root目录。该配置器可将CernVM-FS库名称作为输入数据(其在内部被映射至该CernVM-FS服务器的URL)以及充当容器镜像root所必需的库内路径。

如此一来,我们就能够立足于同一CernVM-FS库实现多种容器镜像的发布。从本质上讲,CernVM-FS库的作用等同于一套安全且可扩展的容器镜像注册表。

从容器化器的角度来看,一切其实丝毫未受影响。它仍然负责处理包含有镜像目录树的本地目录,并利用一切必要元素实现容器启动。不过这种作法的最大优势在于CernVM-FS拥有经过细化调整的重复数据删除功能(在配合Docker的情况下,基于文件或者块而非层),这意味着我们现在能够在无需下载完整镜像的前提下启动容器。一旦容器启动完成,CernVM-FS会下载必要的文件以进行任务处理。

在我们的测试当中,我们启动了一套Ubuntu容器,而后在shell当中运行了一条命令。在传统场景当中,我们需要下载完整的Ubuntu镜像,其体积约为300 MB。然而,当我们使用CernVM-FS配置器时,我们只需要下载该任务所必需的文件——具体为不足6MB。

由于CernVM-FS采用内容可寻址存储,因此我们不需要重复下载同样的文件。所以,如果我们进一步启动其它容器(例如一套CentOS镜像)并运行不同的命令,那么我们只需要下载新命令所需要的文件,并复用此前已经在Ubuntu镜像中下载过的全部通用关联性(例如Bash或者libc.so)。在这种模式下,容器层的概念已经不复存在,重复数据删除将立足于更为细化的层面进行。

我们还计划添加对该配置器的支持以利用对应的检验机制启动任意CernVM-FS目录。这将帮助开发人员更为轻松地在处理容器镜像时实现快速迭代,并使得运维人员便捷地在不同容器镜像版本间来回切换。

配合容器普及的浪潮

CERN与Mesosphere的技术团队对于将CernVM-FS与Apache Mesos集成充满期待,这也意味着IT行业将更为广泛地采纳应用程序容器技术。如果各企业与机构希望从根本层面改善应用程序构建、代码部署以及数据中心运行的实现方式,则必须要立足于高于当前实际规模的水平上进行容器的启动、关闭、更新以及管理。CernVM-FS与Mesos之间的紧密集成将能够成为一种可行途径,帮助各类用户解决容器采纳道路上的存储容量及网络带宽瓶颈。

作为一项新兴的技术,关于Docker的坑很多,需要我们共同来填满。大家如果有相关的疑问和困惑,也欢迎留言和小数进行讨论。

原文链接:https://mesosphere.com/blog/2016/03/08/cernvmfs-mesos-containers/

  查看全部

随着Docker技术的日渐火热,一些容器相关的问题也浮出水面。本文就容器数量激增后造成的分发效率低下问题进行了探讨,并提出了一种新的解决方法。发现问题,解决问题,正是IT技术不断进步的真谛,小数深以为然。



容器技术令应用程序的配置与部署工作效率极大提高,但在不同IT运维领域的具体提升效果却又不尽相同。举例来说,其在利用数据中心存储与网络容量进行容器镜像的大规模分发时往往表现得比较不尽如人意。

这确实有点反直觉:容器技术一直以高效的服务运行能力与相较于虚拟机的可观资源节约水平为人们所称道,为什么也会存在效率低下问题?答案出在Docker镜像的存储与下载方式上。从传统角度讲,存储在库中的每套镜像都必须拥有与其各层相关的全部文件,这意味着对任意主机设备上的Docker镜像进行更新,我们就需要从该库中下载完整的镜像。

在面对小型Web应用中的少量容器时,这种机制似乎构不成什么大问题。然而我们可以设想一旦容器系统数量增长至数百、数千乃至数百万之巨时,那么库的体积就会随着容器系统的增加而不断攀升,而每一次更新所需要下载的数据量也会越来越大。与此同时,获取Docker镜像的下载流量也将提升至数GB,这显然是我们所无法接受的。

像Twitter这样的企业无疑运行有大量容器系统,自然也经历过上述困扰。这种状况会随着更多企业采用容器技术而变得愈发普遍,并导致大型容器库的规模不断向外扩展。

我们认为解决容器臃肿难题的可行方案之一正是名为CernVM文件系统(简称CernVM-FS)的技术成果。其由CERN(欧洲核子研究中心)开发而成,同时囊括了来自世界各地的高能物理学领域、特别是费米实验室的辛勤贡献。

CernVM-FS的作用在于帮助科学家分发每年开发出的高达2TB的软件数据——其中一部分软件甚至每周都需要面向数十万台计算机进行多次分发与上传。CernVM-FS采用一整套独特的索引、重复数据删除、缓存与地理分布机制,旨在最大程度降低与每次下载相关的组件数量,同时尽可能加快必要的下载数据量。

Mesosphere与CERN目前正在探索如何将CernVM-FS同Apache Mesos加以结合,从而了解其在容器下载工作中的实际效果以及我们在大型容器环境下的处理效率。

CernVM-FS工作原理深度解析

CernVM-FS的基本构想诞生于2008年,当时CERN的研究人员与现在的人们一样因为底层硬件虚拟化的需求而开始审视容器技术,即寻求新的应用程序部署机制。相较于创建镜像或者软件包,他们想到使用一套全局分布式文件系统帮助科学家们将自己的软件一次性安装在一台Web服务器上,而后立足世界任意位置对其进行访问。

作为一套分布式文件系统,其首要原则就是在任意时间段之内,全部可用文件都只有一小部分接受实际访问。举例来说,要运行一台Web服务器,大家只需要使用操作系统(例如glibc与OpenSSL)中的一部分库。负责承载操作系统的分布式文件系统只需要使用必要的文件,而且事实上CVMFS只需要下载并在本地缓存这部分必要数据。当时研究人员们选择了HTTP作为下载协议,从而接入其它可用Web缓存基础设施(例如Akamai、CloudFront、Squid以及NGINX代理服务器等等)。

而第二项原则在于元数据(即与文件存在相关的信息,而非文件内容)被优先对待。一般来讲,文件系统所承载的软件会受到“libssl.so是否存在于lib32当中?抑或是存在于/lib64目录当中?还是存在于/usr/lib32当中?”这类请求所困扰。在处理这些请求时,通用型分布式文件系统往往表现得很差。CernVM-FS则将全部元数据保存在SQlite文件当中,并将其作为常规文件进行下载与缓存。在这种情况下,数百万计的元数据请求就能够以本地方式进行解析,使得CernVM-FS在速度表现上几乎与本地POSIX文件系统保持一致。

第三项原则在于,软件只能够在发布点处进行修改——其他一切客户都只能在高可用性水平下实现只读操作。多数此前存在的文件系统在设计中都无法处理CAP定理提到的权衡难题,因为这类系统会假定客户的目标始终是读取最新的可用数据版本。在这种情况下,软件必须在应用或者容器运行的同时保持即时性,这意味着运行过程中该文件系统必须交付单一快照。

有鉴于此,CERN决定使用内容可寻址存储与梅克尔树状结构。与git类似,各文件会在内部根据其(惟一的)加密内容散列进行命名。存在于不同目录内的同一文件的多套副本(例如不同Ubuntu镜像当中的“ls”实体)会被合并为单一文件。SQlite文件目录取决于其中文件的内容散列值。如此一来,其root散列值(一个160位整数)将最终确定整套文件系统快照。要关闭信任链,系统会提供一个经过加密的root散列值,每个客户端则对接收到的数据的每一位进行验证,从而确保其来自预期来源且未被篡改。

如今,CernVM-FS负责为分布在全球各地的约十万台计算机交付来自大型强子对撞机实验软件的数百万个文件与目录。

Mesos中的容器化器

Mesos通过所谓“容器化器(containerizer)”利用多种实现手段提供任务容器化能力。容器化器负责对运行当中的各个任务加以隔离,同时限定各个任务可以使用的资源量(例如CPU、内存、磁盘以及网络)。Mesos容器化器的作用可以通过所谓“隔离器(isolator)”轻松得到扩展,后者可被视为一种执行特定任务的插件(举例来说,在容器当中启动外部分卷)。

最后但同样重要的是,容器化器还能够为任务提供一套运行时环境。它允许用户将全部关联性同任务本体一道预打包至文件系统镜像当中。这套镜像随后可进行任意分发,并被用于启动该项任务。

Mesos目前已经拥有多种类型的容器化器。其默认选项为Mesos容器化器——这款工具采用Linux命名空间与cgropus以实现任务隔离同资源使用量控制,同时配合一整套隔离器实现外部功能交付。另外还有一套Docker容器化器,其利用Docker工具以提取镜像并启动Docker容器。

Mesos容器化器目前已通过扩展实现了多种镜像格式的支持能力,其中包括Docker与AppC,旨在建立一套“统一容器化器”。这套方案令新镜像格式的支持变得非常轻松:利用统一容器化器,我们只需要为新的镜像格式构建一款所谓“配置器(provisioner)”,并复用全部现有隔离代码即可。举例来说,Mesos用户可以继续使用Docker镜像,但全部提取、隔离与其它任务都通过Mesos而非Docker工具实现。

集成CernVM-FS与Mesos以实现容器镜像分发

内容可寻址存储的介入、出色的安全水平以及久经考验的扩展能力使得CernVM-FS成为一款极具吸引力的容器镜像分发处理工具。为了测试其实际效果,我们创建了一套新的CernVM-FS库,并将其添加到一套Ubuntu安装软件包当中。在此之后,我们立足于CVMFS构建了一款Mesos容器镜像配置器。相较于直接下载完整镜像,它能够利用CernVM-FS客户端以本地方式远程启动镜像root目录。该配置器可将CernVM-FS库名称作为输入数据(其在内部被映射至该CernVM-FS服务器的URL)以及充当容器镜像root所必需的库内路径。

如此一来,我们就能够立足于同一CernVM-FS库实现多种容器镜像的发布。从本质上讲,CernVM-FS库的作用等同于一套安全且可扩展的容器镜像注册表。

从容器化器的角度来看,一切其实丝毫未受影响。它仍然负责处理包含有镜像目录树的本地目录,并利用一切必要元素实现容器启动。不过这种作法的最大优势在于CernVM-FS拥有经过细化调整的重复数据删除功能(在配合Docker的情况下,基于文件或者块而非层),这意味着我们现在能够在无需下载完整镜像的前提下启动容器。一旦容器启动完成,CernVM-FS会下载必要的文件以进行任务处理。

在我们的测试当中,我们启动了一套Ubuntu容器,而后在shell当中运行了一条命令。在传统场景当中,我们需要下载完整的Ubuntu镜像,其体积约为300 MB。然而,当我们使用CernVM-FS配置器时,我们只需要下载该任务所必需的文件——具体为不足6MB。

由于CernVM-FS采用内容可寻址存储,因此我们不需要重复下载同样的文件。所以,如果我们进一步启动其它容器(例如一套CentOS镜像)并运行不同的命令,那么我们只需要下载新命令所需要的文件,并复用此前已经在Ubuntu镜像中下载过的全部通用关联性(例如Bash或者libc.so)。在这种模式下,容器层的概念已经不复存在,重复数据删除将立足于更为细化的层面进行。

我们还计划添加对该配置器的支持以利用对应的检验机制启动任意CernVM-FS目录。这将帮助开发人员更为轻松地在处理容器镜像时实现快速迭代,并使得运维人员便捷地在不同容器镜像版本间来回切换。

配合容器普及的浪潮

CERN与Mesosphere的技术团队对于将CernVM-FS与Apache Mesos集成充满期待,这也意味着IT行业将更为广泛地采纳应用程序容器技术。如果各企业与机构希望从根本层面改善应用程序构建、代码部署以及数据中心运行的实现方式,则必须要立足于高于当前实际规模的水平上进行容器的启动、关闭、更新以及管理。CernVM-FS与Mesos之间的紧密集成将能够成为一种可行途径,帮助各类用户解决容器采纳道路上的存储容量及网络带宽瓶颈。

作为一项新兴的技术,关于Docker的坑很多,需要我们共同来填满。大家如果有相关的疑问和困惑,也欢迎留言和小数进行讨论。

原文链接:https://mesosphere.com/blog/2016/03/08/cernvmfs-mesos-containers/