Зачем это нужно? Представь, что на сервере крутится десяток контейнеров, каждый пишет гигабайты логов за день. Без очистки диск заполняется за неделю, и вся система ложится. Мы пройдем по шагам: от поиска файлов до cron-задач и лимитов в Docker. После этого твои контейнеры будут работать стабильно, а место на диске освободится.

Где хранятся логи контейнеров Docker

Логи Docker по умолчанию пишутся в JSON-файлы на хосте, обычно в /var/lib/docker/containers/. Каждый контейнер имеет свой файл с суффиксом -json.log. Эти файлы растут без остановки, если не настроено ограничение. Например, популярный веб-сервер Nginx в контейнере может генерировать логи ошибок и доступа, которые за сутки весят сотни мегабайт.

Чтобы понять проблему, посмотрим реальный сценарий. Допустим, у тебя контейнер my-app, который пишет логи от Node.js приложения. Без контроля файл разрастается до 10 ГБ, и df -h показывает 95% заполнения диска. Docker не останавливает контейнеры автоматически - он просто падает с ошибками I/O. Теперь логично перейти к командам: сначала найдем путь, потом очистим.

• docker inspect --format=‘{{.LogPath}}’ <container_id> - покажет точный путь к файлу лога для конкретного контейнера. Замени <container_id> на ID или имя.
• ls -lh /var/lib/docker/containers//-json.log - выведет размеры всех лог-файлов сразу, чтобы увидеть, кто жрет место.
• docker ps -q | xargs docker inspect --format=‘{{.LogPath}}’ - список путей для всех запущенных контейнеров.

Очистка логов без остановки контейнера

Очистка логов - это не удаление файла, а обнуление его содержимого. Docker продолжает писать в тот же дескриптор, так что контейнер не замечает изменений. Основная команда использует echo или truncate, чтобы записать пустоту в файл. Это работает на запущенных контейнерах, без риска потери данных в памяти.

Возьмем пример: контейнер с базой данных PostgreSQL пишет query-логи. Файл вырос до 5 ГБ, диск на исходе. Выполняем очистку - и место освобождается за секунды. Docker logs после этого покажет только новые записи. Важно: выполняй от root или с sudo, иначе права не хватит. Если контейнеров много, автоматизируй через скрипт.

1. Для одного контейнера: sudo sh -c 'echo "" > $(docker inspect --format="{{.LogPath}}" my-app)' - echo пишет пустую строку, файл становится 0 байт.
2. Для всех: truncate -s 0 /var/lib/docker/containers/*/*-json.log - truncate быстрее, не создает временные файлы.
3. Проверка: docker logs my-app - вывод пустой, новые логи пишутся нормально.
4. Нюанс: если драйвер логов не json-file, команда не сработает - проверь docker info | grep Logging.

Преимущества truncate: быстрее echo на больших файлах, не меняет inode. После очистки контейнер продолжает логировать без перезапусков.

Автоматическая ротация и лимиты логов

Ручная очистка хороша разово, но для продакшена нужна автоматизация. Docker поддерживает ротацию через параметры --log-opt, а cron-задачи обеспечат ежедневную уборку. Это предотвращает рост логов заранее, а не когда диск полный.

Пример: в docker-compose.yml добавь max-size: 10m - логи одного контейнера не превысят 10 МБ. Или настрой cron на truncate каждые 6 утра. В кластерах с Kubernetes это решается через fluentd или ELK, но для простого Docker хватит базовых инструментов. Подведем к настройке шаг за шагом.

• В docker run: docker run --log-opt max-size=10m --log-opt max-file=3 my-image - лимит 10 МБ на файл, 3 файла всего.
• В docker-compose.yml:

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

• Cron для очистки: crontab -e, добавь 10 6 * * * truncate -s 0 /var/lib/docker/containers/*/*-json.log - ежедневно в 06:10.

Масштабная уборка Docker - что еще чистить

Логи - не единственная проблема. Docker копит образы, volumes и stopped контейнеры, которые жрут гигабайты. Команда docker system prune удаляет висячие ресурсы, но для логов она не подходит. Используй в комбо с очисткой json.log. На сервере с 50 ГБ Docker после prune + truncate освобождается до 20 ГБ.

Реальный кейс: после деплоя 10 образов накопилось 15 ГБ. Prune -a удалила неиспользуемое, truncate обнулила логи - диск дышит. Не путай: prune не трогает running контейнеры. Добавь в скрипт для еженедельной уборки.

1. docker system prune -a - удалит все неиспользуемое (осторожно на проде!).
2. docker container prune - stopped контейнеры.
3. docker image prune -a - dangling образы.
4. docker volume prune - unused volumes.

Комбо-скрипт:

#!/bin/bash
truncate -s 0 /var/lib/docker/containers/*/*-json.log
docker system prune -f

Когда логи критичны - мониторинг и альтернативы

Иногда очистка логов - не лучший выход, если нужны исторические данные. Используй docker logs с флагами: --tail 100 для последних строк, --since 1d для дня. Или переключи драйвер на syslog/journald - логи уйдут в системный логгер хоста.

В продакшене подключи Prometheus или ELK для хранения логов вне Docker. Это решает проблему места навсегда. Минус: overhead на сетевые запросы. Для малого проекта cron + лимиты - золотая середина. Остается вопрос: а что с контейнерами в overlayfs? Там prune работает иначе.

Дополнительные фичи docker logs:

• docker logs --tail 50 my-app - последние 50 строк.
• docker logs --since "2026-02-25" my-app - логи с даты.
• docker logs -f my-app - follow в реальном времени.

Логи Docker под контролем - итоги и тонкости

Мы разобрали полный цикл: от поиска логов до автоматизации ротации и общей уборки Docker. Теперь твой сервер не упадет от переполненного диска, а контейнеры будут работать чисто. Ключ: комбинируй truncate с --log-opt для надежности.

Осталось упомянуть edge-кейсы - например, ротацию в Docker Swarm или с внешними драйверами вроде awslogs. Если контейнеры в production, протестируй на staging. Над чем подумать: интегрировать алерты на размер логов через скрипты.