IBM Cloud Docs
规划使用工作空间

规划使用工作空间

根据提示使用以下问题来规划和设计工作空间:

  • 如何将工作空间与 Git 存储库关联?
  • 我的应用程序环境需要多少个工作空间?
  • 如何在不同环境和工作区之间重复使用Terraform配置文件?
  • 如何控制访问权限并管理我的工作区?

工作空间和 Git 存储库

工作空间使用来自专用或公共 Git 存储库 (例如 GitHubGitLabBitbucket 和 Azure DevOps) 的 Terraform 模板。 此表提供存储库源的格式。

Git 存储库
Git 存储库 URL
GitHub https://github.com/<your_user_name>/<repo_name>/tree/<branch_name>/<folder_name>
GitLab https://gitlab.com/<your_user_name>/<project_name>/tree/<branch_name>/<folder_name>
Bitbucket https://bitbucket.org/<your_user_name>/<repo_name>/src/<branch_name>/<folder_name>
https://<username>@bitbucket.org/<workspace_name>/tf_cloudless_sleepy/src/master
Azure DevOps https://azure.com/<your_user_name>/<repo_name>/src/<branch_name>/<folder_name>
https://visualstudio.com/<your_user_name>/<repo_name>/src/<branch_name>/<folder_name>

我的应用程序环境需要多少个工作空间?

IBM Cloud Schematics 中需要的工作空间数由应用程序的结构以及开发,测试和发布应用程序或微服务所需的环境确定。

根据经验,请考虑为每个微服务和您使用的环境分配单独的工作区。 例如,如果您有一个由搜索、支付和评论微服务组件组成的产品应用程序,请考虑为每个微服务组件及其开发、测试和生产环境创建单独的工作区。 每个组件和环境都有独立的工作区,您可以开发、部署和更新Terraform配置文件和相关云资源,而不会影响其他组件。

查看下图,观察由三个微服务组成的应用程序的工作空间结构 IBM Cloud Schematics。

工作区结构用于IBM Cloud Schematics
工作区结构,用于IBM Cloud Schematics

在基础架构职责分散在多个团队的组织中,建议不要使用一个工作空间来管理整个登台或生产环境。 当您使用单一工作区部署所有云资源时,各个团队可能难以协调更新并管理对这些资源的访问。 使用远程状态数据源共享基础架构定义的独立工作空间提供了一种机制来创建单独的职责范围。

我该如何构建 Git 存储库来映射我的工作空间?

整理您的 Git 存储库,以便为构建微服务的所有Terraform配置文件创建一个存储库,并在 Schematics、GitHub 分支或目录中使用输入变量来区分开发、暂存和生产环境。

查看下表,了解如何构建您的 Git 存储库,以映射不同的工作区环境。

Git 存储库的结构
选项 描述
一个 Git 仓库,使用变量区分环境 创建一个 Git 存储库,用于存储构成微服务组件的Terraform配置文件。 尽可能使 Terraform 配置文件通用,以便可以在不同环境中复用相同的配置。 要配置开发、编译打包和生产环境的具体信息,请在配置文件中使用 Terraform 输入变量。 在创建工作空间时,输入变量会自动装入到 IBM Cloud Schematics。 要定制工作空间,请输入变量的特定于环境的值。 如果您有一个团队负责管理微服务组件的生命周期,并且您的不同环境中的配置差异并不大,那么此设置非常有用。
一个 Git 仓库,使用分支来区分环境 为您的微服务组件创建一个 Git 存储库,并使用不同的 Git 分支来存储每个环境的 Terraform 配置文件。 使用此设置时,可以明确区分不同环境,并对谁可以访问和更改特定配置有更多控制权。 请务必设置好如何在分支中填充一个配置文件的更改,以避免在每个环境中都有不同的配置。
一个 Git 仓库,使用目录区分环境 对于首选短期分支,并且其不同环境中的配置差异很大的组织,请考虑创建表示环境不同配置的目录。 使用此设置时,所有目录都将侦听提交到 master 分支的更改。 请务必设置好一个配置文件中的更改如何在目录间填充,以避免每个环境中的配置不同。
每个环境使用一个 Git 仓库 请在每个环境中使用一个 Git 存储库。 通过这种设置,您的工作区和 Git 存储库之间建立了1:1的关系,您可以为每个 Git 存储库设置单独的权限。 确保您的团队能够管理多个 Git 存储库并使其保持同步。

