я есть постановочный и производственный проект на App Engine, с 6 сервисами на каждом.

На данный момент мы развертываем с компьютера разработчиков, используяgcloud app deploy app.staging.yaml --project staging-project

или жеgcloud app deploy app.production.yaml --project production-project

Это работает, но вызывает проблемы с переменными среды, особенно с секретами.

Наши приложения получают ключи Api, учетные данные базы данных и другие данные из переменных среды, что позволяет нам запускать одно и то же приложение локально, в контейнере Docker или в App Engine, не зная, где оно развернуто.

Если я буду следовать документации для развертывания, наши файлы app.yaml будут выглядеть так:

app.production.yaml

runtime: nodejs
env: flex

manual_scaling:
  instances: 1
env_variables:
  DATABASE_PASSWORD: "topsecret"
  MY_API_KEY: "ultrasecret"

Я думаю, что все легко понимают, почему плохая идея хранить это в репозитории Git.

На данный момент у нас есть этот теневой файл, который каждый разработчик должен заполнить перед развертыванием

app.production.yaml.shadow

runtime: nodejs
env: flex

manual_scaling:
  instances: 1
env_variables:
  DATABASE_PASSWORD: "set me"
  MY_API_KEY: "set me"

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

Я обнаружил 3 обходных пути, и причина их неиспользования:

использованиеGoogle KMS - позволяет нам помещать зашифрованные секреты непосредственно в проект, но требует, чтобы мы добавили специальный код в наши приложения для их расшифровки. Это создает другую среду управления между местным, промежуточным и производственным. Это увеличивает риск ошибок из-за сложности.Храните секреты в Google Datastore - Я попробовал это, я создал помощник, который ищет env vars в proccess.ENV, затем в кеше и в конечном итоге в хранилище данных. Но, как и KMS, это значительно увеличивает сложность.Храните секреты вФайл JSON и положить в облачное хранилище Google : опять же, требуется загрузить переменные env через помощника, который проверяет env vars, затем загружает файл и т.д ...

В конечном счете, мы изучаем возможность использованиясервер развертывания, это может быть вызвано разработчиками или Continuous Integration и обрабатывать все секреты внедрения при развертывании в App Engine. Но такие инструменты, каканзибль, Salt, Puppet, Chef имеют только плагины для Compute Engine и не поддерживают App Engine.

+-------------------------+    +-------------------+   +---------------------+
|                         |    |                   +--->                     |
| Developer workspace     |    |    Ansible        |   | App Engine STAGING  |
|                         +---->   (or other)      |   |                     |
+-------------------------+    |                   |   +---------------------+
                               |                   |
+-------------------------+    |                   |   +---------------------+
|                         +---->   Injects secrets |   |                     |
| Continous Integration        |                   |   | App Engine PROD.    |
|                         |    |                   +--->                     |
+-------------------------+    +-------------------+   +---------------------+

Это приводит меня к 3 вопросам:

Как вы думаете, использование сервера развертывания с App Engine - это хорошая идея?Как я могу убедиться, что производственные и промежуточные секреты поддерживают синхронизацию, чтобы развертывания от разработчиков всегда были правильными?Есть ли способ использовать классические переменные среды для секретов в App Engine?