本文摘抄自：DevOps的概念与实践
目录
仅靠Chef/Puppet本身无法实现Full-Stack部署自动化
基于PaaS的实现方式 （以Cloud Foundry为例）
DevOps不仅仅是工具
DevOps是Agile的延伸，Agile依靠Dev & Biz部门紧密协作，通过增量交付的方式来解决需求多变的难题。DevOps则进一步延伸到IT运维，通过Dev & Ops的紧密协作提高软件交付的质量和频率。 人的重要性大于流程，流程的重要性大于工具。 这个结论适应于Agile，也适用于DevOps。 工具带来的影响是短期的、片面的，流程和人产生的影响是长期而全面的。
Chef/Puppet 只是DevOps工具链中的可选工具
DevOps的目的是打造标准化的、可重复的、完全自动化的Delivery Pipeline，其范围涵盖需求、设计、开发、构建、部署、测试、发布。除了需求、设计和开发，其他都是可以自动化的，自动化是提高可测试性、一致性、稳定性和交付频率的核心。
DevOps流程所需要用到的工具和环境有：
-
源代码版本控制工具： SVN、Git等
-
持续集成工具： Jenkins、 Bambo等
-
Artifact存储仓库：持续集成构建后的artifact 都统一放在一个仓库中，比如Nexus/Artifactory，也可以是FTP、S3等
-
配置和部署工具：Chef/Puppet/CFEngine, Fabric/ControlTier，也包括Docker等
-
Cloud Provision工具：在云环境下，由于任何IT Infra资源都以编程接口提供，意味着Full-Stack Automation成为了可能。Cloud Provision工具可以自己通过API构建，也可以直接使用IaaS服务商提供的扩展服务，也可以使用第三方工具，相当一部分 ，Cloud Provision本身也集成了Chef/Puppet来实现后续的部署和配置。
-
测试工具：传统测试工具，模拟Infra灾难、验证系统健壮性的工具，如Netflix的Chao Monkey
-
发布工具：一般情况下，需要DTAP四个环境：开发、测试、Staging、生产。每种环境的作用、部署方式、代码版本等是不一样的。
-
云基础设施：包括AWS/Azure等公有云，CLoudstack/OpenStack等私有云
仅靠Chef/Puppet本身无法实现Full-Stack部署自动化
如果要实现Full-Stack Automation，需要实现环境创建自动化、软件安装和配置自动化、应用部署和配置自动化、监控和告警自动化、故障检测和恢复自动化、扩展自动化。
-
环境创建：创建VMs、网络、存储、负载均衡，协调不同角色VMs的创建过程和配置
-
软件安装和配置：操作系统配置，基础软件安装和配置，这些软件的特点是变动不频繁。对Chef/Puppet来说，这个步骤的自动化是最擅长的，提供大量现成的Recipes，并抽象各种异构系统之间的差异
-
应用部署和配置：部署应用代码，这部分代码的变动是频繁的。另外，对于复杂的系统来说，如果保证升级期间系统的可用性，系统的各个应用组件需尽量是无状态和松耦合的。如果系统的组件之间是有依赖的，那么升级期间必须动态地协调、控制好相关组件的行为。
-
监控和告警：包括OS级别和应用级别的可用性和性能监控。如果发现异常，需要能够自动发出告警信息。
-
健康检查和恢复：为了应付云基础设施故障，系统需要Design By Failure。在异常发生时，系统可以发现并进行自动处理。
-
自动伸缩：一般情况下，业务存在高峰期和低估期。为了节约成本，系统应该是可以自动伸缩的。
每一步都有工具来实现自动化，但实现Full-Stack 部署自动化不是通过简单的拼凑工具就可以的。
两种实现方式
基于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可控制性
Netflix的实现方式
- 环境创建：通过自己研发的Asgard管理和部署工具实现
- 软件安装和配置：基础软件和配置都打包成AMI，基于Netflix自己的打包工具Aminator
- 应用部署和配置：同上，应用代码和配置也打包进AMI
- 监控和告警：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这种部署模式虽可简化部署并确保一致性，但一部分复杂性转移到了应用层面。系统的各个组件是无状态和松耦合，同时还需要Eureka这种服务来实现中间层的负载和failover。
Cloud Foundry和Netflix都没有用到Chef/Puppet。