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

Question

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

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

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

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

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

Answer 1

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

Давайте назовем приложения Heroku ПРОИЗВОДСТВО и STAGING .

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

1. Развертывание нового кода в STAGING
   git push heroku staging
2. Запуск миграций базы данных на STAGING (для обновления базы данных PROD)
   heroku run -a staging-app rake db:migrate
3. Развертывание нового кода для ПРОИЗВОДСТВО
   git push heroku production

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

Удачи!

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

Сейчас я не вижу возможности сделать это без простоев. Я тоже ненавижу это.

Эта консольная команда делает это за наименьшее время, которое я могу придумать

git push heroku master && 
heroku maintenance:on && 
sleep 5 && 
heroku run rails db:migrate && 
sleep 3 && 
heroku ps:restart && 
heroku maintenance:off

1. git push heroku master подтолкнуть мастер ветку к героку
2. heroku maintenance:on для обслуживания, поэтому нет 500 с
3. sleep 5, чтобы позволить dynos запускать новый код (без него миграция может завершиться ошибкой)
4. heroku run rails db:migrate для фактической миграции
5. heroku ps:restart из опыта перезапуска убедитесь, что новые динамометры имеют последнюю схему
6. heroku maintenance:off очереди технического обслуживания

Возможно, вам придется добавить -a <app name> после всех команд heroku, если у вас несколько приложений.

Всего одна команда запускает их последовательно в терминале на Mac OSX.

Answer 7

Героку не может развернуть капистрано. Вы заблокированы инструментом, выпущенным герою.

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

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