[译] 如何在六个月或更短的时间内成为 DevOps 工程师，第二部分：配置

• 原文地址：How To Become a DevOps Engineer In Six Months or Less, Part 2: Configure
• 原文做者：Igor Kantor
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：jianboy
• 校对者：lihanxiang

照片由 Reto Simonet 发布在 Unsplash

注意：这是《如何如何在六个月或更短的时间内成为 DevOps 工程师》系列的第二部分，第一部分请点击这里。

让咱们快速回顾一下上期内容。

在第一部分中，我认为 DevOps 工程师的工做是构建全自动的数字流水线，将代码从开发环境转到生产环境。

如今，要有效地完成这项工做须要对基本原理有充分的了解，请看下图所示：

DevOps 基础介绍图

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

提示：你的目标是先从左到右学习蓝色字体部分知识，而后从左到右学习紫色字体部分知识。

好的，回到咱们的主题。在本文中，咱们将介绍上图学习路线的第一个阶段：配置。

配置阶段介绍图

配置阶段会发生什么？

因为咱们建立的代码须要运行在机器上，所以配置阶段其实是在构建运行代码的基础结构。

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

如今，由于咱们拥有使人敬畏的云服务，因此只需点击一下或者多点几下便可完成全部配置。

然而，实践证实经过点击来完成这些任务是一个坏主意。

为何这么说呢？

由于按钮点击：

1. 容易出错(人为犯错），
2. 没有版本化管理(点击不能存储在 git 中），
3. 不可重复(更多机器=更多点击），
4. 而且不可测试(不知道个人点击是否真的有效或出错）。

例如，想一想在开发环境先配置所需的全部工做...而后是初始化环境...而后系统测试...而后进行分级...而后在美国部署生产环境...而后在欧盟部署生产环境...它很快就会变得很是乏味和烦人。

所以，须要一种新的方式。这种新的方式是架构即代码，这就是这个配置阶段的所有内容。

做为最佳实践，架构即代码要求不管须要哪些工做来配置计算资源，都必须经过代码完成。

注意：“计算资源”是指在产品中正确运行应用程序所需的一切：计算、存储、网络、数据库等。所以，名称为“架构即代码”。

此外，这意味着，咱们将经过架构即代码部署而不是经过点击方式：

1. 在 Terraform 中写出所需的基础设施状态，
2. 将其存储在咱们的源代码控制中，
3. 经过正式 Pull Request 流程征求反馈意见，
4. 测试一下，
5. 执行提供所需的全部容器资源。

如今，显而易见的问题是，“为什么选择 Terraform？为何不使用 Chef 或 Puppet 或 Ansible 或 CFEngine 或 Salt 或 CloudFormation 或其余的？”

好问题！

简而言之，我认为你应该学习 Terraform 的缘由以下：

1. 这很新潮，所以工做机会不少
2. 比其余人更容易学习
3. 这是跨平台的

如今，你能选择其中一个并成功吗？绝对能！

---

注意：这个领域正在迅速发展，很是混乱。我想用几分钟的时间来谈论一些最近的历史和我看到它的发展。像 Terraform 和 CloudFormation 之类的东西被用来提供基础设施，而像 Ansible 之类的东西被用来配置基础设施。

通常，像 Terraform 和 CloudFormation 这样的东西已被用来提供基础设施，而像 Ansible 这样的东西则被用来配置基础设施。

您能够将 Terraform 视为建立基础的工具，Ansible 将房子置于最顶层，而后根据您的须要部署应用程序（例如 Ansible）。

如何理解这些工具介绍图

换句话说，您使用 Terraform 建立 VM ，而后使用 Ansible 配置服务器，以及可能用它部署您的应用程序。

一般将这些工具放在一块儿使用。

可是， Ansible 能够作的（若是不是所有），Terraform 也能够作。反过来也是如此。

不要让那些困扰你。只要知道 Terraform 是基础架构代码空间中最具好的工具之一，因此我强烈建议你从这里开始。

事实上，Terraform + AWS 的专业知识是目前最煊赫一时的技能之一！

可是，若是你想推迟 Ansible 支持 Terraform，你仍然须要知道如何以编程方式批量配置服务器，对吧？

没必要要！

---

实际上，我预测像 Ansible 这样的配置管理工具的重要性将会下降，而像 Terraform 或 CloudFormation 这样的基础配置工具的重要性将会提升。

为何这样说呢？

由于所谓的“不可变部署”。

简而言之，就是是指不改变已部署的基础架构的作法。换句话说，您的部署单元是 VM 或 Docker 容器，而不是一段代码。

所以，您不会将代码部署到VM集群中，而是部署一整个已经编译了代码的 VM。

您不会更改 VM 的配置方式，而是部署更改了配置的新 VM。

您不会对生产环境机器打补丁，而是直接部署已经打补丁的新机器。

您不在开发环境和生产环境部署的 VM 集群配置不一样，它们都是相同的。

你应该明白了个人意思。

若是使用得当，这是一个很是强大的模式，我强烈推荐！

注意：不可变部署要求将配置与您的代码分开。请阅读[12 Factor App](12factor.net/），其中详细介绍了这个(以及其余使人敬畏的想法！）。这是 DevOps 从业者必读的内容。

代码与配置的分离很是重要 —— 您不但愿每次修改数据库密码时都从新部署整个应用程序。相反，请确保应用程序能够从外部配置存储（SSM/Consul/etc）中提取它。

此外，您能够很容易地看到，若是不可变部署的兴起，像 Ansible 这样的工具开始扮演的角色不那么突出。

缘由您只须要配置一台服务器并将其做为自动扩展的集群一部分进行屡次部署。

或者，若是您正在使用容器，您确定但愿几乎按要求进行不可变部署。你不但愿你的开发容器与你的 QA 容器不一样，而且与生产环境不一样。 或者，若是您正在使用容器，您确定但愿几乎按要求进行不可变部署。你不但愿你的开发容器与你的 QA 容器不一样，而且与生产环境不一样。

您但愿在全部环境中使用彻底相同的容器。这能够避免配置误差，并在出现问题时简化回滚。

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

可是等等...若是我须要查看日志来解决问题怎么办？好吧，您将再也不登陆计算机来查看日志，而是查看全部日志的集中式日志记录基础结构。

事实上，一些聪明的家伙已经写了一篇关于如何在 AWS 中部署 ELK 集群的详细文章 —— 若是你想看看它在实践中是如何完成的，请点击上面连接查看。

此外，您能够彻底禁用远程访问，这样比大多数没有禁用的人更安全！

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

最后，若是您对从何处开始感到好奇，Terraform + AWS 组合是您开始旅程的绝佳场所！

这就是“配置”阶段的所有内容。

第三部分的内容在[这里](github.com/xitu/gold-m… -less-part-3-version.md）！

若是发现译文存在错误或其余须要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可得到相应奖励积分。文章开头的本文永久连接即为本文在 GitHub 上的 MarkDown 连接。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。