共计 2575 个字符，预计需要花费 7 分钟才能阅读完成。
基础设施是软件开发过程的外围准则之一——它间接负责软件应用程序的稳固运行。这种基础设施的范畴从服务器、负载平衡器、防火墙和数据库始终到简单的容器集群。
对基础设施的思考不仅要实用于生产环境，因为它们遍布整个开发过程，还包含工具和平台，如 CI/CD 平台、登台环境和测试工具。随着软件产品复杂度的减少，对这些基础设施的思考也要随之变动。为了满足 DevOps 古代疾速软件开发周期的需要，手工治理基础设施的传统办法很快就变成了一个无奈扩大的解决方案。这就是 IaC 已成为现在开发中事实上的解决方案的起因。
什么是基础设施即代码？
IaC，Infrastructure as Code，基础设施即代码，是通过代码而非手动定义的基础设施的供给和治理过程。IaC 从开发人员那里拿走了大部分资源调配工作，开发人员能够执行脚本以筹备好基础设施。这样一来，应用程序部署就不会因为期待基础设施而碰壁，系统管理员也无需治理耗时的手动流程。
以下是创立 IaC 环境工作原理的步骤阐明：
- 开发人员用特定于域的语言（DSL）定义配置参数。
- 指令文件被发送到主服务器、治理 API 或代码存储库。
- IaC 平台依照开发人员的批示创立和配置基础设施。
通过将基础设施作为代码，用户不用在每次开发、测试或部署软件时都配置环境。所有基础设施参数都以称为清单的文件的模式保留。
与所有代码文件一样，清单易于重用、编辑、复制和共享，它使构建、测试、筹备和部署基础设施更快、更统一。
开发人员对配置文件进行编码，并将其存储在版本控制中。如果有人编辑了一个文件，拉取申请和代码审查工作流能够查看更改的正确性。
IaC 最佳实际
基础设施自动化的施行将须要大量的更改和重构，这对组织来说可能是相当沉重的过程。如果想防止大多数的限度，并使过渡尽可能平滑，请遵循上面的最佳实际！
为 IaC 的版本库应用 CI/CD 和品质管制
这将帮忙您放弃代码的良好品质，并从您的 DevOps 团队或开发人员那里取得疾速反馈循环（在利用更改之后）。侥幸的是，有一些测试框架，比方 Terratest for Terraform，容许咱们编写理论的测试。越早尝试用它笼罩所有内容，就越能从中受害，基础设施产生的意外问题也就越少。能够必定的是，在这里虽无奈预测应用程序谬误，但至多能够对本人的基础架构更有信念。
让你的基础设施成为模块化的代码
微服务体系结构是软件开发中的一种风行趋势，它通过开发更小、模块化的代码单元来构建软件，这些代码单元能够独立于产品的其余组件进行部署。
同样的概念也实用于 IaC。能够将基础设施合成为独自的模块或堆栈，并以自动化的形式将它们组合起来。
这种办法有如下劣势：
- 首先，能够灵便管制根底构造代码各局部的拜访权限。例如，高级工程师可能不相熟或不具备基础设施配置某些局部的专业知识，通过模块化基础架构代码，就能够在高级工程师跟上进度之前，回绝他们拜访这些组件。
- 此外，模块化基础设施天然地限度了能够对配置进行的更改数量。较小的更改使 bug 更容易检测，并使您的团队更加灵便。
如果应用 IaC 来反对微服务体系结构，那么应该应用配置模板来确保基础设施扩大为大型服务器集群时的一致性。这最终将对配置服务器和指定它们应该如何交互十分有价值。
继续测试、集成和部署
继续的测试、集成和部署过程是治理可能对基础架构代码进行的所有更改的好办法。
测试应该严格利用于您的基础架构配置，以确保没有部署后问题。依据您的须要，应该执行一系列测试。能够设置自动测试，以便在每次更改配置代码时运行。
基础设施的安全性也应该被继续监控和测试。DevSecOps 是一种新兴的实际，平安业余人员与开发人员一起工作，在整个软件开发生命周期中一直地整合威逼检测和平安测试，而不是仅仅在最初投入。通过减少测试、平安和开发团队之间的合作，能够在开发生命周期的晚期辨认 Bug 和威逼，从而在上线时将其最小化。
通过良好的继续集成过程，这些配置模板能够在不同的环境（如开发、测试和质量保证）中屡次应用。而后，开发人员就能够在这些环境中应用统一的基础设施配置。这种继续集成将升高在将基础架构部署到生产环境中时呈现可能对应用程序无害的谬误的危险。
保护版本控制
这些配置文件将受版本控制。因为所有配置细节都是用代码编写的，所以对代码库的任何更改都能够进行治理、跟踪和协调。
与利用程序代码一样，应该应用 Git、Mercurial、Subversion 等源代码管制工具来保护 IaC 代码库的版本。这不仅能够为代码更改提供审计跟踪，还能够在 IaC 代码上线之前进行合作、同行评审和测试。
代码分支和合并最佳实际也应该用于进一步减少开发人员的合作，并确保对 IaC 代码的更新失去正确治理。
如果刚刚开始应用 IaC，不要试图在一开始就将所有自动化。起因是变动的速度很快。一旦您的平台变得或多或少稳固，您将可能自动化其资源调配和保护。
IaC 的挑战
IaC 的益处很多，但这种模式的确存在一些须要解决的挑战，能够在施行过程之前理解并妥善解决。
配置漂移
无论您配置服务器的一致性或频率如何，从久远来看，都可能呈现配置漂移。这就是在建设 IaC 工作流程后，需确保没有内部烦扰的起因。每次须要批改基础设施时，必须确保依照事后建设的保护工作流程进。这一准则被称为基础设施不变性——即基础设施应齐全依照指定的形式运行，如果须要更改，则会提供一套全新的基础设施，并齐全替换过期的基础设施。
如果您最终依然对相似的零碎组进行了不统一的更改，其中一些更改将不可避免地与其余更改不同，这可能会导致配置的变动。
谬误的潜在反复
只管 IaC 的施行过程和机器创立在很大水平上依赖于自动化，但整个过程中仍有某些局部须要手动实现。编写父代码是其中一个过程，而且当波及人工工作时，总是有可能出错。即便在 QA 查看定期且统一的环境中，人们也可能犯错误或疏忽要害的事件。
作为自动化的副作用，这些谬误可能会在多台机器上产生，并且可能会造成尽可能多的安全漏洞。请记住，简直所有云破绽都来自谬误配置。为了确保从头至尾的平安，倡议仔细检查生成 IaC 体系结构的代码，这能够通过严格且极为统一的测试和彻底的审核过程来实现。当然，这些额定的工序往往也会减少相应的费用收入。
对于寻求自动化和更快交付的组织来说，作为代码的基础设施正在迟缓但确定地成为常态。只有通过简化的工作流程和改良的开发环境，能力更快地开发应用程序。
