基于Docker实现DevOps的一些探索

DevOps介绍

DevOps(Deveplopment和Operations的简称)，中译为开发运维一体化，可定义为是一种过程、方法、文化、运动或实践，主要是为了通过一条高度自动化的流水线来加强开发和其他IT职能部门之间的沟通和协作，加速软件和服务的交付。

在一个较成熟的软件和服务交付的团队里，就技术层面来说主要分为三个组成部分:开发、测试和运维。DevOps的作用就是将这三个部分紧密的连接起来，提供一条从软件开发到质量保障到技术运营的自动化流水线，加强不同角色之间的沟通和协作，基于用户需求实现软件和服务的快速交付。

"开发的这群傻叉新给的发布包又把系统CPU搞到100%了，应用又夯住了，都是些什么水平的人啊..."

"运维的这帮傻鸟技术太差，维护的是些什么稀烂的系统，在我这跑得好好的，上他们那应用就挂..."

"这是开发的锅..."

"这是运维的盘..."

描述得略显浮夸...但这种踢皮球的事情在IT公司里面真的是随处可见。无谓对错，也无锅可背，都是由开发和运维的基因所决定，但是最终的受害者却是用户。偏偏比较有意思的就是，开发和运维人员所做的这些也都是为了用户，开发人员必须根据用户的需求对应用的功能进行不停的变更，运维人员也必须根据用户的需求提供稳定和持续的服务。各司其职的同时也在两者之间形成了一面无形的墙，阻碍了开发和运维之间的沟通和协作，而DevOps的出现就是为了击碎这堵无形之墙。

DevOps落地的思考

技术层面

DevOps不是一个工具，但它需要被工具来实现，好在现今已经有了很多商业版和开源版的软件来形成一个有效的工具链来作为DevOps技术层面的支撑。但是光有工具还不够，再好的工具没人会用也没意义，所以需要有熟悉这个工具链的IT人员来提供技术支持，利用工具实现DevOps的高度自动化。

流程层面

DevOps是一条从开发到运维的流水线，想要流水线能够高效的自动运行，必须要设定一系列的流程和规范来进行管控。IT的管理者需要有基于软件或服务交付的全局观，能够清晰的认识到交付周期中不同角色的痛点在哪里，进而定制出合适的协作流程。

组织层面

DevOps并不是简单的将开发部门和运维部门合并，而是加强开发部门和运维部门之间的协作和沟通。这需要管理者们对企业的IT部门有着足够的重视并且愿意去推动DevOps这种开发和运维间高效协作的模式，并且开发和运维的人员之间也需要有开放、接纳和协作的意识。

DevOps是一个虚无缥缈的玩意儿，它并不能被工具或软件来简单的定义或量化。但工具或软件却是实现DevOps的一个重要组成部分，而Docker就是实现DevOps最合适的工具之一。

Docker介绍

Docker是一个分布式应用构建、迁移和运行的开放平台，它允许开发或运维人员将应用和运行应用所依赖的文件打包到一个标准化的单元(容器)中运行。

容器是一个非常早期的技术，Unix的chroot功能可以说是容器的雏形，而后到大家所熟知的基于Namespace和Cgroups技术的LXC(Linux Container)，最后到现在如日中天的Docker。站在前人的肩膀之上，Docker最妙的地方就是将容器的使用简单化和标准化，再配合一波开源，互联网，云计算，大数据的浪潮，可谓是时代的宠儿。

很多人都喜欢拿容器和虚拟机对比，其实容器和虚机都是属于虚拟化技术的一种实现。两种架构在底层上相同，需要物理硬件和操作系统的支持。不同的是虚拟机场景中，Hypervisor(如KVM)作为操作系统到虚拟机的中间层,而容器场景中Docker Engine(以Docker为例)作为操作系统到容器的中间层。虚机封装操作系统和应用，而容器则直接封装应用，这也是为什么容器要比虚机轻量的原因。

上图中将虚拟机和容器的特性进行了对比，可以看出容器相对于虚拟机比较有优势的地方就是轻量、灵活、资源利用率高。缺点主要就是隔离性不如虚拟机，也就是一直被无限放大的容器的安全性问题。但偏偏就是因为容器没有完全被隔离到一个密封的小黑屋里面，所以才能带来比虚拟机更好的资源利用率。

