标签 DevOps 下的文章

消除一些关于 DevOps 的疑惑。

title=

很多人初学 DevOps 时，看到它其中一个结果就问这个是如何得来的。其实理解这部分 Devops 的怎样实现并不重要，重要的是——理解（使用） DevOps 策略的原因——这是做一个行业的领导者还是追随者的差别。

你可能会听过些 Devops 的难以置信的成果，例如生产环境非常有弹性，就算是有个“ 癫狂的猴子 Chaos Monkey ）跳来跳去将不知道哪个插头随便拔下，每天仍可以处理数千个发布。这是令人印象深刻的，但就其本身而言，这是一个 DevOps 的证据不足的案例，其本质上会被一个反例#Proving_a_negative)困扰：DevOps 环境有弹性是因为严重的故障还没有被观测到。

有很多关于 DevOps 的疑惑，并且许多人还在尝试弄清楚它的意义。下面是来自我 LinkedIn Feed 中的某个人的一个案例：

最近我参加一些 #DevOps 的交流会，那里一些演讲人好像在倡导 #敏捷开发是 DevOps 的子集。不知为何，我的理解恰恰相反。

能听一下你们的想法吗？你认为敏捷开发和 DevOps 之间是什么关系呢？

  1. DevOps 是敏捷开发的子集
  2. 敏捷开发是 DevOps 的子集
  3. DevOps 是敏捷开发的扩展，从敏捷开发结束的地方开始
  4. DevOps 是敏捷开发的新版本

科技行业的专业人士在那篇 LinkedIn 的帖子上表达了各种各样的答案，你会怎样回复呢？

DevOps 源于精益和敏捷

如果我们从亨利福特的战略和丰田生产系统对福特车型的改进（的历史）开始， DevOps 就更有意义了。精益制造就诞生在那段历史中，人们对精益制作进行了良好的研究。James P. Womack 和 Daniel T. Jones 将精益思维（Lean Thinking）提炼为五个原则：

  1. 指明客户所需的价值
  2. 确定提供该价值的每个产品的价值流，并对当前提供该价值所需的所有浪费步骤提起挑战
  3. 使产品通过剩余的增值步骤持续流动
  4. 在可以连续流动的所有步骤之间引入拉力
  5. 管理要尽善尽美，以便为客户服务所需的步骤数量和时间以及信息量持续下降

精益致力于持续消除浪费并增加客户的价值流动。这很容易识别并明白精益的核心原则：单一流。我们可以做一些游戏去了解为何同一时间移动单个比批量移动要快得多。其中的两个游戏是硬币游戏和飞机游戏。在硬币游戏中，如果一批 20 个硬币到顾客手中要用 2 分钟，顾客等 2 分钟后能拿到整批硬币。如果一次只移动一个硬币，顾客会在 5 秒内得到第一枚硬币，并会持续获得硬币，直到在大约 25 秒后第 20 个硬币到达。（LCTT 译注：有相关的视频的）

这是巨大的不同，但是不是生活中的所有事都像硬币游戏那样简单并可预测的。这就是敏捷的出现的原因。我们当然看到了高效绩敏捷团队的精益原则，但这些团队需要的不仅仅是精益去做他们要做的事。

为了能够处理典型的软件开发任务的不可预见性和变化，敏捷开发的方法论会将重点放在意识、审议、决策和行动上，以便在不断变化的现实中调整。例如，敏捷框架（如 srcum）通过每日站立会议和冲刺评审会议等仪式提高意识。如果 scrum 团队意识到新的事实，框架允许并鼓励他们在必要时及时调整路线。

要使团队做出这些类型的决策，他们需要高度信任的环境中的自我组织能力。以这种方式工作的高效绩敏捷团队在不断调整的同时实现快速的价值流，消除错误方向上的浪费。

最佳批量大小

要了解 DevOps 在软件开发中的强大功能，这会帮助我们理解批处理大小的经济学。请考虑以下来自Donald Reinertsen 的产品开发流程原则的U曲线优化示例：

title=

这可以类比杂货店购物来解释。假设你需要买一些鸡蛋，而你住的地方离商店只有 30 分钟的路程。买一个鸡蛋（图中最左边）意味着每次要花 30 分钟的路程，这就是你的交易成本。持有成本可能是鸡蛋变质和在你的冰箱中持续地占用空间。总成本是交易成本加上你的持有成本。这个 U 型曲线解释了为什么对大部分人来说，一次买一打鸡蛋是他们的最佳批量大小。如果你就住在商店的旁边，步行到那里不会花费你任何的时候，你可能每次只会买一小盒鸡蛋，以此来节省冰箱的空间并享受新鲜的鸡蛋。

这 U 型优化曲线可以说明为什么在成功的敏捷转换中生产力会显著提高。考虑敏捷转换对组织决策的影响。在传统的分级组织中，决策权是集中的。这会导致较少的人做更大的决策。敏捷方法论会有效地降低组织决策中的交易成本，方法是将决策分散到最被人熟知的认识和信息的位置：跨越高度信任，自组织的敏捷团队。

下面的动画演示了降低事务成本后，最佳批量大小是如何向左移动。在更频繁地做出更快的决策方面，你不能低估组织的价值。

title=

DevOps 适合哪些地方

自动化是 DevOps 最知名的事情之一。前面的插图非常详细地展示了自动化的价值。通过自动化，我们将交易成本降低到接近于零，实质上是可以免费进行测试和部署。这使我们可以利用越来越小的批量工作。较小批量的工作更容易理解、提交、测试、审查和知道何时能完成。这些较小的批量大小也包含较少的差异和风险，使其更易于部署，如果出现问题，可以进行故障排除和恢复。通过自动化与扎实的敏捷实践相结合，我们可以使我们的功能开发非常接近单件流程，从而快速、持续地为客户提供价值。

更传统地说，DevOps 被理解为一种打破开发团队和运营团队之间混乱局面的方法。在这个模型中，开发团队开发新的功能，而运营团队则保持系统的稳定和平稳运行。摩擦的发生是因为开发过程中的新功能将更改引入到系统中，从而增加了停机的风险，运营团队并不认为要对此负责，但无论如何都必须处理这一问题。DevOps 不仅仅尝试让人们一起工作，更重要的是尝试在复杂的环境中安全地进行更频繁的更改。

