Konfiguracja rotacji logów Dockera ze sterownikiem logowania: logowanie Dockera przez journald i sterownik plików local

Poziom: Ekspert
Szacowany czas: ~20 minut
Cel: Skonfigurowanie rotacji logów Dockera, aby zapewnić zarządzanie logami bez przestojów i zapobiec wyczerpaniu miejsca na dysku.

Wprowadzenie

Niezarządzane logi Dockera mogą szybko wyczerpać przestrzeń dyskową serwera. Domyślnie demon Dockera zapisuje logi w formacie json-file bez ograniczeń rozmiaru. Aby utrzymać niezawodną infrastrukturę, należy skonfigurować rotację logów Dockera przy użyciu skalowalnego sterownika logowania Dockera. Ten przewodnik opisuje, jak wdrożyć rotację logów Dockera globalnie, korzystając z logowania Dockera przez journald albo z lokalnego sterownika plikowego (local) Dockera. Wybór właściwej konfiguracji zapewnia wydajne zarządzanie logami i stabilność systemu.

Terminologia

Zanim przejdziesz dalej, zapoznaj się z poniższymi podstawowymi pojęciami:

• Docker: platforma do uruchamiania aplikacji w izolowanych środowiskach zwanych kontenerami.
• Logi Dockera: strumienie wyjściowe przechwytywane ze standardowego wyjścia (Stdout) i standardowego wyjścia błędów (Stderr) kontenera.
• Rotacja logów: praktyka archiwizowania i usuwania starych logów w celu odzyskania miejsca.
• Sterownik logowania (logging driver): mechanizm, za pomocą którego Docker przechwytuje, formatuje i przekierowuje logi.
• Journald: usługa logowania systemd, idealna do scentralizowanego logowania na hoście.
• Lokalny sterownik plikowy (local): wbudowany, wydajny sterownik zoptymalizowany pod kątem lokalnego magazynu danych.
• Json-file: domyślny sterownik, który zapisuje logi w formacie JSON.
• Demon Dockera: usługa działająca w tle, zarządzająca operacjami Dockera.
• Daemon.json: plik konfiguracyjny demona.
• Konfiguracja sterownika logów: globalne lub per kontener ustawienia logowania.
• Opcje logowania: parametry przekazywane do sterownika.
• Max-size: rozmiar progowy, po którego przekroczeniu plik logu jest rotowany.
• Max-file: maksymalna liczba przechowywanych plików po rotacji.

Wymagania wstępne

Zanim zaczniesz, upewnij się, że masz:

• System operacyjny: Ubuntu 22.04 / 24.04 LTS, Debian 12 / 13, RHEL 9 / 10, AlmaLinux 9 / 10, Rocky Linux 9 / 10
• Docker: zainstalowana wersja 24.x lub nowsza
• Dostęp: uprawnienia sudo
• Wymagana wiedza: administracja systemem Linux oraz koncepcje Infrastructure as Code

Krok 1: Różnice między sterownikami json-file i local w Dockerze

Przy porównywaniu sterowników json-file i local w Dockerze o wyborze decydują wydajność i narzut. Domyślny sterownik json-file jest prosty, ale zużywa więcej CPU i miejsca na dysku z powodu formatowania JSON. Natomiast sterownik plikowy local używa binarnego formatu typu append-only, zoptymalizowanego specjalnie pod kątem wydajnej rotacji. W typowych obciążeniach produkcyjnych lokalny sterownik plikowy (local) Dockera zmniejsza narzut na dysku i niezawodnie wymusza rotację w sposób natywny.

Aby sprawdzić aktualny sterownik, uruchom:

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

Oczekiwany wynik:

json-file

Jeśli widzisz json-file, przejdź do modyfikacji konfiguracji logowania Dockera w daemon.json.

Krok 2: Konfiguracja rotacji logów Dockera za pomocą lokalnego sterownika plikowego (local)

Aby wymusić globalne limity dla wszystkich kontenerów, edytujesz plik /etc/docker/daemon.json. Jest to zalecane podejście do konfiguracji logowania Dockera w daemon.json.

Otwórz plik konfiguracyjny:

Jeśli plik /etc/docker/daemon.json nie istnieje w systemie, nano utworzy go przy zapisie. To normalne - gdy pliku brak, Docker używa wbudowanych ustawień domyślnych.

sudo nano /etc/docker/daemon.json

Dodaj następującą konfigurację sterownika logów:

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

Zapisz i zamknij plik. Nowe ustawienia zostają zapisane na dysku. Ta konfiguracja stosuje sterownik globalnie. Opcje logowania nakazują Dockerowi rotować logi po osiągnięciu 50 megabajtów (max-size dla logów Dockera) i przechowywać maksymalnie 3 pliki (max-file dla logów Dockera). Zwróć uwagę, że sterownik local, w przeciwieństwie do journald, nadal natywnie obsługuje te jawne ograniczenia rozmiaru i liczby plików.

Zrestartuj demon Dockera, aby zastosować zmiany. Usługa docker.service obsługuje kontenery, więc jej restart wprowadza limity w życie:

sudo systemctl restart docker

Na kilka sekund utracisz łączność z demonem. Po restarcie wszystkie nowo utworzone kontenery będą używać lokalnego sterownika plikowego (local) Dockera i odziedziczą te limity max-size oraz max-file dla logów Dockera.

Ponadto warto znać kolejność priorytetów konfiguracji logowania:

1. Flagi CLI (docker run --log-driver) mają pierwszeństwo przed wszystkim innym.
2. Nadpisania logowania w docker-compose.yml działają per usługa w momencie tworzenia kontenera.
3. daemon.json pełni rolę domyślnej wartości globalnej dla wszystkich kontenerów bez jawnej konfiguracji.

