Как именно работает процесс развертывания Heroku?

Question

Что произойдет, когда я разверну новую версию своего сервиса в Heroku?

Предположим, у меня сейчас N веб-динос онлайн, из них M в настоящее время обслуживают запросы.

• Все ли они закрыты до того, как новая версия начнет выходить в сеть? Что происходит с любыми отложенными запросами, которые в настоящее время обслуживаются?
• Есть ли время простоя? (предположим, у меня просто служба без сохранения состояния без каких-либо миграций)
• Есть ли ловушка для выполнения пользовательских миграций (например, перенос таблиц базы данных)?
• Могу ли я вызвать N серверов с новой версией, заставить их начать обслуживание запросов и отключить предыдущие N серверов только после того, как они не обслуживают какие-либо запросы?
• Зависит ли ответ от стека / языка? (Аспен / Бамбук / Кедр, Рубин / Node.js / Java /...)

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

Answer 1

Вот что происходит во время развертывания Heroku (по состоянию на 20.10.2011 *) [1]:

• Героку получает твой толчок мерзавца
• Новая версия компилируется из последней версии вашего приложения и сохраняется
• [Это происходит примерно одновременно]
  • Сетка dyno сигнализирует о прекращении [2] всех запущенных процессов для вашего приложения
  • Сетка dyno сигнализирует о запуске новых процессов для вашего приложения
  • Сетка dyno сигнализирует об отмене всех бездействующих процессов вашего приложения
  • Маршрутизатор HTTP получает сигнал о начале маршрутизации HTTP-трафика к веб-динамиям, работающим с новым выпуском

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

Следуя осторожным методам миграции, можно нажать новый код, а затем выполнить миграцию во время работы приложения. Вот пример для Rails: http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/

Чтобы минимизировать потерянные соединения во время перезапуска, используйте веб-сервер, который соответствующим образом реагирует на SIGTERM, начиная постепенное завершение работы (завершите существующие соединения, не устанавливайте новые). Более новые версии thin будут правильно обрабатывать SIGTERM.

1. Эта тема является предметом большого обсуждения внутри страны и может изменить в будущем.
2. SIGTERM и 10 секунд спустя SIGKILL, если все еще работает

Answer 2

Я могу ответить "Есть ли ловушка для выполнения пользовательских миграций (например, миграция таблиц базы данных)?"часть этого вопроса.Я выполнил миграцию, написав сценарий оболочки, который выполняет «heroku rake db: migrate» сразу после того, как я выпустил «git push heroku».Я не знаю, есть ли более «зацепка» - у вас есть способ сделать это.