我们可以看看 Ron Westrum 在有关复杂组织中实现安全性的研究。在研究为什么有些组织比其他组织更安全时，他发现组织的文化可以预测其安全性。他确定了三种文化：病态的、官僚主义的和生产式的。他发现病态的可以预测其安全性较低，而生产式文化被预测为更安全（例如，在他的主要研究领域中，飞机坠毁或意外住院死亡的数量要少得多）。

title=

高效的 DevOps 团队通过精益和敏捷的实践实现了一种生成性文化，这表明速度和安全性是互补的，或者说是同一个问题的两个方面。通过将决策和功能的最佳批量大小减少到非常小，DevOps 实现了更快的信息流和价值，同时消除了浪费并降低了风险。

与 Westrum 的研究一致，在提高安全性和可靠性的同时，变化也很容易发生。当一个敏捷的 DevOps 团队被信任做出自己的决定时，我们将获得 DevOps 目前最为人所知的工具和技术：自动化和持续交付。通过这种自动化，交易成本比以往任何时候都进一步降低，并且实现了近乎单一的精益流程，每天创造数千个决策和发布的潜力，正如我们在高效绩的 DevOps 组织中看到的那样

流动、反馈、学习

DevOps 并不止于此。我们主要讨论了 DevOps 实现了革命性的流程，但通过类似的努力可以进一步放大精益和敏捷实践，从而实现更快的反馈循环和更快的学习。在DevOps手册 中，作者除了详细解释快速流程外， DevOps 如何在整个价值流中实现遥测，从而获得快速且持续的反馈。此外，利用精益求精的突破和 scrum 的回顾，高效的 DevOps 团队将不断推动学习和持续改进深入到他们的组织的基础，实现软件产品开发行业的精益制造革命。

从 DevOps 评估开始

利用 DevOps 的第一步是，经过大量研究或在 DevOps 顾问和教练的帮助下，对高效绩 DevOps 团队中始终存在的一系列维度进行评估。评估应确定需要改进的薄弱或不存在的团队规范。对评估的结果进行评估，以找到具有高成功机会的快速获胜焦点领域，从而产生高影响力的改进。快速获胜非常重要，能让团队获取解决更具挑战性领域所需的动力。团队应该产生可以快速尝试的想法，并开始关注 DevOps 转型。

一段时间后，团队应重新评估相同的维度，以衡量改进并确立新的高影响力重点领域，并再次采纳团队的新想法。一位好的教练将根据需要进行咨询、培训、指导和支持，直到团队拥有自己的持续改进方案，并通过不断地重新评估、试验和学习，在所有维度上实现近乎一致。

在本文的第二部分中，我们将查看 Drupal 社区中 DevOps 调查的结果，并了解最有可能找到快速获胜的位置。

via: https://opensource.com/article/19/3/devops-most-important-tech-strategy

作者：Kelly Albrecht 选题：lujun9972 译者：zgj1024 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

6 位专家为你解析 DevOps 及其实现、实践和哲学的关键。

如果你问 10 个人关于 DevOps 的问题，你会得到 12 个答案。这是对于 DevOps 的意见和期望的多样性的结果，更不用说它在实践中的差异。

为了解读 DevOps 的悖论，我们找到了最了解它的人 —— 这个行业的顶尖从业者。这些人熟悉 DevOps，了解技术的来龙去脉，并且已经有了多年 DevOps 实践。他们的观点应该能鼓励、刺激和激发你对 DevOps 的想法。

DevOps 对你意味着什么？

让我们从基本原理开始。我们不能只在教科书上寻找答案，而应该需要知道专家们怎么说。

简而言之，专家们说的是关于 DevOps 的原则、实践和工具。

IBM 数字企业集团 DevOps 商业平台领导者 Ann Marie Fred，说，“对于我来说，DevOps 是一套实践和原则，旨在使团队在设计、开发、交付和操作软件方面有更好的效率。”

据红帽资深 DevOps 布道者 Daniel Oh，“通常来说，DevOps 促使企业基于当前的 IT 发展与应用开发、IT 运维和安全协议的流程和工具。”

Tactec 战略解决方案的创始人 Brent Reed，谈及了利益相关者的持续改进，“DevOps 对我来说意味着包括了一种思维方式的工作方式，它允许持续改进运维绩效，进而提升组织绩效，从而让利益相关者受益。”

许多专家也强调 DevOps 文化。Ann Marie 说，“这也是持续改进和学习的问题。它涉及的是人和文化，以及工具和技术。”

美国保监会 (NAIC) 首席架构师兼 DevOps 领导者 Dan Barker，“DevOps 主要是关于文化…它将几个独立的领域聚集在一起，如精益生产、公正文化 和持续的学习。我认为文化是最关键和最难执行的。”

Atos 的 DevOps 负责人 Chris Baynham-Hughes，说，“[DevOps] 实践是通过组织内的文化、流程和工具的发展而被采用的。重点是文化变革，DevOps 文化借鉴的关键是协作、试验、快速反馈和持续改进。”

云架构师 Geoff Purdy，谈及敏捷和反馈，“缩短和放大反馈回路。我们希望团队在几分钟内而不是几周内获得反馈。”

但在最后，Daniel 通过解释开源和开源文化是如何让他以简单快捷的方式实现目标来强调这点，“在推动 DevOps 中，最重要的事情应该是开源文化而不是具体的工具或复杂的解决方案。”

你认为哪些 DevOps 实践有效？

专家列举的那些最佳实践是普遍存在的，但又各不相同。

Ann Marie 表示：“一些十分强大灵活的项目管理[实践]，能在职能、独立的小组之间打破壁垒；全自动化持续部署，蓝/绿部署实现零时间停机状态；开发人员设置自己的监控和警告，无缝自我修复，自动化的安全性与合规性。”

Chris 说，“特别的突破是倾情合作、持续改进、开放领导、缩短业务距离、从垂直孤岛转向横向/跨功能的产品团队、工作透明化、相互影响、Mobius 循环、缩短反馈回路、自动化（从环境到 CI/CD）。”

