Как выбрать и проверить образ Ubuntu для VPS

Проверьте требования до создания VM

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

Сузьте выбор по сроку сопровождения и наличию нужного образа в регионе. Ubuntu 24.04 — конкретный пример: выпуск представил Python 3.12 по умолчанию, PHP 8.3 и PostgreSQL 16. Версии исправлений меняются при обновлениях; совместимость со старой основной версией не гарантирует поддержку новой.

Сроки смотрите в таблице Ubuntu LTS. Если дистрибутив ещё не выбран, начните с сравнения требований к Linux VPS.

Подтвердите выпуск и архитектуру

Внутри VPS выполните команды чтения состояния. Сохраните результаты до установки дополнительных пакетов.

cat /etc/os-release
uname -r
dpkg --print-architecture
uname -m

Прокрутите таблицу, чтобы увидеть остальные столбцы →

У провайдера может быть специальное облачное ядро. Его строка версии сама по себе не определяет выпуск Ubuntu или покрытие поддержки. Не считайте бинарный файл только для amd64 нативно совместимым с arm64.

Проверьте подготовку образа

cloud-init часто создаёт пользователей, устанавливает ключи и настраивает сеть. Сначала выясните, есть ли он в образе. Отсутствие не обязательно ошибка: провайдер может использовать другой механизм.

if command -v cloud-init >/dev/null 2>&1; then
    cloud-init status --long
else
    printf '%s\n' 'cloud-init не установлен; проверьте способ подготовки образа у провайдера.'
fi

running означает, что подготовка ещё идёт. error или degraded требует разбора, даже если SSH уже доступен. При установленном cloud-init просмотрите соответствующие журналы.

sudo tail -n 50 /var/log/cloud-init.log
sudo tail -n 50 /var/log/cloud-init-output.log

Скрипты инициализации могут выводить секреты. Удалите чувствительные данные перед передачей журналов. Не запускайте cloud-init clean и не заменяйте сетевые файлы ради скрытия ошибки. Завершённая подготовка ещё не доказывает исправность приложения, базы или копирования.

Посмотрите доступные версии пакетов

Обновите индекс и проверьте кандидатов для нужных компонентов. Эта команда обновления индекса не устанавливает перечисленные приложения.

sudo apt update
apt-cache policy python3 php postgresql
apt-cache policy python3.12 php8.3 postgresql-16

Installed: (none) означает, что пакет не установлен. Candidate: (none) — что текущие источники не предлагают подходящего кандидата. Сначала проверьте имя, архитектуру и компоненты Ubuntu, а не добавляйте случайный репозиторий.

Метапакеты php и postgresql выбирают реализацию по умолчанию. Посмотрите и версионированный пакет. Для установленного ПО проверьте фактический исполняемый файл или службу: версия клиента базы не доказывает версию серверной части.

Разберите несовместимость на конкретном примере

Предположим, приложению нужны только Python 3.10 и нативное расширение amd64. Это условный пример, не описание определённого продукта. Стандартный Ubuntu 24.04 arm64 не проходит две проверки: Python по умолчанию 3.12, а расширение предназначено для другой архитектуры.

Переход на amd64 решает вопрос процессора, но не версии Python. Виртуальное окружение изолирует пакеты вокруг создавшего его интерпретатора и не превращает 3.12 в 3.10. Не подменяйте системный Python Ubuntu.

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

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

Учтите контейнеры и сопровождение пакетов

Контейнер отделяет зависимости от стандартных пакетов Ubuntu, но использует ядро, сеть и хранилище хоста. Нужна подходящая сборка образа. Эмуляция меняет условия производительности и поддержки — не заменяйте ею нативную сборку незаметно.

Постоянные данные храните в описанных томах или внешнем хранилище и проверяйте восстановление независимо от удаляемых контейнеров. Фиксируйте версии или digest для повторяемости, одновременно планируя обновления. Навсегда зафиксированный уязвимый образ остаётся уязвимым.

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

Отделите обновление пакетов от смены выпуска

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

apt list --upgradable
systemctl --failed
if [ -f /var/run/reboot-required ]; then cat /var/run/reboot-required; fi

Выполняйте обслуживание в подходящее окно и повторяйте проверки приложения. Службы могут перезапускаться. Отсутствие reboot-required не доказывает, что все процессы используют актуальные компоненты.

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

Сохраните воспроизводимое решение

Прокрутите таблицу, чтобы увидеть остальные столбцы →

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

Вопросы и ответы