Krok 3: Włączenie logowania Dockera przez journald jako sterownika logowania Dockera

Alternatywnie możesz kierować logi bezpośrednio do demona journald systemu. Logowanie Dockera przez journald płynnie integruje się z systemctl i zewnętrznymi mechanizmami przekazywania logów.

Otwórz plik konfiguracyjny:

sudo nano /etc/docker/daemon.json

Zastąp zawartość konfiguracją journald. Całkowicie zastąp zawartość pliku - usuń wszystkie wcześniejsze wpisy log-opts, ponieważ journald nie obsługuje opcji max-size ani max-file:

{
  "log-driver": "journald"
}

Zapisz i zamknij plik. Konfiguracja została zaktualizowana.

Zrestartuj usługę. Usługa docker.service musi zostać przeładowana, aby przenieść zarządzanie logami do journald:

sudo systemctl restart docker

Przy używaniu logów Dockera z journald sterownik journald odbiera Dockerowi kontrolę nad rotacją. Rotacja logów nadal istnieje, ale jest w całości obsługiwana poza Dockerem przez dziennik systemd. Logi trafiają bezpośrednio do dziennika systemd. Są indeksowane według pól metadanych kontenera, a nie powiązane z jednostką docker.service.

Operacyjnie journald zarządza tymi logami za pomocą konkretnych limitów skonfigurowanych w /etc/systemd/journald.conf, w szczególności SystemMaxUse, RuntimeMaxUse i MaxRetentionSec. Wiąże się to z istotnym ryzykiem o dużym promieniu rażenia (blast radius): wyczerpanie zasobów journald może w środowisku produkcyjnym wpłynąć na logowanie ssh, logi jądra, logi audytu i wszystkie inne usługi współdzielące dziennik. Pamiętaj, że opcje max-size i max-file dotyczą wyłącznie sterowników json-file i local, a nie journald.

Aby zastosować zmiany w konfiguracji journald:

sudo systemctl restart systemd-journald
# Or to trigger immediate rotation without a full restart:
sudo systemctl kill -s SIGUSR2 systemd-journald

Krok 4: Zarządzanie danymi wyjściowymi journalctl

Po skonfigurowaniu rotacji logów Dockera przez journald logi przeglądasz za pomocą journalctl, a nie docker logs. Usługa journald przetwarza te logi centralnie.

Aby wyświetlić logi konkretnego kontenera przy użyciu logów Dockera w journald, uruchom:

journalctl CONTAINER_NAME=<YOUR_CONTAINER_NAME> -o cat

Oczekiwany wynik:

Application started successfully

Krok 5: Weryfikacja

Aby zweryfikować konfigurację sterownika logowania Dockera na działającym kontenerze, uruchom kontener testowy:

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

Sprawdź opcje logowania kontenera:

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

Oczekiwany wynik dla sterownika local:

local

Jeśli skonfigurowano journald, wynikiem będzie journald.

Sprawdź zastosowane parametry sterownika local:

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

Oczekiwany wynik:

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

Potwierdza to, że Twoja konfiguracja logowania Dockera w daemon.json poprawnie zastosowała parametry max-size i max-file dla logów Dockera. Zwróć uwagę, że journald nie udostępnia tu opcji max-size ani max-file, ponieważ rotację przejmuje system operacyjny.

Użyj tego polecenia, aby wskazać istniejące kontenery, które nadal używają poprzedniego sterownika. Sterownik logowania jest ustalany w momencie tworzenia kontenera - te kontenery muszą zostać utworzone ponownie (np. za pomocą docker compose up -d --force-recreate), aby przejęły nową konfigurację:

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

Cofanie zmian

Aby przywrócić globalną konfigurację sterownika logów do formatu domyślnego, usuń konfigurację z daemon.json.

Usuń plik (przed modyfikacją zawsze wykonuj kopię zapasową plików konfiguracyjnych) i zrestartuj usługę Dockera:

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

Rozwiązywanie problemów

• journalctl nie zwraca wyników dla CONTAINER_ID: sterownik journald Dockera zapisuje w CONTAINER_ID krótki, 12-znakowy identyfikator, podczas gdy docker inspect zwraca pełny, 64-znakowy identyfikator. Użyj zamiast tego CONTAINER_NAME lub CONTAINER_ID_FULL.
• Istniejące kontenery nadal używają json-file po restarcie: polecenie docker update nie zmienia sterownika logowania. Aby zastosować nowy sterownik logowania, musisz ponownie utworzyć kontener (np. za pomocą docker compose down, a następnie up).
• max-size i max-file nie mają wpływu przy journald: rotacja logów dla journald jest zarządzana globalnie przez /etc/systemd/journald.conf (np. SystemMaxUse), a nie przez log-opts Dockera.

Podsumowanie

Właściwe zarządzanie wyjściem kontenerów to fundament niezawodnej infrastruktury. Dzięki trafnemu wyborowi między sterownikami json-file i local w Dockerze unikniesz problemów z miejscem na dysku. Niezależnie od tego, czy skonfigurujesz rotację logów Dockera za pomocą lekkiego lokalnego sterownika plikowego (local) Dockera, czy zintegrujesz się natywnie przez logowanie Dockera z journald, Twoje środowisko jest teraz przygotowane do bezpiecznej obsługi dużych strumieni logów. Stosowanie tych praktyk rotacji logów Dockera sprawia, że konfiguracja Twojego sterownika logowania Dockera pozostaje stabilna, a zasoby hosta przewidywalne.

Wersja dokumentu: 1.0
Ostatnia aktualizacja: maj 2026
Właściciel: Zespół dokumentacji technicznej