使用App Engine和云功能的基于Python的GCP项目的推荐项目结构

Question

我继承了一个使用Python作为主要语言的GCP项目。这是我第一次接触GCP，我担心就最佳实践而言，该项目的结构可能不合理。

该项目由应用引擎（标准）组成，用于公开几个供web应用使用的HTTPendpoint，以及几个“触发”云函数，这些函数被部署用于处理需要后端处理的各种情况，例如：对象上传到bucket。目前，项目代码库包含应用程序引擎代码和云功能代码。

代码结构如下：

project/
├── main.py
└── common-ftns/
    ├── __init__.py
    └── initialize-app.py
    └── utils.py
└── cloud-ftns/
    └── cloud_ftn-1.py
    └── cloud_ftn-2.py
└── services/
    └── service-1-routes.py
    └── service-1.py
    └── service-2-routes.py
    └── service-2.py

我们正在使用GCP Cloud Build部署整个解决方案，一切都很好。然而，我关心的是main的常见用法。应用程序引擎和云功能的py。GAE和Cloud函数似乎都需要根级别的main。py文件来初始化应用程序（包括Flask）以及声明云函数入口点。这让我感到困扰，因为云功能和应用引擎似乎不需要一个共同的起点，更不用说触发处理云功能不需要有烧瓶，因为它们没有使用烧瓶。

我的问题是：这种类型的结构在GCP/Python世界中被认为是“最佳实践”吗？如果没有，那么有没有更好的方法来利用main.py使得云函数和GAE不必运行完全相同的启动脚本？

Answer 1

这个项目似乎以一种理想的方式构建，可以在应用引擎应用程序和一个或多个云功能之间共享一个公共代码库，而无需管理私有子依赖项或复杂的构建步骤。

Answer 2

你可以拥有一个monorepo项目，并将其用于生产。当您执行此操作时，如果您希望部署某些部分而不是全部，则需要对CI脚本进行更多的工作，但这是可行的。这一切都取决于你的要求和你的工作方式。

所以，我的建议是为每个服务创建子目录

• 一个用于AppEngine服务

部署时，转到正确的目录并执行服务部署。app.yaml在App Engine目录中，函数不关心它。

对于这些功能，每个功能都有不同的要求。txt文件。这就是为什么把它们分成目录很重要。在这里，再次进入正确的目录，并部署该函数。

问题来自于函数和应用引擎（您的“公共”包）之间共享的公共文件。有两种方法：

• 要么构建一个包，然后将其导入到依赖项中