Миграция Docker-контейнеров с Ubuntu 22.04 на 24.04

Содержание

Запланировали обновление Ubuntu? Наш новый материал посвящён миграции Docker-инфраструктуры с Ubuntu 22.04 на 24.04. Мы показываем, как выполнить переход на VPS с минимальным простоем, сохранив все данные и конфигурации.

Введение

Миграция с Ubuntu 22.04 на 24.04 необходима для получения актуальных обновлений безопасности, поддержки нового оборудования и доступа к современным версиям системного ПО и инструментов. Но один из главных аспектов успешной миграции — обеспечение непрерывной работы сервисов.

В данной статье мы разберём комплексный подход к переносу Docker-инфраструктуры, который минимизирует простои и позволит безопасно воспользоваться всеми преимуществами новой версии дистрибутива.

Аренда VPS/VDS — от ₽219/месяц

Почему выбирают VPS от AdminVPS:

✓ Дешевле физического сервера

✓ Более гибкий и мощный, чем обычный хостинг

✓ Бесплатная защита от DDoS и техподдержка 24/7

✓ Масштабируется под любые задачи

Виртуальный сервер VPS/VDS — ваш личный сервер для сайтов, магазинов, ботов и других проектов.

Подготовка к миграции

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

Анализ текущего состояния

Первый шаг — полная инвентаризация Docker-окружения. Получите список всех запущенных и остановленных контейнеров с детальной информацией об их конфигурации:

docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}"

Информация будет выведена в табличном формате и включать идентификаторы, имена контейнеров, используемые образы, текущий статус и проброшенные порты.

Проанализируйте используемые образы и оцените, нужно ли обновлять их перед миграцией:

docker image ls --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}\t{{.CreatedSince}}"

Проверьте конфигурацию сетей Docker:

docker network ls --no-trunc

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

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

docker volume ls -q | xargs docker volume inspect

Создание полного бекапа

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

Экспортируйте все образы в архивные файлы:

docker image ls -q | xargs -I {} docker save {} -o /путь/к/бекапу/{}.tar

Для каждого образа будет создан отдельный .tar-файл.

Для контейнеров с критическими данными выполните дамп содержимого томов:

docker run --rm --user root -v имя_тома:/data -v /путь/к/бекапу:/backup ubuntu:22.04 \

    tar czf /backup/имя_тома_$(date +%Y%m%d).tar.gz -C /data

Экспортируйте конфигурации запуска для каждого контейнера:

docker inspect контейнер > /путь/к/бекапу/контейнер_config.json

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

Проверка совместимости

Анализ совместимости следует проводить на нескольких уровнях

проверьте требования ваших приложений к версии ядра Linux;
убедитесь в совместимости версий Docker Engine и containerd;
протестируйте работу образов на тестовой системе с Ubuntu 24.04.

Особое внимание уделите контейнерам, использующим специфичные функции ядра или низкоуровневые системные вызовы, так как они наиболее чувствительны к изменениям версии ОС.

Обновление ОС и компонентов Docker

Процесс включает в себя не только обновление пакетов ОС, но и контроль версий container runtime для обеспечения совместимости с существующими контейнерами.

Остановка контейнеров и подготовка к обновлению

Перед началом обновления операционной системы необходимо корректно остановить все работающие контейнеры. Важно сохранить порядок остановки для приложений с зависимостями.

Остановите все запущенные контейнеры:

docker stop $(docker ps -q)

Проверьте, что все контейнеры перешли в состояние Exited:

docker ps -a

Проверьте логи критически важных контейнеров перед остановкой для фиксации последнего рабочего состояния.

Если Docker был установлен из репозитория Ubuntu, то сразу переходите к обновлению системы, Docker обновится вместе с ней.

Удаление Docker

Если вы устанавливали Docker из репозитория разработчиков, то придётся удалить Docker, обновить систему, добавить новый репозиторий и установить Docker заново.

Удалите старые версии Docker командой:

sudo apt remove -y docker docker-engine docker.io containerd runc

