, Это позволит вам делиться ими между вашими проектами и определять, кто может получить к ним доступ в вашей команде.
я есть постановочный и производственный проект на 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?