Рекомендуемый сине-зеленый шаблон развертывания GCP?

Question

Мы разрабатываем / поддерживаем мобильное приложение для клиента, который использует React-Native для взаимодействия с серверной частью GCP. База данных - это Firestore, объектное хранилище использует GCP Storage, мы используем движок приложения GCP для нескольких вызовов REST и серию облачных функций для обработки некоторой обработки Firestore и GCP Storage.

Развертывание нашего продукта состоит из доставки файлы сборки мобильного приложения для клиента (они распространяют приложение внутри на своих серверах), а для бэкэнда мы используем GCP CloudBuild для развертывания нашего движка приложения и облачных функций из нашей ветки master / prod. Однако за последние шесть месяцев у нас была серия грубых развертываний продуктов, которые в основном сводились к неожиданным проблемам с конфигурацией среды, когда мы не сталкивались с dev или qa envs (или забыли о них), а также с несколькими проблемами обновления базы данных ( изменения модели). Это оставляет нас с яйцом на лице с клиентом, поскольку развертывание может быть отложено на несколько часов, поскольку мы исправляем проблемы.

Чтобы попытаться решить эту проблему, мы рассматривали сине-зеленый стратегия развертывания для серверной части GCP. Это будет состоять из создания нового проекта GCP, развертывания в нем последней ветки master / prod и предоставления нам возможности полностью протестировать перед отправкой обновленного мобильного приложения клиенту - никаких сюрпризов. В теории это звучит великолепно, но на практике все не так просто. Основная проблема - это база данных Firestore и хранилище GCP - нам также потребуется перенести объекты хранилища и базу данных Firestore в новый проект. Выполнимо, но еще одна сложность.

Итак, наша сине-зеленая идея такова:

1. Мы создаем новый проект «Firestore / GCP storage», единственной целью которого было бы действовать как место хранения данных "prod" (без движка приложения или облачных функций в этом проекте) и выступать в качестве поставщика аутентификации. Этот проект будет иметь статус c и не будет обновляться между развертываниями prod
2. . Мы создаем новый проект «prod» (зеленый) GCP, в котором будут размещены новейшие функции App-Engine и Cloud для «зеленого» развертывания. Этому проекту будут предоставлены разрешения на доступ к данным проекта «Firestore / GCP storage» и объектам хранилища.
3. Мобильное приложение будет подключаться к проекту «data-storage» для связи с Firestore и загрузки файлов и подключится с новым «зеленым» проектом для вызовов REST App-Engine

Мы надеемся, что этот шаблон позволит нам выполнять сине-зеленое развертывание логики c на бэкэнде, не беспокоясь о данных / передача объекта. У меня такой вопрос: Кто-нибудь когда-нибудь использовал этот тип шаблона развертывания в GCP? Это рекомендуемый шаблон или даже нежелательный анти-шаблон?

Любые отзывы приветствуются. Спасибо

Answer 1

Я согласен с тем, что перед запуском необходимо протестировать что-то важное, например мобильный бэкэнд.

Доступ к API виртуальных машин с помощью gcloud или перенос трафика c в соответствии с утверждением нового обновления, это то, что знакомо с Cloud Build с использованием предоставленных сборщиков.

https://cloud.google.com/cloud-build/docs/cloud-builders#supported_builder_images_provided_by

Cloud Build позволяет развертывать в соответствии с концептуальным этапом или этапом, который вы можете определить заранее (например, сине-зеленая стратегия). Во время определения вы должны помнить о типе развертываемого приложения; в этом случае вы упомянули экземпляр Firestore, и общее предложение состоит в том, чтобы выполнить репликацию в другом экземпляре, чтобы все было организовано.

https://cloud.google.com/appengine/docs/flexible/nodejs/migrating-traffic

С другой стороны, у вас может быть кластер kubernetes, который позволит вам управлять этими функциями более естественным образом, поэтому, возможно, вам придется оценить рабочую нагрузку вашего приложения и попробовать облачную сборку за пределами шаблонов.

Я надеюсь, что это точка зрения был полезен для вас.