Обновление Ubuntu на сервере

Цель статьи и варианты задач

Цель: безопасно выполнить дистрибутивное обновление Ubuntu на сервере с помощью команды do-release-upgrade. Варианты задач: обновление удалённого сервера по SSH, автоматизация в скрипте/Ansible, откат при проблемах.

Предварительные требования

Доступ к серверу с правами root или возможность выполнить sudo su.
Рабочая сеть и достаточное место на диске для загрузки обновлений.
Резервная копия конфигураций и данных (снимок LVM/ZFS, образ диска, резервная копия баз данных).
Желательно тестовая среда для проверки обновления до продакшена.

1 Подготовка и установка инструментов

Сначала станьте root:

sudo su

Обновите индекс пакетов:

aptitude update

Установите пакет update-manager-core, если он не установлен:

aptitude install update-manager-core

Откройте файл /etc/update-manager/release-upgrades и убедитесь, что там указано Prompt=normal. Для редактирования можно использовать vi или любой другой редактор:

vi /etc/update-manager/release-upgrades

В файле должно быть:

[...]
Prompt=normal

Примечание: значение Prompt=normal позволяет обновляться на обычные релизы. Для LTS-to-LTS используйте Prompt=lts.

2 Запуск обновления

Запустите дистрибутивное обновление:

do-release-upgrade

Пример вывода при запуске (системные сообщения):

root@server1:~# do-release-upgrade  
Checking for a new ubuntu release  
Done Upgrade tool signature  
Done Upgrade tool  
Done downloading  
extracting 'maverick.tar.gz'  
authenticate 'maverick.tar.gz' against 'maverick.tar.gz.gpg'  
tar: Removing leading `/' from member names

Дальнейшие стадии показывают проверку кэша и пакетного менеджера:

Reading cache

Checking package manager

3 Работа по SSH — предупреждение и решение

При запуске обновления по SSH вы увидите предупреждение вида:

Continue running under SSH?

Текст предупреждения:

This session appears to be running under ssh. It is not recommended
to perform a upgrade over ssh currently because in case of failure it
is harder to recover.

Если вы продолжите, дополнительный SSH-демон будет запущен на порту 1022, чтобы дать доступ в случае проблем. В большинстве случаев продолжение безопасно, если вы предварительно сделали резервную копию и имеете консольный доступ (или доступ через облачную консоль).

При запросе:

Do you want to continue?

Ответьте y для продолжения.

Важно: если вы обновляете критичный продакшен по SSH, запустите в одной из сессий screen или tmux и/или убедитесь, что есть out-of-band доступ (IPMI, консоль провайдера, облачная консоль). Альтернативно используйте тестовую машину.

4 Разрешения и подтверждения во время обновления

В процессе вы будете подтверждать ряд пунктов. Пример интерактивного диалога:

Подтвердите начало обновления:
“Do you want to start the upgrade?”
В выводе показывается, какие пакеты будут удалены, установлены и обновлены, а также сколько будет скачано. При согласии введите y.
Когда менеджер обновлений спросит о перезапуске сервисов, обычно безопасно принять значения по умолчанию. Нажмите ENTER, чтобы принять список.
При вопросе об установке GRUB вы можете выбрать Continue without installing GRUB (продолжить без установки GRUB). Я рекомендую ответить Yes, чтобы сохранить текущую рабочую конфигурацию загрузчика. Установка нового GRUB может потребовать выбора диска и привести к неудачному загрузочному сценарию при ошибке.

Пример запроса о конфигурационном файле:

Configuration file `/etc/update-manager/release-upgrades'  
==> Modified (by you or by a script) since installation.  
==> Package distributor has shipped an updated version.  
What would you like to do about it ?  Your options are:  
Y or I  : install the package maintainer's version  
N or O  : keep your currently-installed version  
D     : show the differences between the versions  
Z     : start a shell to examine the situation  
The default action is to keep your current version.  
*** release-upgrades (Y/I/N/O/D/Z) [default=N] ?

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

