如何确定要创建的组件类型?

如何决定是创建模块、可部署架构，还是将可部署架构堆叠在一起？让我们比较这些差异，并评估以下部分中的用例，以帮助您做出决定。

比较可部署架构和模块

下表提供了模块和可部署体系结构类型之间的关键差异的比较和快速摘要。

概念比较
方法	作用域	耦合 (coupling)	可部署	作者
创建模块	狭义	紧	否	开发者
创建可部署的架构	从中到广	紧	是	开发者
堆栈可部署体系结构	广义	松散	是	任何人

下表可帮助您根据使用情况决定是使用模块、可部署架构，还是将可部署架构堆叠在一起。

帮助我选择要使用的组件
用途	建议的方法	注释
加速编码自动化	使用模块	模块提供可复用的组织自动化，帮助可部署架构的开发人员更快地进行编码。模块适用于开发者，而不是使用者。
确保云安全且合规	使用可部署架构	可部署的体系结构对体系结构实施安全性和合规性。如果可部署体系结构的作用域太小，那么它无法强制实施合规性。例如，仅部署虚拟服务器实例的可部署体系结构无法确保网络安全。
为用户提供具有护栏的选项	将可部署架构堆叠在一起	通过堆叠可部署架构，您可以交换可部署架构或添加可部署架构，为用户提供更多选择。由于可部署架构可强制实施安全性和合规性，因此堆栈有助于确保整体解决方案保持合规性。堆叠可部署架构是一种很好的方法，比如选择使用哪种数据库。
用户创建的解决方案或体系结构	将可部署架构堆叠在一起	通过堆叠可部署架构，用户可以创建并发布自己的可重复模式，由于这些模式是由安全、合规的可部署架构组成的，因此仍然是安全的。
解耦的体系结构组件	将可部署架构堆叠在一起	可部署架构可以独立开发和版本化，但可以堆叠在一起进行部署。
简化用户体验	使用可部署架构	可部署体系结构可以向用户提供小型或简单的输入列表，即使对于大型或复杂体系结构也是如此。可部署架构易于理解和部署。相比而言，随着可部署架构的暴露，堆叠可部署架构会更复杂一些。

IBM Cloud 项目确保通过目录中的可部署体系结构部署资源，并在组织的安全性和合规性护栏内运行。它们还确保这些资源保持最新，不会漂移。

可部署架构的依赖关系

当一个可部署架构提供的资源被另一个可部署架构需要时，就会产生依赖关系。也就是说，一个可部署架构所提供的资源可在另一个架构的部署过程中使用，如下图所示。

具有依赖关系的可部署架构的直观表示。可部署架构 A 输出资源，然后将其用作可部署架构 B 的输入。 — 可部署架构依赖性

处理依赖关系的一种方法是在项目中堆叠可部署架构并在它们之间添加引用。例如 VSI on VPC landing zone 可部署架构包括扩展 Red Hat OpenShift Container Platform on VPC landing zone 可部署架构的变体。考虑在一个项目中将这些架构堆叠在一起。如果尚未部署先决条件架构，则此方法效果很好。您也不需要编辑代码来堆叠可部署的架构。

许多可部署架构都是独立的，并不是其他架构的扩展，但你可以选择扩展一些可部署架构建筑学目录详细信息页的部分。从中选择一个选项你想怎样构建这个架构？ 菜单。

但是，如果你已经部署了Red Hat OpenShift容器平台，您需要部署 VSI，VSI 所需的资源已经配置完毕。您不需要部署Red Hat OpenShift再次是容器平台架构。由于 VSI 架构是Red Hat OpenShift容器平台，您可以部署 VSI，并且该架构使用来自Red Hat OpenShift根据需要使用容器平台。

可选和可互换的可部署架构

这是一项试验性功能，用于评估和测试目的，可能会更改，恕不另行通知。

将可部署架构加入私有目录后，可通过与其他架构堆叠来扩展该架构。通过这种方式，您可以为用户创建一个更加个性化的解决方案。

为什么要在入职培训期间进行堆叠？

入职过程中的架构堆叠与项目中的架构堆叠类似。在加入一个架构时，可以通过堆叠所需的架构来加入依赖关系。不过，与在项目中堆叠架构不同，在入职过程中堆叠架构包括以下功能：

