Docker Compose для продакшена на Ubuntu 24.04: пошаговая установка

MAATRIX

Свежий сервер на Ubuntu 24.04 и стек сервисов, который нужно вывести в продакшен так, чтобы он сам поднимался после сбоя, не съедал память и не терял данные. Настроить Docker Compose для продакшена на Ubuntu 24.04 можно по чёткому чек-листу. Ниже — пошаговая установка с готовыми командами: от официального репозитория Docker до рабочего стека с политиками перезапуска, лимитами и проверками здоровья. Сначала о том, чем продакшен принципиально отличается от локального запуска, потому что именно это отличие и определяет все шаги. На своей машине compose-файл обычно минимален: образ, порты, пара переменных. Вы сами перезапускаете упавший контейнер, вам не страшно, если один сервис съест всю память, и данные не жалко. На сервере всё наоборот: контейнер должен подниматься сам после сбоя и перезагрузки, один сервис не имеет права задушить соседей по памяти, а потеря данных недопустима. Отсюда обязательный набор продакшен-настроек — политика перезапуска, лимиты ресурсов, проверки здоровья, именованные тома и аккуратная работа с секретами. Ubuntu 24.04 с её долгой поддержкой — удачная база: свежее ядро, актуальные пакеты и стабильность на годы.

Шаг 1. Подготовка сервера Ubuntu 24.04

Начните с чистого VPS с root-доступом. Для продакшена берите ресурсы с запасом под ваши контейнеры: типовому набору из веб-приложения, базы и кеша комфортно на 2–4 ядрах и 4–8 ГБ RAM, а тяжёлые сервисы считают отдельно. Обновите систему:

apt update && apt upgrade -y

Убедитесь, что время синхронизировано — это важно и для TLS, и для согласованности логов. В Ubuntu 24.04 синхронизация обычно уже работает через systemd-timesyncd:

timedatectl status

Локацию сервера выбирайте по задаче проекта: для российской аудитории ниже пинг с RU-площадки, для доступа к зарубежным сервисам — US, для Европы — UK. У MAATRIX доступны все три с оплатой из России картой, СБП или криптой, поэтому продакшен-сервер можно взять там, где он ближе к пользователям.

Шаг 2. Установка Docker из официального репозитория

Важный момент: для продакшена ставьте Docker из официального репозитория, а не пакет docker.io из стандартного репозитория Ubuntu — так вы получите свежую версию Docker Engine вместе с плагином Compose. Самый простой способ — официальный установочный скрипт:

curl -fsSL https://get.docker.com | sh
systemctl enable --now docker

Скрипт подключает официальный репозиторий Docker для Ubuntu 24.04 и ставит движок с плагином compose. Обратите внимание: современная команда — docker compose без дефиса, старый docker-compose устарел. Проверьте версии:

docker --version
docker compose version

Команда systemctl enable --now docker включает автозапуск демона, чтобы после перезагрузки VPS весь стек поднимался сам. Без этого шага контейнеры не встанут после ребута, даже с правильными политиками перезапуска.

Шаг 3. Продакшен-структура проекта

Организуйте файлы аккуратно: отдельный каталог проекта, compose-файл и файл переменных, который не попадёт в систему контроля версий. Создайте структуру:

mkdir -p /opt/myapp
cd /opt/myapp
touch compose.yaml .env
chmod 600 .env

Файл .env с паролями и ключами должен быть закрыт от посторонних (права 600) и исключён из репозитория. Это базовая гигиена секретов: пароли не место в самом compose-файле, который коммитится. Держите резервную копию .env в надёжном месте — потерять его вместе с сервером означает не восстановить конфигурацию. Проверьте, что файл защищён:

ls -la /opt/myapp/.env

Шаг 4. Продакшен-конфиг compose.yaml

Теперь опишем стек с продакшен-настройками. Ключевые отличия от локального запуска: политика перезапуска, лимиты ресурсов, проверки здоровья, именованные тома и привязка портов к localhost. Отредактируйте compose.yaml:

services:
  web:
    image: myapp:1.4.0
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    env_file: .env
    depends_on:
      db:
        condition: service_healthy
    deploy:
      resources:
        limits:
          memory: 512M
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 5s
      retries: 3

  db:
    image: postgres:16
    restart: unless-stopped
    env_file: .env
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      retries: 5

volumes:
  db_data:

Разберём главное. restart: unless-stopped поднимает контейнеры после сбоя и перезагрузки, но не после ручной остановки. Порт 127.0.0.1:8080 доступен только с хоста — наружу стек отдаёт реверс-прокси, а не Docker напрямую. Лимит памяти защищает соседей от прожорливого сервиса. healthcheck и depends_on: service_healthy гарантируют, что приложение стартует лишь после готовности базы. Данные базы — в именованном томе db_data, который переживает пересоздание контейнера. И версия образа зафиксирована (1.4.0), а не latest, чтобы деплой был предсказуемым и откатываемым.

Шаг 5. Запуск и проверка стека

Запустите стек в фоновом режиме и проверьте состояние сервисов:

docker compose up -d
docker compose ps

В выводе ps у сервисов с проверкой здоровья появится статус healthy — это подтверждает, что приложение не просто запущено, а действительно отвечает. Разница тут принципиальная: без healthcheck контейнер считается живым, пока работает его главный процесс, даже если приложение внутри давно зависло и не обслуживает запросы. Проверка здоровья регулярно опрашивает эндпоинт и честно сообщает системе реальное состояние, а заодно управляет порядком запуска через depends_on. Смотрите логи, если что-то не так:

docker compose logs -f web

Ограничьте размер логов, чтобы болтливый сервис не заполнил диск за недели, — добавьте каждому сервису блок logging с ротацией:

logging:
  driver: json-file
  options:
    max-size: "10m"
    max-file: "3"

Без этого ограничения логи контейнеров растут неограниченно и однажды забивают диск — частая причина внезапного отказа продакшена. Ротация решает это раз и навсегда.

Шаг 6. Обновления, бэкапы и обслуживание

Обновление сервиса на новую версию делается в два шага: подтянуть образ и пересоздать только этот сервис, не трогая базу и остальное:

docker compose pull web
docker compose up -d web

Если новая версия сломалась, откат — это возврат тега образа на прежний в compose.yaml и повторный up -d. Именно ради предсказуемого отката версии фиксируют, а не используют latest. Данные из томов регулярно бэкапьте отдельным процессом — том защищает от пересоздания контейнера, но не от гибели диска, поэтому копии увозите за пределы сервера.

Регулярно чистите неиспользуемые образы, следите за местом и памятью:

docker image prune -f
docker system df

Этого набора достаточно, чтобы продакшен на Docker Compose работал стабильно. Когда контейнеров становится много и сервер упирается в память или диск, тонкая настройка уже не поможет — нужен VPS помощнее с быстрым NVMe. У MAATRIX апгрейд доступен без смены провайдера, с оплатой из России картой или криптой, а при перерастании одного сервера следующим шагом становится кластер вроде Docker Swarm на нескольких VPS в одной локации.

Частые вопросы