版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/M2l0ZgSsVc7r69eFdTj/article/details/85043015
在第一篇中，我认为DevOps工程的工作是构建全自动的数字流水线，将代码从开发人员的手里上线到生产。
现在，要有效地完成这项工作需要对基本原理有充分的了解，如下所示：
以及基于这些基础知识的工具和技能的良好理解（见下图）。
一个快速提醒：你应该从左到右先学习蓝色的部分，然后再从左到右学习紫色的那部分。
那么，回到我们的主题。在本文中，我们将介绍数字管道流程的第一阶段：配置。
在配置阶段发生了什么呢？
由于我们的代码需要机器来运行，因此配置阶段实际上打造了运行代码的基础设施。
在过去，配置基础设施是一项漫长的，劳动密集型，容易出错的考验。
现在，因为我们拥有令人敬畏的云服务，所以只需点击一下（或多下）按钮即可完成所有配置。
然而，结果发现通过点击按钮来完成这些任务是一个坏主意。
为什么？
因为按钮点击操作：
容易出错（人类犯错误）
没有版本化（这些操作不能存储在Git中）
不可重复（当更多机器时你需要更多次点击）
而且不可测试（我不清楚这些点击操作是否真的有效或是产生其他未知风险）
例如，想想配置你的开发环境所需的所有工作，然后是集成环境，然后QA，然后是灰度，接着是在美国的生产环境，欧洲的生产环境。重复性工作是非常乏味，非常烦人的。
因此，我们需要一种新的方式。那便是“基础设施即代码”，这就是这个配置阶段所要讲的。
作为最佳实践，基础设施即代码要求无论需要哪些工作来配置计算资源，都必须通过代码完成。
注意：“计算资源”是指在产品中正确运行应用程序所需的一切资源，例如计算，存储，网络，数据库等。故名为“基础设施即代码”。
此外，这意味着我们不会用点击操作来作为我们的基础设施部署方式，而是：
在Terraform中写下所需的基础架构状态
并将它存储在我们的源代码控制系统中
通过正式的Pull Request流程来征求反馈
再运行测试
执行以提供生成我们所需的所有资源
问得好！关于这一问题，人们已经展开了大量的讨论。
简而言之，我认为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法则[1]（或是参考其他更棒的思路），其中详细介绍了这一点。这是DevOps从业者必读的内容。
代码与配置的分离非常重要，你也不希望每次替换数据库密码时都要重新部署整个应用程序。相反，请确保应用程序从外部配置存储（SSM/Consul或是其他）中获取这个配置。
此外，你可以很容易地看到，随着不可变部署的兴起，像Ansible这样的工具扮演的角色将越来越小。
原因就是你只需配置一台服务器并将其作为自动扩展组的一部分去进行多次部署就可以了。
或者，如果你正在使用容器，你肯定希望所有都按定义来进行不可变部署。你不希望开发环境的容器与QA或是生产环境上的不同。
你希望在所有环境中使用完全相同的容器。这可以避免配置偏差，并在出现问题时简化回滚。
除了容器之外，对于那些刚刚开始使用Terraform的人来说，使用Terraform配置AWS基础设施是一个教科书式的DevOps模式，你需要真正掌握它。
等等，如果我需要查看日志来解决问题呢？好吧，你将无需登录服务器去查看日志，而是通过统一日志中心来查看日志。
事实上，一些人早就写过关于如何在AWS中部署ELK的详细文章[2]，如果你想看看它在实践中是如何完成的，那可以先去搜索阅读一下。
此外，你可以完全禁用远程访问，做到比其他人所能做到的更安全！
总而言之，我们的全自动“DevOps”之旅始于配置运行代码所需的计算资源，这就是配置阶段，而实现这一目标的最佳方法是通过不可变部署。
最后，如果你好奇从何处开始，Terraform+AWS组合将是一个不错的选择！
这就是“配置”阶段的全部内容。
相关链接：
https://12factor.net/
https://medium.com/@devfire/deploying-the-elk-stack-on-amazon-ecs-dd97d671df06
原文链接：https://medium.com/@devfire/how-to-become-a-devops-engineer-in-six-months-or-less-part-2-configure-a2dfc11f6f7d