转载

Fbric、Ansible、Docker、Chaos Monkey：DevOps工具的年中回顾

【编者按】近日，Cyber Engineering Solutions Group 技术经理 Hasan Yasar 在 SEI 攥文盘点了当下流行的 DevOps 思想和工具，其中包括Fabric、Ansible、Docker、Chaos Monkey等。本文系OneAPM 联合高效运维联合编译整理文：

在2014年年底，SEI 博客发表了一系列有关DevOps 的博客文章，提供指南，实用的建议和教程。这些帖子针对越来越多的采用 DevOps 的企业（2011年以来，高达26％）。根据最近的研究，这些组织部署变更代码比传统的方式快30倍。尽管 DevOps 的好处显而易见，但是许多企业仍不敢采用 DevOps，因为这需要转变心态、文化和技术要求，对于传统企业是非常大的挑战。鉴于这些障碍，CERT 研究人员的文章主要集中在介绍 Amazon和 Netflix DevOps 的成功案例，以及一些 DevOps 流行技术的教程，如 Fabric、Ansible 和Docker。这个帖子介绍了过去六个月，10个最流行的 DevOps 相关文章（根据访问次数排序）。

1. DevOps 技术：Fabric 与 Ansible

这篇博客文章 DevOps 技术：Fabric 与Ansible 中，CERT 研究人员 Tim Palko 重点描述了使用 DevOps 部署过程相关的情况，包括评估资源需求、设计生产系统、配置和生产服务器的配置、同步代码等等。

以下为摘录:

部署代码的工作流程几乎和代码本身一样古老。有许多与部署过程相关联的用例，包括评估资源需求、设计一个生产系统、配置和配置生产服务器、同步代码等等。在这篇博客文章中，我将会专注于配置一个远程服务器上的软件包和必要的软件来执行您的代码。这个用例可以使用许多不同的，相互竞争的技术完成，如：Chef、Puppet、Fabric、Ansible、Salt、Foreman，这些只是少数你可能已经听到过的有关 DevOps 自动化运维之路的技术。所有这些技术都有提供仓库，可以提交脚本到仓库，并完成任务。这篇文章更深入的探讨了Fabric 和 Ansible。要了解更多关于其他基础设施即代码的解决方案，看看 Joe Yankel 关于 Docker 的文章或我的关于 Vagrant 的文章。

Fabric 和 Ansible 之间的一个区别是，Fabric 会让你在几分钟内看到结果，而 Ansible 需要付出更多的努力去理解。通常来说，Ansible 是更强大的，因为它提供了更深入和更复杂的多层架构模型的语义，如 Web 和数据库主机阵列。从运维的角度看，Fabric 具有更直接和基本 API，可以使用 Python 编写，而 Ansible 使用 YAML，提供了丰富的操作（我以后再讨论这篇文章）。我们将通过这篇文章中的例子来说明。

阅读完整的文章 DevOps 技术：Fabric 与 Ansible 请访问 http://blog.sei.cmu.edu/post.cfm/devops-technologies-fabric-or-ansible。

2. DevOps 之 Docker

3. 使用Dokcer做开发

Docker 这些日子在 DevOps 社区是相当火爆，这有很好的理由。Docker 容器使开发和部署应用软件达到可控制的、隔离的、灵活的和高度可移植的基础设施。在 DevOps 和 Docker 这篇文章中，CERT 研究员 Joe Yankel 介绍了使用 Docker 开发和部署软件应用程序的可扩展性，资源效率，以及弹性。

以下为摘录:

Linux 容器技术（LXC），为 Docker 的建立提供了基础，然而这并不是一个新想法。LXC 早已出现在 Linux 内核2.6.24版本中，当控制族群（或 cgroups）正式被集成时。实际上谷歌早在2006就使用了 Cgroups 技术，因为谷歌一直在寻找，在共享硬件上进行资源隔离和运行的方式。事实上，谷歌承认每周会启动200万个容器，使用自己发布的 LXC 容器 imctfy 。

