基于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的朋友都知道，Docker将自身最主要的特点以下面这一句话来描述"Build,Ship and Run Any App Anywhere"。Build出Image，然后使用Registry来Ship镜像，最终使用Engine将Container和包含的App在任意平台（Anywhere）上运行起来。 Docker原生工具介绍
这三个工具构成了Docker的原生环境，加上比较火的Kubernetes、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应用环境的一致性部署。运作流程
目前该环境主要用于Docker Image的构建和发布，Ops（Prod）环境中跑了一些项目内部使用的应用，但更多的是作为Demo环境提供给客户访问而并非真正意义上的生产环境。 由于时间有限，此次交流就到这里了。内容比较粗燥，旨在抛砖引玉，谢谢大家的参与。开源的不仅仅是技术，而是思想，整套环境搭建的过程和技术细节会在本人的微信订阅号和DockOne官方网站（dockone.io）中陆续发出，有兴趣的朋友可关注“小张烤茄”订阅号，再次感谢! Q&AQ：对于一些中小互联网企业尤其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，或许能够满足你的需求。 DevOps 概念的流行跟近来微服务架构的兴起应该有很大关系，微服务架构主张一个应用只做一件事，而 Docker 的应用哲学也是一个容器只负责一个功能，从一致的理念上来说 Docker确实是适合微服务架构的，说Docker适合DevOps，却不止理念一致这一原因。 DevOps 是两个传统角色 Dev(Development) 和 Ops(Operations) 的结合，Dev 负责开发，Ops 负责部署上线，但 Ops 对 Dev 开发的应用缺少足够的了解，而 Dev 来负责上线，很多服务软件不知如何部署运行，二者中间有一道明显的鸿沟，DevOps 就是为了弥补这道鸿沟。DevOps 要做的事，是偏 Ops 的；但是做这个事的人，是偏 Dev 的, 说白了就是要有一个了解 Dev 的人能把 Ops 的事干了。 Docker 出现之前，你要搭建一个 DB 环境，你需要下载 DB 的软件，下载 DB 依赖的软件，编译，安装，配置，最终让服务可用。一旦中间有个步骤出错，还需从头再来，Ops 对这些操作轻车熟路，如果让一个 Dev 来做，痛苦之处可想而知。而用了 Docker 之后，你只需要 pull 一个镜像，run 一个容器，你的服务就可用了，所有的依赖，别人都在镜像里帮你做好了，这样是不是就容易多了？ 换成公司自己开发的应用，不用 Docker 的话，在部署上线前也需要做同样的事，有了 Docker 之后，只需在一些开源的基础镜像上 build 出公司自己的镜像，以后的部署上线操作都只是 pull 镜像、run 容器的操作了，那么 Dev 做 Ops 的事就容多了。
Docker 是容器，主要的目的是为了隔离，但从我接触身边的人应用 Docker 的主要却是因为 Docker 镜像、容器运行的简单便捷，适合于应用的快速部署上线、快速弹性扩充，从这点来说，Docker 是适合 DevOps 的。 DevOps是个概念，不指任何具体的技术，类比Develop（开发）和Operation（运维），实际上DevOps就是开发和运维组合的概念。 Docker适合DevOps，原因是Docker实现的资源隔离，而且提供易用的镜像管理，还有很多优点我就无需赘叙，实际上我每天用到的大部分软件开发和调试都在Docker容器内。 Docker项目口号是Build, ship and run any app, anywhere，实际上与Devops的终极目标类似，这也是Docker希望实现的目标，因此Docker是实现Devops很好的工具。----------------------------------------------- 1. Docker的容器是把应用程序和环境打包在一起的，所以是一次构建，多处发布。举个例子，以前你开发完程序后，测试人员和运维人员都需要去部署，通过docker只需要一个run命令即可。因此docker最大的好处就是标准化了应用交互，同时支持多个不同平台和多个不同的云服务商，只要机器能装docker，就能无差别的运行程序。 2. docker的容器由于没有包含操作系统个，可以更方便的植入你的应用的虚拟化容器中 3. 运行效率更快，没有操作系统，比hyper-v快N倍 4. 方便管理，通过容器云平台，如Ghostcloud可以更方便的做集群和容器管理 &nb (责任编辑：IT) |
