Горячее развертывание на Heroku без простоя

Плохая сторона нажатия на Heroku заключается в том, что я должен нажать код (и сервер перезагрузится автоматически) перед запуском миграции db.

Это может вызвать около 500 ошибок для пользователей, которые перемещаются по веб-сайту с новым кодом без новых таблиц/атрибутов: решение, предлагаемое Heroku, должно использовать режим обслуживания, но я хочу, чтобы без поддержки, каждый раз!

Есть ли способ? Например, с Capistrano:

  • Я готовлю код для развертывания в новом каталоге
  • Я запускаю (назад) миграции, и старый код продолжает работать отлично
  • Я перебираю экземпляр mongrel в новый каталог и перезагружаю сервер

... и у меня нет простоев!

ОТВЕТЫ

Ответ 1

Вы можете настроить второе приложение Heroku, которое указывает на тот же БД, что и ваше основное производственное приложение, и использовать вторичное приложение для запуска миграции базы данных без прерывания производства (при условии, что миграция не нарушит предыдущую версию вашего приложения).

Позвоните в приложения Heroku ПРОДУКЦИЯ и STAGING.

Ваша последовательность развертывания станет примерно такой:

  • Разверните новый код STAGING
    git push heroku staging
  • Запуск миграции баз данных на STAGING (для обновления PROD db)
    heroku run -a staging-app rake db:migrate
  • Разверните новый код ПРОДУКЦИЯ
    git push heroku production

Проджект-приложение не будет стоить вам ничего, поскольку вам не нужно будет превышать свободный уровень Heroku, и было бы довольно тривиально настроить развертывание rake script, чтобы сделать это для вас автоматически.

Удачи!

Ответ 2

Если вы одновременно можете жить с двумя версиями одного и того же приложения, у Heroku теперь есть функция предварительной загрузки.

https://devcenter.heroku.com/articles/preboot

Ответ 3

Единственный способ улучшить этот процесс - это то, что предлагает этот парень. Это все еще не горячий вариант развертывания:

http://casperfabricius.com/site/2009/09/20/manage-and-rollback-heroku-deployments-capistrano-style/

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

Ответ 4

У вас действительно будет время простоя, когда Heroku перезапустит ваше приложение. У них есть новая функция Preboot, которая запускает новые динамики, прежде чем вынимать старые: https://devcenter.heroku.com/articles/labs-preboot/

Что касается миграции данных, эта статья ссылается на этот вопрос о том, как справиться с этой проблемой: http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/

Ответ 5

Сначала я переношу миграции, запускаю их, а затем нажимаю остальную часть кода. Добавьте один файл следующим образом:

git commit -m 'added migration' -- db/migrate/2012-your-migration.rb

Ответ 6

Heroku не может развертывать capistrano. Вы блокируете инструмент, выпущенный heroku.

Система простоя невозможна во всех случаях. Как изменить схему с большими изменениями, не останавливая ваш сервер. Если вы не остановите его, вы можете избежать некоторых изменений, и ваша база данных может быть непоследовательной. SO использование страницы обслуживания является нормальным решением.

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