作用域

为可部署体系结构定义一个明确的范围至关重要，因为它应该足够全面，包含所有必需的资源，但要足够集中，以避免不必要的复杂性。

最佳实践是包含通常作为一个单元一起部署的基础架构资源，这些资源需要类似的访问权和许可权，并且具有相同的生命周期。 例如，让我们考虑 VPC landing zone 可部署体系结构。 此可部署体系结构具有明确定义的作用域，该作用域包含以下基础结构资源:

这些资源通常作为一个单元一起部署，需要类似的网络管理权限和许可权，并且具有相同的生命周期，这意味着它们:

• 一起创建，例如，当为新 VPC 供应其关联的子网，公共网关和安全组时。
• 一起更新，例如，对 VPC 的网络配置进行更改时，需要对子网，公共网关和安全组进行更新。
• 一起删除，例如，当 VPC 已停用并且除去其所有关联资源 (包括子网，公共网关和安全组) 时。

可组合性

可部署体系结构的一个基本原则是可组合性，这使您能够通过组合多个可部署体系结构来创建更广泛的 可部署体系结构堆栈。 这种模块化方法使自动化资源具有最大的灵活性和可重用性。

要实现可组合性，应设计可部署的体系结构以:

• 最大化通过输出值显示的信息量，但使输出类型保持简单。 此实践使可部署的体系结构自动化能够在广泛的场景中复用，并使其成为各种自动化解决方案的通用构建块。

• 允许对现有已部署资源 (例如，资源组，IBM® Key Protect for IBM Cloud® 或 Hyper Protect Crypto Services 实例以及 IBM Cloud Secrets Manager 实例等) 的可选引用。 然后，用户可以配置现有实例或部署到现有资源组中，从而提高自动化的通用性。 Secrets Manager 可部署体系结构 是此操作原则的伟大示例。 通过允许用户复用现有 Secrets Manager 实例，资源组和 KMS 加密密钥，此自动化提供了高度的灵活性和适应性。 例如，您可以：

  • 通过传递标识来配置现有 Secrets Manager 实例，并在现有实例中创建私钥组。
  • 与现有密钥管理系统 (例如 Key Protect 或 Hyper Protect Crypto Services) 集成。
  • 在现有资源组中部署或创建具有可定制命名约定的新资源组。

或者，此可部署体系结构还允许从头开始创建新的 Secrets Manager 实例，新的资源组和其他资源，从而提供独立解决方案。

通过采用可组合性，可部署体系结构可以轻松集成到更复杂的解决方案体系结构 (例如，可部署体系结构堆栈) 中。 例如，Retrieval Augmented Generation Pattern 演示了如何组合多个可部署体系结构 (包括 Secrets Manager 可部署体系结构) 以构建复杂解决方案。 设计时考虑到可组合性的可部署体系结构为这些更复杂的解决方案提供了基础。

在可部署体系结构堆栈中，每个成员可部署体系结构都保持其独立配置状态，从而允许单个部署，更新或取消部署。 这种模块化方法使成本，合规性，支持和质量保证能够从包含的可部署架构中衍生出来，而每个堆栈都保持独特的版本，具有自己的描述和参考架构。

易用性

设计可部署的体系结构时应牢记可使用性，使用户易于理解和部署。 为此，可部署体系结构应提供包含以下内容的综合文档:

先决条件

部署所需的软件依赖关系和基础架构需求。

详细的输入变量和输出值描述

包括用途，数据类型和缺省值。

必需的最低许可权

运行可部署体系结构自动化所需的许可权。

图和体系结构图

可部署体系结构的组件和关系的可视表示。

简化配置

易于部署和管理。

所需资源减少

优化可部署架构，最大程度降低硬件和资源需求，如更低的 CPU 和内存需求，使其更经济高效。

简化部署

更快，更轻松地入门。