个人认为容器在短期之内还取代不了虚机，在未来很长一段时间内会是容器和虚机并存的情况。而到最终谁替代谁，取决的不是技术本身，而是用户体验时代的需求。

PS:希望有朋友能够发现此图中的一点小漏洞。

Docker基本组件介绍

• Docker Image
  Docker镜像是一个运行容器的只读模板。
• Docker Container
  Docker容器是一个运行应用的标准化单元。
• Docker Registry
  Docker注册服务器用来存放镜像。
• Docker Engine
  Docker引擎用来在主机上创建，运行和管理容器。

了解Docker的朋友都知道,Docker将自身最主要的特点以下面这一句话来描述"Build,Ship and Run Any App Anywhere"。Build出Image，然后使用Registry来Ship镜像，最终使用Engine将Container和包含的App在任意平台(Anywhere)上运行起来。

Docker原生工具介绍

• Docker Machine 让用户在基础架构平台快速部署Docker宿主机
• Docker Swarm 让用户在集群环境中调度和运行容器
• Docker Compose 让用户在集群环境中编排和部署应用

这三个工具构成了Docker的原生环境，加上比较火的k8s,Mesos,Rancher,etcd等外部生态，构建出了一个比较完整的Docker容器生态圈。对于原生工具和外部工具，个人觉得工具或技术并没有好坏之分，主要还是看适用场景和客户需求。而正是有这些生态的合作和竞争造就的乱世，才促进了容器技术的高速发展和逐步成熟。

Docker适用的场景

• 持续集成和持续交付
• 开发运维一体化
• 容器云
• 大数据
  

Docker官方给的Use Case是CI/CD,DevOps,Big Data和Infrastructure Optimization(Cloud)。

这里比较有意思的就是，这几个使用场景似乎正好描绘着Docker当前的发展史。

起初Docker的出现主要面向的对象是开发者，为开发者提供应用快速开发和测试的环境，这就是CI/CD所在的场景。

随后的发展使得Docker不再仅仅只关注开发层面的东西，而在向运维层面迈进，就出现了DevOps的场景。

既然有了运维，那肯定避免不了接触到基础架构的东西，而现今的基础架构基本都是围绕着云计算来展开，所以Docker又涉及到了基础架构优化的层面，也就是Container Cloud。

基础架构的容器云有了，那么势必需要对云中的应用提供服务，加上Docker自身的许多优势，自然而然的又涉及到了Big Data的使用场景。

而Docker自身的解决方案Docker Cloud和Docker Data Center的先后推出也侧面反应了从开发到运维场景的逐步支持。DDC的出现更是将目标直接瞄准了企业内部容器云。

难以分清是新技术成就了Docker，还是Docker承载了新技术。至少就目前来看，Docker的发展方向是顺应这个时代的。这只是三岁多的Docker，不敢想象它在将来会有多大的能量爆发出来，将这些留给时间去述说。

Docker实现DevOps的优势

优势一

开发、测试和生产环境的统一化和标准化。镜像作为标准的交付件，可在开发、测试和生产环境上以容器来运行，最终实现三套环境上的应用以及运行所依赖内容的完全一致。

优势二

解决底层基础环境的异构问题。基础环境的多元化造成了从Dev到Ops过程中的阻力，而使用Docker Engine可无视基础环境的类型。不同的物理设备，不同的虚拟化类型，不同云计算平台，只要是运行了Docker Engine的环境，最终的应用都会以容器为基础来提供服务。

优势三

易于构建、迁移和部署。Dockerfile实现镜像构建的标准化和可复用，镜像本身的分层机制也提高了镜像构建的效率。使用Registry可以将构建好的镜像迁移到任意环境，而且环境的部署仅需要将静态只读的镜像转换为动态可运行的容器即可。

优势四

轻量和高效。和需要封装操作系统的虚拟机相比，容器仅需要封装应用和应用需要的依赖文件，实现轻量的应用运行环境，且拥有比虚拟机更高的硬件资源利用率。

优势五

工具链的标准化和快速部署。将实现DevOps所需的多种工具或软件进行Docker化后，可在任意环境实现一条或多条工具链的快速部署。

实例分享

架构介绍

