Обычно безопасно запускать «apt-get upgrade» (с точки зрения стабильности) на рабочем сервере?

Я часто захожу на свой сервер Ubuntu 12.04.2 (с Postgres 9.2.4, работающим с производственными данными) и вижу что-то похожее на:

4 packages can be updated.
4 updates are security updates.

Конечно, это происходит примерно каждые несколько дней. Меня не интересуют автоматические обновления (чем меньше у меня изменений, когда я сплю, тем лучше), но меня интересует постоянное обновление моего сервера, поэтому мой вопрос: когда я вижу вывод, такой как это всегда считается безопасным для запуска apt-get upgrade, или есть моменты, когда это может сломать вещи. Я понимаю, что патчи не всегда идеальны (отсюда и цитата «всегда» в заголовке), но, как правило, предполагается, что это безопасно выполнять (особенно если учесть, что это сервер баз данных, а не что-то, что просто обслуживает CSS-файлы через Nginx). )?

Как правило, да, это безопасно. Однако для критически важных пакетов (Postgres, Nginx и т. Д.) Я бы рекомендовал прикрепить эти пакеты к определенной версии, чтобы они не обновлялись. Например, когда Postgres обновляется, он перезапускает сервер базы данных, что вы хотите запланировать в связи с запланированным временем простоя.

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

Склонность имеет легче запомнить команды: aptitude safe-upgradevs. aptitude full-upgrade. Это все еще хорошая идея для установки, apt-listchangesтак что вам будет предоставлена ​​информация об изменениях в обновленных пакетах и ​​возможность отменить обновление.

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

Я видел примеры, когда приложения, использующие Java с 1.6.29 по 1.6.30, ломают приложение. Также замечен разрыв mysql между 5.0.X 5.0.X + 1 (точные цифры здесь не помню).

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

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