Also published on my website.

还发布在 我的网站上 。

目录 (Table of contents)

What is Infrastructure as CodeKey Principles- Idempotency- ImmutabilityPatterns and Practices- Everything in Source Control- Modularize and Version- Documentation- Testing- Security and Compliance- Automate Execution from a Shared Environment — Infrastructure as Code Pipeline — GitOpsConclusion

什么是基础架构即代码 关键原则 - 幂等 - 不变性 模式和实践 - 源代码管理中的所有内容 - 模块化和版本 - 文档 - 测试 - 安全性和合规性 - 从共享环境中自动执行 - 基础结构作为代码管道 -GitOps 结论

Notes:1. There is a certain level of Organizational maturity needed to use these Principles, Patterns, and Practices. This article is not focused on the cultural side of things but it is very important for the successful adoption of these.2. Examples used in this article are using Terraform and AWS but these Principles, Patterns, and Practices are generic and can mostly be applied to other IaC tools like Pulumi, CloudFormation, etc. and Cloud Providers like GCP and Azure or even On-Premise.

注意： 1.使用这些原则，模式和实践需要一定程度的组织成熟度。 本文不关注事物的文化方面，但是对于成功地采用这些东西非常重要。2。 在这篇文章中使用的例子使用Terraform和AWS但这些原则，模式和实践是通用的，大多可应用于其他IAC工具，如 Pulumi ， CloudFormation 等与云供应商，如GCP和Azure的，甚至内部部署。

什么是基础架构即代码？ (What is Infrastructure as Code?)

Infrastructure as Code (IaC) is an approach that takes proven coding techniques used by software systems and extends it to infrastructure. It is one of the key DevOps practices that enable teams to deliver infrastructure, and the software running on it, rapidly and reliably, at scale.

基础架构即代码(IaC)是一种采用软件系统使用的成熟编码技术并将其扩展到基础架构的方法。 它是DevOps的关键实践之一，它使团队能够快速，可靠地交付基础架构及其上运行的软件。

If you want to achieve Continuous Delivery for your applications, having a rapid and reliable, provisioning mechanism for your infrastructure is important.

如果要实现应用程序的持续交付 ，那么为基础架构提供快速，可靠的配置机制非常重要。

In this article, we will go through various Principles, Patterns, and Practices that have helped me, and the organizations I have worked with, over the years.

在本文中，我们将介绍多年来为我以及与我合作过的组织提供帮助的各种原则，模式和实践。

关键原则 (Key Principles)

Before we start talking about Patterns and Practices lets look at key principles for effective IaC.

在我们开始讨论模式和实践之前，让我们看一下有效IaC的关键原则。

幂等 (Idempotency)

Idempotency means no matter how many times you run your IaC and, what your starting state is, you will end up with the same end state. This simplifies the provisioning of Infrastructure and reduces the chances of inconsistent results.

幂等意味着无论您运行IaC多少次，并且无论您的起始状态是什么，您都将以相同的结束状态结束。 这简化了基础架构的配置，并减少了结果不一致的机会。

Idempotency can be achieved by using a stateful tool with a declarative language, like Terraform, where you define the desired end state of infrastructure you want, and then it is Terraform’s job to get you to that end state. If it can’t get to the desired state it will fail.

可以通过使用带有声明性语言的有状态工具(例如Terraform)来实现幂等性，在该工具中定义所需的基础架构的所需最终状态，然后Terraform的工作就是使您达到该最终状态。 如果无法达到所需的状态，它将失败。

In diagram #1 below as you can see that for a Non-Idempotent IaC if you run it twice it will provision 6 VMs instead of desired 3. In the case of Idempotent IaC, it only provisions the 3 VMs even if you run it multiple times thereby making it more reliable and consistent.

在下面的图1中，您可以看到，对于非幂等IaC如果运行两次，它将提供6个VM而不是所需的3个VM。对于幂等IaC，即使多次运行它，它也只能提供3个VM。从而使它更加可靠和一致。

不变性 (Immutability)

