Вы написали docker‑compose.yml, подняли сервис локально, всё крутится. Задеплоили на сервер, запустили docker compose up -d, неделю всё нормально. А потом контейнер с Postgres тихо съедает всю память на хосте и OOM‑киллер убивает соседний сервис. Или приложение падает в два часа ночи, а Docker не перезапускает его, потому что restart policy стоит в дефолтном no. Или логи за месяц занимают 40 ГБ, и на диске кончается место.

Все пять проблем решаются парой строк в compose‑файле. Но про них забывают, потому что локально они не проявляются: на вашей машине 32 ГБ RAM, места на диске полтерабайта, и сервис перезапускать не нужно, потому что вы рядом.

Нет лимитов на память и CPU

По умолчанию контейнер может использовать всю память и все ядра хоста. На сервере с тремя контейнерами (приложение, Postgres, Redis) любой из них может захватить все ресурсы. Обычно это Postgres: ему сказали «бери сколько нужно», он и берёт. Когда RAM заканчивается, Linux OOM‑киллер убивает процесс с наибольшим потреблением, и часто это не Postgres (у него есть shared buffers), а ваше приложение, которое в этот момент обрабатывает 500 запросов и держит их в памяти.

services:
  app:
    image: myapp:latest
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.0"
        reservations:
          memory: 256M

  postgres:
    image: postgres:16-alpine
    deploy:
      resources:
        limits:
          memory: 1G

limits — потолок. reservations — гарантированный минимум. Если контейнер превысит лимит памяти, Docker убьёт его сам, без OOM‑киллера (точнее, cgroup OOM, что по сути то же самое, но изолированно).

Как узнать, что контейнер умер от OOM:

docker inspect myapp --format='{{.State.OOMKilled}}'

Если true — контейнер был убит за превышение лимита. Увеличьте лимит или оптимизируйте потребление.

Для Postgres внутри контейнера shared_buffers нужно выставлять с учётом лимита: обычно 25% от доступной памяти. При лимите 1G это 256M. Если оставить дефолтные 128MB shared_buffers при лимите 1G, Postgres будет использовать RAM через файловый кеш ОС, что тоже нормально, но менее предсказуемо.

Нет restart policy

По умолчанию restart: no. Контейнер упал — лежит. Никто его не перезапустит, пока вы не проснётесь и не заметите.

services:
  app:
    restart: unless-stopped

unless-stopped перезапускает при любом падении, кроме случая, когда вы остановили контейнер руками. Это лучше, чем always, который перезапустит даже после docker compose stop (мешает при обслуживании).

Для одноразовых задач (миграции, seed данных) — restart: "no" или restart: on-failure:

services:
  migrator:
    image: myapp:latest
    command: ["python", "manage.py", "migrate"]
    restart: "no"

  app:
    restart: unless-stopped
    depends_on:
      migrator:
        condition: service_completed_successfully

Приложение стартует только после того, как миграция завершилась успешно. Если миграция упала, приложение не запустится, и вы сразу увидите проблему, а не узнаете о ней по 500-м ошибкам от приложения, которое пытается работать с неактуальной схемой.

3. Логи без ротации

Docker пишет логи в JSON‑файл без ограничения размера. Сервис, который логирует каждый запрос при 100 RPS, за месяц сгенерирует десятки гигабайт. Я видел сервер, на котором /var/lib/docker/containers/ занимал 80 ГБ, и диск кончился посреди ночи. Всё упало: не только контейнеры, но и сам Docker, потому что ему некуда писать.

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

Один файл не больше 10 МБ, максимум 3 файла. Итого до 30 МБ на контейнер. Старые файлы удаляются автоматически. Для большинства сервисов 30 МБ — это несколько часов логов, достаточно для оперативной диагностики. Если нужна история за неделю, увеличьте до max-size: 50m и max-file: 10 (500 МБ).

Можно задать глобально для всех контейнеров через /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "5"
  }
}

После изменения перезапустите Docker daemon. Настройка применится ко всем новым контейнерам. Проверить, сколько места логи занимают прямо сейчас:

du -sh /var/lib/docker/containers/*/*-json.log | sort -h

Если видите файлы по 5–10 ГБ — ротация не настроена, и это бомба замедленного действия.

Нет healthcheck

Docker не знает, работает ли ваше приложение. Он знает, что процесс запущен (PID существует), но не знает, отвечает ли сервис. Приложение может зависнуть, исчерпать соединения, войти в бесконечный цикл — процесс жив, Docker считает контейнер работающим.

services:
  app:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s

  postgres:
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5

start_period — время после старта, в течение которого неудачные проверки не считаются. Приложению нужно время на инициализацию (загрузка конфигурации, прогрев кеша, подключение к базе), и без start_period Docker может решить, что контейнер unhealthy, пока тот ещё грузится.

Самое полезное — связка healthcheck с depends_on:

services:
  app:
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy

Приложение запускается только когда Postgres и Redis прошли healthcheck. Без этого приложение может стартовать раньше базы и упасть на первом запросе. Да, можно написать retry‑логику при подключении к базе внутри приложения, но зачем, если Docker может гарантировать порядок?

Если в образе нет curl (alpine‑образы часто без него):

healthcheck:
  test: ["CMD-SHELL", "wget -q --spider http://localhost:8080/health || exit 1"]

Volumes без плана бэкапов

volumes:
  pgdata:

Named volume хранит данные Postgres между перезапусками. Физически это папка на хосте в /var/lib/docker/volumes/. Если хост умрёт, данные потеряны. Если кто‑то случайно сделает docker compose down -v (с флагом ‑v, который удаляет volumes), данные потеряны.

Минимальный бэкап — pg_dump в файл:

services:
  backup:
    image: postgres:16-alpine
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - ./backups:/backups
    entrypoint: >
      sh -c "while true; do
        PGPASSWORD=$$POSTGRES_PASSWORD pg_dump -h postgres -U postgres mydb |
        gzip > /backups/backup_$$(date +%Y%m%d_%H%M%S).sql.gz;
        find /backups -mtime +7 -delete;
        sleep 86400;
      done"
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    restart: unless-stopped

Каждые 24 часа: дамп, сжатие, удаление дампов старше 7 дней. Папку ./backups нужно синхронизировать на S3 или другой сервер — бэкап на том же хосте спасает от docker compose down -v, но не от отказа железа.

Для Redis, если он используется как кеш (а не как основное хранилище), бэкап обычно не нужен. Если как хранилище — включите persistence:

redis:
    command: redis-server --save 60 1000 --appendonly yes
    volumes:
      - redisdata:/data

Итого

Пять настроек, которые не нужны для локальной разработки, но нужны на любом сервере, где сервис работает дольше недели. Лимиты памяти (чтобы один контейнер не убил остальные), restart policy (чтобы сервис пережил ночь), ротация логов (чтобы диск не кончился), healthcheck (чтобы Docker знал, жив ли сервис), бэкап volumes (чтобы данные пережили down -v и отказ хоста). Каждая настройка — пара строк в compose‑файле.

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

docker-compose.yml живёт спокойно ровно до первого реального сервера: OOM, переполненные логи, упавший контейнер без рестарта и volumes без бэкапов быстро показывают, где локальная конфигурация не готова к продакшену.

Продолжить тему можно на бесплатных открытых уроках OTUS:

• 2 июня, 20:00 — «Введение в Docker: контейнеризация приложений в Linux».
  _{Разберём базовые принципы контейнеризации приложений в Linux и то, как Docker помогает упаковывать и запускать сервисы предсказуемо.}

• 22 июня, 20:00 — «Память в Linux. Cache, swap, dirty pages».
  _{Поговорим о том, как Linux работает с памятью, почему процессы могут упираться в RAM и как понимать поведение системы до того, как всё закончится OOM.}

И подписывайтесь на блог — здесь регулярно выходят разборы production‑проблем, инфраструктуры, DevOps и практики эксплуатации без пересказов документации.