DevOps ≠ Chef/Puppet-InfoQ

低代码到底是不是行业毒瘤？一线大厂怎么做的？戳此了解>>> 了解详情 



 写点什么

DevOps 是一个热词，但是毫无疑问，也是未来的趋势（注 1）。高效率的 IT 组织常常贴着 DevOps 的标签，是人们讨论的焦点和学习的对象。2009 年时，人人都在讨论如何像 Flickr 一样一天内完成十几次的部署（注 2）。今天，人人都谈论如何像 Netflix/Pinterest 一样基于云基础设施构建大规模、高可用、可伸缩的服务（注 3）。

如何才能实现 DevOps 呢？很多人会不假思索地告诉你，使用 Chef/Puppet，你就能实现 DevOps。于是，DevOps 变成了一个简单的问题，选择 Chef 还是 Puppet。这并不奇怪，在开源软件盛行的今天，各种软件声称自己是 DevOps 工具，而人们通常不会去思考一项新技术或者新思路背后的缘由，人们需要的是“银弹”。

如同 Agile，把 DevOps 等同于工具层面的 Chef/Puppet，是错误的，会严重束缚人们的思维。在国内 Cloud Native 应用开发时代即将开启的今天，充分认识 DevOps 是很有必要的（注 4）。

（一）DevOps 不仅仅是工具

DevOps 是 Agile 的延伸，Ailge 依靠 Dev & Biz 部门紧密协作，通过增量交付的方式来解决需求多变的难题。DevOps 则进一步延伸到 IT 运维，通过 Dev & Ops 的紧密协作提高软件交付的质量和频率。人的重要性大于流程，流程的重要性大于工具。这个结论适应于 Agile, 也同样适用于 DevOps。工具带来的影响是短期的和片面的，流程和人所产生的影响是长期的和全面的。

事实上，大部分人都知道这个道理，只是在潜意识中仍然把 DevOps 当成 Chef/Puppet 等工具。建设 DevOps 的正确步骤应该是充分理解 DevOps 的原则，认真分析自身需求和条件，选择正确的方法和流程，最后才是选择或构建适当的工具。Learn By Example 仍然是学习和建设 DevOps 的重要途径。在今后的各种会议上，分享 DevOps 经验会越来越多。我们应该不仅仅关注讲演中提到的工具，更要多关注流程、组织结构和文化方面的分享。

DevOps 不仅仅是工具，即便是工具，其也是建设 DevOps 所需工具链中的可选工具。

（二）Chef/Puppet 只是 DevOps 工具链中的可选工具

DevOps 目的是打造标准化的、可重复的、完全自动化的 Delivery Pipeline, 其范围涵盖需求，设计，开发，构建，部署，测试和发布。除了需求、设计和开发外，其他的四个步骤都是可以自动化的。自动化是提高可测试性，一致性，稳定性和交付频率的核心。

下图来自 IBM Agile, ITITL, Cloud How DevOps brings it all together 。该图非常清晰地解释 DevOps 如何实现交付的自动化（注 5）。

图中 DevOps 流程所需要用到的工具和环境有：

源代码版本控制工具：比如 SVN， Git 等。
持续集成工具：比如 Jenkins, Bambo 等。
Artifact 存储仓库：持续集成构建后的 artifact 都统一放在一个仓库中，比如 Nexus/Artifactory, 当然也可以是 FTP, S3 等。
配置和部署工具：Chef/Puppet/CFEngine, Fabric/ControlTier，也包括新兴的 Docker 等。
Cloud Provision 工具：在云环境下，由于任何 IT Infra 资源都以编程接口提供，意味着 Full-Stack Automation (from “bare-metal to running business services”) 成为了可能。Cloud provision 工具可以自己通过 API 构建 (如 Netflix Asgard)，也可以直接使用 IaaS 服务商提供的扩展服务如 AWS CloudFormation & Opsworks，也可以使用第三方工具如 Ringscale/Scalr 等。相当一部分 Cloud Provision 本身也集成了 Chef/Puppet 来实现后续的部署和配置。
测试工具：除了传统的测试工具外，还需要模拟 Infra 灾难、验证系统健壮性的工具，如 Netflix 的 Chao Monkey。
发布工具：一般情况下，人们需要拥有 DTAP 四个环境，即开发环境、测试环境、Staging 环境和生产环境。每种环境的作用，部署方式和代码版本等是不一样。比如开发环境是持续部署的，测试环境是定期如每天晚上自动部署，Staging 和生产环境是手动触发的。
云基础设施：包括 AWS/Azure 等公有云，Cloudstack/Openstack 等私有云。

因此，我们看到，Chef/Puppet 只是实现 DevOps 工具链的可选工具，可以用来实现配置和部署自动化。但是仅靠 Chef/Puppet 本身无法实现 Full-Stack 部署自动化。

（三）仅靠 Chef/Puppet 本身无法实现 Full-Stack 部署自动化

