Нулевое время простоя на Heroku

Question

Можно ли сделать что-то вроде развертывания Github с нулевым временем простоя на Heroku с использованием Unicorn в стеке Cedar?

Я не совсем уверен, как перезапуск работает на Heroku и как мы контролируем процессы перезапуска, но мне нравится возможность развертывания без простоев и до сих пор, начиная с , что я прочитал, это невозможно

Есть несколько вещей, которые потребуются для того, чтобы это работало.

1. Прежде всего, нам понадобятся обратно совместимые миграции.Я оставляю это на усмотрение нашей команды.
2. Во-вторых, мы бы хотели перенести базу данных сразу после пуша, но до перезапуска (при условии, что наши миграции полностью обратно совместимы, это ни на что не должно повлиять)
3. В-третьих, мы бы хотели дать Unicorn команду запустить новый мастер-процесс и подключить несколько рабочих, затем поменять местами PID и корректно завершить работу старого процесса / рабочих

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

Answer 1

Я не могу обратиться к миграции, но часть о перезапуске процессов и избежании времени ожидания:

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

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

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

http://ylan.segal -family.com / blog / 2012/08/27 / время развертывания до нуля / почти нулевое время простоя /

Answer 2

Возможно, вас заинтересует их функция, называемая preboot .

Взято из их документации:

Эта функция обеспечивает плавное развертывание путем загрузки веб-динамометров с новымикод перед уничтожением существующих веб-dynos.

Некоторым приложениям требуется много времени для загрузки, и это может привести к недопустимым задержкам в обслуживании запросов HTTP во время развертывания.

Есть несколько предостережений:

• Для использования этой функции у вас должно быть как минимум два веб-динамометра.Если ваш тип веб-процесса масштабируется до 1 или 0, предварительная загрузка будет отключена.
• Любому, кто выполняет развертывание, придется подождать несколько минут, прежде чем новый код начнет обслуживать пользовательские запросы;это происходит позже, чем без предварительной загрузки (но в то же время пользовательские запросы по-прежнему своевременно обрабатываются старыми динамо).
• Будет короткий период (минута или две), когда heroku ps показывает состояниеновый код, но запросы пользователей по-прежнему обслуживаются старым кодом.

Информации об этом гораздо больше, поэтому обратитесь к их документации .

Answer 3

Нет - в настоящее время это невозможно при использовании Unicorn на кедре Heroku. Я не давал покоя Героку по этому поводу уже несколько недель.

Вот ответ службы поддержки Heroku на мое письмо от 8 марта 2012 года:

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

Мы определенно осознаем, что это проблема, и мы работаем над тем, чтобы предложить развертывание с нулевым временем простоя в будущем. У нас нет ETA, чтобы объявить, хотя.

Answer 4

Возможно, но требует значительного объема заблаговременного планирования. Начиная с Rails 3.1, есть три задачи, которые нужно выполнить

• Загрузить новый код
• Запуск любых миграций базы данных
• Синхронизация активов

Загрузка кода и перезапуск довольно просты, основная проблема заключается в двух других, но обход их почти одинаков.

По сути, вам нужно:

• Сделать код совместимым с миграцией, необходимой для запуска
• Запустите миграцию и удалите любой код, написанный специально для нее

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

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

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

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