该DevOps环境基于开源产品Rancher进行管理，分为三套环境和一套横跨各环境的私有Registry。基于RancherUI和Docker宿主机，每套环境对不同的角色配置权限管理，每个角色仅能访问对应的环境。开发、测试和运维人员可自由选择Web UI或Docker CLI的方式去管理自己的环境。

DEV ENV

定义为开发环境，包含开发人员客户端的笔记本和服务端的一台Docker主机。

**TEST ENV **

定义为测试环境，包含测试人员客户端笔记本和服务端的一台Docker主机。

OPS ENV

定义为运维环境，包含运维人员客户端笔记本和服务端的两台Docker主机构建的Swarm集群。

**Pri-Registry **

私有镜像服务器，整个DevOps流水线中的核心。将镜像作为最终的交付件在不同的环境中Ship和Run，以实现从Dev到Ops应用环境的一致性部署。

运作流程

• 开发者通过本地的Git客户端向服务端的Gogs提交代码，Jenkins将代码构建成镜像放到本地。开发人员将对应的镜像启动容器来预览的开发结果。如果确认已满足预期，则将该镜像推送到私有的Docker注册服务器中进行存储。
• 测试人员将私有镜像仓库中开发人员新提交的镜像运行成容器，并进行手动或者自动的功能性测试，测试通过后镜像会被打上一个新的Tag以被其他环境使用。
• 运维人员基于私有镜像仓库中被打过Tag的镜像启动为容器，最终交付给客户。

目前该环境主要用于Docker Image的构建和发布，Ops(Prod)环境中跑了一些项目内部使用的应用，但更多的是作为Demo环境提供给客户访问而并非真正意义上的生产环境。

由于时间有限，此次交流就到这里了。内容比较粗燥，旨在抛砖引玉，谢谢大家的参与。开源的不仅仅是技术，而是思想，整套环境搭建的过程和技术细节会在本人的微信订阅号和DockOne官方网站(dockone.io)中陆续发出，有兴趣的朋友可关注“小张烤茄”订阅号，再次感谢!

Q&A

Q1：对于一些中小互联网企业尤其devops二次开发能力不强的，在使用docker 集群方面有什么建议？

A2：一条DevOps流水线对集群环境的需求不高，我们更应该关心的是对每一个步骤的单个工具怎么去使用和管理，集群环境适用于都会用到大规模的容器部署中。还是那句话，技术不分好坏，选择最合适的就行。如果把容器当作虚拟机来跑，可以解决你的一些问题，那就这样跑又如何呢，技术或者工具是为需求服务的。

Q2：运维投拆开发应用消耗太大，为什么用了容器就能解决了，只是开发和运行用了同一套环境，性能低下一样得靠优化，客器只是让大家在同一个平台上对话了。

A2：对的，如果应用本身的代码写得不好，不论在开发环境和运维环境都会造成应用消耗大的问题。使用DevOps这样的流水线，一个方面就是解决环境异构的问题。好比我是一个开发者，我在Windows里面开发,java用的是1.5。但是在生产环境中，APP服务器用的是Linux,java是1.6,那这样可能会引起功能性的问题。

Q3：您好，有些传统应用比较难拆分，上云的话难免会把容器做虚拟机用，请问在这一块有好的实践么？

A3：传统应用拆分确实是个难题，从可用性和性能方面考虑把传统应用放到容器当作虚拟机跑是可以的。这种场景实现了硬件的资源的高利用率，但是由于传统应用的紧耦合，很难以利用到容器的灵活迁移和弹性部署。而且需要关心的是，传统应用放到容器里面跑，数据保护这方面到底如何去做。目前我这边没有很好的实践方案，而且这种案例确实是国内整个Docker界需要面临的一个问题。

Q4：虚机或容器，传统双机节点模式部署，出问题通过双机切换主备应用还有意义么？

A4：有，双机热备或互备的方案是在传统IT环境中经历了时间的考验的。容器的出现并不是要颠覆以前的所有，而是让客户的应用场景拥有一个多的选择。

Q5：目前容器化的都是应用app之类的，可以使用容devops器化一个类Unix系统么？比如容器化一个苹果系统能实现么

A5：容器的定位就是在于APP的封装，就算有CentOS这样的镜像也只是为了拉取运行应用需要的Bin文件和Lib文件。你这个问题有点是想把容器当作虚拟机跑了，可以去了解一下RancherVM或HyperContainer，或许能够满足你的需求。