如果要实现 Full-stack Automation，那么就必须实现环境创建自动化，软件安装和配置自动化，应用部署和配置自动化，监控和告警自动化，故障检测和恢复自动化，扩展自动化，如下图所示（注 6）。

环境创建：创建 VMs、网络、存储、负载均衡，协调不同角色 VMs 的创建过程和配置。
软件安装和配置：操作系统配置，比如创建用户、组，设置 ulimit 参数等；基础软件安装和配置，比如 mysql/nginx。这些软件的特点是变动不频繁。对于 Chef/Puppet 来说，这个步骤的自动化是其最擅长的。它们都提供大量现成的 Recipes，并抽象各种异构系统之间的差异。
应用部署和配置：部署应用代码，比如 war 包、db 脚本、php/rails 代码等。这部分的变动是频繁的。对于 Chef/Puppet 来说，其是可以做这个工作的，但是很多人认为用 Fabric/Glu 等更为合适。另外，对于复杂的系统来说，如果保证升级期间系统的可用性，系统的各个应用组件需尽量是无状态和松耦合的。如果系统的组件之间是有依赖的，那么升级期间必须动态地协调 (Orchestration)、控制好相关组件的行为。
监控和告警：包括 OS 级别和应用级别的可用性和性能监控。如果发现异常，需要能够自动发出告警信息。
健康检测和恢复：为了应付云基础设施故障，系统需要 Design By Failure. 在异常发生时，系统可以发现并进行自动处理。
自动伸缩：一般情况下，业务存在高峰期和低估期。为了节省成本，系统应该是可以自动伸缩的。

对于上述的每一个步骤，看似都存在现成的工具可以用来实现自动化。但是，实现 Full-Stack 部署自动化从来就不是一件容易的事情，绝非简单通过选择、拼凑相关工具即可实现。Autodesk 中国研发中心最近在 InfoQ 上分享了他们基于AWS 的自动化部署实践。文章详细阐述了业务目标，设计目标和限制，和最终的实现方案，是一个非常好的案例。在这里，我们再来分析一下两种差异较大的实现方式。

(1) 基于 PaaS 的实现方式 (以 Cloud Foundry 为例)。

环境创建

用户不需要创建物理资源环境，Cloud Foundry 会自动创建并分配资源给各个租户，用户无法控制底层 OS 等

软件安装和配置

用户不需要软件安装。Cloud Foundry 已经安装好相关软件，只是支持的类型和版本有限

应用部署和配置

Cloud Foundry 提供接口，用户调用接口进行应用部署和配置。应用类型必须是 Cloud Foundry 支持的，只能进行有限的配置，比如 Tomcat 的配置参数等

监控和告警

Cloud Foundry 提供监控服务，但是 Metric 类型有限，无法支持自定义 Metric

健康检测和恢复

Cloud Foundry 提供 Container 级别的健康检测和恢复

自动伸缩

基于 Cloud Foundry 提供的 monitoring 接口和应用控制接口，可以实现 instance 级别的自动伸缩

貌似这种方式是最完美的方案，Cloud Foundry 基本替你实现了上述的所有自动化步骤，应用开发人员只需专注于应用逻辑本身的开发。然而，Cloud Foundry 也限制了用户的选择权和控制权，特别是大型的、复杂的、分布式系统，开发人员需要的是 Full-Stack 可控制性。

(2) Netflix 的实现方式。

环境创建

通过自己研发的 Asgard 管理和部署工具实现

软件安装和配置

基础软件和配置都打包成 AMI，基于 Netflix 自己的打包工具 Aminator

应用部署和配置

同上，应用代码和配置也打包进 AMI（注 7）

监控和告警

Leverage AWS Cloudwatch, 同时也将通过自己开发的 Servo

Lib 将 custom metric 发送至 Cloudwatch.

健康检测和恢复

Leverage Atoscaling group，健壮性测试有 Netflix 自己开发的 Chaos Monkey 工具

自动伸缩

Leverage AWS AutoScaling Group

Netflix 除了 Leverage AWS 的 CloudWatch/Auto Scaling Group/ELB 等服务外，自己也开发了一序列工具完成了 Full-Stack 部署自动化。这些工具通过 Asgard 这个可视化云管理和部署控制台集成起来。另外，Deployable image 这种部署模式虽可简化部署并确保一致性，但是一部分复杂性转移到了应用层面（注 7）。系统的各个组件是无状态和松耦合，同时还需要 Eureka 这种服务来实现中间层的负载和 failover。

在上述两个案例中，我们都看不到 Chef/Puppet 的影子。即便是 Cloud Foundry 自身的部署工具 Bosh，但也不是基于 Chef/Puppet。所以，尽管 Chef/Puppet 非常流行，并且有很多成功案例，但是我们决不能把 DevOps = Chef/Puppet。它们只是建设 DevOps 所需工具链中的可选工具，仅此而已。