您可以添加针对不同用例的可选架构。
您可以添加可互换的架构，供用户选择。

可选架构

也许你的架构与另一个可部署架构配合得很好，但却不需要满足依赖性或合规性要求。您可以将可部署架构添加为可选项，用户可以在将可部署架构添加到项目时选择包含该架构。例如，监控架构可能有用，但不是必需的。

可互换架构

在入职过程中，任何与自己的架构堆叠在一起的架构都可以与其他架构互换。可互换架构让用户可以在提供相同功能的多个选项中进行选择。例如，你可以包含两个可部署的架构，创建不同的数据库，用户可以决定他们想在你的架构中使用哪个数据库选项。

有关更多信息，请参阅在上架过程中扩展可部署架构。

在将可部署架构加入私有目录时，可添加可选和可交换架构。目前，在项目中堆叠可部署架构不支持可选或可交换架构。

Terraform 与 Ansible

在 IBM Cloud中，可部署体系结构必须使用 Terraform 来声明可部署体系结构 (接口) 的输入和输出，因为 Ansible 没有机器可读接口定义。否则，可部署体系结构的作者可以使用 Ansible 前或后脚本与 Terraform 的任何组合来运行可部署体系结构的工作。那么，开发人员如何决定使用哪种技术?

配置语言的比较
第一列是用于比较 Terraform 和Ansible 的类别。第二列提供有关 Terraform 如何与第一列中的集合类别相关的信息，第三列提供有关 Ansible 如何与第一列中的集合类别相关的信息。
	Terraform	Ansible
语言	声明式	程序
语法	HCL (类似于 JSON)	YAML (以及其他脚本的标注)
缺省方法	可变基础结构	不可改变的基础架构
设置焦点	基础架构	配置
漂移	与所需状态进行比较	幂等任务

Terraform 在创建和管理基础架构方面非常出色，而 Ansible 在配置在该基础架构上运行的软件和操作系统方面非常出色。由于 Ansible 是过程操作，因此您还可以对一次性操作进行脚本编制。维护任务 (例如，从备份复原) 在 Ansible中很简单。

帮助我选择要使用的配置语言
用途	建议的配置语言	注释
部署云基础架构或服务	Terraform	Terraform 以此用例为目标，更适合处理不断变化的基础架构。IBM Cloud 提供 Terraform 模块和受支持的可部署体系结构，以加速安全且合规的基础架构模式。 Terraform 状态模型允许开发者预览更改。可以扫描这些更改以获取合规性。
安装或配置软件	Ansible	如果预构建的容器或虚拟机映像不适合该用例，那么 Ansible 更适合处理软件安装和配置。 Ansible 广泛支持自动化操作，例如配置编辑，程序包管理和进程重新启动。 Ansible 模块和运行手册的大型库可用于简化数千个常用软件包的配置。
CCDB 集成	Ansible	对内部部署服务 (如 CCDB) 进行动态调用可以在 Terraform 或 Ansible 中完成，但在过程语言或脚本语言中更容易完成。
输入验证	Terraform 或 Ansible	Terraform 执行输入验证的能力有限，但它是声明式的，可供用户界面使用。 Ansible 添加了执行动态输入验证的功能，其中针对远程服务检查可部署体系结构的输入。
第 2 天维护操作	Ansible	日 2 维护通常是程序性的，最好在 Ansible中完成。示例包括手动备份，复原或密钥轮换。
漂移管理	Terraform Ansible	Terraform 可用于确定是否发生了漂移以及该漂移是什么，这可以帮助您决定如何管理漂移。漂移信息很强大，因为它可能指示您可以向自动化添加更改。 Ansible 无法检测漂移。但通过定期重新应用一个幂等的 ansible 脚本，您可以防止漂移。

有关将预脚本或后脚本包括在可部署体系结构中的更多信息，请参阅为可部署体系结构创建脚本。

后续步骤: 决定在何处发布

在规划好体系结构并决定要创建的组件类型之后，应该考虑您计划在何处共享或发布解决方案，以便其他用户可以利用您创建的解决方案。根据您计划共享或发布的位置，您可能需要完成不同级别的需求或核准。