Моя проблема в том, что я хочу создавать среды dev, stage, prod, используя различные проекты GCP.

В основном они запускают один и тот же код, просто запускают их в разных изолированных средах.

Я использую gcloud app deploy в командной строке для развертывания приложения прямо сейчас.

Как я могу эффективно развернуть приложение в другом проекте?
Нужно ли мне делать gcloud init каждый раз, чтобы менять конфигурацию проекта по умолчанию?
Должны быть некоторые лучшие практики.

Или есть лучший способ настроить среды dev ... в контексте движка приложения?

Спасибо.

4
Lucas Shen 8 Сен 2016 в 18:46

4 ответа

Лучший ответ

Для приложений Python вы можете установить приложение в файле app.yaml. Это позволяет использовать разные данные для каждого проекта. Это когда вы развертываете с помощью команды appcfg.py.

application: myproject
version: alpha-001
runtime: python27
api_version: 1
threadsafe: true

handlers:
- url: /
  script: home.app

Если вы не хотите изменять значение приложения в этом файле для каждого проекта, вы можете запустить следующее:

appcfg.py -A <YOUR_PROJECT_ID> -V v1 update myapp/

https://cloud.google.com/appengine/docs/python/config/appref

Если вы не укажете приложение в файле, используйте параметр --application в команде appcfg при развертывании. Этот элемент игнорируется при развертывании с помощью команды развертывания приложения gcloud.

1
Jeff Deskins 9 Сен 2016 в 01:37

Вместо того чтобы использовать gcloud init для изменения конфигурации каждый раз, используйте этот код для более быстрого развертывания в нескольких проектах:

gcloud app deploy -q --project [YOUR_PROJECT_ID]

Если у ваших проектов похожие идентификаторы, скажем: test1, test2, test3, test4, вы можете развернуть их в четырех проектах с помощью одной команды. Используйте этот код:

for i in {1..4}; do gcloud app deploy -q --project test${i}; done
4
Ibrahim 26 Авг 2017 в 03:55

«Стандартный» подход заключается в использовании версий, например

qa.myApp.appspot.com

Как только версия будет готова к следующему шагу, вы развертываете ее с другим идентификатором версии.

Одна из проблем с использованием нескольких проектов заключается в том, что вам нужно поддерживать разные наборы данных для каждого проекта.

2
Andrei Volgin 8 Сен 2016 в 17:56

Я предпочитаю, чтобы различные среды управлялись с помощью того же управления версиями, что и код - по одной ветке для каждой среды, поддерживая идеальное соответствие развертываний естественному потоку изменений кода, продвигаемых посредством слияния ветвей: dev -> { {X1}} -> production.

Чтобы свести к минимуму риск человеческой ошибки, я стараюсь как можно больше сохранять конфигурации развертывания в самом коде (т. Е. Чтобы идентификаторы, версии и т. Д. Приложений были взяты из файлов .yaml, а не передавались в развертывание cmd как аргументы). Сами команды развертывания хранятся в файле шпаргалки (слишком простой, чтобы гарантировать полноценный сценарий в настоящее время), также контролируемый git. Проиллюстрировано в этом ответе: https://stackoverflow.com/a/34111170/4495081

Развертывания выполняются из отдельных выделенных рабочих областей - по одной для каждой среды на основе соответствующей ветки git (я никогда не переключаю ветки в этих рабочих областях). Я просто обновляю рабочую область, соответствующую желаемой среде, до необходимой версии, и копирую и вставляю команду развертывания из шпаргалки рабочей области.

Эта модель IMHO CI / CD-ready и может быть легко полностью автоматизирована.

2
Community 23 Май 2017 в 12:17