Configuration drift is a huge problem with infrastructure. It occurs when over a period there are changes made to infrastructure that are not recorded, and your various environments drift from each other in ways that are not easily reproducible. This usually happens if you have a mutable infrastructure that lives for a long time. The system is more brittle in general for long-lived infrastructure since issues like a slow memory leak, disk out of space due to log accumulation, etc. might occur over a period. It also means that you won’t be provisioning the infrastructure as frequently as your applications or configuration and as a result won’t be confident in your ability to do so. These issues can be resolved by using immutable infrastructure.

配置漂移是基础架构的一个巨大问题。 如果在一段时间内未记录对基础结构的更改，并且您的各种环境以不易复制的方式彼此漂移，则会发生这种情况。 如果您的可变基础设施可以长期使用，通常会发生这种情况。 对于长期使用的基础架构，该系统通常较脆弱，因为可能会在一段时间内发生诸如内存泄漏缓慢，日志积累导致磁盘空间不足等问题。 这也意味着您将不会像应用程序或配置那样频繁地配置基础架构，因此对自己的能力没有信心。 这些问题可以通过使用不可变的基础结构来解决。

Immutable infrastructure means instead of changing an existing infrastructure you replace it with new. By provisioning new infrastructure every time, you are making sure it is reproducible and doesn’t allow for configuration drift over time.

不可变的基础架构意味着您无需更改现有基础架构，而是将其替换为新的基础架构。 通过每次供应新的基础架构，您可以确保它具有可重现性，并且不会随时间推移而导致配置漂移。

Immutable infrastructure also enables scalability when provisioning infrastructure on cloud environments. You can see in diagram #2 below that for mutable infrastructure v2 of application is deployed on the same servers as v1 but for immutable infrastructure, it provisions new VMs with v2 of application.

在云环境中配置基础架构时，不可变的基础架构还可以实现可伸缩性。 您可以在下面的图2中看到，对于可变的应用程序基础架构v2与v1部署在同一服务器上，但是对于不可变的基础架构，它为应用程序v2提供了新的VM。

模式与实践 (Patterns and Practices)

源代码管理中的所有内容 (Everything in Source Control)

It goes without saying that everything should be in source control. Even a script that you run occasionally to fix an issue, as well as the pipeline used to provision your infrastructure and deploy your software (pipeline as code). I have been at places where no one knows where a script that runs in production lives, who created it, and history of changes. This is a situation you don’t want to be in.

不言而喻， 一切都应该在源代码控制中 。 甚至您偶尔运行以解决问题的脚本，以及用于预配置基础架构和部署软件的管道 ( 管道作为代码 )。 我到过的地方，没人知道在生产环境中运行的脚本的位置，创建者和更改历史。 这是您不想遇到的情况。

Make sure the code is accessible to everyone in the company, even for developers that don’t make changes to the IaC code base. An exception might be that you have a very strong reason for not doing it, like a legal reason. This gives visibility and a better understanding to those who run their applications on your infrastructure, so when your consumers want to troubleshoot an issue, and want to understand how the infrastructure was provisioned, they can easily do that by looking at the code. They should be able to look at the code, understand how the infrastructure is provisioned, and even contribute if they choose to do so. I have worked with teams where it is not only the case that IaC repositories are not accessible to the rest of the organization, but they are also stored on separate source control tools that keep them hidden. This is an anti-pattern.

确保公司中的每个人都可以访问该代码，即使对于不更改IaC代码库的开发人员也是如此。 一个例外可能是您有很强的理由不这样做，例如出于法律原因。 这为在您的基础结构上运行其应用程序的人员提供了可视性和更好的理解，因此，当您的消费者想要解决问题并想了解如何配置基础结构时，他们可以通过查看代码轻松地做到这一点。 他们应该能够查看代码，了解如何配置基础结构，甚至在愿意的情况下做出贡献。 我曾与团队合作，不仅无法让组织的其他部门访问IaC信息库，而且还将它们存储在单独的源代码控制工具中以使其隐藏。 这是一种反模式。

模块化和版本化 (Modularize and Version)

