dpkg/apt-get обновление пакета - время простоя?
Я задавался вопросом, управляют ли apt-get/dpkg пакеты (.deb's) временем простоя вообще при обновлении?
Например, при обновлении nginx (принятие это уже установлено) через sudo apt-get install nginx, это смотрит на меня, любят нет никакого времени простоя.
Если это правда, я хочу передать эту способность к развертыванию приложения PHP через deb файлы. Я обычно делал бы развертывание Capistrano-стиля (создайте сайт, получите его на веб-сервер и подкачайте старый код с новым кодом через символьные ссылки).
Если вместо этого я устанавливаю свое созданное приложение с .deb пакетом, я должен также использовать symlinking стратегию минимизировать время простоя, или это установит/обновит пакет способом, который уже минимизирует это?
Предположите, что .deb пакет просто заменяет файлы кода и затем называет сценарий постустановки для перезагрузки шлюза приложений (php-fpm, gunicorn, единорог, phusion, независимо от того, что шлюз приложения, оказывается).
Пакеты Debian специально не "управляют" простоями. В общем случае, пакеты либо:
- Останавливают службу перед распаковкой новой версии пакета, затем запускают её снова после распаковки; либо
- Выполняют цикл остановки/запуска (или перезапуска) после распаковки новой версии пакета.
Какой из них выбирают, зависит от многих вещей, в том числе от того, как давно написаны или просмотрены сценарии сопровождающего пакета, предоставляет ли пакет другие файлы-советники, которые, если старая версия программы читает более новые файлы, то вихляют (динамически загружаемые модули, изменённые форматы файлов, и что-что-бы-вы-делали), и знает ли сопровождающий пакета, что они делают.
Всё это, однако, в значительной степени не имеет значения в вашей ситуации, потому что вы пишете сценарии сопровождающего, так как это ваш пакет, так что вы можете делать это так, как сочтёте нужным. Однако, нет никакой стратегии, которая бы включала перезапуск службы (в отличие от запуска некоторого рода изящной перезагрузки), которая не будет иметь некоторого периода времени, в течение которого служба будет недоступна. Правильным решением в этой ситуации является наличие некоторого рода избыточности, будь то две отдельные машины (которые вы обновляете по одной за раз), или две отдельные копии службы, запущенной на одной машине (которые, опять же, вы обновляете по одной за раз)
.