转载

年度十佳 DevOps 博客文章（后篇）

如果说 15 年你还没有将 DevOps 真正应用起来，16 年再不实践也未免太落伍了。在上篇文章中我们了解到 15 年十佳DevOps 博客文章的第 6-10 名，有没有哪一篇抓住了您的眼球，让您有所收获呢？接下来让我们来看一看排名前五的文章，究竟是不是妙笔生花，鞭辟入里！

本文是「年度十佳 DevOps 博客文章（前篇）」的后半部分，译自 Hasan Yasar 的文章 the Top 10 Devops Posts of 2015 .

2015 年 8 月， DevOps 博客推出了自己的平台。DevOps 博客针对越来越多采用 DevOps 的企业（自 2011 年来占比高达 26%），提供各种指南、实用建议和教程。根据近期研究，这些企业变更代码的速度比传统企业快 30 倍。尽管 DevOps 的优势显而易见，很多企业仍然不敢欣然采用，因为这不仅需要转变观念，还要改变文化和技术要求，后者对孤立的竖井式企业而言，是极大的挑战。考虑到这些障碍，CERT 研究人员的文章主要集中介绍 Amazon 和 Netflix 的 DevOps 成功案例，以及 Fabric 、 Ansible 和 Docker 等流行 DevOps 技术的教程。本文则介绍了 2015 年 10 篇最受欢迎的 DevOps 文章中的第 1-5 名（倒序）。

5.DevOps 案例分析：Netflix 和 Chaos Monkey

DevOps 经常被用在敏捷开发、自动化和持续交付等实践中，但 DevOps 的精神却可以应用在很多方面。在这篇博文中，C. Aaron Cois 剖析了另一个影响深远的 DevOps 思维案例分析 - Netflix 的开箱即用方式。

下面是这篇文章的摘录：

对于 DevOps 来说，Netflix 是一个奇妙的案例，因为 Netflix 软件工程过程显示了对 DevOps 思维本质的深刻理解和通过自动化辅助过程对质量属性的关注。DevOps 从业者信奉以一种注重质量属性的驱动满足业务需求，充分利用自动化过程实现一致性和高效率。

Netflix 的流媒体服务是一个托管在 AWS 上的大型分布式系统。众多组件必须一起工作，才能为使用各种设备的客户提供可靠的视频流。过去， Netflix 工程师需要同时重点关注服务器和客户端组件这二者的可靠性和鲁棒性等质量属性。简而言之，他们得出结论，正确应对失败的唯一方法是不断失败。为了实现确实符合 DevOps 风格、预期的信赖水准和质量水平，Netflix 工程师开始采用自动化故障方案。

阅读原文： DevOps 案例分析：Netflix 和 Chaos Monkey

4.用 Docker 进行开发

在用 Docker 进行开发这篇文章中，Joe Yankel 分享了一份利用 Docker 在软件开发通用环境中进行开发的入门教程：启动一种数据库容器 ( MongoDB ) 和一种网络服务容器（一款 Python Bottle 应用），然后对二者进行通信配置，形成实用的多容器应用。

下面是这篇文章的摘录：

如果您还不了解 Docker 的基本知识，请先点击此处学习 Docker 的官方教材再继续阅读本文。

入门前，您需要有一台虚拟主机或其他兼容 Docker 的主机。根据下面的操作说明来创建演示程序所需的源文件。

为方便起见，请从我们的 github 资源库下载所有源文件，然后跳转到演示部分。我们的源代码包含一份 Vagrant 配置文件，可在适用环境下运行演示。请点击此处查看我们对 Vagrant 的介绍。

阅读原文： 用 Docker 进行开发 & 推荐文章为什么 Cloud Insight 要支持监控 Docker

3.DevOps 的持续集成

人们首次展望敏捷软件开发模式时，核心原则是：更快地实现软件更改迭代、通过探索确定适当的路径，本质上来说，就是力求“ 故障快速修复 (fail fast)”并将正确性作为基本项目目标进行迭代。有人认为，由于对客户认识不足以及无法预期客户不断变化的需求，在项目开始时开发人员缺少正确定义长期项目要求的必要信息，因此，敏捷过程应运而生。近期的研究继续凸显出软件开发周期中规划、设计和执行阶段之间的断层问题，为这一结论提供了有力证明。在 DevOps 的持续集成这篇文章中，C. Aaron Cois 强调需要进行持续集成以避免断层，从而降低软件开发项目的风险。

