Установка пакетов и обновление Debian-сервера на практике

На сервере Debian 12 команда apt upgrade может обновить десятки пакетов, но не решить все зависимости: часть обновлений останется отложенной, а новый пакет ядра сам по себе не переключит работающую систему на него. На примере сервера с nginx разберём, как установить пакет, оценить обновления и провести их так, чтобы не обнаружить проблему только после жалобы пользователей.

Сценарий: nginx на Debian 12 Bookworm

Рассматриваем Debian 12 Bookworm с APT ветки 2.6. Номера конкретных выпусков пакетов меняются вместе с обновлениями Debian, поэтому сверяйте их в выводе своей системы. У нас есть доступ к серверу с правами sudo, установленный nginx и возможность подключиться к консоли, если SSH или веб-служба перестанут отвечать.

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

Термин. Индекс пакетов — локальный список версий и адресов пакетов из настроенных репозиториев. Команда apt update обновляет этот список, а не установленные программы.

Три способа обновить пакеты — и чем они различаются

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

Практический порядок работ

1. Обновите индекс и посмотрите доступные версии. Выполните sudo apt update, затем apt list --upgradable. В первой команде ожидайте завершения без ошибок получения данных из репозиториев; во второй проверьте, какие пакеты предлагаются к обновлению. Если APT сообщает, что не может получить файлы или проверить подпись репозитория, не переходите к установке: сначала разберитесь с сетью, адресом репозитория или его ключом.
2. Установите nginx, если его ещё нет. Запустите sudo apt install nginx и внимательно прочитайте список изменений перед подтверждением. После установки проверьте конфигурацию командой sudo nginx -t, а состояние службы — systemctl is-active nginx. Ожидаемый результат проверки конфигурации — сообщение об успешном тесте, службы — active.
3. Оцените обычное обновление. Выполните sudo apt upgrade. До подтверждения сравните список пакетов и объём загрузки с ожидаемыми изменениями; если в списке есть незапланированные ключевые компоненты, отмените операцию и выясните причину. После завершения проверьте, не остались ли пакеты в списке apt list --upgradable.
4. Отдельно проверьте обновления, требующие смены зависимостей. Сначала запустите симуляцию: sudo apt-get -s full-upgrade. Симуляция показывает предполагаемые действия, но не меняет установленные пакеты. Если план предлагает удалить nginx, SSH-сервер, компонент хранения данных или другой критичный для работы пакет, не запускайте реальное обновление, пока не поняли причину.
5. Выполните согласованные изменения и проверьте сервис. Если план симуляции понятен и одобрен, выполните sudo apt full-upgrade. Затем повторите sudo nginx -t, проверьте systemctl status nginx и откройте сайт внешней проверкой. Ожидайте, что конфигурация проходит тест, служба работает, а приложение отвечает так, как до обновления.

В примерах apt удобен для работы в терминале и показывает подтверждения человеку. Для сценариев, где важна стабильность интерфейса команд, обычно используют apt-get; не смешивайте это с предположением, что команды имеют полностью одинаковые параметры.

Безопасное обновление — это не команда, а проверяемый план: что изменится, как вы заметите сбой и как вернётесь к рабочему состоянию.

Что может пойти не так

В списке есть пакеты, которые не обновились

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

Служба не работает после установки или обновления

Проверьте вывод systemctl status nginx и журнал службы через journalctl -u nginx. Если тест конфигурации не проходит, сравните изменённые файлы в /etc/nginx с резервной копией. Не перезаписывайте конфигурацию шаблоном из интернета: на сервере могут быть собственные виртуальные хосты, сертификаты и прокси-настройки.

Пакеты скачиваются не из того источника

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

После обновления ядра сервер продолжает работать на старом

Установка нового ядра не означает, что уже запущенная система перешла на него: для загрузки нового ядра нужна перезагрузка. Сверьте установленное ядро и текущее значение uname -r, запланируйте перезапуск и заранее убедитесь, что сервер поднимется после него. В виртуальной среде дополнительно проверьте доступ к консоли провайдера.

Что проверять после работ

Не ограничивайтесь сообщением «пакеты настроены». Для сервера с nginx проверьте, что сайт доступен снаружи, корректный домен отвечает по HTTPS, а приложение за прокси-сервером возвращает ожидаемый результат. Сравните журналы ошибок с состоянием до обновления и проверьте мониторинг: доступность, загрузку процессора и памяти, ошибки приложения.

• Сверьте список оставшихся обновлений и выясните причину каждого отложенного пакета.
• Проверьте состояние nginx и конфигурацию после обновления.
• Если обновлялось ядро, запланируйте перезагрузку и подтвердите, что сервер вернулся в сеть.
• Зафиксируйте выполненные изменения и результат проверки, чтобы следующий дежурный видел, что именно обновляли.

Что делать дальше

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