确保可部署体系结构易于使用的另一个方面是提供多个变体，包括快速启动变体。 应提供可部署体系结构的快速启动版本，这更便宜且运行速度更快。 例如，Red Hat OpenShift Container Platform on VPC landing zone 的 QuickStart 变体 可部署体系结构在单个区域中创建完全可定制的虚拟私有云 (VPC) 环境，在安全 VPC 中为工作负载提供单个 Red Hat OpenShift 集群。 这种快速启动变体专为演示和开发目的而设计，每月运行成本低于 400 美元。

相反，Red Hat OpenShift Container Platform on VPC landing zone 可部署体系结构的标准版本基于 IBM Cloud Framework for Financial Services 参考体系结构，在虚拟私有云 (VPC) 网络上创建安全且合规的 Red Hat OpenShift Container Platform 工作负载集群，但每月运行成本超过 4,000 美元。 并且，它包括管理 VPC 服务，工作负载 VPC 服务，管理 VPC 和工作负载 VPC 的隔离以及高级网络安全架构决策等高级功能。

代码质量

利用 linting 和 code 格式。 实施一致的编码样式和格式设置，使代码易于阅读和维护。 检测代码中的错误和警告，以防止在部署期间发生问题。 请考虑超越 Terraform 代码，而是整合与可部署体系结构中所有资源相关的任何工具，例如 Bash 脚本，Python 脚本，YAML 和 JSON 文件以及 Golang。

示例：

• terraform_fmt，用于格式化 Terraform 代码。
• go-fmt 以格式化 Go 代码。
• black 以格式化 Python 代码。
• isort，用于对 Python 导入进行排序。
• flake8，用于检查 Python 代码中是否存在错误和警告。
• shellcheck，用于检查 shell 脚本是否存在错误和警告。
• golangci-lint，用于检查 Go 代码以查找错误和警告。

配置验证

使用静态验证来检查可部署体系结构的语法和配置，以确保其正确且一致。 验证可部署体系结构的配置以防止部署期间发生错误。 同样，请考虑超越 Terraform 代码，并整合与可部署体系结构中所有资源相关的任何工具，例如 Bash 脚本，Python 脚本，YAML 和 JSON 文件以及 Golang。

示例：

• terraform_validate 以验证 Terraform 配置。
• checkov，用于检查 Terraform 代码中是否存在安全性和合规性问题。
• tflint，用于检查错误和警告。
• detect-secrets 以检测代码中的私钥。
• hadolint，用于检查 Docker 文件中是否存在错误和警告。
• helmlint，用于检查 Helm Chart 以查找错误和警告。

测试

在测试基础架构代码时，对于应用程序代码而言，您可能认为没有纯粹的单元测试。 相反，测试策略涉及将基础结构部署到实际环境，验证其是否有效，然后取消部署该基础结构。

持续集成

为确保可部署体系结构的可靠性，一致性和可维护性，建议采用左移方法，在开发周期早期集成质量检查和测试。 此方法有助于及早捕获错误和缺陷，降低发生下游问题的可能性并提高整体质量。

作为此方法的一部分，建议执行以下质量检查:

客户机端质量控制

客户机端 Git 落实挂钩 应用于在落实代码之前在开发者机器上运行检查。 这包括检查编码标准，语法错误和敏感数据。 可以使用 pre-commit 之类的工具来自动执行此过程。

CI 实践

应遵循持续集成 (CI) 的最佳实践。 任何软件工程产品的一般实践都适用于可部署体系结构开发，包括:

• 处理重点突出的小型拉取请求 (PR)，以促进及时复审并减少合并冲突。
• 定期将代码更改集成到主分支中，以防止长时间存在的功能分支并降低合并复杂性。
• 实施自动化测试和代码复审，确保代码质量和一致性。
• 持续验证可部署体系结构的配置和语法，以确保正确性和一致性。

CI 管道

应设置 CI 管道以自动执行这些实践，确保可部署体系结构中的每个代码更改都经过系统测试和验证。 此管道确保可部署体系结构正确且一致地工作，并确保及早捕获任何错误或缺陷。