Brent 支持“发展学习文化，包括 TTD [测试驱动开发] 和 BDD [行为驱动开发]捕获事件，并通过持续集成和持续交付从设计、构建和测试到实施在生产环境上一系列事件的自动化。测试采用故障优先的方法，能够自动化集成和交付流程，并在整个生命周期中包含快速反馈。”

Geoff 强调自动化配置。“选择一个自动化配置，对我的团队来说非常有效。更具体地说从版本控制代码库中自动配置。”

Dan 则玩的开心，“ 我们做了很多不同的事情来建立 DevOps 文化。我们举办 ‘午餐 & 学习’ 活动，提供免费的食物来鼓励大家一起学习。我们买书，分组学习。”

你如何激励你的团队实现 DevOps 这个目标？

Daniel 强调“自动化的问题就是为了减少 DevOps 计划中来自多个团队的异议，你应该鼓励你的团队提高开发、测试与 IT 运营的自动化能力，以及新的流程和程序。例如，Linux 容器是实现 DevOps 自动化功能的关键工具。”

Geoff 很是赞同，“机械化的劳作，你有讨厌现在做的任务吗？很棒。如果可能的话，让它们消失。不行，那就让它们自动化。它能使工作不会变得太枯燥，因为工作总是在变化。”

Dan、Ann Marie 和 Brent 强调团队的执行力。

Dan 说，“在 NAIC，我们有个很好的奖励系统来鼓励特定的行为。我们有多个级别的奖项，其中两个奖项可以由任何人颁布给某人。我们也会颁奖给完成重要任务的团队，但我们通常只奖励给个人贡献者。”

Ann Marie 表示，“我所在地区的团队最大的动力是看见其他人成功。我们每周都会彼此回放一次，其中一部分是分享我们从尝试新工具或实践中学到的东西。团队热衷于他们现在做的事情，并愿意帮助其他人开始，相信更多的团队很快也会加入进来。”

Brent 表示赞同。“让每个人学习，并掌握同样的基础知识至关重要……我喜欢从评估什么能帮助团队实现目标[以及]产品负责人和用户需要提供的内容入手。”

Chris 推荐采用双管齐下的方法。“运行可以每周可以实现的小目标，并且[在这]可以看到他们正在运做的功能工作之外的进展，庆祝你所取得的进步。”

DevOps 和敏捷开发如何协同工作？

这是一个重要的问题，因为 DevOps 和敏捷开发都是现代软件开发的基石。

DevOps 是一个软件开发的过程，专注与沟通与协作，以促进快速部署应用程序和产品。而敏捷开发是一种开发方法，涉及持续开发、连续迭代和连续测试，以实现可预测和可交付的成果质量。

那么，它们又有怎样的联系？让我们去问问专家吧。

在 Brent 来看，“DevOps != 敏捷。其次 敏捷 != Scrum 流程……敏捷工具和工作方式支撑着 DevOps 策略和目标，它们是如此融合在一起的。”

Chris 说，“对我而言敏捷是 DevOps 的一个基本组件。当然，我们可以讨论如何在非敏捷开发环境中采用 DevOps 文化，但最终表明，提高软件设计方式的灵活性是采用 DevOps 成熟读的一个关键指标。”

Dan 将 DevOps 与更伟大的 敏捷宣言 联系起来。“我在谈到敏捷时总会引用敏捷宣言来设置基准，而有许多实现中并不关注该宣言。当你阅读这份宣言时，你会发现它确实从开发的角度描述了 DevOps。因此，将敏捷融入 DevOps 文化非常容易，因为敏捷关注于沟通、协作、变化的灵活性以及快速地投入生产。”

Geoff 认为 “DevOps 是敏捷实施的众多实现之一。敏捷本质上是一套原则，而 DevOps 则是体现这些原则的文化、流程和工具链。”

Ann Marie 简洁说明，“敏捷是 DevOps 的先决条件。DevOps 使敏捷变得更加有效。”

DevOps 是否受益于开源？

这个问题得到了所有参与者的热烈肯定，然后解释了他们看到的好处。

Ann Marie 说，“我们站在巨人的肩膀上，在已有的基础之上发展。拉取请求和代码评审的开源模式，对 DevOps 团队维护软件很有效果。”

Chris 赞同 DevOps “毫无疑问”受益于开源。“从设计和工具方面（例如，Ansible），到流程和人员方面，通分享行业内的故事和开源社区的领导。”

Geoff 提到一个好处是“基层的采纳”。免费的软件不需要签署购买申请。团队发现了满足他们需求的工具，可以自行进行修改。[然后]在它之上构建，并为更大的社区提供更好的功能。如此往复。

开源已经向 DevOps 展示着“就像开源软件开发者正在做的那样，采用更好的方式来克服新的变化”，Daniel 说。

Brent 同意道 “DevOps 从开源中获益良多。一种方法是使用这些工具来理解它们是如何加速 DevOps 的目标和策略；在自动化、自动伸缩、虚拟化和容器化等关键方面对开发人员和操作人员进行培训，如果不引入使 DevOps 更加容易的技术支持，就很难实现这些特性。”

Dan 指出了 DevOps 和开源之间的双向共生关系，“做好开源需要 DevOps 文化。大多数开源项目都具有非常开放的沟通结构，很少有不透明的地方。对于 Devops 实践者来说，这实际上是一个很好的学习机会，可以让他们了解到可能需要将什么引入自己的组织中。此外能够使用来自社区与组织类似的工具来鼓励自己的文化成长。我喜欢用 GitLab 作为这种共生关系的一个例子。当我把 GitLab 带入一家公司时，我们得到了一个很棒的工具，但我们真正购买的是他们独特的文化，通过我们与他们的互动以及我们的贡献带来了巨大价值。他们的工具也可以为 DevOps 组织提供更多东西，而他们的文化已经在我引入它的公司中引起了他们的敬畏。”

现在我们的 DevOps 专家已经参与进来了，请在评论中分享你对 DevOps 的理解，以及向我们提出其他问题。

via: https://opensource.com/article/19/1/what-does-devops-mean-you

作者：Girish Managoli 选题：lujun9972 译者：MZqk 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

