本文目录
基于容器的DevOps平台应该提供哪些功能
“DevOps”提倡开发和IT运维之间的高度协同，它拓展和完善了持续集成和发布流程，从而能够提高复杂的分布式应用的开发和运维效率，加快交付速度。DevOps的理论已经响彻业界，快节奏的互联网公司大都已经按照不同的方式在公司内部的研发体系中引入了DevOps流程，它的效果也已经得到了实践验证。公有云巨头们都了提供DevOps服务，例如亚马逊的AWS OpsWorks、阿里云的CRP持续交付平台、网易蜂巢等；一些新兴的创业公司例如时速云、DaoCloud、灵雀云等也都提供了基于容器云平台的DevOps服务解决方案。
然而，DevOps只是一个方法、过程的统称。 运维人员可以自己编写脚本或者使用Puppet、chef、Docker等自动化配置工具实现DevOps的流程（我们的项目就是通过自己攒的工具实现了DevOps流程），也可以由专门的平台提供全套DevOps解决方案，但是这个平台该有什么具体功能、该如何实现，并没有标准答案。
本章节将简要对比分析业内的各平台提供的DevOps平台服务功能及实现方式，并且依据自身项目的实践经验，梳理出适合支持DevOps流程的、比较实用且适合为企业提供容器服务的平台需求。
几家DevOps相关平台的对比
如表所示简要对比了阿里云CRP平台、阿里云容器服务、网易蜂巢、时速云、DaoCloud几家：
阿里云CRP（持续发布平台）：主要作用是在Dev阶段提供快速构建、发布功能，最终能直接将开发成果发布到阿里云ESC上，Ops部分就由ESC接管了。具体来说平台提供项目代码管理、代码构建、持续集成、持续发布功能，其功能亮点在于可视化的CI、CD流程，代替了Jenkins的部分功能，不过个人感觉简化了的可视化发布向导，方便得同时有失灵活性。
阿里云容器服务平台、时速云和DaoCloud差不多：包括构建源代码将应用打包成容器镜像、将容器部署到云端、镜像仓库管理、服务编排、平台对运行的容器及集群进行调度管理、支持负载均衡及数据卷等功能。可以说把Dev阶段和Ops阶段连接起来了，但是更侧重于Ops阶段的容器管理。
网易蜂巢：功能纯粹只管Ops阶段，支持用户把镜像提交到镜像仓库，然后在平台上部署容器、并提供容器调度及负载均衡等操作。
容器服务平台针对运维阶段应该具备的重点功能：
Google在很早以前就已经把容器应用到生产运维环境了，目前，包括腾讯、新浪、京东在内越来越多的国内互联网企业已经在生产环境中受益于容器的轻量和敏捷性，大幅提高了运维资源使用效率，据京东员工发布的技术文章提到：今年618核心业务都容器化了。因而主流的容器服务平台都在容器弹性调度和容器集群管理方面下功夫，具体来说对于运维的支持以下功能是必不可少的：
i. 镜像仓库：镜像仓库中需要具有较为丰富的基本镜像；并且支持用户高速的上传、下载镜像，并且镜像仓库需要有一定的权限控制；
ii. 容器调度管理：容器实例的启、停；容器集群资源管理；弹性伸缩；实例的failover；安全控制等。
iii. 相关容器组合的编排管理：包括容器的跨节点关联、涉及到网络和数据共享等功能；容器集的动态生命周期和横向扩展等功能，可实现例如数据库集群部署等复杂的运行环境部署和管理。
iv. 服务发现相关功能：可以让一个应用或者组件动态发现其运行环境以及其它应用或组件的信息，主要场景如负载均衡、环境变量的更新等功能。
v. 运行环境的日志、监控和告警：为保证生产环境正常运行，容器实例及其主机系统级别的日志、监控和告警功能是必不可少的。
容器服务平台针对开发阶段应该具备的重点功能：
随着容器技术的兴起，近1-2年容器技术大会也频繁的召开，根据各家互联网公司的积极分享的实践经验可知：容器重新定义了交付方式，大多数互联网公司已经大规模的把容器引入了开发环节，采用容器交付应用。实践证明：容器的可移植性和良好的隔离性，能够充分提高开发和发布效率。因为各家公司软件开发使用的开发工具和开发流程不同，具体在开发阶段基于容器实现快速开发、部署的功能并没有标准化。这里梳理一下开发阶段的容器服务平台应该具有的功能：
i. 提供基础的开发环境，使得开发者只需要关注代码开发减少相关工具的安装和配置工作量：例如本项目用到的Git库、Docker镜像仓库、禅道、wiki、jenkins等工具；
ii. 利用自动化工具及持续集成工具如Puppet、chef或者原生的脚本、jenkins、Dockerfile等工具，实现自动化的持续集成和持续发布，简化运维工作；
iii. 提供各类服务的容器镜像，可在平台上快速部署开发所需要的服务，并且支持通过环境变量绑定服务；
iv. 实现开发环境、测试环境以及生产环境的隔离以及环境的快速搭建和回收；
v. 持续集成、部署的日志和监控、告警等。
如何构建适合自己的 DevOps 工具与平台
DevOps 起源于亚马逊和 Google 这样的大型互联网公司
DevOps: Development和Operations的组合
可以把DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集。
传统的软件组织将开发、IT运营和质量保障设为各自分离的部门。在这种环境下如何采用新的开发方法（例如敏捷软件开发），这是一个重要的课题：按照从前的工作方式，开发和部署不需要IT支持或者QA深入的、跨部门的支持，而却需要极其紧密的多部门协作。然而DevOps考虑的还不止是软件部署。它是一套针对这几个部门间沟通与协作问题的流程和方法。
需要频繁交付的企业可能更需要对DevOps有一个大致的了解。Flickr发展了自己的DevOps能力，使之能够支撑业务部门“每天部署10次”的要求──如果一个组织要生产面向多种用户、具备多样功能的应用程序，其部署周期必然会很短。这种能力也被称为持续部署，并且经常与精益创业方法联系起来。 从2009年起，相关的工作组、专业组织和博客快速涌现。
DevOps的引入能对产品交付、测试、功能开发和维护（包括──曾经罕见但如今已屡见不鲜的──“热补丁”）起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。
以下几方面因素可能促使一个组织引入DevOps：
使用敏捷或其他软件开发过程与方法
业务负责人要求加快产品交付的速率
虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍
数据中心自动化技术和配置管理工具的普及
有一种观点认为，占主导地位的“传统”美国式管理风格（“斯隆模型 vs 丰田模型”）会导致“烟囱式自动化”，从而造成开发与运营之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。
DevOps经常被描述为“开发团队与运营团队之间更具协作性、更高效的关系”。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低。
DevOps对应用程序发布的影响
在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低，原因如下：
与传统开发方法那种大规模的、不频繁的发布（通常以“季度”或“年”为单位）相比，敏捷方法大大提升了发布频率（通常以“天”或“周”为单位）
减少变更范围与传统的瀑布式开发模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。加强发布协调靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电话会议、即时消息、企业门户（wiki、sharepoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。自动化强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。
什么是DevOps
DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
引入DevOps的因素：
1、使用敏捷或其他软件开发过程与方法
2、业务负责人要求加快产品交付的速率
3、虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍
4、数据中心自动化技术和配置管理工具的普及
5、有一种观点认为，占主导地位的“传统”美国式管理风格（“斯隆模型vs 丰田模型”）会导致“烟囱式自动化”，从而造成开发与运营之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。