不幸的是，这种技术并不容易被采用，直到 Docker 来简化容器技术，使它更易于使用。在没有 Docker 的时代，开发者很难访问，实现，更不用说要理解 LXC 的优点。 DotCloud 创始人、现任首席技术官 Solomon Hykes 发现 Docker 的潜力，在2013年三月份Docker作为开源项目被发布。Docker的易用性是由于其高层次抽象的API以及文档，使得 DevOps 社区充满力量，并创建 Docker 教程、官方化应用程序和许多其他的技术。通过降低进入容器技术的门槛，Docker 已经改变了开发人员共享、测试和部署应用程序的方式。

在这篇文章使用 Docker 开发中，Yankel 描述了如何开始使用 Docker 在一个普通的软件开发环境开发相应的软件，通过启动一个数据库容器（MongoDB），一个 Web 服务容器（Python Bottle APP），并配置它们可以互相访问。这是一个多容器应用程序。

以下为摘录:

如果你没有事先了解过 Docker，你应该去官方教程学习一下教程再在这里继续。

在开始教程之前，你需要有一个虚拟机或其他兼容 Docker 的主机。按照下面的说明创建演示程序所需的源文件。为方便起见，从我们的 GitHub 库上下载所有源文件并跳转到演示部分。我们的源代码包含一个 Vagrant 的配置文件，自动配置能够运行的正确环境。这里可以看看我们有关Vagrant的帖子。

阅读完整的文章，DevOps 和Docker，请访问 http://blog.sei.cmu.edu/post.cfm/devops-docker-015

阅读完整的使用 Docker 开发，请访问 http://blog.sei.cmu.edu/post.cfm/development-with-docker

4. DevOps 示例：Amazon AWS

经常阅读 DevOps 博客的读者会发现这个系列中会反复出现的主题：DevOps 本质上是通过精心的构建组织过程、加强沟通和工作流程来提升质量。通过学习知名高科技公司的技术管理和软件工程，我们的系列文章，可以从真实世界的案例中获得非常大的价值和相关的结果。这些案例也为 DevOps 从业者的提供非常优秀案例。在 DevOps 示例：Amazon AWS ，C. Aaron Cois 分享了 Amazon DevOps 的经验。

以下为摘录:

Amazon 是当今最多产的科技公司之一。Amazon 在2006年时做了转变，从一个在线零售商，转变成一个科技巨头，并发布了（AWS），成为云服务的先锋，AWS 提供了广泛使用的一种按需配置的基础设施服务（IaaS）。Amazon 的 AWS 承受了大量的风险。通过开发第一个大规模的公共云服务，他们了解了很多的挑战都是未知的，有许多未经证实的解决方案去证实。要学习亚马逊的成功，我们需要问正确的问题。亚马逊采取什么措施来减少这种固有风险的风险？亚马逊工程师如何定义他们的过程，以确保质量？

幸运的是，当谷歌工程师Steve Yegge（前亚马逊工程师）意外地公开了一份内部备忘录，概述了他所了解的谷歌平台工程的失败（亚马逊的成功）。这使我们可以大致了解 Amazon 成功的过程。这本备忘录（这 Yegge 特别允许可以在网络上传播）概述了具体决策，描述了首席执行官 Jeff Bezos 的基本原则，这些原则我们现在称之为 DevOps，以及 AWS 平台的质量属性：互操作性、可用性、可靠性和安全。

阅读完整的文章， DevOps 示例：Amazon AWS ，请访问 http://blog.sei.cmu.edu/post.cfm/devops-casestudy-amazon-aws-036 .

5. DevOps 示例：Netfix的Chaos Monkey

DevOps 经常被运用在如敏捷开发、自动化和持续交付，DevOps 的精神可以应用在很多方面。在这篇博客中，C. Aaron Cois分享了另外一个具有开创性的 DevOps 案例研究， Netflix 的一些开箱即用的方式。

以下为摘录:

Netflix 是一个奇妙的案例研究，因为他们的 DevOps 软件工程过程，展示了一个对 DevOps 本质的了解，专注通过 DevOps 自动化辅助过程来达到质量要求。DevOps 从业者信奉一种注重质量属性的驱动来满足业务需求，利用自动化过程实现一致性和效率。