如何在不同环境和工作空间中复用配置文件?

通过创建标准化的Terraform模板,并使用变量根据需要自定义模板的使用,尽量减少需要管理的Terraform配置文件的数量。

现在,您可以从 IBM Cloud的 Terraform 模块注册表中使用 Terraform 模块。

使用标准化的Terraform模板或Terraform模块,您可以确保组织内遵循最佳开发实践,并确保所有Terraform配置文件具有相同的结构。 通过了解 Terraform 配置文件的结构,开发者可以更轻松地理解文件,声明变量,添加代码以及对错误进行故障诊断。

如何控制对工作空间的访问?

IBM Cloud Schematics 与 IBM Cloud® Identity and Access Management完全集成。 要控制对工作空间的访问,以及谁可以使用 IBM Cloud Schematics 来执行基础架构代码,请参阅管理用户访问权

当我具有先前与 Terraform 单机一起使用的存储库时,需要注意什么?

由于 IBM Cloud Schematics 提供Terraform即服务,您可以使用工作区重复使用现有的Terraform模板。 根据 Terraform 模板的编写方式以及 Git 存储库的结构化方式,您可能需要进行更改以成功使用 IBM Cloud Schematics。

  • 提供者块声明:由于 IBM Cloud Schematics 与 IBM Cloud® Identity and Access Management 集成,您的 IBM Cloud API密钥会自动为所有启用IAM的资源检索,您无需在 provider 块中提供此信息。 但是,对于传统基础设施资源,无法获取API密钥。 有关更多信息,请参阅配置 provider
  • Terraform 命令行和 IBM Cloud 提供程序插件: 要使用 IBM Cloud Schematics,您无需安装 Terraform 命令行或 IBM Cloud Provider Plug-in for Terraform。 如果您想自动配置资源,请尝试使用 IBM Cloud Schematics 命令行插件

为工作空间设置持续交付工具链

每当您更新 Terraform 配置文件时,请将源存储库连接到 IBM Cloud 中的持续交付管道,以自动生成 Terraform 执行计划并在 IBM Cloud 中运行 Terraform 代码。

  1. 如果您的帐户中还没有 Continuous Delivery 服务实例,请创建一个服务实例。
    1. 在 IBM Cloud 目录中,打开 Continuous Delivery 服务
    2. 选择要在其中创建服务的 IBM Cloud 区域。
    3. 选择定价套餐。
    4. 输入服务实例的名称,选择资源组,然后输入要与服务实例关联的任何标记。
    5. 单击创建以在帐户中创建服务实例。
  2. 工作空间仪表板中,选择工作空间。
  3. 选择设置选项卡。
  4. 在“摘要”部分中,单击 启用持续交付
  5. 配置工具链。
    1. 输入工具链的名称,然后选择要在其中部署此工具链的区域和资源组。 区域和资源组可以与用于 Schematics 工作空间的区域和资源组不同。
    2. 选择存储 Terraform 配置文件的源存储库的类型。 例如 GitHub。
    3. 查看源存储库的信息。 例如,如果您的 Terraform 文件存储在 GitHub, 请查看 GitHub 服务器和要创建持续交付工具链的版本库。 这些字段是根据工作空间配置预先填充的。
    4. 可选: 选择是否要对工具链启用 Git 问题和代码更改跟踪。
  6. 选择 Delivery Pipeline 图标以配置 Delivery Pipeline。
    1. 验证向您显示的工作空间标识是否正确。
    2. 输入 IBM Cloud API密钥。 如果您没有 API 密钥,请单击 新建 + 以创建 API 密钥。
  7. 单击 创建 以完成工具链的设置。 您将看到为工具链配置的工具的概述。
  8. 打开 Delivery Pipeline。 Delivery Pipeline 包含用于从源存储库检索更新,创建 Terraform 执行计划,应用此计划以及对工作空间运行状况检查的阶段。
  9. 更新源存储库中的 Terraform 文件,并查看如何在 Delivery Pipeline中处理此更改。 如果其中一个阶段失败,请单击 查看日志和历史记录 以开始对错误进行故障诊断。 有关查看日志和历史记录的更多信息,请参阅 查看 Schematics 作业详细信息