Terraform 等 IaaS 配置工具的用处？
Usefulness of IaaS Provisoning tools like Terraform?
对于“基础架构即代码”或使用 Terraform 等工具进行 IaaS 配置的整个概念，我很快就感到困惑。
我最近在一个使用 Terraform 预置其所有 AWS 资源的团队工作，我一直在学习它并承认它是一个非常漂亮的工具。
除了基础设施即代码是在 AWS 控制台中手动配置资源的“酷”替代方案之外，我不明白为什么它实际上有用。
以典型的数据库部署为例。在我初始配置此基础架构之后，为什么我什至需要再次 运行 Terraform 计划？在我的 AWS 账户上配置了我需要的所有内容后，我需要“重新配置”此基础设施的用例是什么？
在这种假设下，配置我需要的一切的过程从一开始就被预先加载了，所以当我第一次部署我的网站时只需单击 AWS 控制台中的一些按钮，我为什么还要费心学习工具呢？
老实说，我认为这是一个很常见的混淆点，但我似乎无法在其他地方找到清晰的地方，所以我想在这里问一下。可能是一个幼稚的问题，但请记住，我对这整个哲学都是陌生的。
提前致谢！
从长远来看，手动配置速度慢、不可重现、麻烦、无法自我记录且难以在团队中进行。
使用 Terraform 或 CloudFormation 等工具，您可以获得以下好处：
应用您在编写传统代码时所拥有的所有相同开发原则。您可以使用注释来记录您的基础架构。您可以使用 软件版本控制 系统（例如 git）跟踪所有更改以及谁进行了这些更改。
您可以轻松共享您的基础架构。您的 VPC 和 ALB 不起作用？只需 post 您的 terraform 代码即可，或与同事分享以供审查。手动完成后，分享您的 VPC 和 ALB 的屏幕截图要容易得多。
易于规划灾难恢复和全局应用程序。您只需在不同区域自动部署相同的基础架构。在许多地区手动执行相同操作会很困难。
开发、生产和暂存基础设施的分离。您只需在不同环境中重复使用相同的基础架构代码。对开发基础架构的更改可以轻松移植到产品中。
在实际执行之前检查更改。由于多米诺骨牌效应，手动升级您的基础设施可能会产生灾难性的影响。更改一个，可以 change/break 架构的许多其他组件。使用基础架构即代码，您可以预览更改并在实际进行更改之前很好地了解可能产生的影响。
工作团队。您可以让很多人处理相同的基础架构代码、提出更改、测试和审查。
我非常喜欢@Marcin 的回答。
根据我的经验补充几点：
至于软件版本控制案例，您不仅可以看到history/authors，进行代码审查，还将基础设施变更视为产品功能。比方说，您正在为您的应用程序添加 CDN 支持，因此您必须对您的基础设施（以提供云 CDN 服务）、应用程序（以实际支持和使用 CDN）和您的管道（以交付静态到CDN，如果您使用这种方法）。如果与此新功能相关的所有更改都在一个分支中 - 所有与功能相关的更改都将对团队中的每个人都是透明的，以后可以轻松追踪。
与版本控制相关的另一件事 - 能够使用触发器和您CI/CD 用于自动和手动测试的工具。甚至可以 运行 自动测试您在基础设施声明中的更改。
如果您从事多个相似的项目，或者如果您的项目需要多个相似但相互隔离的环境, IaC 可以帮助节省无数小时的配置和跟踪一切。虽然它并不总是灵丹妙药，但在几乎所有情况下，它都有助于节省时间并避免大多数意外错误。
最后但同样重要的是 - 如果您使用 混合 或 [=22]，它有助于 看到更大的 图片=]多云 环境。不如基础架构图好，但与您的代码不同，图表可能并不总是最新的。
对于“基础架构即代码”或使用 Terraform 等工具进行 IaaS 配置的整个概念，我很快就感到困惑。
我最近在一个使用 Terraform 预置其所有 AWS 资源的团队工作，我一直在学习它并承认它是一个非常漂亮的工具。
除了基础设施即代码是在 AWS 控制台中手动配置资源的“酷”替代方案之外，我不明白为什么它实际上有用。
以典型的数据库部署为例。在我初始配置此基础架构之后，为什么我什至需要再次 运行 Terraform 计划？在我的 AWS 账户上配置了我需要的所有内容后，我需要“重新配置”此基础设施的用例是什么？
在这种假设下，配置我需要的一切的过程从一开始就被预先加载了，所以当我第一次部署我的网站时只需单击 AWS 控制台中的一些按钮，我为什么还要费心学习工具呢？
老实说，我认为这是一个很常见的混淆点，但我似乎无法在其他地方找到清晰的地方，所以我想在这里问一下。可能是一个幼稚的问题，但请记住，我对这整个哲学都是陌生的。
提前致谢！
从长远来看，手动配置速度慢、不可重现、麻烦、无法自我记录且难以在团队中进行。
使用 Terraform 或 CloudFormation 等工具，您可以获得以下好处：
应用您在编写传统代码时所拥有的所有相同开发原则。您可以使用注释来记录您的基础架构。您可以使用 软件版本控制 系统（例如 git）跟踪所有更改以及谁进行了这些更改。
您可以轻松共享您的基础架构。您的 VPC 和 ALB 不起作用？只需 post 您的 terraform 代码即可，或与同事分享以供审查。手动完成后，分享您的 VPC 和 ALB 的屏幕截图要容易得多。
易于规划灾难恢复和全局应用程序。您只需在不同区域自动部署相同的基础架构。在许多地区手动执行相同操作会很困难。
开发、生产和暂存基础设施的分离。您只需在不同环境中重复使用相同的基础架构代码。对开发基础架构的更改可以轻松移植到产品中。
在实际执行之前检查更改。由于多米诺骨牌效应，手动升级您的基础设施可能会产生灾难性的影响。更改一个，可以 change/break 架构的许多其他组件。使用基础架构即代码，您可以预览更改并在实际进行更改之前很好地了解可能产生的影响。
工作团队。您可以让很多人处理相同的基础架构代码、提出更改、测试和审查。
我非常喜欢@Marcin 的回答。
根据我的经验补充几点：
至于软件版本控制案例，您不仅可以看到history/authors，进行代码审查，还将基础设施变更视为产品功能。比方说，您正在为您的应用程序添加 CDN 支持，因此您必须对您的基础设施（以提供云 CDN 服务）、应用程序（以实际支持和使用 CDN）和您的管道（以交付静态到CDN，如果您使用这种方法）。如果与此新功能相关的所有更改都在一个分支中 - 所有与功能相关的更改都将对团队中的每个人都是透明的，以后可以轻松追踪。
与版本控制相关的另一件事 - 能够使用触发器和您CI/CD 用于自动和手动测试的工具。甚至可以 运行 自动测试您在基础设施声明中的更改。
如果您从事多个相似的项目，或者如果您的项目需要多个相似但相互隔离的环境, IaC 可以帮助节省无数小时的配置和跟踪一切。虽然它并不总是灵丹妙药，但在几乎所有情况下，它都有助于节省时间并避免大多数意外错误。
最后但同样重要的是 - 如果您使用 混合 或 [=22]，它有助于 看到更大的 图片=]多云 环境。不如基础架构图好，但与您的代码不同，图表可能并不总是最新的。