5 Очистка и перезагрузка

После завершения обновления система предложит удалить устаревшие пакеты:

Remove obsolete packages?

Подтвердите удаление, если вы хотите освободить место и не нуждаетесь в старых пакетах.

Завершение обновления требует перезагрузки:

Restart required

Подтвердите перезагрузку: Continue [yN] введите y. После перезагрузки система будет работать на новой версии Ubuntu.

6 Практические рекомендации и чеклист перед обновлением

Сделайте полную резервную копию данных и конфигураций.
Проверяйте доступное пространство /var и /tmp.
Остановите критичные нагрузочные сервисы (если возможно) перед обновлением.
Выполните обновление в окно обслуживания.
Используйте screen/tmux и обеспечьте консольный доступ.
Протестируйте обновление в стенде.

Короткий чеклист для администратора

Резервная копия базы данных и важных файлов
Снимок диска / снапшот тома
Доступ к консоли провайдера (IPMI, облачная консоль)
Установлен update-manager-core
Файл /etc/update-manager/release-upgrades проверен
Выполнен aptitude update

7 Альтернативные подходы

Использовать чистую установку новой версии и мигрировать сервисы (минимизирует риски, но требует времени).
Использовать apt-get dist-upgrade для постепенного обновления — не рекомендуется для смены версии дистрибутива; do-release-upgrade выполняет дополнительные шаги и изменения метаданных.
Автоматизировать через Ansible/MAAS/Cloud-init для массовых серверов.

8 Возможные проблемы и сценарии отката

Проблема: система не загружается после обновления.
Митигирование: загрузитесь с живого образа, смонтируйте корень, проверьте /boot и конфигурации GRUB, восстановите снимок.
Проблема: критичный сервис не стартует (например, веб или БД).
Митигирование: посмотреть логи (systemctl status, journalctl), откатить конфигурацию из резервной копии, запустить контейнер с предыдущей версией сервиса.

Руководство по откату (микропроцесс)

Если есть snapshot LVM/ZFS/VM — восстановите snapshot.
Если нет snapshot, восстановите из резервной копии конфигураций и данных.
Проверяйте логи и зависимости, откатывайте поочередно сервисы.

9 Риск-матрица и рекомендации

Низкий риск: обновление тестового стенда. Митигирование: обычная резервная копия.
Средний риск: продакшен с возможностью рестарта. Митигирование: окно обслуживания, снимок диска.
Высокий риск: продакшен без доступа к консоли. Митигирование: обеспечить out-of-band доступ или использовать миграцию на новую хост-машину.

10 Критерии приёмки

Сервер успешно загружен в новую версию Ubuntu.
Все критичные сервисы находятся в состоянии active/running.
Нет ошибок в журнале при старте сервисов в течение N часов наблюдения.
Сети и внешние интеграции работают корректно.

11 Быстрые советы по безопасности

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

12 Decision flowchart

Используйте этот простой алгоритм для принятия решения об обновлении:

flowchart TD
  A[Готовы резервные копии?] -->|Да| B[Есть доступ к консоли?]
  A -->|Нет| X[Сделать резервную копию]
  B -->|Да| C[Запуск do-release-upgrade]
  B -->|Нет| Y[Организовать консольный доступ или миграцию]
  C --> D{Ошибки во время обновления?}
  D -->|Нет| E[Перезагрузка и проверка сервисов]
  D -->|Да| F[Использовать snapshot/восстановление]

13 Справочные ссылки

Ubuntu: http://www.ubuntu.com/

Краткое резюме

do-release-upgrade — предпочитаемый инструмент для перехода между релизами Ubuntu.
Обязательно делайте резервные копии и обеспечьте консольный доступ при обновлении по SSH.
Тестируйте обновления на стенде и имейте план отката.

Обновление сервера Ubuntu через do-release-upgrade