Netflix 的流媒体服务是一个托管在 AWS 的大型分布式系统。由于这么多组件一起工作，为各个地区的客户提供可靠的视频流，Netflix 工程师需要侧重于服务端-客户端组件质量属性的可靠性和鲁棒性的。总之，他们得出结论认为，处理失败的唯一方法是不断实践失败。为了实现如此可信赖的，质量达标的水平，使用 DevOps 的风格，Netflix 公司的工程师开始使用自动化故障方案。

阅读完整的文章 DevOps 示例：Netfix 的 Chaos Monkey，请访问 http://blog.sei.cmu.edu/post.cfm/devops-case-study-netflix-and-the-chaos-monkey。

6. DevOps 和敏捷开发

Melvin Conway ，一个杰出的计算机科学家和程序员，创造了康威定律，康威定律说：设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。因此，一个公司的前端、后端和数据库团队可能会倾向于使用三层架构。在很大程度上，应用程序的结构，是由组织沟通后产生。简而言之，形式是交流的产物。

在文章 DevOps 和敏捷开发中，C. Aaron Cois学习康威定律并应用到自己的组织。

以下为摘录:

传统的，但不足的，瀑布式开发模式已经为我们的应用程序定义一个特定的沟通结构：开发开发人员让（QA）团队测试并质量保证，QA 让运维（OPS）团队去部署。这种方式的沟通，是非敏捷的，加重了我们有缺陷的组织结构，这又是一个印证了康威定律的例子：组织结构决定产品。

阅读完整的文章 DevOps 和敏捷开发，请访问 https://blog.sei.cmu.edu/post.cfm/devops-agile-317。

7. DevOps 团队需要 ChatOps

项目团队关键利益相关者之间的对话（例如，开发人员、业务分析员、项目经理、安全团队），平台之间的沟通，可以对协作产生深远的影响。较差的或甚至没有使用通讯工具，导致沟通不畅，重复的工作，或错误的实现。另一方面，开发和业务基础设施相结合的通信工具，可以加快向组织交付业务价值。一个团队如何组织基础设施结构，如何沟通，将直接影响团队的效率。

在文章 DevOps 团队需要 ChatOps 中，CERT研究员 Todd Waits 介绍了 ChatOps，DevOps 的一个分支，关注 DevOps 团队的沟通。ChatOps 包括了团队的沟通和协作工具：通知、聊天服务器、机器人、问题跟踪系统等等。

以下为摘录:

在最近的一篇博客中，Eric Sigler写道，ChatOps，一词起源于GitHub上，都是关于基于对话的驱动开发方式。“把你的工具带到您的沟通过程中，并使用一个聊天机器人修改关键的插件和脚本工作，团队可以自动执行任务和协作工作，使工作更好、更便捷、更快”Sigler写道。

大多数团队在聊天服务器上都有一定程度的合作。聊天服务器可以作为一个城市广场一样容纳开发团队、促进团队之间的凝聚力、讨论实际问题以及潜在解决方案等。我们希望所有的团队成员使用聊天服务器。在我们的团队中，为了避免一般聊天室的灌水聊天，我们也创建专用聊天室，每个项目，项目团队成员可以谈论项目的细节，不涉及其他的团队。

和其他简单的沟通介质不一样，聊天服务器可以智能化，开发的基础设施，向团队传递通知，团队执行命令并反馈回基础设施。我们的聊天服务器是通知的枢纽，与我们的基础设施快速互动。项目团队通过聊天服务器接到通知（还有其他方法），关注基础设施任何生成状态，他们关注：构建失败、构建成功、超时等。

阅读完整的文章 DevOps团队需要ChatOps ，请访问 http://blog.sei.cmu.edu/post.cfm/chatops-in-devops-team-029。

8. DevOps之Vagrant

