MAATRIX / Блог / Микросервисы на одном VPS через docker-compose

Микросервисы на одном VPS через docker-compose

Блог MAATRIX · 2026-07-07

Не всякой микросервисной архитектуре нужен Kubernetes. На старте несколько сервисов прекрасно живут на одном VPS под docker-compose. Соберём стек с reverse proxy, внутренней сетью, healthcheck и централизованными логами.

Содержание

  1. Когда достаточно одного VPS
  2. Структура стека
  3. Сеть и обращение по именам
  4. Запуск, логи и масштабирование
  5. Частые ошибки

Когда достаточно одного VPS

['Kubernetes оправдан, когда сервисов десятки и нужен автоскейлинг между нодами. Пока их 3–8 и трафик умеренный, docker-compose на одном сервере проще в эксплуатации и дешевле: один VPS вместо кластера.', 'compose даёт всё нужное: изолированные контейнеры, общую сеть по именам, healthcheck, лимиты ресурсов и одну команду для подъёма всего стека.', 'Несколько сервисов делят одно ядро и диск, поэтому важна производительность на ядро. AMD EPYC + NVMe у MAATRIX держит и БД, и очередь, и веб одновременно без деградации отклика. Именно IO-latency обычно становится первым узким местом при уплотнении сервисов на одну машину, и здесь NVMe даёт запас, которого нет у SATA-виртуалок.', 'Важно и то, что миграция на Kubernetes позже пройдёт безболезненно: те же образы, те же переменные окружения, те же healthcheck. docker-compose — это не тупик, а естественная первая ступень, с которой вы в любой момент шагнёте в k3s, когда сервисов станет по-настоящему много.']

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать VPS для микросервисов

Структура стека

['Возьмём типичный набор: reverse proxy (Caddy), два бэкенд-сервиса (api, worker), база (Postgres) и брокер (Redis). Все — в одной compose-сети, наружу торчит только прокси.', '
services:\n  proxy:\n    image: caddy:2-alpine\n    ports: [ "80:80", "443:443" ]\n    volumes:\n      - ./Caddyfile:/etc/caddy/Caddyfile\n    depends_on: [ api ]\n\n  api:\n    build: ./api\n    environment:\n      DATABASE_URL: postgres://app:secret@db:5432/app\n      REDIS_URL: redis://cache:6379\n    healthcheck:\n      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]\n      interval: 30s\n      retries: 3\n    depends_on:\n      db: { condition: service_healthy }\n\n  worker:\n    build: ./api\n    command: python worker.py\n    depends_on: [ cache, db ]\n\n  db:\n    image: postgres:16-alpine\n    environment:\n      POSTGRES_USER: app\n      POSTGRES_PASSWORD: secret\n    volumes: [ pgdata:/var/lib/postgresql/data ]\n    healthcheck:\n      test: ["CMD-SHELL", "pg_isready -U app"]\n      interval: 10s\n      retries: 5\n\n  cache:\n    image: redis:7-alpine\n\nvolumes:\n  pgdata:
']

Сеть и обращение по именам

['compose автоматически создаёт общую сеть, и сервисы видят друг друга по имени. Внутри контейнера api адрес базы — просто db:5432, брокера — cache:6379. Никаких IP руками прописывать не нужно.', 'Наружу выставлен только proxy. Порты db и cache не публикуйте через ports — иначе база окажется в открытом интернете. Доступ к ней только изнутри сети compose.', "Reverse proxy Caddy автоматически получает Let's Encrypt-сертификат. Минимальный Caddyfile:", '
api.example.com {\n    reverse_proxy api:8000\n}
']

Запуск, логи и масштабирование

['Поднимаем весь стек и смотрим статус healthcheck:', '
docker compose up -d\ndocker compose ps\ndocker compose logs -f api
', 'Отдельный сервис можно масштабировать в несколько реплик — прокси распределит нагрузку, если сервис stateless:', '
docker compose up -d --scale worker=3
', 'Ограничьте ресурсы, чтобы один сервис не съел весь VPS. В compose это делается через deploy.resources.limits:', '
    deploy:\n      resources:\n        limits:\n          cpus: "0.50"\n          memory: 256M
', 'Лимит памяти особенно важен для сервисов с потенциальными утечками: контейнер, упёршийся в свой memory-лимит, будет перезапущен, а не утянет за собой весь VPS. Это дешёвая страховка, которую часто забывают выставить.']

Частые ошибки

['
  • Сервис стартует раньше БД — depends_on без condition: service_healthy не ждёт готовности, только запуска. Всегда добавляйте healthcheck базе.
  • БД доступна из интернета — опубликовали порт 5432 наружу. Убирайте ports у внутренних сервисов.
  • Диск забит логами — настройте ротацию через logging.options.max-size.
  • Один сервис положил сервер — нет лимитов CPU/RAM, утечка памяти съела весь VPS.
']

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать VPS для микросервисов

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

Сколько сервисов потянет один VPS?

Зависит от нагрузки, но 5–10 лёгких сервисов на VPS с 4 ГБ RAM работают комфортно. Следите за суммарным потреблением памяти.

Как обновить один сервис без остановки остальных?

Выполните docker compose up -d --no-deps --build api — пересоберётся и перезапустится только указанный сервис.

Нужен ли отдельный сервер под базу?

На старте нет. Когда БД станет узким местом, вынесете её на отдельный VPS, изменив DATABASE_URL.

Читайте также