本文是一篇简单指南：介绍一些顶级的开源的持续集成、持续交付和持续部署（CI/CD）工具。

虽然持续集成、持续交付和持续部署（CI/CD）在开发者社区里已经存在很多年，一些机构在其运维部门也有实施经验，但大多数公司并没有做这样的尝试。对于很多机构来说，让运维团队能够像他们的开发同行一样熟练操作 CI/CD 工具，已经变得十分必要了。

无论是基础设施、第三方应用还是内部开发的应用，都可以开展 CI/CD 实践。尽管你会发现有很多不同的工具，但它们都有着相似的设计模型。而且可能最重要的一点是：通过带领你的公司进行这些实践，会让你在公司内部变得举足轻重，成为他人学习的榜样。

一些机构在自己的基础设施上已有多年的 CI/CD 实践经验，常用的工具包括 Ansible、Chef 或者 Puppet。另一些工具，比如 Test Kitchen，允许在最终要部署应用的基础设施上运行测试。事实上，如果使用更高级的配置方法，你甚至可以将应用部署到有真实负载的仿真“生产环境”上，来运行应用级别的测试。然而，单单是能够测试基础设施就是一项了不起的成就了。配置管理工具 Terraform 可以通过 Test Kitchen 来快速创建更短暂和冥等的的基础设施配置，这比它的前辈要强不少。再加上 Linux 容器和 Kubernetes，在数小时内，你就可以创建一套类似于生产环境的配置参数和系统资源，来测试整个基础设施和其上部署的应用，这在以前可能需要花费几个月的时间。而且，删除和再次创建整个测试环境也非常容易。

当然，作为初学者，你也可以把网络配置和 DDL（ 数据定义语言 data definition language ）文件加入版本控制，然后开始尝试一些简单的 CI/CD 流程。虽然只能帮你检查一下语义语法或某些最佳实践，但实际上大多数开发的管道都是这样起步的。只要你把脚手架搭起来，建造就容易得多了。而一旦起步，你就会发现各种管道的使用场景。

举个例子，我经常会在公司内部写新闻简报，我使用 MJML 制作邮件模板，然后把它加入版本控制。我一般会维护一个 web 版本，但是一些同事喜欢 PDF 版，于是我创建了一个管道。每当我写好一篇新闻稿，就在 Gitlab 上提交一个合并请求。这样做会自动创建一个 index.html 文件，生成这篇新闻稿的 HTML 和 PDF 版链接。HTML 和 PDF 文件也会在该管道里同时生成。除非有人来检查确认，这些文件不会被直接发布出去。使用 GitLab Pages 发布这个网站后，我就可以下载一份 HTML 版，用来发送新闻简报。未来，我会修改这个流程，当合并请求成功或者在某个审核步骤后，自动发出对应的新闻稿。这些处理逻辑并不复杂，但的确为我节省了不少时间。实际上这些工具最核心的用途就是替你节省时间。

关键是要在抽象层创建出工具，这样稍加修改就可以处理不同的问题。值得留意的是，我创建的这套流程几乎不需要任何代码，除了一些轻量级的 HTML 模板，一些把 HTML 文件转换成 PDF 的 nodejs 代码，还有一些生成索引页面的 nodejs 代码。

这其中一些东西可能看起来有点复杂，但其中大部分都源自我使用的不同工具的教学文档。而且很多开发人员也会乐意跟你合作，因为他们在完工时会发现这些东西也挺有用。上面我提供的那些代码链接是给 DevOps KC（LCTT 译注：一个地方性 DevOps 组织） 发送新闻简报用的，其中大部分用来创建网站的代码来自我在内部新闻简报项目上所作的工作。

下面列出的大多数工具都可以提供这种类型的交互，但是有些工具提供的模型略有不同。这一领域新兴的模型是用声明式的方法例如 YAML 来描述一个管道，其中的每个阶段都是短暂而幂等的。许多系统还会创建有向无环图（DAG），来确保管道上不同的阶段排序的正确性。

这些阶段一般运行在 Linux 容器里，和普通的容器并没有区别。有一些工具，比如 Spinnaker，只关注部署组件，而且提供一些其他工具没有的操作特性。Jenkins 则通常把管道配置存成 XML 格式，大部分交互都可以在图形界面里完成，但最新的方案是使用领域专用语言（DSL）（如 Groovy）。并且，Jenkins 的任务（job）通常运行在各个节点里，这些节点上会装一个专门的 Java 代理，还有一堆混杂的插件和预装组件。

Jenkins 在自己的工具里引入了管道的概念，但使用起来却并不轻松，甚至包含一些禁区。最近，Jenkins 的创始人决定带领社区向新的方向前进，希望能为这个项目注入新的活力，把 CI/CD 真正推广开（LCTT 译注：详见后面的 Jenkins 章节)。我认为其中最有意思的想法是构建一个云原生 Jenkins，能把 Kubernetes 集群转变成 Jenkins CI/CD 平台。

当你更多地了解这些工具并把实践带入你的公司和运维部门，你很快就会有追随者，因为你有办法提升自己和别人的工作效率。我们都有多年积累下来的技术债要解决，如果你能给同事们提供足够的时间来处理这些积压的工作，他们该会有多感激呢？不止如此，你的客户也会开始看到应用变得越来越稳定，管理层会把你看作得力干将，你也会在下次谈薪资待遇或参加面试时更有底气。

让我们开始深入了解这些工具吧，我们将对每个工具做简短的介绍，并分享一些有用的链接。

GitLab CI

GitLab 可以说是 CI/CD 领域里新登场的玩家，但它却在权威调研机构 Forrester 的 CI 集成工具的调查报告中位列第一。在一个高水平、竞争充分的领域里，这是个了不起的成就。是什么让 GitLab CI 这么成功呢？它使用 YAML 文件来描述整个管道。另有一个功能叫做 Auto DevOps，可以为较简单的项目用多种内置的测试单元自动生成管道。这套系统使用 Herokuish buildpacks 来判断语言的种类以及如何构建应用。有些语言也可以管理数据库，它真正改变了构建新应用程序和从开发的开始将它们部署到生产环境的过程。它原生集成于 Kubernetes，可以根据不同的方案将你的应用自动部署到 Kubernetes 集群，比如灰度发布、蓝绿部署等。

