Rack: Bundler :: GemNotFound ошибки во время `bundle install --deployment`

Question

Итак, у меня есть несколько машин в производстве, на которых работает приложение Sinatra поверх стойки. Обычно все это hunky dory, пока Puppet - который мы используем для синхронизации изменений с нашими серверами, - отмечает, что Gemfile.lock для проекта изменился, и, как результат, необходимо выдать команду bundle install --binstubs --deployment, чтобы мы получили новые драгоценные камни. Когда это произойдет, ЛЮБЫЙ запрос HTTP вызовет ошибку 500, когда он вызовет Bundler, чтобы потребовать наши драгоценные камни, потому что новые драгоценные камни еще не установлены.

Обычно у нас есть хотя бы один процесс Rack, связанный с другим процессом, который периодически делает HTTP-запрос, чтобы обеспечить работоспособность сервера, но когда это произойдет, процессов в стойке нет. Кажется, что директива PassengerMinInstances может помочь, если проблема связана с новыми экземплярами, но у нас также есть процесс, который периодически извлекает страницу для проверки того, что сервер все еще работает, поэтому все еще должен быть хотя бы один процесс Rack для обработки запрос.

Я должен, вероятно, отметить, что куколка на самом деле не перезапускает стойку (на touch файла restart.txt) до тех пор, пока не завершится bundle install, поэтому не имеет никакого смысла, почему наши процессы в стойке исчезнут при этом время. Кто-нибудь сталкивался с чем-то подобным? Есть ли опция Rack, чтобы не перезагружать всю среду при каждом запросе, который я забыл?

Answer 1

Для потомков я отвечу на этот вопрос. В рамках развертывания все файлы были затронуты chown -R, который обновляет ctime (но не mtime) файла. Также есть интересный bug/feature в Пассажире, где они будут перезапускать сервер при изменении mtime или ctime файла /tmp/restart.txt.

Решение: прекратите каталогизировать каталог во время развертывания.

Answer 2

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

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