基于Docker实现DevOps的一些探索

基于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实现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环境提供给客户访问而并非真正意义上的生产环境。

Q&A

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

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

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

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

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

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

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

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

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

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