下面是这篇文章的摘录：

持续集成 (CI) 是 DevOps 的基石。持续集成技术由 Grady Booch 开发并命名，可持续合并来自团队所有开发人员的最新源代码并形成共享主线。持续的合并可以防止其他成员新增代码时开发人员的软件项目本地复本偏离主题过远，从而避免灾难性的合并冲突。实际应用中，CI 会有一台中央服务器，在开发人员提交新的源码或从头构建软件应用时，这台服务器会持续地纳入所有源码的修改情况，并将此过程中的任何故障告知团队。如果发现故障，开发团队应该重新将精力集中在故障修改，直到修复完成才能提交新的代码修改。虽然看起来有些混乱，但实际上 CI 使开发团队专注于单一的稳定性指标：行之有效的软件自动构建。

DevOps 方法的关键要素是消除理解断层和影响力断层，企业必须派遣一位或多位相关专家与开发团队展开全面交流，巩固域中心观点。要消除开发和维护之间的断层，DevOps 从业人员一开始就将开发团队中的 IT 运维专业人员视为团队正式成员。同样地，为了确保软件质量，在整个项目周期内质量管理人员都必须作为团队成员。换句话说，DevOps 意识到，确保高质量开发需要与多位技术专家（包括质量管理专家和运维专家）持续交流并积极听取专家意见，继而以敏捷为原则扩展示其应用范围。

阅读原文

2.DevOps 与 Docker

Docker 是 DevOps 社群近来的热门话题，这自然是有充分理由的。Docker 容器提供的工具可在可控、独立、灵活同时高度可移植的基础架构中开发和部署软件应用。在 DevOps 与 Docker 这篇文章中，CERT 研究人员 Joe Yankel 将 Docker 介绍为一个对可扩展性、资源利用率和弹性都有极大好处的软件应用开发和部署工具。

下面是这篇文章的摘录：

Linux 容器技术 (LXC) 作为 Docker 的构建基础，已经不是什么新理念了。自 2.6.24 版起，LXC 就是 Linux 内核的一部分，该版本正式集成了控制组（Control Groups，简称 cgroups）。实际上，早在 2006 年，谷歌就开始使用 Cgroups，这是因为谷歌一直设法分离在共享硬件上运行的资源。事实上，谷歌承认一周启动超过 20 亿台容器，同时发布了谷歌版 LXC 容器并命名为 lmctfy，即“让我容纳你的程序 (Let Me Contain That For You) ”。

不幸的是，在 Docker 出现并简化容器技术之前，容器技术一直难以采用。在 Docker 出现之前，开发人员一度难以使用、实施甚至理解 LXC 技术，更别提意识到 LXC 的系统管理程序优势了。 DotCloud 创始人兼 Docker 现任首席技术官 Solomon Hykes 启动 Docker 项目并于 2013 年 3 月将其作为开源软件公之于世，这无疑是一个伟大的行动。Docker 的易用性源于其高水平 API 和文档支持，这使得 DevOps 社群全速发展，进而创建出各种教程和官方集成化应用，并衍生了众多附加技术。Docker 降低了容器技术领域的准入门槛，改变了开发人员共享、测试和部署应用程序的方式。

阅读原文 & 推荐文章Docker 监控实战年度十佳 DevOps 博客文章（后篇）

1.DevOps 技术：Fabric 还是 Ansible

在 DevOps 技术：Fabric 还是 Ansible 这篇文章中，CERT 研究人员 Tim Palko 特别介绍了 DevOps 部署过程的用例，包括评估资源要求、设计产品系统、配置产品服务器和推送代码等。

下面是这篇文章的摘录：

部署代码的工作流程几乎和代码本身的历史一样久远。与 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 并提供更丰富的行为（这一点稍后讨论）。我们会在这篇文章中仔细分析 Fabric 和 Ansible 的例子。

阅读原文