Удалите оставшиеся зависимости:

sudo apt autoremove -y

Обновление Ubuntu 22.04 до 24.04

Обновите индекс пакетов и установите обновления для текущей версии:

sudo apt update && sudo apt upgrade -y

Установите инструмент для обновления дистрибутива:

sudo apt install -y update-manager-core

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

sudo do-release-upgrade -d

Во процессе система запросит подтверждение на замену конфигурационных файлов. Рекомендуется сохранять текущие версии файлов, если в них были внесены изменения, связанные с Docker.

Установка Docker

Если вы удаляли Docker перед обновлением, то установите его заново из официального репозитория.

Установите зависимости для добавления репозиториев:

sudo apt install -y ca-certificates curl

Добавьте GPG-ключ и репозиторий Docker:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Обновите индекс пакетов и установите актуальные версии Docker-компонентов:

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Перенос данных и конфигураций

После успешного обновления ОС и установки актуальных версий Docker-компонентов переходим к главному этапу миграции — восстановлению работоспособности контейнерной инфраструктуры.

Восстановление образов из бекапов

Импорт ранее сохранённых образов выполняется с помощью команды docker load, которая восстанавливает образы из .tar-архивов. Проверьте целостность архивов перед загрузкой.

Восстановление образов:

find /путь/к/бекапу -name "*.tar" -exec docker load -i {} \;

Чтобы контролировать процесс импорта, проверяйте наличие образов в локальном хранилище:

docker image ls --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}"

Если образов слишком много, используйте параллельную загрузку через xargs, это ускорит процесс:

find /путь/к/бекапу -name "*.tar" | xargs -I {} -P 4 docker load -i {}

Флаг -P 4 указывает на одновременную обработку четырех архивов.

Работа с томами и перенос данных

Для томов типа bind mount копируйте данные с сохранением прав доступа:

rsync -avz --progress /исходный/путь/тома /целевой/путь/тома

Для named volumes создайте новые тома и восстановите данные:

docker volume create имя_тома
docker run --rm -v /путь/к/бекапу:/backup -v имя_тома:/data ubuntu:24.04 \
    tar xzf /backup/имя_тома.tar.gz -C /data

Проверьте содержимое восстановленных томов:

docker run --rm -v имя_тома:/путь ubuntu:24.04 ls -la /путь

Воссоздание пользовательских сетей

Восстановите пользовательские сети на основе сохранённых конфигураций:

docker network create --driver bridge \
    --subnet=172.20.0.0/16 \
    --gateway=172.20.0.1 \
    my_custom_network

Для сложных сетевых конфигураций используйте данные из резервных копий:

jq -r '.NetworkSettings.Networks' контейнер_config.json

Восстановление конфигурации демона

Остановите демон Docker перед изменением конфига, чтобы избежать конфликтов:

sudo systemctl stop docker

Восстановите конфигурационный файл демона:

sudo cp /путь/к/бекапу/daemon.json /etc/docker/

Примените изменения конфигурации:

sudo systemctl daemon-reload
sudo systemctl restart docker

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

sudo systemctl status docker
sudo docker info | grep -E "Storage Driver|Logging Driver|Cgroup Driver"

Проверка целостности перенесённых данных

Сравните контрольные суммы важных файлов:

sha256sum /целевой/путь/файл | diff - /путь/к/бекапу/файл.sha256

Проверьте соответствие версий образов:

docker inspect образ:тег | jq '.[].RepoDigests'

Протестируйте работу томов с тестовым контейнером:

docker run --rm -v имя_тома:/тест ubuntu:24.04 \
    find /тест -type f -name "*.db" -exec test -e {} \; -print

Проверьте сетевые настройки:

docker network inspect my_custom_network | jq '.[].IPAM.Config'

Проверьте журналы демона Docker на наличие ошибок:

sudo journalctl -u docker.service --since "10 minutes ago" | grep -i error

Запуск и валидация

Постепенный запуск контейнеров

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

Запустите контейнеры с зависимостями первыми:

docker run -d --name redis-server \
    -v redis_data:/data \
    --network=my_custom_network \
    redis:7-alpine

Для контейнеров с healthcheck дождитесь их перехода в здоровое состояние:

while [ "$(docker inspect -f '{{.State.Health.Status}}' redis-server)" != "healthy" ]; do
    echo "Ожидание готовности redis-server..."
    sleep 5
done

Запустите основные контейнеры только после готовности зависимостей:

docker run -d --name web-app \
    -v app_data:/app/storage \
    --network=my_custom_network \
    -e REDIS_HOST=redis-server \
    -p 80:8080 \
    my-web-app:latest

Валидация функциональности

Проверьте доступность web-приложения через health endpoint:

curl -f http://localhost:80/health || echo "Health check failed"

Протестируйте критические функциональные возможности:

curl -X POST http://localhost:80/api/test \
    -H "Content-Type: application/json" \
    -d '{"test": "data"}' \
    -w "HTTP Status: %{http_code}\n"

Проверьте подключение к зависимостям через логи:

docker logs web-app | grep -i "connected\|ready"

Мониторинг потребления ресурсов

В первые часы после миграции наблюдайте за потреблением ресурсов, чтобы вовремя выявить аномалии и потенциальные проблемы.

Потребление ресурсов в реальном времени:

docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}}\t{{.BlockIO}}"

Использование памяти для выявления утечек:

docker exec web-app vmstat -s | grep -i "memory"

Диагностика возможных проблем

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

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

docker logs web-app --since 5m

Поиск в логах ошибок и предупреждений (если приложение пишет их в stdout/stderr):

docker logs web-app | grep -E -i "(error|warn|exception|failed)"

Просмотр информации о состоянии контейнера, его сетевых настройках и точках монтирования:

docker inspect web-app

Также для большей наглядности можно извлечь конкретные данные:

docker inspect web-app | jq '.[].State'       # состояние (Status, Running, ExitCode)
docker inspect web-app | jq '.[].Mounts'      # смонтированные тома
docker inspect web-app | jq '.[].NetworkSettings.Networks'  # сетевые настройки

Чтобы проверить базовую работоспособность контейнера, выполните простую команду, например, посмотрите список процессов:

docker exec web-app ps aux

Убедитесь, что контейнер видит другие сервисы в сети Docker. Проверка разрешения имён (должен вернуть IP-адрес):

docker exec web-app nslookup redis-server || docker exec web-app ping -c 1 redis-server

Проверка доступности порта с помощью /dev/tcp (работает в bash):

docker exec web-app bash -c 'timeout 2 bash -c "</dev/tcp/redis-server/6379" && echo "Port is open" || echo "Port is closed"'

Проверьте, что тома смонтированы корректно и доступны для чтения/записи:

docker exec web-app df -h /app/storage

docker exec web-app ls -la /app/storage

Следующие команды понадобятся для продвинутой диагностики, но они требуют наличия соответствующих утилит (strace, ldd, nc, curl) внутри контейнера. Если их нет, нужно будет собрать кастомный образ для отладки или подключиться к процессу с хостовой машины.

Диагностика системных вызовов (почему процесс не может открыть файл и т. п.):

docker exec web-app strace -p 1

Проверка зависимостей бинарных файлов (нет ли отсутствующих библиотек):

docker exec web-app ldd /usr/local/bin/php-fpm

Точная проверка доступности сетевых портов:

docker exec web-app nc -zv redis-server 6379

Проверка HTTP-эндпоинтов:

docker exec web-app curl -I http://redis-server:6379

Если эти утилиты отсутствуют, основным источником информации остаются логи, inspect и базовые команды проверки процессов и файловой системы.

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

wrk -t4 -c100 -d30s http://localhost:80/api/health

Постоянный мониторинг и постепенное увеличение нагрузки в течение первых 24 часов после миграции позволят выявить и устранить потенциальные проблемы до их воздействия на конечных пользователей.

Читайте в блоге: