在Google Cloud Platform中如何组织项目结构

131次阅读

问题描述

作为一名刚刚接手前任 DevOps 主管职责的人，你需要管理一个从 Heroku 和 AWS 迁移到 GCP 的转型过程。你想了解在 GCP 中组织项目的最佳实践是什么。
你是否应该按照生产、预发布和 QA 环境进行组织？还是应该按照每个独立的前端项目或中间件项目进行组织？如果是这样，数据库应该放在哪个功能中？中间件项目？
你可以看到许多核心问题会引发相关问题… 是否有关于如何在企业中组织他们的 GCP 项目的最佳实践呢？
附加问题：项目组织如何影响成本或互联网络？

解决方案

请注意以下操作注意版本差异及修改前做好备份。

基于环境的项目拆分

从 Google App Engine (GAE) 的角度来看，我的偏好是基于环境进行项目拆分。这可能会对你有所帮助：在 GAE 项目/应用级别与服务/模块级别实现 CI/CD 环境的优势。

我不会选择基于架构的项目拆分，除非有充分的理由这样做（如果你觉得你有这样的理由，你应该提供详细信息）：
– 很可能难以（如果不是不可能的话）避免项目间的带宽费用。
– 在项目之间的互操作性上增加了配置复杂性（除了可能共享的 IAM 权限外，GCP 几乎认为它们是完全隔离/独立的）。可能会涉及：Google App Engine 访问跨项目资源。

根据使用的 GCP 产品，可能已经有足够的支持在同一个项目内部进行架构拆分。至少 GAE 在我看来是这样的。

我的 GAE 应用都是独立的，根本不使用项目间的互联网络，因此从这个角度来看，没有成本问题。访问各种 GCP 提供的基础设施/服务仍然会产生网络（带宽）费用，但从项目拆分的角度来看，这些费用是不相关/不可避免的。

使用 Google Cloud 组织结构

Google 的推荐最佳实践是在 GCP 中创建一个组织，以便获得文件夹的访问权限，然后在 GCP 中模拟组织的层次结构：

在Google Cloud Platform中如何组织项目结构

一些指导方针/规则：
1. 只应该有一个代表整个组织的组织；否则配置目录同步将非常繁琐。
2. 文件夹应该代表业务单位。
3. 项目应该代表应用程序或组件的实例。
4. 由于每个环境通常是应用程序或组件的实例，所以应该为每个环境使用不同的项目。
5. 对每个文件夹或项目的名称进行全面限定，因为 GCP 通常不会显示项目的完整路径。考虑上图中故意有两个名为 mgmt-prod 的应用程序。然而，因为它们被称为 amido-ops-pmo-mgmt-prod 和 amido-people-mgmt-prod，从项目名称就很容易看出它们的用途。

这种模型的重要优势在于，你可以创建一个名为 TechOps 的组，并在组织级别为其赋予审计或只读权限。这些人将能够访问整个资源。同样，在文件夹和项目级别基于业务需求也可以授予细粒度的权限。

嗨 Richard，你建议只有 1 个组织，但是为不同环境分别创建不同的组织是否有好处？我能想到的唯一原因是从安全的角度来看，如果一个帐户被入侵，他们只能获得对单个环境的访问权限，而不是可能随时跨多个环境具有权限的单个帐户。 2. 你可以通过分层文件夹模型实现责任隔离，很可能总会有一些帐户可以访问所有环境，但是你的目标应该是那些组织管理帐户从不在操作层面使用。拥有多个组织是可能的，尽管你将不得不注册和管理一个单独的 Google Cloud Identity 目录，这可能会在单一登录方面给你带来一些麻烦。我个人认为，多个组织是过度复杂的。
— 用户评论