【译文】原文地址
注意:这是一个系列的第2部分。有关第一部分，请点击这里。
快速回顾
在第一部分中我认为DevOps Engineering的工作是构建完全自动化的数字管道，将代码从开发人员的机器转移到产品中。
现在，为了高效地完成这项工作，需要对基本原理有一个扎实的理解，如下所示:
以及对建立在这些基础之上的工具和技能的良好理解(见下图)。
提醒:你的目标是先学习蓝色的内容，从左到右，然后学习紫色的，从左到右。一共有6个学习技术点，每个月一个。
好了，回到我们的话题。在本文中，我们将介绍数字管道的第一阶段:配置。
概述
在配置阶段会发生什么?
因为我们编写的代码需要运行在机器上，所以Configure阶段实际上是为运行我们的代码构建基础设施。
在过去，基础设施的配置是一个漫长的、劳动密集型的、容易出错的工作。
现在，因为我们有了很方便的云服务，所有的配置都可以通过点击一个按钮来完成。或者，需要多次点击。 然而，事实证明，点击按钮来完成这些任务不是一个好主意。为什么呢？
因为点击按钮：
1、容易出错(人为错误)
2、无法版本化(点击不能存储在git中)
3、不可重复（更多的机器=更多的点击）
4、不可测试（不知道我的点击是真的有用还是会把事情搞砸）
举个例子来说吧，想像下提供你的开发环境所需要的所有工作，从测试环境，然后是QA环境，然后是生产环境，所以这些环境准备工作，很快就会变得非常乏味，非常烦人。
因此，需要一种新的方法。这种新方法是基础设施即代码，这就是配置阶段的全部内容。
作为一种最佳实践，基础设施即代码要求提供计算资源所需的任何工作都必须仅通过代码完成。
注意:这里的“计算资源”指的是在生产环境中正确运行应用程序所需的一切:包括计算、存储、网络、数据库等。因此得名“基础设施即代码”。
此外，这意味着我们将不再用点击方式部署基础设施，而是将这样做：
1、在Terraform中写下想要的基础设施状态
2、将它存储在我们的源代码管理中
3、通过一个Pull Request过程来获得反馈
4、然后测试
5、最后执行代码以提供所需的所有资源
为什么是terraform而不是别的？
现在，一个明显的问题是，“为什么是Terraform?”而不是Chef、Puppet、Ansible、CFEngine、Salt、CloudFormation或其他别的?
好问题!关于这个问题的争论已经沸沸扬扬。
简而言之，我认为你应该学习Terraform，因为：
1、它与时俱进，因此工作机会很多。
2、它比其他工具更容易学习
3、它是跨平台的
但是，你能选择其他任意一个工具而仍然获得成功吗?绝对可以!
旁注:这个领域正在迅速发展，而且相当令人困惑。我想花几分钟谈谈最近的一些历史以及我所看到的变化。
传统上，像Terraform和CloudFormation这样的工具被用来提供基础设施，而像Ansible这样的工具被用来配置应用程序。
你可以把Terraform看作是打地基的工具，Ansible是将房子放在顶部，然后应用程序可以按照你的意愿部署。
然而，Ansible远比Terraform能做更多的事情。反之亦然。
(别让这事困扰你。)要知道，Terraform是基础设施即代码领域中最主要的参与者之一，所以我强烈建议您从它开始。
事实上，Terraform+AWS的专业知识是目前最热门的技能之一!
不可变的部署
我预测像Ansible这样的配置管理工具的重要性将会下降，而像Terraform或CloudFormation这样的提供基础设施工具的重要性将会上升。
为什么？
因为存在所谓的“不可变部署”。
简单地说，不可变部署指的是永远不更改已部署的基础设施。换句话说，您的部署单元是一个VM或Docker容器，而不是一段代码。
因此，您不需要将代码部署到一组静态虚拟机中，而是部署完整的vm，并且代码已经嵌入其中。您不需要更改虚拟机的配置方式，只需使用所需的配置部署新的虚拟机。 你不给机器打补丁，而是部署打过补丁的新机器。你不会在开发环境中运行一组vm，而在生产中运行另一组vm，它们都是相同的（指的是配置上）。
实际上，出于安全您可以禁用对生产环境机器的所有SSH访问，因为在那里不需要做什么—没有需要更改的设置，没有需要查看的日志(稍后将详细介绍日志)。
如果使用正确，这是一个非常强大的模式，我强烈推荐!
注意:不可变部署要求配置与代码分开。请阅读《12 Factor App宣言》，其中详细阐述了这一点(以及其他很棒的做法!)这是DevOps实践者的必读指南。
代码与配置的解耦非常重要——每次修改数据库密码时，你都不希望重新部署整个应用程序。相反，请确保应用程序从外部存储(SSM/Consul/等)中获取修改后密码。
此外，您可以很容易地看到，由于不可变部署的兴起，像Ansible这样的工具开始扮演不那么重要的角色。原因是，您只需要配置一台服务器，并将其作为自动伸缩组的一部分进行多次部署。或者，如果您使用的是容器，那么您肯定想要不可变部署。你不希望你的开发容器与QA容器不同，也不希望它与生产环境容器不同。
您希望在所有环境中运行完全相同的容器。这避免了配置偏差，并简化了出现问题时的回滚。除了容器之外，对于那些刚刚开始的人来说，使用Terraform提供AWS基础设施是一种教科书式的DevOps模式，是你真正需要掌握的东西。
但是，如果我需要查看日志来排除问题怎么办?您将不再登录到机器上查看日志，而是查看中心化的日志基础设施，将所有日志集中存储。
事实上，一些牛人已经写了一篇关于如何在AWS中部署ELK的详细文章——如果你想了解在实践中是如何实现的，请阅读。
同样，你可以完全禁用远程访问，因为这比大多数人的处理方式更安全!
总而言之，完全自动化的“DevOps”旅程开始于能提供运行代码所需的计算资源-集配置阶段。实现这一目标的最佳方式是通过不可变部署。
最后，如果你想知道从哪里开始，那么Terraform+AWS组合是一个很好的开始!
这就是“配置”阶段的全部内容。