本部分介绍可用于部署蓝图、蓝图的命名规则以及蓝图建议的替代方案的流程。
综合应用
如需实现本文档中所述的架构,请完成本部分中的步骤。
在新组织中部署蓝图
如需在新的 Google Cloud 组织中部署蓝图,请完成以下操作:
使用企业基础蓝图创建基础设施。请完成以下操作:
- 创建组织结构,包括用于分离环境的文件夹。
- 配置基本 IAM 权限以向开发者平台管理员授予访问权限。
- 创建 VPC 网络。
- 部署基础设施流水线。
如果您不使用企业基础蓝图,请参阅不使用企业基础蓝图部署蓝图。
开发者平台管理员使用基础设施流水线创建多租户基础设施流水线、应用工厂和舰队范围流水线。
开发者平台管理员使用多租户基础设施流水线部署 GKE 集群和共享基础设施。
应用运维人员使用应用工厂对新应用进行初始配置。运维人员在应用工厂代码库中添加一个或多个条目,以触发应用专用资源的创建。
应用开发者在其应用专用基础设施中使用应用 CI/CD 流水线,将应用部署到多租户基础设施。
不使用企业基础蓝图部署蓝图
如果您不在企业基础蓝图上部署企业应用蓝图,请完成以下步骤:
- 创建以下资源:
- 包含
development
、nonproduction
和production
文件夹的组织层次结构 - 每个文件夹中的共享 VPC 网络
- 可提供 GKE 集群需要的 IP 地址范围的 IP 地址方案
- GKE 集群的 DNS 机制
- 符合您的安全状况的防火墙政策
- 通过专用 IP 地址访问 Google Cloud API 的机制
- 与您的本地环境连接的机制
- 用于安全和审核用途的中心化日志
- 用于监控威胁的 Security Command Center
- 符合您的安全状况的组织政策
- 可用于部署应用工厂、多租户基础设施流水线和舰队范围流水线的流水线
- 包含
- 部署资源后,继续执行在新组织中部署蓝图中的第 2 步。
将蓝图整合到现有 GKE 部署中
此蓝图要求您先部署开发者平台,然后再将应用部署到开发者平台。下表介绍了当您已有在 Google Cloud 上运行的容器化应用时可如何使用蓝图。
现有使用情况 | 迁移策略 |
---|---|
已有 CI/CD 流水线。 | 即使应用构建和部署使用不同的产品,您也可以使用蓝图的舰队和集群架构。我们建议您至少将映像镜像到两个区域。 |
现有组织结构与企业基础蓝图不匹配。 | 建议至少有两个环境,以实现更安全的顺序部署。您不一定要在不同的共享 VPC 或文件夹中部署环境。但是,请勿将属于不同环境的工作负载部署到同一集群中。 |
不使用 IaC。 |
如果您当前的应用部署过程不使用 IaC,则可以使用 Terraform on Google Cloud 成熟度模型来评估就绪情况。导入现有资源到另一个 Terraform 项目(其组织方式与此蓝图类似),并将多租户流水线和每租户流水线分隔开来。如需创建新集群,您可以使用适用于 Google Cloud 的 Terraform 模块。 |
集群分布在同一环境的多个项目中。 |
您可以将多个项目中的集群分组到一个舰队中。验证您的命名空间在同一舰队内具有唯一含义。在将集群添加到舰队之前,请让团队将其应用移至具有唯一名称(例如,不是 然后,您可以将命名空间分组到范围内。 |
所有集群位于单一区域中。 |
您无需在生产环境和非生产环境中使用多个区域也可采用此蓝图。 |
存在不同的环境组。 |
您可以修改蓝图,以支持多于或少于三个环境。 |
集群创建工作委托给应用开发或应用运维团队。 |
为了获得最安全、最一致的开发者平台,您可以尝试将集群的所有权从应用团队转移到开发者平台团队。如果无法这样做,您仍然可以采用许多蓝图做法。例如,您可以将不同应用团队拥有的集群添加到舰队。但是,在将集群与独立所有权相结合时,请勿使用 Workload Identity 或 Cloud Service Mesh,因为它们无法充分控制谁可以声明哪些工作负载身份。请使用自定义组织政策来阻止团队在 GKE 集群上启用这些功能。 将集群分组到舰队后,您仍可以审核和强制执行政策。您可以使用自定义组织政策要求集群在与集群项目所在环境文件夹相对应的舰队中创建。您可以使用舰队默认配置来要求新集群使用政策控制。 |
默认建议的替代方案
本部分介绍本指南中包含的默认建议的替代方案。
决策区域 | 可能的替代方案 |
---|---|
所有应用都在相同的一组五个集群中运行。 |
蓝图使用一组五个集群(两个在生产环境中,两个在非生产环境中,一个在开发环境中)。您可以修改蓝图,以创建更多这样的五集群组。 将应用分配到各个五集群组。请勿将应用的范围或舰队命名空间绑定到其他组的集群。建议您将应用隔离到不同的集群组中,以完成以下活动:
避免为每个应用或租户创建新的集群组,因为这种做法可能会导致以下情况之一:
|
生产环境和非生产环境中的集群分布在两个区域。 |
如需缩短多个区域中的最终用户的延迟时间,您可以将生产和非生产工作负载部署到两个以上的区域(例如,生产环境三个区域,非生产环境三个区域,开发环境一个区域)。此部署策略会增加在其他区域中维护资源的费用和开销。 |
如果所有应用都具有较低的可用性要求,您可以将生产和非生产工作负载仅部署到一个区域(一个生产环境、一个非生产环境和一个开发环境)。此策略有助于降低费用,但无法确保提供与双区域或多区域架构相同的可用性级别。 |
|
如果应用具有不同的可用性要求,您可以为不同的应用创建不同的集群组(例如, |
|
中心辐射型拓扑比共享 VPC 更符合您的要求。 |
您可以在中心辐射型配置中部署蓝图,其中每个环境(开发、生产和非生产)都托管在各自的 spoke 中。中心辐射型拓扑可以增强环境的隔离。如需了解详情,请参阅中心辐射型网络拓扑。 |
每个应用都有一个单独的 Git 代码库。 |
某些组织对所有源代码使用单个 Git 代码库 (monorepo) 而不是多个代码库。如果您使用 monorepo,则可以修改蓝图的应用工厂组件来支持您的代码库。请完成以下操作:
|
后续步骤
- 详细了解企业基础蓝图。
- 查看以下内容,详细了解 Google Cloud 上的软件交付:
- 查看以下内容,详细了解如何在 GKE 上运行应用: