如何在六个月或更短的时间内成为DevOps工程师（二）：配置

注意：这是该系列的第二篇。点击此处阅读第一篇。

快速回顾

在第一篇中，我认为DevOps工程的工作是构建全自动的数字流水线，将代码从开发人员的手里上线到生产。

现在，要有效地完成这项工作需要对基本原理有充分的了解，如下所示：

以及基于这些基础知识的 工具 和技能的良好理解（见下图）。

一个快速提醒：你应该从左到右先学习蓝色的部分，然后再从左到右学习紫色的那部分。

那么，回到我们的主题。在本文中，我们将介绍数字管道流程的第一阶段：配置。

在配置阶段发生了什么呢？

由于我们的代码需要机器来运行，因此配置阶段实际上打造了运行代码的基础设施。

在过去，配置基础设施是一项漫长的，劳动密集型，容易出错的考验。

现在，因为我们拥有令人敬畏的云服务，所以只需点击一下（或多下）按钮即可完成所有配置。

然而，结果发现通过点击按钮来完成这些任务是一个坏主意。

为什么？

因为按钮点击操作

• 容易出错（人类犯错误）
• 没有版本化（这些操作不能存储在git中）
• 不可重复（当更多机器时你需要更多次点击）
• 而且不可测试（我不清楚这些点击操作是否真的有效或是产生其他未知风险）

例如，想想配置你的开发环境所需的所有工作，然后是集成环境，然后QA，然后是灰度，接着是在美国的生产环境，欧洲的生产环境。重复性工作是非常乏味，非常烦人的。

因此，我们需要一种新的方式。那便是“基础设施即代码”，这就是这个配置阶段所要讲的。

作为最佳实践，基础设施即代码要求无论需要哪些工作来配置计算资源，都必须通过代码完成。

注意：“计算资源”是指在产品中正确运行应用程序所需的一切资源，例如计算，存储，网络，数据库等。故名为“基础设施即代码”。

此外，这意味着我们用不会点击操作来作为我们的基础设施部署方式，而是

• 在 Terraform 中写下所需的基础架构状态
• 并将它存储在我们的源代码控制系统中
• 通过正式的 Pull Request 流程来征求反馈
• 再运行测试
• 执行以提供生成我们所需的所有资源

那么问题来了，“为什么需要Terraform？为什么不使用Chef、Puppet、Ansible、CFEngine、Salt、CloudFormation或其他工具来实现呢？”

问得好！关于这一问题，人们已经展开了大量的讨论。

简而言之，我认为Terraform的优势有

• 它非常流行，因此工作机会很多
• 它比其他工具更容易学习
• 它是跨平台的

虽然当前你仍能选择其他工具中的某个！

---

边注：这个领域正在迅速发展并且很容易令人困惑。我觉得需要花几分钟时间来谈谈这些工具发展的近况。

传统上，像Terraform和CloudFormation这样的东西已被用于配置基础设施，而像Ansible这样的东西则用于来配置它。

你可以将Terraform视为创建基础的工具，Ansible在其之上完成其他工作，根据你的需求来部署应用程序。

换句话说，你能使用Terraform来创建VM，然后使用Ansible配置服务器或是部署你的应用程序。

传统上这些工具会这样结合起来一起使用。

但是，Ansible可以做很多（如果不是全部）Terraform可以做的事情。反之亦然。

不要因为工具的选择而困扰到你。你只需知道Terraform是基础设施即代码领域中最具统治力的工具之一，所以我强烈建议你从它开始。

事实上，Terraform+AWS的专业知识是目前最炙手可热的技能之一！

但是，如果你想逐步用Terraform来取代Ansible，你仍然需要知道如何以编程的方式来配置大量服务器，对吧？

完全不必要如此！

事实上，我预测配置管理工具，如Ansible的重要性将会降低，而基础设施配置工具，如Terraform或CloudFormation的重要性将会显著上升。

为什么呢？

因为所谓的“ 不可变部署 ”。

简而言之，不可变部署是指从不改变已部署的基础设施的做法。换句话说，你的部署单元是VM或 Docker 容器，而不是一段代码。

因此，你不会去将代码部署到一组静态VM中，而是部署已经包含了已编译代码的整个VM。

你不会选择更改VM的配置方式，而是部署具有所需配置的新的VM。

你不必去修复生产的机器，你可以直接部署一个新的实例，直接就修复好了！

你将不必在开发与生产环境部署不同的VM集，因为它们都是一样的。

你应该明白我的意思吧。

如果使用得当，这个模式是非常强大的，我强烈推荐使用！

注意：不可变部署要求将配置与代码分开。请阅读12法则（或是参考其他更棒的思路），其中详细介绍了这一点。这是DevOps从业者必读的内容。

代码与配置的分离非常重要，你也不希望每次替换数据库密码时都要重新部署整个应用程序。相反，请确保应用程序从外部配置存储（SSM/Consul或是其他）中获取这个配置。

此外，你可以很容易地看到，随着不可变部署的兴起，像Ansible这样的工具扮演的角色将越来越小。

原因就是你只需配置 一台 服务器并将其作为自动扩展组的一部分去进行多次部署就可以了。

或者，如果你正在使用容器，你肯定希望所有都按定义来进行不可变部署。你不希望开发环境的容器与QA或是生产环境上的不同。

你希望在所有环境中使用完全相同的容器。这可以避免配置偏差，并在出现问题时简化回滚。

除了容器之外，对于那些刚刚开始使用Terraform的人来说，使用Terraform配置AWS基础设施是一个教科书式的DevOps模式，你需要真正掌握它。

等等，如果我需要查看日志来解决问题呢？好吧，你将无需登录服务器去查看日志，而是通过统一日志中心来查看日志。

事实上，一些人早就写过关于如何在AWS中部署ELK的详细文章，如果你想看看它在实践中是如何完成的，那可以先去搜索阅读一下。

此外，你可以完全禁用远程访问，做到比其他人所能做到的更安全！

总而言之，我们的全自动“DevOps”之旅始于配置运行代码所需的计算资源，这就是配置阶段，而实现这一目标的最佳方法是通过不可变部署。

最后，如果你好奇从何处开始，Terraform+AWS组合将是一个不错的选择！

这就是“配置”阶段的全部内容。

未完待续，第三篇 - 版本 ！

（翻译：fengxsong）