Налаштування ротації логів Docker за допомогою драйвера логування Docker: логування Docker journald та локальний файловий драйвер Docker

Рівень: Експерт
Орієнтовний час: ~20 хвилин
Мета: Налаштувати ротацію логів Docker для забезпечення безперебійного управління логами та запобігання вичерпанню дискового простору.

Вступ

Некеровані логи Docker можуть швидко вичерпати дисковий простір сервера. За замовчуванням демон Docker записує логи у форматі json-file без обмежень за розміром. Для підтримки надійної інфраструктури необхідно налаштувати ротацію логів Docker, використовуючи масштабований драйвер логування Docker. У цьому посібнику докладно описано, як глобально реалізувати ротацію логів Docker за допомогою логування Docker journald або локального файлового драйвера Docker. Вибір правильної конфігурації забезпечує ефективне управління логами та стабільність системи.

Термінологія

Перш ніж продовжити, ознайомтеся з цими основними поняттями:

• Docker: Платформа для запуску додатків в ізольованих середовищах, які називаються Контейнерами.
• Docker logs: Потоки виводу, захоплені з Stdout (стандартний вивід) та Stderr (стандартна помилка) контейнера.
• Log rotation: Практика архівування та видалення старих логів для звільнення простору.
• Logging driver: Механізм, який Docker використовує для захоплення, форматування та маршрутизації логів.
• Journald: Служба логування systemd, ідеальна для централізованого логування на хості.
• Local file driver: Високопродуктивний вбудований драйвер, оптимізований для локального зберігання.
• Json-file: Драйвер за замовчуванням, який записує логи як масиви JSON.
• Docker daemon: Фонова служба, що керує операціями Docker.
• Daemon.json: Конфігураційний файл демона.
• Log driver configuration: Глобальне або індивідуальне для кожного контейнера налаштування логування.
• Log options: Специфічні параметри, що передаються драйверу.
• Max-size: Граничний розмір, після якого відбувається ротація файлу логу.
• Max-file: Максимальна кількість збережених файлів після ротації.

Передумови

Перш ніж почати, переконайтеся, що у вас є:

• Операційна система: Ubuntu 22.04 / 24.04 LTS, Debian 12 / 13, RHEL 9 / 10, AlmaLinux 9 / 10, Rocky Linux 9 / 10
• Docker: встановлена версія 24.x або новіша
• Доступ: привілеї sudo
• Необхідні знання: адміністрування Linux та концепції "Інфраструктура як код" (Infrastructure as Code)

Крок 1: Розуміння драйверів Docker json-file та local

При порівнянні драйверів Docker json-file та local вибір залежить від продуктивності та накладних витрат. Драйвер json-file за замовчуванням є простим, але споживає більше ресурсів процесора та дискового простору через форматування JSON. Натомість локальний файловий драйвер має бінарний формат лише для додавання (append-only), оптимізований спеціально для ефективності ротації. При нормальних робочих навантаженнях у продакшені використання локального файлового драйвера Docker зменшує накладні витрати на диск і надійно забезпечує ротацію нативно.

Щоб перевірити поточний драйвер, виконайте:

docker info --format '{{.LoggingDriver}}'

Очікуваний вивід:

json-file

Якщо ви бачите json-file, перейдіть до зміни конфігурації daemon.json Docker logging.

Крок 2: Налаштування ротації логів Docker за допомогою локального файлового драйвера Docker

Щоб застосувати глобальні обмеження до всіх контейнерів, вам потрібно відредагувати файл /etc/docker/daemon.json. Це рекомендований підхід для daemon.json Docker logging.

Відкрийте конфігураційний файл:

Якщо /etc/docker/daemon.json не існує у вашій системі, nano створить його під час збереження. Це нормально - Docker використовує вбудовані значення за замовчуванням, коли файл відсутній.

sudo nano /etc/docker/daemon.json

Додайте наступну конфігурацію драйвера логування (log driver configuration):

{
  "log-driver": "local",
  "log-opts": {
    "max-size": "50m",
    "max-file": "3"
  }
}

Збережіть і закрийте файл. Нові налаштування записуються на диск. Ця конфігурація застосовує драйвер глобально. Параметри логування (log options) вказують Docker виконувати ротацію логів, коли вони досягають 50 мегабайт (max-size Docker logs), і зберігати максимум 3 файли (max-file Docker logs). Зверніть увагу, що драйвер local нативно підтримує ці явні обмеження розміру та файлів, на відміну від journald.

Перезапустіть демон Docker, щоб застосувати зміни. Служба docker.service керує контейнерами, тому її перезапуск застосовує обмеження:

sudo systemctl restart docker

Ви втратите з'єднання з демоном на кілька секунд. Після перезапуску всі новостворені контейнери будуть використовувати локальний файловий драйвер Docker і успадкують ці обмеження max-size Docker logs та max-file Docker logs.

Крім того, зрозумійте порядок пріоритету конфігурацій логування:

1. Прапорці CLI (docker run --log-driver) мають найвищий пріоритет.
2. Перевизначення логування у docker-compose.yml діють для кожного сервісу під час створення контейнера.
3. daemon.json діє як глобальний резервний варіант за замовчуванням для всіх неявних контейнерів.

Крок 3: Увімкнення логування Docker journald як вашого драйвера логування Docker

