Как настроить промежуточную среду в Google App Engine

Question

После правильной настройки сервера Development и сервера Production я хотел бы настроить среду Staging в Google App Engine, полезную для тестирования новых разработок версии живут до развертывания их в производство.

Я знаю два разных подхода:

A. Первый вариант - изменение параметра app.yaml версия .

version: app-staging

Что мне не нравится в этом подходе, так это то, что производственные данные загрязнены моими промежуточными тестами, потому что (поправьте меня, если я ошибаюсь):

1. Промежуточная версия и производственная версия находятся в одном хранилище данных
2. В промежуточной версии и рабочей версии одни и те же журналы

_{Что касается первого пункта, я не знаю, можно ли его «исправить» с помощью нового Python API пространства имен .}

B. Второй вариант заключается в изменении app.yaml application параметр

application: foonamestaging

при таком подходе я бы создал второе приложение, полностью независимое от производственной версии.
Единственный недостаток, который я вижу, это то, что я вынужден настроить второе приложение (администраторы настроены).
С таким инструментом резервного копирования \ восстановления, как Gaebar , это решение также работает хорошо.

Какой подход вы используете для настройки промежуточной среды для вашего веб-приложения?
Кроме того, есть ли у вас какой-либо автоматический скрипт для изменения yaml перед развертыванием?

Answer 1

Если требуется отдельное хранилище данных, вариант B выглядит для меня более чистым решением , потому что:

1. Вы можете сохранить функцию версий для реальных версий производственных приложений.* Вы можете сохранить функцию версий для разделения трафика.
2. Вы можете сохранить функцию пространств имен для многопользовательского режима.
3. Вы можете легко копировать объекты из одного приложения в другое.Между пространствами имен это не так просто.
4. Немногие API по-прежнему не поддерживают пространства имен.
5. Для групп с несколькими разработчиками вы можете предоставить разрешение на загрузку в производство одному человеку.1017 *

Answer 2

Я выбрал второй вариант в моей настройке, потому что это было самое быстрое решение, и я еще не создал ни одного сценария для изменения параметра приложения при развертывании.Теперь вариант А является более чистым решением.Вы можете с помощью нескольких строк кода переключить пространство имен хранилища данных на основе версии, которую вы можете динамически получить из переменной среды CURRENT_VERSION_ID, как описано здесь:

Answer 3

Мы выбрали вариант B. И я думаю, что в целом лучше, так как он полностью изолирует проекты.Так, например, игра с некоторыми конфигурациями на промежуточном сервере не повлияет на безопасность и не поставит под угрозу безопасность, а также не вызовет никакого другого эффекта «бабочки» в производственной среде.

Что касается сценария развертывания, вы можете иметь любое имя приложения.Вы хотите в своем app.yaml.Некоторые фиктивные / dev-имена и при развертывании просто используйте параметр -A:

appcfg.py -A your-app-name update .

Это значительно упростит ваш сценарий развертывания, не нужно заменять строки или что-то подобное в вашем app.yaml

Answer 4

Мы используем вариант Б.

В дополнение к предложениям Zygmantas о преимуществах отделения dev от prod на уровне приложения мы также используем наше приложение dev для тестирования производительности.

Обычно экземпляр dev работает без особых ресурсов, это помогает увидеть, где приложение чувствует себя медленно. Затем мы можем также независимо настроить параметры производительности, чтобы увидеть, что имеет значение (например, класс экземпляра внешнего интерфейса).

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

Все еще используйте пространства имен и версии, просто dev грязный и экспериментальный.

Answer 5

Я предпочитаю вариант A, и я пытаюсь настроить простой скрипт сборки для автоматизации обработки