即使关于如何“正确”执行它的公认标准仍然难以捉摸，DevOps 仍然是现代 IT 的关键要素。Corey Quinn，FutureAdvisor 的 DevOps 总监，在运营和 DevOps 方面拥有丰富的经验。我有机会在他在 2016 年西北 Linux 节上的两次演讲之前与他进行了交谈：Git 中的糟糕想法 和 Docker 必须死：Docker 教堂的异端。
继续阅读以获得富有洞察力的对话，我们在其中就 DevOps、Git、Docker 和开源进行了非正式的讨论，并带有一点 Corey 式的幽默。
DevOps 是一个流行且有时令人困惑的话题。您如何定义它？它对您意味着什么？
五年前，“DevOps”这个术语是这样的，你可以让 10 个人定义这个术语，得到 12 个不同的答案。今天，这种情况并没有真正改变——如果有什么变化的话，你会得到 15 个答案，范围从理想主义的（“帮助打破文化孤岛”）到描述性的（“文化和工具的结合”）到愤世嫉俗的（“一种通过一个简单的职位更改为你的薪水增加 3 万美元的方法”）。今天，我将选择：DevOps 是开始语义争论的好方法。
你能举一个 DevOps 做得好的例子吗？使用了哪些工具？
很难回过头来说，“这家公司确实做得很好地掌握了 DevOps，所以其他所有人都应该完全按照他们的方式去做。” 这不是 DevOps 文化。那是 货物崇拜编程，我们一直都能看到这样的例子。我见过的最好的例子是那些意识到他们 20 人的工程团队不是谷歌数万名工程师的公司，或者那些在 Facebook 上运行良好的东西根本无法映射到他们今天正在做的事情的公司。因此，他们吸取其他商店的最佳方面，并将它们融入到独一无二的东西中。我希望可以说“DevOps in a Box”存在——我很乐意把它卖给你！——但它就是不存在。
请告诉我们不应该如何做 DevOps。您有最喜欢的恐怖故事吗？
我遇到的对 DevOps 文化最糟糕的误解可能是一家商店，他们期望人们花一半的时间做运营任务，另一半的时间做公司核心应用程序的开发。那不是 DevOps；那是两个不同的工作。毫不奇怪，团队中的每个人都至少在其中一项工作中失败了。
您现在看到哪些趋势，特别是在云和容器化方面？
一个常见的趋势是不可变基础设施的兴起，但我更愿意将其视为短暂基础设施：现在存在的东西在 10 分钟后将不存在，这是设计使然。如何在寻呼机不断响起的情况下监控它？当问题出现在你的雷达上时，如何诊断上次发生在已被重新调度到另一个节点的容器中的间歇性问题？容器和云要求我们重新思考的不仅仅是我们使用的交付技术；它们迫使我们重新思考我们如何监控我们的环境以及我们关心什么。
您曾说过 Git 在 DevOps 工具中变得越来越重要。是什么让它如此关键？
Git 很重要，即使仅仅因为它是目前大多数商店中版本控制的事实标准。更大的版本控制领域很重要，因为它直接说明了“基础设施即代码”的心态。了解在更改某些内容之前代码是什么样的，识别何时以及为何更改了某些内容，提供异步工作流模型——所有这些对于我们作为运营人员所做的事情远不止手动配置服务器或交换机的世界至关重要。我还要进一步说：如果没有 Git 或类似的东西，大多数环境在任何合理的方式下都无法扩展到超过一千个节点。
您觉得哪些与 Git 集成的工具有用？
当您说“Git 工具”时，我想到了那些帮助 Git 变得不那么可怕的东西。为此，Joey Hess 的 myrepos 非常适合简化大量 Git 仓库的管理和更新。Githug（一个 Ruby gem）非常适合通过有趣的挑战来教授 Git 的工作原理。当然，随机 Git 手册页生成器 对于其大多数自动生成的结果来说都非常逼真；Git 是一个非常简单的工具，但很快就会变得非常复杂。
在您的演讲《Docker 必须死：Docker 教堂的异端》中，您为什么说谨慎行事很重要？
我们这个行业有一种令人不安的倾向，即为了本周闪亮的新玩具而抛弃那些经受了时间考验的工具。重要的是要确保你正在为自己的用例进行优化，而不是为别人的用例进行优化。如果你最终试图解决在 20 万个节点的规模下出现的问题，而你自己更接近 20 个节点，你可能就跑题了。我的演讲的重点不是说 Docker 是一项糟糕的技术——它不是。但重要的是要对进入你的基础设施的东西、它的工作原理以及故障案例在你遇到它们之前是什么样子保持意识。
您对容器的最佳实践建议是什么？
我的第一个最佳实践是不使用容器。当你回来并说，“这太荒谬了！由于 X、Y 和 Z 原因，它是我们用例的最佳解决方案，”你很有可能对这个问题进行了足够的思考，而不仅仅是盲目地跳上潮流。记住，最佳实践并非适用于所有情况！
我的第二个最佳实践是确保每个人都彻底理解您的新架构。当开发人员给你一个 3TB 的容器，因为它包含数据库的完整副本时，肯定在某个地方发生了沟通失误。
我的第三个最佳实践是考虑容器化将对您当前环境产生的影响。我们在早期转向更不可变的模型时发现，我们的许多无状态实例远没有我们想象的那么无状态。硬编码的 IP 地址、写出日志文件、运行已遗忘的特定任务的“特殊”主机——许多垃圾在遗留环境中积累。
作为 SaltStack 的贡献者，Salt 在 Docker 等容器化技术中的相关性是什么？
这是一个很好的问题！我们将抛开 Kubernetes（一种流行的容器调度器）是建立在 SaltStack 之上的事实，而是谈谈配置管理背景下的不可变基础设施。即使在您的所有基础设施都是不可变的世界中，编排仍然是一个非常未解决的问题。此外，很少有商店符合该定义——几乎每个人最终都会介于纯配置管理和纯黄金镜像之间。您很可能在您的环境中至少有一些节点不是短暂的或不可变的。
评论已关闭。