从devops到containerops，打破开发、IT运营之间的墙！

1 什么是Devops

我们都知道在软件开发过程中应用程序的发布是整个开发流程中压力最高、风险最高的流程。这是需要开发与运营通力合作才能顺利完成的工作。而在传统的软件组织是将开发、IT运营和质量保障设为各自分离的部门。这就造成了他们之间有一堵沉重的墙，使得这些流程是相互割裂开的。

而当前敏捷开发的要求：

1. 尽早地、持续地交付可评价的软件来使客户满意。

2. 频繁交付可使用的软件，交付间隔越短越好。

3. 在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。与开发团队以及在开发团队内部要面对面的交谈。

等等的这一切都要求这三个部门融在一起，要将横在Dev(开发)和Ops(运维)之间的鸿沟给填平，DevOps就在这样的背景中应运而生。

Devops就是这样的一个方法论，它是来思考如何让Dev(开发)和Ops(运维)进行合作与协同，它要求我们：

1. 要考量系统级别的整体效率，而不是某一个环节上的效率。

2. 要确保能够提供持续不断的反馈循环。

3. 要持续的学习和吸取经验，不停的提升。

而其最终目标是实现从代码编译到应用上线自动化实现，以及相应的自动化运维。从而减轻运维人员的压力，提升运维效率，释放生产力，同时降低运维门槛，使得开发人员能够参与到运维工作之中，降低Dev(开发)和Ops(运维)沟通成本，打破两者之间的“墙”。

2 容器给Devops带来了什么?

于2013年初诞生的Docker，它能够快速的交付和部署、高效的虚拟化、轻松的迁移和扩展，简单的管理，更加敏捷。使得它天然的拥抱敏捷开发，与微服务开发结合起来。云原生开发的概念甚嚣尘上，尤其当K8S成为容器编排的事实标准之后，云原生越加火热，而它天然包含了devops流程。

在中国Devops时代社区发布了中国IT企业DevOps持续交付流水线现状调查报告，几个数据印象比较深刻：

• 调查者中65%以上用户实现了一周一次以上的部署，在微服务的时代快速发布将成为常态。

• 64%的受访者已经引入持续交付流水线，其中86%都在使用Jenkins。看来Jenkins基本都已经成为交付流水线的代名词了。

• 各阶段工具与流水线集成比例低于25%，流水线自动化出发比例只有31%。可见虽然不少公司都已经开始交付流水线了，但各个阶段的集成还是比较缺乏实践。

由此可见Jenkins已经成为了大家实现devops流水线首选工具。但是Jenkins受限于时代的局限性，虽然在当时是跨时代的优秀产品，但是在当前技术迅速发展的时代，有些固有问题很难解决。首先master节点的高可用无法保证，其次当脚本越来越复杂时性能的消耗会非常严重，即使使用Master+Slave方式，随着集群规模的增大，网络维持的消耗都非常巨大，高峰期会严重影响开发和部署效率。

当docker，k8s出现后，我们突然发现有了更好的解决方案，我们将每个Stage做成一个docker容器，利用K8S的能力去编排Devops流程。使得Devops流程的编排更加灵活，另外借用K8S实现了高可用，以及环境的无关性。同时使得Devops流程的高扩展性。于是华为提出了ContainerOps的概念。

3 华为云是如何实践ContainerOps的

我们华为云在实践ContainerOps的时候，不是简简单单的把它视作流水线，一个简单的工作流。我们更愿意从用户的视角去看待为什么选择上云，上云给他们带来了什么好处。

在那个还没有云技术，大家把机器都部署在机房的时代，往往运维部门都需要提前三个月收集大家的资源需求，提前采购资源。一旦出现紧急上线的情况，就会很容易出现系统上线失败。但是用户上云后，这种情况发生的可能性非常小。在云上用户资源是按需申请，降低了运维难度，节省了成本提高了资源利用率。除了这一有优点，云还提供了各种自动化运维工具集，但实际上这些工具对于用户来说相互之间的使用是孤立的。而且对于用户来说，他最关注的是如何降低自身的运维成本，让应用从代码到系统上线完全自动化。

华为云的ContainerOps不只是简单的把自己定义成一条流水线，而是有机的把这些自动化工具集整合在一起，给用户上线服务的完美体验。

1. 完善：从源码到部署的完整的一套流水线，满足客户各方面的需求。

2. 灵活：提供了多种Stage，客户可以灵活搭配自己的流水线。涵盖了源码下载、镜像构建、Jenkins构建、镜像部署、灰度发布等核心组件。满足用户多样化的需求。

3. 全连接：提供多种notification方式，方便客户原有系统的接入，以轻量化的形式去使用流水线。

4. 安全：基于镜像仓库的权限管理，客户完全不用担心镜像的安全性，保障用户的使用。