Рекомендуемая структура проекта для проектов GCP на основе Python с использованием как App-Engine, так и облачных функций

Question

Я унаследовал проект GCP, используя Python в качестве основного языка. Это мое первое знакомство с GCP, и я обеспокоен тем, что проект не может быть должным образом структурирован в отношении передового опыта.

Проект состоит из App-Engine (стандарт) для предоставления нескольких конечных точек HTTP для использования веб-приложением, а также нескольких «триггерных» облачных функций, которые развертываются для обработки различных ситуаций, требующих внутренней обработки, например : объект загружается в корзину. В настоящее время база кода проекта содержит как код App-Engine, так и код облачных функций.

Структура кода выглядит следующим образом:

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 как для App-Engine, так и для облачных функций. Кажется, что и для GAE, и для облачных функций требуется наличие файла main.py уровня root для инициализации приложения (включая Flask), а также для объявления точек входа в облачную функцию. Это беспокоит меня, так как кажется, что облачные функции и App-Engine не должны требовать общей отправной точки, не говоря уже о том, что облачные функции для обработки триггеров не должны иметь Flask, поскольку они не используют его.

Мой вопрос таков: считается ли этот тип структуры "наилучшей практикой" в мире GCP / Python? Если нет, то есть ли лучший способ использовать main.py, чтобы облачным функциям и GAE не приходилось запускать один и тот же сценарий запуска?

Answer 1

Вы можете создать монорепроект и использовать его в производстве. Когда вы делаете это, и если вы хотите развернуть некоторые части, а не все одновременно, это требует больше работы над сценарием CI, но он работает. Все зависит от ваших требований и вашего способа работы.

Итак, я рекомендую создать подкаталог для каждой службы

• Один для службы AppEngine
• Один для функции службы, а в ней - каталог для каждой функции
• Нет основного на root, только ваш сценарий CI / CD и другой сценарий bash (terraform или другой) для развертывания

При развертывании введите go в правильный каталог и выполните развертывание службы. App.yaml находится в каталоге App Engine, функции не заботятся об этом.

Для функций каждая из них может иметь отдельный файл requirements.txt. Вот почему важно разделить их на каталоги. Здесь снова go в правильном каталоге и разверните функцию.

Проблема возникает из-за общих файлов, которые делятся между функциями и App Engine, вашим «общим» пакетом. Для этого есть 2 способа:

• Либо вы создаете пакет и импортируете его в свои зависимости
• , либо копируете общий каталог в правильный каталог перед развертыванием. -> Я выполняю это большую часть времени . Это легко выполнить в Java (с maven), который требует больше сценариев в Python.

Answer 2

Этот проект выглядит идеально структурированным для совместного использования общей базы кода между приложением App Engine и одной или несколькими облачными функциями, без дополнительных затрат на управление частными подчиненными зависимостями или сложные этапы сборки.