除了它的持续集成功能，GitLab 还提供了许多补充特性，比如：将 Prometheus 和你的应用一同部署，以提供操作监控功能；通过 GitLab 提供的 Issues、Epics 和 Milestones 功能来实现项目评估和管理；管道中集成了安全检测功能，多个项目的检测结果会聚合显示；你可以通过 GitLab 提供的网页版 IDE 在线编辑代码，还可以快速查看管道的预览或执行状态。

GoCD

GoCD 是由老牌软件公司 Thoughtworks 出品，这已经足够证明它的能力和效率。对我而言，GoCD 最具亮点的特性是它的价值流视图（VSM）。实际上，一个管道的输出可以变成下一个管道的输入，从而把管道串联起来。这样做有助于提高不同开发团队在整个开发流程中的独立性。比如在引入 CI/CD 系统时，有些成立较久的机构希望保持他们各个团队相互隔离，这时候 VSM 就很有用了：让每个人都使用相同的工具就很容易在 VSM 中发现工作流程上的瓶颈，然后可以按图索骥调整团队或者想办法提高工作效率。

为公司的每个产品配置 VSM 是非常有价值的；GoCD 可以使用 JSON 或 YAML 格式存储配置，还能以可视化的方式展示数据等待时间，这让一个机构能有效减少学习它的成本。刚开始使用 GoCD 创建你自己的流程时，建议使用人工审核的方式。让每个团队也采用人工审核，这样你就可以开始收集数据并且找到可能的瓶颈点。

Travis CI

我使用的第一个软件既服务（SaaS）类型的 CI 系统就是 Travis CI，体验很不错。管道配置以源码形式用 YAML 保存，它与 GitHub 等工具无缝整合。我印象中管道从来没有失效过，因为 Travis CI 的在线率很高。除了 SaaS 版之外，你也可以使用自行部署的版本。我还没有自行部署过，它的组件非常多，要全部安装的话，工作量就有点吓人了。我猜更简单的办法是把它部署到 Kubernetes 上，Travis CI 提供了 Helm charts，这些 charts 目前不包含所有要部署的组件，但我相信以后会越来越丰富的。如果你不想处理这些细枝末节的问题，还有一个企业版可以试试。

假如你在开发一个开源项目，你就能免费使用 SaaS 版的 Travis CI，享受顶尖团队提供的优质服务！这样能省去很多麻烦，你可以在一个相对通用的平台上（如 GitHub）研发开源项目，而不用找服务器来运行任何东西。

Jenkins

Jenkins 在 CI/CD 界绝对是元老级的存在，也是事实上的标准。我强烈建议你读一读这篇文章：“Jenkins: Shifting Gears”，作者 Kohsuke 是 Jenkins 的创始人兼 CloudBees 公司 CTO。这篇文章契合了我在过去十年里对 Jenkins 及其社区的感受。他在文中阐述了一些这几年呼声很高的需求，我很乐意看到 CloudBees 引领这场变革。长期以来，Jenkins 对于非开发人员来说有点难以接受，并且一直是其管理员的重担。还好，这些问题正是他们想要着手解决的。

Jenkins 配置既代码（JCasC）应该可以帮助管理员解决困扰了他们多年的配置复杂性问题。与其他 CI/CD 系统类似，只需要修改一个简单的 YAML 文件就可以完成 Jenkins 主节点的配置工作。Jenkins Evergreen 的出现让配置工作变得更加轻松，它提供了很多预设的使用场景，你只管套用就可以了。这些发行版会比官方的标准版本 Jenkins 更容易维护和升级。

Jenkins 2 引入了两种原生的管道功能，我在 LISA（LCTT 译注：一个系统架构和运维大会） 2017 年的研讨会上已经讨论过了。这两种功能都没有 YAML 简便，但在处理复杂任务时它们很好用。

Jenkins X 是 Jenkins 的一个全新变种，用来实现云端原生 Jenkins（至少在用户看来是这样）。它会使用 JCasC 及 Evergreen，并且和 Kubernetes 整合的更加紧密。对于 Jenkins 来说这是个令人激动的时刻，我很乐意看到它在这一领域的创新，并且继续发挥领袖作用。

Concourse CI

我第一次知道 Concourse 是通过 Pivotal Labs 的伙计们介绍的，当时它处于早期 beta 版本，而且那时候也很少有类似的工具。这套系统是基于微服务构建的，每个任务运行在一个容器里。它独有的一个优良特性是能够在你本地系统上运行任务，体现你本地的改动。这意味着你完全可以在本地开发（假设你已经连接到了 Concourse 的服务器），像在真实的管道构建流程一样从你本地构建项目。而且，你可以在修改过代码后从本地直接重新运行构建，来检验你的改动结果。

Concourse 还有一个简单的扩展系统，它依赖于“资源”这一基础概念。基本上，你想给管道添加的每个新功能都可以用一个 Docker 镜像实现，并作为一个新的资源类型包含在你的配置中。这样可以保证每个功能都被封装在一个不可变的独立工件中，方便对其单独修改和升级，改变其中一个时不会影响其他构建。

Spinnaker

Spinnaker 出自 Netflix，它更关注持续部署而非持续集成。它可以与其他工具整合，比如 Travis 和 Jenkins，来启动测试和部署流程。它也能与 Prometheus、Datadog 这样的监控工具集成，参考它们提供的指标来决定如何部署。例如，在 金丝雀发布 canary deployment 里，我们可以根据收集到的相关监控指标来做出判断：最近的这次发布是否导致了服务降级，应该立刻回滚；还是说看起来一切 OK，应该继续执行部署。

谈到持续部署，一些另类但却至关重要的问题往往被忽略掉了，说出来可能有点让人困惑：Spinnaker 可以帮助持续部署不那么“持续”。在整个应用部署流程期间，如果发生了重大问题，它可以让流程停止执行，以阻止可能发生的部署错误。但它也可以在最关键的时刻让人工审核强制通过，发布新版本上线，使整体收益最大化。实际上，CI/CD 的主要目的就是在商业模式需要调整时，能够让待更新的代码立即得到部署。

Screwdriver