Modularizing IaC like software code helps with maintenance, readability, as well as ownership. It also helps in keeping the changes small and independently deployable. Refactoring IaC is relatively difficult compared to software especially for critical pieces like DNS records, CDN, Network, Databases, etc. so being biased towards over-abstraction up-front works better even though that means dealing with slightly more complex IaC than needed.

像软件代码一样模块化IaC有助于维护，可读性以及所有权。 它还有助于使更改保持较小并可以独立部署。 与软件相比，重构IaC相对困难，尤其是对于诸如DNS记录，CDN，网络，数据库等关键部分的软件而言，因此偏向于过度抽象的前期工作效果更好，即使这意味着处理比所需稍微复杂的IaC。

In many organizations where they have different teams like Networking, Security, and Platform Engineering¹ it might make sense to separate various layers of your infrastructure and give ownership to appropriate teams to allow better control. I have also separated the layers in cases where it is a cross-functional team managing both software and infrastructure due to the other reasons mentioned above. In diagram #3 below I have shown an example for deployments to Amazon Elastic Kubernetes Service (EKS) with various modules within each infrastructure layer and its ownership. These modules/layers might be different for you based on the setup you have.

在许多拥有不同团队的组织中，例如网络，安全和平台工程¹ ，将基础结构的各个层分开并将所有权分配给适当的团队以更好地进行控制可能是有意义的。 由于上述其他原因，在由软件和基础架构同时管理的跨职能团队的情况下，我也将各层分开。 在下面的图3中，我展示了一个示例，该示例说明了如何部署到Amazon Elastic Kubernetes Service(EKS)，其中每个基础架构层中都有各种模块及其所有权。 根据您的设置，这些模块/层可能与您有所不同。

Versioning for modules is pretty important to make sure you are not breaking things in production unless you are using monorepo in which case you are always using the latest version from the same repo.

模块的版本控制非常重要，以确保您不会破坏生产环境，除非您使用的是monorepo，在这种情况下，您始终使用同一仓库中的最新版本。

文献资料 (Documentation)

With IaC, you should not need extensive documentation since everything is codified, but some documentation is still essential. Better quality documentation not only helps the team that is maintaining IaC but the consumers of the infrastructure as well.

使用IaC，由于所有内容均已编纂，因此您不需要大量的文档，但是某些文档仍然是必不可少的。 高质量的文档不仅对维护IaC的团队有帮助，而且对基础架构的使用者也有帮助。

Documentation is hard. Just like with code, making sure that you have just enough documentation to convey the message you want is important. More documentation doesn’t mean it’s better. Out of date documentation is even worse.

文档很难。 就像使用代码一样，确保您有足够的文档来传达所需的消息也很重要。 更多文档并不意味着更好。 过时的文档甚至更糟。

Making the documentation easily available when needed is important. For example, if you display an error message, it’s a good idea to include a link to the documentation to troubleshoot issues like that. Also, having runbook for typical scenarios help troubleshooting during production issues.

使文档在需要时轻松可用非常重要。 例如，如果显示错误消息，则最好包括指向文档的链接以解决此类问题。 此外，具有运行手册中的生产问题的典型方案协助解决疑难。

The documentation should live closer to the code. There are more chances you will keep it updated if it is with the code or closer to it. For example, adding a README in the same repository as IaC instead of some external place like confluence or wiki outside the repository is better. This way there are more chances you will remember to update the documentation in the same commit as the code changes and it can also be a reminder during the Pull Request process. If you can generate documentation from your code or use tests as documentation, that’s ideal.

该文档应该更接近代码。 如果与代码一起或更靠近代码，则有更多机会使它保持更新。 例如，最好在与IaC相同的存储库中添加自述文件，而不是在存储库外部添加诸如Confluence或Wiki之类的外部位置。 这样，您将有更多的机会记得在代码更改的同一提交中更新文档，这也可以在“拉取请求”过程中提醒您。 如果您可以从代码中生成文档或将测试用作文档，那是理想的选择。

测试中 (Testing)