Як альтернативу, ви можете маршрутизувати логи безпосередньо до демона системи journald. Логування Docker journald безперешкодно інтегрується з systemctl та зовнішніми системами пересилання логів.

Відкрийте конфігураційний файл:

sudo nano /etc/docker/daemon.json

Замініть вміст конфігурацією journald. Повністю замініть вміст файлу - видаліть будь-які попередні записи log-opts, оскільки journald не підтримує параметри max-size або max-file:

{
  "log-driver": "journald"
}

Збережіть і закрийте файл. Конфігурацію оновлено.

Перезапустіть службу. docker.service потрібно перезавантажити, щоб перенести управління логами до journald:

sudo systemctl restart docker

При використанні логування Docker journald (Docker logs journald), драйвер journald знімає контроль за ротацією на стороні Docker. Ротація логів все ще існує, але вона повністю обробляється поза Docker системним журналом systemd. Ви побачите, що логи маршрутизуються безпосередньо до журналу systemd. Ці логи індексуються за полями метаданих контейнера, а не прив'язані до юніту docker.service.

В операційному плані journald управляє цими логами, використовуючи конкретні обмеження, налаштовані у файлі /etc/systemd/journald.conf, зокрема SystemMaxUse, RuntimeMaxUse та MaxRetentionSec. Це несе значний ризик: вичерпання ресурсів journald може вплинути на логування ssh, логи ядра, логи аудиту та всі інші служби, що спільно використовують журнал у продакшені. Зверніть увагу, що параметри max-size і max-file застосовуються лише до драйверів json-file і local, а не до journald.

Щоб застосувати зміни до конфігурації journald:

sudo systemctl restart systemd-journald
# Або щоб викликати негайну ротацію без повного перезапуску:
sudo systemctl kill -s SIGUSR2 systemd-journald

Крок 4: Управління виводом journalctl

Коли ви налаштовуєте ротацію логів Docker за допомогою journald, ви взаємодієте з логами, використовуючи journalctl замість docker logs. Служба journald обробляє ці логи централізовано.

Щоб переглянути логи певного контейнера за допомогою Docker logs journald, виконайте:

journalctl CONTAINER_NAME=<YOUR_CONTAINER_NAME> -o cat

Очікуваний вивід:

Application started successfully

Крок 5: Перевірка

Щоб перевірити конфігурацію драйвера логування Docker на запущеному контейнері, запустіть тестовий контейнер:

docker run -d --name log-test nginx:latest

Перевірте параметри логування (log options) контейнера:

docker inspect -f '{{.HostConfig.LogConfig.Type}}' log-test

Очікуваний вивід для локального драйвера:

local

Якщо ви налаштували journald, натомість вивід буде journald.

Перевірте застосовані параметри для локального драйвера:

docker inspect -f '{{.HostConfig.LogConfig.Config}}' log-test

Очікуваний вивід:

map[max-file:3 max-size:50m]

Це підтверджує, що ваше налаштування daemon.json Docker logging успішно застосувало параметри max-size Docker logs та max-file Docker logs. Зверніть увагу, що journald тут не відображає параметри max-size або max-file, оскільки ротація відкладена до ОС.

Використовуйте цю команду, щоб визначити будь-які раніше існуючі контейнери, які все ще використовують попередній драйвер. Драйвер логування фіксується під час створення контейнера - ці контейнери потрібно перестворити (наприклад, docker compose up -d --force-recreate), щоб успадкувати нову конфігурацію:

docker ps -aq | xargs -r docker inspect -f '{{.Name}}: {{.HostConfig.LogConfig.Type}}'

Скасування змін

Щоб повернути глобальну конфігурацію драйвера логування (log driver configuration) до формату за замовчуванням, видаліть конфігурацію з daemon.json.

Видаліть файл (завжди створюйте резервні копії конфігураційних файлів перед зміною) та перезапустіть службу Docker:

sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak.$(date +%F)
sudo rm /etc/docker/daemon.json
sudo systemctl restart docker

Вирішення проблем

• journalctl не повертає виводу для CONTAINER_ID: Драйвер Docker journald записує короткий 12-символьний ID у CONTAINER_ID, тоді як docker inspect повертає повний 64-символьний ID. Використовуйте замість цього CONTAINER_NAME або CONTAINER_ID_FULL.
• Існуючі контейнери все ще використовують json-file після перезапуску: Команда docker update не змінює драйвер логування. Ви повинні перестворити контейнер (наприклад, через docker compose down та up), щоб застосувати новий драйвер логування.
• max-size та max-file не мають ефекту з journald: Ротація логів для journald управляється глобально через /etc/systemd/journald.conf (наприклад, SystemMaxUse), а не через log-opts Docker.

Висновок

Належне управління виводом контейнерів є фундаментальною частиною надійної інфраструктури. Правильно вибираючи між драйверами Docker json-file та local, ви запобігаєте проблемам зі сховищем. Незалежно від того, чи налаштовуєте ви ротацію логів Docker, використовуючи легкий локальний файловий драйвер Docker, чи нативно інтегруєте через логування Docker journald, ваше середовище тепер обладнане для безпечної обробки масивних потоків логів. Впровадження цих практик ротації логів Docker гарантує, що конфігурація вашого драйвера логування Docker залишиться стабільною, а ресурси хоста - передбачуваними.

Версія документа: 1.0
Останнє оновлення: Травень 2026
Відповідальний: Команда технічної документації