Screwdriver 是个简单而又强大的软件。它采用微服务架构，依赖像 Nomad、Kubernetes 和 Docker 这样的工具作为执行引擎。官方有一篇很不错的部署教学文档，介绍了如何将它部署到 AWS 和 Kubernetes 上，但如果正在开发中的 Helm chart 也完成的话，就更完美了。

Screwdriver 也使用 YAML 来描述它的管道，并且有很多合理的默认值，这样可以有效减少各个管道重复的配置项。用配置文件可以组织起高级的工作流，来描述各个任务间复杂的依赖关系。例如，一项任务可以在另一个任务开始前或结束后运行；各个任务可以并行也可以串行执行；更赞的是你可以预先定义一项任务，只在特定的拉取请求时被触发，而且与之有依赖关系的任务并不会被执行，这能让你的管道具有一定的隔离性：什么时候被构造的工件应该被部署到生产环境，什么时候应该被审核。

以上只是我对这些 CI/CD 工具的简单介绍，它们还有许多很酷的特性等待你深入探索。而且它们都是开源软件，可以自由使用，去部署一下看看吧，究竟哪个才是最适合你的那个。

via: https://opensource.com/article/18/12/cicd-tools-sysadmins

作者：Dan Barker 选题：lujun9972 译者：jdh8383 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

了解一下配置管理工具，以找出哪个最适合你的 DevOps 组织。

DevOps 正因为有提高产品质量、缩短产品开发时间等优势，目前备受业界关注，同时也在长足发展当中。

DevOps 的核心价值观是 团队文化 Culture 、 自动化 Automation 、 评估 Measurement 和 分享 Sharing （CAMS），同时，团队对 DevOps 的执行力也是 DevOps 能否成功的重要因素。

  • 团队文化让大家团结一致；
  • 自动化是 DevOps 的基础；
  • 评估保证了及时的改进；
  • 分享让 CAMS 成为一个完整的循环过程。

DevOps 的另一个思想是任何东西，包括服务器、数据库、网络、日志文件、应用配置、文档、自动化测试、部署流程等，都可以通过代码来管理。

在本文中，我主要介绍配置管理的自动化。配置管理工具作为 基础架构即代码 Infrastructure as Code （IaC）的一部分，支持使用经过测试和验证的软件开发实践，通过明文定义文件管理和配置数据中心。

DevOps 团队只需要通过操作简单的配置文件，就可以实现应用开发中包括版本控制、测试、小型部署、设计模式在内的这些最佳实践。总而言之，配置管理工具实现了通过编写代码来使基础架构的配置和管理变得自动化。

为什么要使用配置管理工具？

配置管理工具可以提高应用部署和变更的效率，还可以让这些流程变得可重用、可扩展、可预测，甚至让它们维持在期望的状态，从而让资产的可控性提高。

使用配置管理工具的优势还包括：

  • 让代码遵守编码规范，提高代码可读性；
  • 具有 幂等性 Idempotency ，也就是说，无论执行多少次重复的配置管理操作，得到的结果都是一致的；
  • 分布式的设计可以方便地管理大量的远程服务器。

配置管理工具主要分为 拉取 pull 模式和 推送 push 模式。拉取模式是指安装在各台服务器上的 代理 agent 定期从 中央存储库 central repository 拉取最新的配置并应用到对应的服务器上；而推送模式则由 中央服务器 central server 的中央服务器会触发其它受管服务器的更新。

五大最流行的配置管理工具

目前配置管理工具有很多，不同的配置管理工具都有自己最适合的使用场景。而对于下面五个我按照字母顺序列出的配置管理工具，都对 DevOps 有明显的帮助：全都具有开源许可证、使用外部配置文件、支持无人值守运行、可以通过脚本自定义运行。下面对它们的介绍都来源于它们的软件库和官网内容。

Ansible

“Ansible 是一个极其简洁的 IT 自动化平台，可以让你的应用和系统以更简单的方式部署。不需要安装任何代理，只需要使用 SSH 的方式和简单的语言，就可以免去脚本或代码部署应用的过程。”——GitHub Ansible 代码库

Ansible 是我最喜欢的工具之一，我在几年前就开始使用了。你可以使用 Ansible 在命令行中让多个服务器执行同一个命令，也可以使用 YAML 格式的 剧本 playbook 来让它自动执行特定的操作，这促进了技术团队和非技术团队之间的沟通。简洁、无代理、配置文件对非技术人员友好是它的几个主要优点。

由于 Ansible 不需要代理，因此对服务器的资源消耗会很少。Ansible 默认使用的推送模式需要借助 SSH 连接，但 Ansible 也支持拉取模式。剧本 可以使用最少的命令集编写，当然也可以扩展为更加精细的自动化任务，包括引入角色、变量和其它人写的模块。

你可以将 Ansible 和其它工具（包括 Ansible Works、Jenkins、RunDeck、ARA 等）结合起来使用，因为这些工具 提供了运行剧本时的可追溯性，这样就可以创建控制流程的中央控制台。

CFEngine

“CFEngine 3 是一个流行的开源配置管理系统，它主要用于为大规模的系统提供自动化配置和维护。”——GitHub CFEngine 代码库

CFEngine 最早在 1993 年由 Mark Burgess 作为自动配置管理的科学方法提出，目的是降低计算机系统配置中的熵，最终收敛到期望的配置状态，同时还阐述了幂等性是让系统达到期望状态的能力。Burgess 在 2004 年又提出了 承诺理论 Promise Theory ，这个理论描述了代理之间自发合作的模型。

CFEngine 的最新版本已经用到了承诺理论，在各个服务器上的代理程序会从中央存储库拉取配置。CFEngine 的配置对专业技能要求较高，因此它比较适合技术团队使用。

Chef

“为整个基础架构在配置管理上带来便利的一个系统集成框架。”——GitHub Chef 代码库

Chef 通过由 Ruby 编写的“ 菜谱 recipe ”来让你的基础架构保持在最新、最兼容的状态，这些“菜谱”描述了一系列应处于某种状态的资源。Chef 既可以通过客户端-服务端的模式运行，也可以在 chef-solo 这种独立配置的模式下运行。大部分云提供商都很好地集成了 Chef，因此可以使用它为新机器做自动配置。

