Назад | Перейти на главную страницу

dpkg / apt-get обновление пакета - время простоя?

Мне было интересно, управляют ли пакеты apt-get / dpkg (.deb) временем простоя при обновлении?

Например, при обновлении nginx (при условии, что он уже установлен) через sudo apt-get install nginx, мне кажется, что простоя нет.

Если это правда, я хочу передать эту возможность развертыванию приложения PHP через файлы deb. Обычно я выполняю развертывание в стиле Capistrano (создаю сайт, загружаю его на веб-сервер и заменяю старый код новым кодом через символические ссылки).

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

Предположим, что пакет .deb просто заменяет файлы кода, а затем вызывает сценарий после установки для перезагрузки шлюза приложений (php-fpm, gunicorn, unicorn, phusion, каким бы ни был шлюз приложения).

Пакеты Debian специально не «управляют» временем простоя. Как правило, пакеты:

  • Остановите службу перед распаковкой новой версии пакета, затем снова запустите ее после распаковки; или
  • Запуск цикла остановки / запуска (или перезапуска) после распаковки новой версии пакета.

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

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