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

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。

10.什么是 DevOps？

一般，当咱们设想一个实现了 DevOps 的组织，咱们能够想象一个自动化运转良好的机器

• 基础设施配置
• 代码测试
• 应用部署

最终，这些作法的结果是运用 DevOps 的方法和工具。DevOps 适合全部规模的团队，从一个一我的的团队到一个企业组织。在这篇博文中，什么是 DevOps，CERT 研究员 Todd Waits 介绍了 DevOps 的基础。

DevOps 能够看做是敏捷方法的推广。它要求掌握至关多的知识和技能，包括一个项目从开始到持续，到被一个专门的项目小组负责。组织壁垒必须打破。只有这样才能有效地缓解项目风险。

如下为摘录:

然而严格来讲，DevOps 并非持续集成，交付或部署。DevOps 的作法能使团队达到协调，理解必要的自动化基础设施、测试和部署。特别是，DevOps 提供了组织如何保证：

• 不一样项目团队人员之间的合做
• 基础设施即为代码
• 自动化任务、过程和工做流程
• 监控应用和基础设施

商业价值驱动 DevOps 的发展。若是没有 DevOps 的心态，组织常常发现他们的运维、开发和测试团队，目光短浅，只致力于建立方便本身的基础设施、测试套件或产品增量。一旦一个组织打破了这些孤岛，把这些领域的专业知识整合起来，就能够把重点放在共同致力于提供商业价值的基本目标上。

组织良好的团队会发现（或建立）工具和技术，使他们的组织实践 DevOps。每一个组织都是不一样的，有不一样的需求，不一样的可是必须知足的需求。DevOps 的关键，并非一个杀手级的工具或脚本，而是合做文化和传递价值的终极承诺。

阅读完整的什么是DevOps，请访问
https://blog.sei.cmu.edu/post.cfm/what-is-devops-324。

每两周，SEI 会发布一篇新的博客，为那些尝试采用 DevOps 的组织提供指南，实用的建议和教程。咱们欢迎您对本系列文章提供反馈，以及对将来内容的建议。请在下面的评论部分反馈意见。

原文连接：Fabric, Ansible, Docker, and Chaos Monkey: The DevOps Mid-Year Review

OneAPM 是应用性能管理领域的新兴领军企业。想阅读更多技术文章，请访问 OneAPM 官方博客。