Chef 有广泛的用户基础，同时也提供了完备的工具包，让不同技术背景的团队可以通过“菜谱”进行沟通。尽管如此，它仍然算是一个技术导向的工具。

Puppet

“Puppet 是一个可以在 Linux、Unix 和 Windows 系统上运行的自动化管理引擎，它可以根据集中的规范来执行诸如添加用户、安装软件包、更新服务器配置等等管理任务。”——GitHub Puppet 代码库

Puppet 作为一款面向运维工程师和系统管理员的工具，在更多情况下是作为配置管理工具来使用。它通过客户端-服务端的模式工作，使用代理从主服务器获取配置指令。

Puppet 使用 声明式语言 declarative language 或 Ruby 来描述系统配置。它包含了不同的模块，并使用 清单文件 manifest files 记录期望达到的目标状态。Puppet 默认使用推送模式，但也支持拉取模式。

Salt

“为大规模基础结构或应用程序实现自动化管理的软件。”——GitHub Salt 代码库

Salt 的专长就是快速收集数据，即使是上万台服务器也能够轻松完成任务。它使用 Python 模块来管理配置信息和执行特定的操作，这些模块可以让 Salt 实现所有远程操作和状态管理。但配置 Salt 模块对技术水平有一定的要求。

Salt 使用客户端-服务端的结构（Salt minions 是客户端，而 Salt master 是服务端），并以 Salt 状态文件记录需要达到的目标状态。

总结

DevOps 工具领域一直在发展，因此必须时刻关注其中的最新动态。希望这篇文章能够鼓励读者进一步探索相关的概念和工具。为此， 云原生计算基金会 Cloud Native Computing Foundation （CNCF）在 Cloud Native Landscape Project 中也提供了很好的参考案例。

via: https://opensource.com/article/18/12/configuration-management-tools

作者：Marco Bravo 选题：lujun9972 译者：HankChow 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

让一名非工程师来解释为什么你不必成为一位开发者或运维就能爱上 DevOps。

我从未做过开发或运维的工作 —— 那怎么我在写一篇关于 DevOps 的文章？我一直都对计算机和技术有兴趣。我还对社群、心理学以及帮助他人充满热情。当我第一次听到 DevOps 时，这个概念激起了我的兴趣，因为它看起来融合了很多我感兴趣的东西，即便我是不写代码的。

我的第一台电脑是 TRS-80，我喜欢在上面编写 BASIC 程序。我只上过两门我的高中开设的计算机编程课程。若干年后，我创办了一家计算机公司。我定制邮件标签和信纸，并建立了一个数据库来存储地址。

问题是我并不能从写代码中获得享受。我想要教育和帮助人们，我没法将写代码看作这样的一个机会。是的，技术可以帮助人们并改变生活，但是写代码没有点燃我的热情。我需要对我的工作感到兴奋并做我喜欢的事情。

我发现我爱 DevOps。对我而言，DevOps 指的是：

  • 文化，而不是代码
  • 过程，而不是结果
  • 建立一个所有人可以持续提升的环境
  • 沟通与合作，而不是独立工作

归根结底，DevOps 是指成为社区工作的一部分，实现共同的目标。DevOps 融合了心理学、社群、技术。DevOps 不是一个职位名称，它是一种生活和工作的哲学。

找到我的社群

快四年前，我在西雅图参加了我的第一个 DevOps 日 会议。我感觉我找到了我的社群。我觉得受到了欢迎和接受，尽管我从事营销工作而且没有计算机科学文凭。我可以从心理学和技术中寻找乐趣。

在 DevOps 日，我学到了 DevOps“三步工作法” —— 流动、反馈、持续实验和学习 —— 以及新（对我而言）的概念，如 Kaizen（改善）和 Kaikaku（改革）。随着我的学习深入，我发现我在说这样的话，“我是这样做的！我都不知道这样做还有个名字！”

Kaizen（改善）是持续改进和学习的实践。小的量变积累随着时间的推移可以引起质变。我发现它和卡罗尔·德韦克的成长型思维的想法很相似。人们不是生来就是专家。在某方面拥有经验需要花费时间、练习，以及常常还有失败。承认增量的改善对确保我们不会放弃是很有必要的。

另一方面，Kaikaku（改革）的概念是指，长时间的小的改变有时不能起作用，你需要做一些完全的或破坏性的改变。在没有找到下份工作前就辞职或移居新城市就足够有破坏性 —— 是的，两者我都做过。但这些彻底的改变收获巨大。如果我没有辞职并休息一段时间，我也许不会接触到 DevOps。等我决定继续工作的时候，我一直听到 DevOps，我开始研究它。这引导我参加了我的第一个 DevOps 日，从那里我开始看到我的所有热情开始聚集。从那时起，我已经参加了五次 DevOps 日活动，并且定期撰写关于 DevOps 话题的文章。

将三步工作法用到工作中

改变是困难的，学习新事物可以听起来很吓人。DevOps 的三步工作法提供了一个管理改变的框架。比如：信息流动是怎样的？是什么驱动着你做出改变？一旦你认为一个改变是必需的，你如何获得这个改变是否正确的反馈？你如何知道你在取得进展？反馈是必要的，并且应该包含积极和有建设性的要素。困难的地方在于保证建设性的要素不要重于积极要素。

对我而言，第三步 —— 持续实验和学习 —— 是 DevOps 最重要的部分。有一个可以自由地实验和冒险的环境，人们可以获得意想不到的结果。有时这些结果是好的，有时不是太好 —— 但这没事。创建一个可以接受失败结果的环境可以鼓励人们冒险。我们都应该力争定期的持续实验和学习。

DevOps 的三步工作法提供了一个尝试，获得反馈，以及从错误中获取经验的方法。几年前，我的儿子告诉我，“我从来就没想做到最好，因为那样我就没法从我的错误中学到东西了。”我们都会犯错，从中获得经验帮助我们成长和改善。如果我们的文化不支持尝试和学习，我们就不会愿意去犯错。

成为社区的一部分

