Docker Compose на VPS: готовые примеры стеков

Один файл docker-compose.yml описывает весь ваш стек — базу, приложение, кэш и прокси. Ниже рабочие примеры, которые можно поднять на любом VPS за пару минут.

Зачем Compose вместо голых docker run

Когда сервисов больше одного, команды docker run с десятком флагов превращаются в ад. Compose переносит всю конфигурацию в декларативный YAML: сети, тома, переменные окружения, зависимости между контейнерами. Поднять или снести весь стек — одна команда.

Ставим движок и плагин compose на свежий VPS:

curl -fsSL https://get.docker.com | sh
docker compose version

В современном Docker команда пишется через пробел — docker compose, а не устаревшее docker-compose. На тарифах MAATRIX с AMD EPYC + NVMe сборка и запуск образов идут заметно быстрее за счёт диска, поэтому compose up редко становится узким местом.

Структура файла всегда одинакова: корневой ключ services с описанием контейнеров, опциональные volumes и networks. Каждый сервис получает имя, по которому к нему обращаются соседи внутри общей сети — не нужно знать IP-адреса, работает встроенный DNS Docker. Это и есть главная магия compose: приложение ходит к базе по имени db, а не по адресу, который меняется при каждом пересоздании.

Стек 1: WordPress + MariaDB

Классика для сайта или блога. Два контейнера, один том под базу, автоперезапуск:

services:
  db:
    image: mariadb:11
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
      MYSQL_DATABASE: wp
      MYSQL_USER: wp
      MYSQL_PASSWORD: wppass
    volumes:
      - db_data:/var/lib/mysql
  wordpress:
    image: wordpress:php8.3-apache
    restart: always
    depends_on:
      - db
    ports:
      - "80:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wp
      WORDPRESS_DB_PASSWORD: wppass
      WORDPRESS_DB_NAME: wp
volumes:
  db_data:

Запуск в фоне и просмотр логов:

docker compose up -d
docker compose logs -f wordpress

Стек 2: приложение + PostgreSQL + Redis

Типичный бэкенд: сервис на своём образе, база и кэш. Обратите внимание на healthcheck — приложение стартует только когда база готова.

services:
  app:
    build: .
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      DATABASE_URL: postgres://app:secret@db:5432/app
      REDIS_URL: redis://cache:6379
    ports:
      - "8080:8080"
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: app
    volumes:
      - pg:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
      interval: 5s
      retries: 5
  cache:
    image: redis:7-alpine
volumes:
  pg:

Стек 3: Nextcloud — своё облако

Замена Google Drive на собственном сервере. Файлы остаются у вас, никаких лимитов чужого провайдера.

services:
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nc
      POSTGRES_PASSWORD: ncpass
    volumes:
      - db:/var/lib/postgresql/data
  app:
    image: nextcloud:apache
    restart: always
    ports:
      - "8081:80"
    depends_on:
      - db
    environment:
      POSTGRES_HOST: db
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nc
      POSTGRES_PASSWORD: ncpass
    volumes:
      - nc:/var/www/html
volumes:
  db:
  nc:

Полезные команды и частые ошибки

• Обновить образы и пересоздать: docker compose pull && docker compose up -d
• Остановить, не удаляя тома: docker compose down
• Снести всё вместе с данными: docker compose down -v — осторожно, стирает тома
• Статус: docker compose ps

Частые грабли: публикация портов наружу без фаервола — база с проброшенным 5432:5432 оказывается в открытом интернете. Не пробрасывайте порты БД, если к ней ходит только сосед по compose-сети. И не храните пароли в git — выносите их в .env рядом с compose-файлом.

Для продакшена берите VPS с ежедневными бэкапами: если стек с данными живёт на MAATRIX, снапшот тома всегда можно восстановить из резервной копии.

Ещё один нюанс — переменные окружения. Вместо того чтобы хардкодить пароли в YAML, создайте файл .env в той же папке, и Compose автоматически подставит значения по имени переменной. Так один и тот же compose-файл легко переносится между dev и prod: меняется только окружение, а не разметка стека.

# .env
MYSQL_ROOT_PASSWORD=super-secret
WP_TAG=php8.3-apache
# в compose: image: wordpress:${WP_TAG}

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