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

Правильно настроив сервер разработки и производственный сервер, я хотел бы настроить среду разработки Google App Engine для тестирования новых разработанных версий в прямом эфире до их развертывания.

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

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

version: app-staging

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

  • Простая версия и производственная версия используют один и тот же хранилище данных
  • Простая версия и производственная версия имеют одни и те же журналы

Что касается первого момента, я не знаю, может ли он быть "исправлен" с использованием нового пространства имен python API.суб >

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

application: foonamestaging

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

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

Ответы

Ответ 1

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

Но, как я вижу это сейчас, вариант A является более чистым решением. Вы можете с помощью пары строк кода переключать пространство имен хранилища данных на основе версии, которую вы можете получить динамически из переменной среды CURRENT_VERSION_ID, как описано здесь: http://code.google.com/appengine/docs/python/runtime.html#The_Environment

Ответ 2

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

  • Вы можете сохранить версию для реальной версии производственных приложений.
  • Вы можете сохранить функцию версий для разделения трафика.
  • Вы можете сохранить функцию namespaces для многопользовательской аренды.
  • Вы можете легко копировать объекты из одного приложения в другое. Это не так просто между пространствами имен.
  • Несколько API по-прежнему не поддерживают пространства имен.
  • Для команд с несколькими разработчиками вы можете предоставить загрузку для разрешения на производство для одного человека.

Ответ 3

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

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

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

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

Ответ 4

Мы используем опцию B.

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

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

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

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

Ответ 5

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