我已经在技术领域工作了超过 20 年，直到我发现 DevOps 社区前，我还经常感觉自己是个外行。如果你像我一样——对技术充满热情，但不是工程和运维那方面——你仍然可以成为 DevOps 的一部分，即便你从事的是销售、营销、产品营销、技术写作、支持或其他工作。DevOps 是属于所有人的。

via: https://opensource.com/article/18/11/how-non-engineer-got-devops

作者：Dawn Parych 选题：lujun9972 译者：alim0x 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

想要提升你的 DevOps 效率吗？将基础设施当成你的 CI 流程中的重要的一环。

持续交付（CD）和持续集成（CI）是 DevOps 的两个众所周知的方面。但在 CI 大肆流行的今天却忽略了另一个关键性的 I： 基础设施 infrastructure 。

曾经有一段时间 “基础设施”就意味着 无头 headless 的黑盒子、庞大的服务器，和高耸的机架 —— 更不用说漫长的采购流程和对盈余负载的错误估计。后来到了虚拟机时代，把基础设施处理得很好，虚拟化 —— 以前的世界从未有过这样。我们不再需要管理实体的服务器。仅仅是简单的点击，我们就可以创建和销毁、开始和停止、升级和降级我们的服务器。

有一个关于银行的流行故事：它们实现了数字化，并且引入了在线表格，用户需要手动填写表格、打印，然后邮寄回银行（LCTT 译注：我真的遇到过有人问我这样的需求怎么办）。这就是我们今天基础设施遇到的情况：使用新技术来做和以前一样的事情。

在这篇文章中，我们会看到在基础设施管理方面的进步，将基础设施视为一个版本化的组件并试着探索 不可变服务器 immutable server 的概念。在后面的文章中，我们将了解如何使用开源工具来实现持续的基础设施。

title=

实践中的持续集成流程

这是我们熟悉的 CI，尽早发布、经常发布的循环流程。这个流程缺少一个关键的组件：基础设施。

突击小测试：

  • 你怎样创建和升级你的基础设施？
  • 你怎样控制和追溯基础设施的改变？
  • 你的基础设施是如何与你的业务进行匹配的？
  • 你是如何确保在正确的基础设施配置上进行测试的？

要回答这些问题，就要了解 持续基础设施 continuous infrastructure 。把 CI 构建流程分为 代码持续集成 continuous integration code （CIc）和 基础设施持续集成 continuous integration infrastructure （CIi）来并行开发和构建代码和基础设施，再将两者融合到一起进行测试。把基础设施构建视为 CI 流程中的重要的一环。

title=

包含持续基础设施的 CI 流程

关于 CIi 定义的几个方面：

  1. 代码

通过代码来创建基础设施架构，而不是通过安装。 基础设施如代码 Infrastructure as code （IaC）是使用配置脚本创建基础设施的现代最流行的方法。这些脚本遵循典型的编码和单元测试周期（请参阅下面关于 Terraform 脚本的示例）。

  1. 版本

IaC 组件在源码仓库中进行版本管理。这让基础设施的拥有了版本控制的所有好处：一致性，可追溯性，分支和标记。

  1. 管理

通过编码和版本化的基础设施管理，你可以使用你所熟悉的测试和发布流程来管理基础设施的开发。

CIi 提供了下面的这些优势：

  1. 一致性 Consistency

版本化和标记化的基础设施意味着你可以清楚的知道你的系统使用了哪些组件和配置。这建立了一个非常好的 DevOps 实践，用来鉴别和管理基础设施的一致性。

  1. 可重现性 Reproducibility

通过基础设施的标记和基线，重建基础设施变得非常容易。想想你是否经常听到这个：“但是它在我的机器上可以运行！”现在，你可以在本地的测试平台中快速重现类似生产环境，从而将环境像变量一样在你的调试过程中删除。

  1. 可追溯性 Traceability

你是否还记得曾经有过多少次寻找到底是谁更改了文件夹权限的经历，或者是谁升级了 ssh 包？代码化的、版本化的，发布的基础设施消除了临时性变更，为基础设施的管理带来了可追踪性和可预测性。

  1. 自动化 Automation

借助脚本化的基础架构，自动化是下一个合乎逻辑的步骤。自动化允许你按需创建基础设施，并在使用完成后销毁它，所以你可以将更多宝贵的时间和精力用在更重要的任务上。

  1. 不变性 Immutability

CIi 带来了不可变基础设施等创新。你可以创建一个新的基础设施组件而不是通过升级（请参阅下面有关不可变设施的说明）。

持续基础设施是从运行基础环境到运行基础组件的进化。像处理代码一样，通过证实的 DevOps 流程来完成。对传统的 CI 的重新定义包含了缺少的那个 “i”，从而形成了连贯的 CD 。

(CIc + CIi) = CI -> CD

基础设施如代码 （IaC）

CIi 流程的一个关键推动因素是 基础设施如代码 infrastructure as code （IaC）。IaC 是一种使用配置文件进行基础设施创建和升级的机制。这些配置文件像其他的代码一样进行开发，并且使用版本管理系统进行管理。这些文件遵循一般的代码开发流程：单元测试、提交、构建和发布。IaC 流程拥有版本控制带给基础设施开发的所有好处，如标记、版本一致性，和修改可追溯。

这有一个简单的 Terraform 脚本用来在 AWS 上创建一个双层基础设施的简单示例，包括虚拟私有云（VPC）、弹性负载（ELB），安全组和一个 NGINX 服务器。Terraform 是一个通过脚本创建和更改基础设施架构和开源工具。

title=

Terraform 脚本创建双层架构设施的简单示例

完整的脚本请参见 GitHub。

不可变基础设施

你有几个正在运行的虚拟机，需要更新安全补丁。一个常见的做法是推送一个远程脚本单独更新每个系统。

要是不更新旧系统，如何才能直接丢弃它们并部署安装了新安全补丁的新系统呢？这就是 不可变基础设施 immutable infrastructure 。因为之前的基础设施是版本化的、标签化的，所以安装补丁就只是更新该脚本并将其推送到发布流程而已。

现在你知道为什么要说基础设施在 CI 流程中特别重要了吗？

via: https://opensource.com/article/17/11/continuous-infrastructure-other-ci

作者：Girish Managoli 选题：lujun9972 译者：Jamskr 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8