原文地址：https://medium.com/@devfire/how-to-become-a-devops-engineer-in-six-months-or-less-part-2-configure-a2dfc11f6f7d
原文作者：Igor Kantor
翻译君：CODING 戴维奥普斯
在第一篇文章中，我对 DevOps 工程师的工作定义是搭建一个数字化的全自动流水线来高效地将代码从编写环节部署到生产环境中：《DevOps 工程师成长日记系列一：必备知识与技能组合》。
但是高效地完成这项工作首先需要有一定的基础，如下图：
同时还要对各类工具和使用这些工具所需的技能有所了解，才能做到事半功倍。
温馨提示：我们的目标是快速地学习下图中蓝色部分的内容，按从左到右的顺序，然后开始学习紫色的部分，同样是从左到右。整个流程分为六个模块，顺利的话每个月完成一个模块的学习，刚好六个月学完。
在这篇文章中我们会 cover 整个流水线中的第一部分：配置（Configure）。
综述所以在配置阶段到底是要我们做什么呢？
简而言之，就是我们写的代码需要跑在服务器上，在配置阶段我们所要做的就是在服务器上搭建适合我们的代码运行的基础环境。
在过去配置基础环境的过程是一个及其冗长、到处是坑、重复性高的痛苦经历。
现在由于我们拥有了云服务器这种高级服务，所有的基础环境设置都可以通过点击完成，当然有时候可能需要很多次点击。
但是，我们发现通过点击来实现配置环境也不是一个好主意，因为同样的问题仍然存在：
还是到处是坑（human error 无法避免）
没法控制版本（点击没办法存储在 git 里）
重复性高（更多的机器 = 更多次的点击）
同时还没法测试（完全黑箱，不知道点击后会不会把所有东西弄乱）
想象一下，当你需要给你的 dev 环境、QA 环境、Staging 环境和各个地区不同的生产环境做配置时所需的工作量，而且这项工作很快就会变得非常烦人和冗长。
所以我们就需要一种新的方式来完成这个工作，而这个新的解决方案就是 “基础设施即代码（Infrastructure as Code）“ 这也是本文关于 DevOps 中配置环节的重点。
基础设施即代码（Infrastructure as Code）的最佳实践即所有归为计算资源编排工具类的工作都必须使用代码来完成。这里的计算资源指的是为了让代码跑起来所需要的一切，比如：服务器、存储、网络、数据库等等。
此外，这意味着我们部署基础设施的方式从各种点击变为：
在 Terraform 中编写所需的基础架构状态
将其存储在我们的源代码版本控制中
通过正式的 Pull Request 流程征求反馈
测试一下配置
通过执行代码来配置所需的资源
为什么选用 Terraform 而不是其他的呢？
你现在可能会问为什么要选用 Terraform 而不是 Chef 或者 Puppet 或者 Ansible 或者 CFEngine 或者 Salt 或者其他什么呢？
好问题，而且这个问题已经在各个社区翻来覆去讨论过无数遍了，简而言之，我认为你应该学习 Terraform 有以下原因：
Terraform 现在很火，这代表着会有很多相关的工作机会
相对于其他的来说，它比较容易学习
它有跨平台支持
当然这绝不代表着你选择了其他的工具就没法玩转了，相信每个工程师都有着自己对于工具的理解和选择。
SIDE NOTE：这个领域正在经历迅速发展并且可能会让人困惑，所以我想花几分钟时间谈谈最近的一些历史，以及我看到事情在往哪里发展。
传统意义上来说，Terraform 和 CloudFormation 这类工具是用来编排基础设施的，而其他像 Ansible 这类的工具是用来做配置的。
你可以想像成 Terraform 是一个打地基的工具，然后 Ansible 在地基上盖房子，在帮助你的代码部署到相应的环境。
换句话说，通过 Terraform 来创建虚拟机，然后使用 Ansible 来配置和部署应用，过去都是这么搭配操作的。
然而，工具发展到现在，其实 Ansible 能干的事 Terraform 基本上也能做了，反之亦然。不过也别让这些事儿烦你，只需要知道现在 Terraform 已经是这个领域最重量级的选手，所以强烈推荐从 Terraform 开始学习。
事实上，Terraform + AWS 已经成为最火的技术需求之一了。
不可变基础设施（Immutable Infrastructure）实际上，我预测 Ansible 这类配置管理工具的重要性会降低，而 Terraform 或 CloudFormation 等基础设施编排工具的重要性将会提高。
为什么呢？正是因为不可变基础设施（Immutable Infrastructure）概念的出现。