Like in software development, you need to think about testing your IaC at various levels. If you are not aware of the Test Pyramid, here is an article on Martin Fowler’s website. Below is my attempt at a test pyramid for IaC.

像在软件开发中一样，您需要考虑在各个级别上测试IaC。 如果你不知道的测试金字塔， 这里是Martin Fowler的网站上的一篇文章。 以下是我为IaC测试金字塔的尝试。

The idea here is that as you go up the test pyramid, the tests are more costly, more brittle, take longer to run, and require higher maintenance. So for these reasons and to get faster feedback, you should run tests at the bottom of the pyramid as often as possible, and the tests at the top, less frequently.

这里的想法是，随着您逐步进入测试金字塔，测试成本更高，更脆弱，运行时间更长且需要更高的维护。 因此，由于这些原因并为了获得更快的反馈，您应该尽可能在金字塔的底部运行测试，而在金字塔的顶部运行的频率要低一些。

Static Analysis: As this is the quickest way to get the feedback, you should run it as often as possible, even on your machine. There are integrations to do this automatically when you save a file in your text editor or IDE. You can do static analysis using tools like terraform validate or TFLint.

静态分析：由于这是获取反馈的最快方法，因此，即使在您的计算机上，也应尽可能频繁地运行它。 当您在文本编辑器或IDE中保存文件时，有一些集成可以自动执行此操作。 您可以使用terraform validate或TFLint等工具进行静态分析。

Unit Testing: Since most of the tools (like terraform and ansible) are declarative, unit testing is usually not needed for IaC. In some cases, though, unit tests might be helpful like when you have conditionals or loops. If you are writing bash scripts you can do unit testing using bats, or if you are using Pulumi, which supports languages like TypeScript, Python, Go, or C# you can use the language test framework.

单元测试：由于大多数工具(例如terraform和ansible)都是声明性的，因此IaC通常不需要单元测试。 但是，在某些情况下，单元测试可能会很有用，例如当您有条件或循环时。 如果你正在写的bash脚本可以做单元测试使用蝙蝠 ，或者如果你正在使用Pulumi ，支持像打字稿，巨蟒，围棋，或C＃语言，你可以使用的语言测试框架。

Integration Testing: This is when you provision your resources in an environment and verify whether you have met certain requirements. Remember not to write tests for things that your tool is responsible for especially if you are writing declarative code. For example, you should be writing automated tests to make sure that none of your s3 buckets are public instead of verifying whether the policies specified in IaC were applied or not. Another example would be to test that only certain ports are open across all of your EC2 instances. You can also provision an Ephemeral² environment (that you can tear down later) to run these tests. Depending on how long these tests take you might want to run these after every commit or as nightly builds. Tools like Chef InSpec and goss are helpful for these types of tests.

集成测试：这是在环境中置备资源并验证是否满足某些要求时的情况。 切记不要为工具负责的事情编写测试，尤其是在编写声明性代码时。 例如，您应该编写自动化测试以确保没有s3存储桶公开，而不是验证是否应用了IaC中指定的策略。 另一个示例是测试在所有EC2实例之间仅打开某些端口。 您也可以提供一个短暂的²环境(以后可以拆掉)来运行这些测试。 根据这些测试花费的时间，您可能希望在每次提交后或每晚进行构建时运行这些测试。 像工具厨师INSPEC和戈斯都对这些类型的测试很有帮助。

Smoke Test with Dummy Application: Last but not the least way of testing is by provisioning an environment, deploying a dummy application, and running quick smoke tests to verify that the application was deployed correctly. Use a dummy application to test scenarios your real application would have but is not configured for production. For example, if your apps connect to a database that’s externally hosted, you should try connecting to it in your dummy application. This gives you confidence that infrastructure that you are provisioning allows you to run applications you intend to run on it. Since these are slow tests you can run these after a new environment is provisioned and then periodically.