环境等同是一个理想的状态，在不同的环境中执行代码都将正常运行。缺乏环境等同会使软件开发陷入令人沮丧的困境。部署和开发都经常会陷入这样的陷阱，降低了稳定性、可预测性和生产力。当环境不等同时，这使得故障难以排除，而且难以协作。这种缺乏环境等同使开发人员和运维人员负担太多。

在这篇博客中 DevOps 之 Vagrant ，CERT研究员 Tim Palko 描述了 Vagrant，这是一个开发者使用的工具，提供了一个虚拟化和环境配置，Vagrant 为开发者提供了一个单一的，声明式脚本，以及一个简单的命令行界面。通过使用相同的预先配置的 Vagrant 脚本，Vagrant 为所有开发者统一了线上的环境。Vagrant 的消除了“环境不同”的借口，在应用开发生命周期过程中。

以下为摘录:

运维团队的作业通常包括在所有部署环境中实施全面的校验，例如用于测试、分段和上线。相反，开发团队几乎完全自己负责配置开发机器。为了达到百分之100的环境等同，两个团队必须使用相同的语言，使用相同的资源。

Chef和Puppet，这两个都是为运维而生，对一个繁忙的开发人员来说可能不太友好。Chef和Puppet都有一个比较陡的学习曲线，并没有真正解决环境等同的问题：开发者仍然需要和线上环境同步。所有这些额外的工作会带来一个相当大的开销，而你只想好好的写业务代码！

这就是Vagrant出现的意义。Vagrant是一个面向开发者的工具，基本上Vagrant提供了一个虚拟化环境，提供了一个单一的，声明式的脚本和一个简单的命令行界面。Vagrant通过启动一个虚拟机（VM），去除繁重的工作，消除了人工配置或运行，例如，chef-server和chef-client。Vagrant的隐藏这一切，提供一个简单的脚本给开发人员，一个名叫Vagrantfile无扩展项文件，可随着代码签入到源代码控制。

阅读完整的文章 DevOps之Vagrant ，请访问 https://blog.sei.cmu.edu/post.cfm/devops-technologies-vagrant-345。

9. 使用DevOps解决上下文切换的不利影响

在计算系统中，上下文切换发生在，操作系统保存一个应用程序线程的状态，停止线程并恢复其他线程的状态（之前停止线程），使其他线程恢复执行。上下文切换管理的开销，发生在处理状态的保存和恢复，这个过程会对操作系统产生负荷，并影响应用程序的性能。在博客使用DevOps解决上下文切换的不利影响中，CERT研究员Todd Waits描述了如何使用DevOps改善负面影响，减少项目之间的“上下文切换”对软件工程团队效率的影响。

以下为摘录:

Quality Software Management: Systems Thinking , Gerald Weinberg在这本书中讨论了，上下文切换的概念是如何适用于一个工程团队。从人力劳动力的角度来看，上下文切换是一个项目停止工作的过程，并在不同的项目上完成不同的任务后，将其重新捡起来。就像计算机系统一样，在多个项目之间进行上下文切换时，团队成员通常会产生开销。

当团队成员被分配到多个项目时，上下文切换通常会发生。上下文切换的合理理由是，逻辑上来讲，为团队成员分配项目任务，比为每个项目分配专用资源更省时省力。这似乎是合理的假设，将一个人的精力平分，对每个项目，两者之间的项目收益率百分之50。此外，如果一个团队成员只在一个单独的项目中，如果这个项目正在等待处理某些事情，比如等待书面工作审批、审查等，该小组成员将是空闲的，没有充分利用。

使用我们计算系统的隐喻，任务之间的切换类似多线程概念，如果一个线程因为某些事情阻塞，其他线程可以执行其他工作，而不是等待第一个线程直到恢复。如果所有的工作只分配给第一个线程，进展很慢。虽然多线程在计算系统中很合理，问题是，人类并不总是能很好分配精力。因此效率会在上下文切时损失，生产力可能会在精力分散在更多的项目的时候下降。

阅读完整的文章使用 DevOps 解决上下文切换的不利影响，请访问 http://blog.sei.cmu.edu/post.cfm/addressing-detrimental-effects-context-switching-devops-064。