使用虚拟应用程序进行冒烟测试：最后但并非最不重要的测试方法是通过配置环境，部署虚拟应用程序以及运行快速冒烟测试来验证应用程序是否已正确部署。 使用虚拟应用程序测试您的实际应用程序可能具有但未配置用于生产的方案。 例如，如果您的应用程序连接到外部托管的数据库，则应尝试在虚拟应用程序中连接到该数据库。 这使您确信配置的基础架构允许您运行打算在其上运行的应用程序。 由于这些是缓慢的测试，因此您可以在配置新环境之后定期运行它们。

安全与合规 (Security and Compliance)

Making sure your infrastructure, and the applications running on it, are secure and compliant is an important, but often overlooked aspect. Traditionally, a lot of organizations have manual checks and gates for this that are time-consuming and usually happen at a later stage in the deployment cycle, but with IaC you can automate those to provide better security/compliance and run them more frequently and sooner in the cycle.

确保基础架构及其上运行的应用程序安全且合规是一个重要但经常被忽视的方面。 传统上，许多组织为此进行手动检查和控制，这很耗时，通常在部署周期的后期进行，但是使用IaC，您可以将其自动化以提供更好的安全性/合规性，并更频繁，更早地运行它们在周期中。

Here are some of the aspects to consider:

这里是一些要考虑的方面：

Identity and Access Management: Make sure you have a robust Identity and Access Management for your IaC and the infrastructure it provisions. Using Role-Based Access Control (RBAC) for IaC that provisions the infrastructure helps in reducing the overall attack surface. With RBAC you grant just enough permission to your IaC to perform the operation it’s supposed to do.

身份和访问管理：确保您对IaC及其提供的基础架构具有强大的身份和访问管理。 使用为基础架构配置IaC 的基于角色的访问控制(RBAC)有助于减少总体攻击面。 使用RBAC，您仅向IaC授予足够的权限即可执行它应该执行的操作。

Secrets Management: IaC usually needs secrets to provision any infrastructure. For example, if you are provisioning resources in AWS you will need AWS credentials to connect to it. Make sure you use a reliable secrets management tool like Hashicorp Vault or AWS Secrets Manager.

机密管理： IaC通常需要机密来配置任何基础结构。 例如，如果您要在AWS中配置资源，则需要AWS凭证才能连接到它。 确保使用可靠的机密管理工具，例如Hashicorp Vault或AWS Secrets Manager 。

If you need to output or store any secrets in the state file (though you should try to avoid this) make sure they are encrypted so if someone gets hold of the state file they can’t extract the secret out of it.

如果您需要在状态文件中输出或存储任何机密信息(尽管您应尽量避免这样做)，请确保已对其进行加密，这样，如果有人掌握了状态文件，他们将无法从中提取机密信息。

Security Scanning: Running security scans after provisioning or changing infrastructure in a Lower or Ephemeral environment helps in avoiding security issues in Production. Using tools like CIS Benchmark and Amazon Inspector helps with finding common vulnerabilities/exposures and also make sure that security best practices are followed.

安全扫描：在较低或临时环境中配置或更改基础结构之后运行安全扫描有助于避免生产中的安全问题。 使用诸如CIS Benchmark和Amazon Inspector之类的工具有助于发现常见的漏洞/暴露，并确保遵循最佳安全实践。

Compliance: Many companies have compliance requirements, but especially if you work in the Healthcare or Financial domain there are stricter requirements. I’m sure you are aware of some if not all of these: HIPAA, PCI, GDPR, and SOX. As mentioned above traditionally compliance teams used to do all the checks and paperwork manually. Using various tools like Chef Inspec or Hashicorp Sentinel to automate these compliance requirements helps in running it more frequently and finding the issues much faster. For example, you can run these compliance tests every time you change your IaC by provisioning an Ephemeral² environment so you find out if there are any issues with the new code before going to production.

合规性：许多公司都有合规性要求，但是特别是如果您在医疗保健或金融领域工作，则有更严格的要求。 我确信您知道其中一些(如果不是全部)：HIPAA，PCI，GDPR和SOX。 如上所述，传统上，合规团队通常手动进行所有检查和文书工作。 使用Chef Inspec或Hashicorp Sentinel等各种工具来自动化这些合规性要求有助于更频繁地运行它并更快地发现问题。 例如，您可以运行这些一致性测试每次通过配置一个临时更改IAC时间²环境，让你看看，才去生产有新代码的任何问题。

在共享环境中自动执行 (Automate Execution from a Shared Environment)

All the steps mentioned above should be brought together and IaC executed with appropriate checks in a certain sequence to provision infrastructure with confidence in various environments. For this, I’m going to talk about 2 options below.

应该将上述所有步骤放在一起，并按一定顺序通过适当的检查执行IaC，以在各种环境中充满信心地提供基础架构。 为此，我将在下面讨论2个选项。

基础架构即代码管道 (Infrastructure as Code Pipeline)

See below an example that demonstrates a typical sequence of steps in an IaC pipeline. I have used CircleCI in the example below but you can use any pipeline tool to execute this. The pipeline provides visibility to everyone who is dependent on the infrastructure that gets provisioned and notifies appropriate teams when there is a failure.

参见下面的示例，该示例演示了IaC管道中的典型步骤序列。 我在下面的示例中使用了CircleCI，但是您可以使用任何管道工具来执行此操作。 管道可以为依赖于已配置基础结构的每个人提供可见性，并在出现故障时通知适当的团队。

GitOps (GitOps)

Another way of executing IaC is by using GitOps which extends IaC and adds a workflow (Pull Request Process) to apply a change to the Production or any environment for that matter. It could also have a control loop that verifies periodically that the real state of the infrastructure is the same as the desired state. For example, it will make sure that if any changes were done directly to infrastructure it reverts to the desired state as per the source control. GitOps can be used instead of an IaC pipeline defined above. For more on GitOps, you can read the documentation on the Weaveworks website here.

执行IaC的另一种方法是使用GitOps，它扩展了IaC并添加了工作流(拉请求流程)以将更改应用于生产或任何与此相关的环境。 它还可以具有一个控制循环，该循环定期验证基础结构的实际状态与所需状态相同。 例如，它将确保，如果直接对基础结构进行了任何更改，它将根据源控件还原到所需的状态。 可以使用GitOps代替上面定义的IaC管道。 欲了解更多关于GitOps，你可以阅读Weaveworks网站上的文档在这里 。

GitOps = IaC + (Workflow + Control Loop)

GitOps = IaC +(工作流程+控制回路)

结论 (Conclusion)

Thanks for reading the article and hope that you find it useful. If you know of other IaC Principles, Patterns, or Practices that could be added to this article or have any questions let me know in the comments below or reach out to me on twitter and I will look into it.

感谢您阅读本文，希望对您有所帮助。 如果您知道可以添加到本文的其他IaC原则，模式或实践，或者有任何问题要在下面的评论中告诉我，或者在Twitter上与我联系，我将进行调查。

Acknowledgments: Matt Kuritz, Michael Wytock and Arielle Sullivan read the draft version of this article and provided feedback to improve it.

致谢： Matt Kuritz，Michael Wytock和Arielle Sullivan阅读了本文的草稿并提供了改进意见。

[1]: The Platform Engineering Team mentioned in diagram #3 is responsible for operating a platform that enables delivery teams to self-service deploy and operate systems with reduced lead time and complexity. For more on it, you can watch the talk Priyanka Rao and I gave at DevOpsdays Edinburgh here or look at the deck here.

[1]：图3中提到的平台工程团队负责操作一个平台，该平台使交付团队能够自助部署和操作系统，并减少了交付时间和复杂性。 欲了解更多关于它，你可以观看谈话普里饶我给在DevOpsdays爱丁堡这里还是看甲板这里 。

[2]: Ephemeral environment means to provision an environment on demand when needed and then destroying it afterward. It is a useful technique to test your IaC and applications running on it without a need to keep it running all the time thereby saving costs.

[2]：临时环境是指在需要时按需提供环境，然后将其销毁。 这是测试IaC及其上运行的应用程序的有用技术，而无需一直保持其运行状态，从而节省了成本。