☰

Wie konfiguriere ich die Protokollierung in einem Docker-Container?

tag-icon • tag-icon debian syslog docker rsyslog container
Wie konfiguriere ich die Protokollierung in einem Docker-Container?

Ich habe versucht, einen OpenVPN-Server zu dockerisieren (in Debian 8.2) (ja, ich weiß, es gibt bereits solche Container), aber im Container ist etwas schiefgelaufen und der Server konnte nicht gestartet werden.

Ich habe beschlossen, die Protokolle zu überprüfen, aber /var/log/syslog(OpenVPN-Protokolle hier auf meinem Hostcomputer) fehlten im Container.

Ich dachte, das rsyslogsei nicht installiert und habe die Installation vor der OpenVPN-Installation zum Dockerfile hinzugefügt. Aber das hatte keinen Effekt, das syslogfehlte immer noch.

Mein Dockerfile ist:

FROM debian:8.2
USER root
EXPOSE 53/udp
EXPOSE 1194/udp
EXPOSE 443/tcp
RUN apt-get update
RUN apt-get install -y rsyslog
RUN apt-get install -y openvpn
# ...
# Some configuration stuff
# ...
ENTRYPOINT service openvpn start && sh

Die Fragen sind:

  • Warum loggt sich OpenVPN syslognach der Standardinstallation auf meinem Host Debian 8.2 bei ein und nicht innerhalb eines Containers? Ich habe auf meinem Hostcomputer nichts konfiguriert, um OpenVPN zum Loggen bei zu zwingen syslog. Das war ein Standardverhalten.

  • Wie konfiguriere ich die Protokollierung des OpenVPN-Servers, der in einem Docker-Container ausgeführt wird?

Antwort1

OpenVPN würde mit diesem Dockerfile nicht starten, da es nichts gibt, um es zu starten :-). Ihr Einstiegspunkt ist sh; das ist alles, was ausgeführt wird.

Wenn Sie zwei Daemons in Docker starten möchten, muss Ihr Einstiegspunkt ein Programm sein, das beide startet. Viele Leute verwenden supervisorddafür. Beachten Sie, dass Docker eine relativ eigenwillige Software ist und das Ausführen mehrerer Daemons in einem Container nicht als idiomatisch gilt.

Wenn es nur ums Debuggen geht, gibt es kein Problem. Führen Sie es einfach nicht openvpnmit --daemonoder --logaus. Es wird in stdout geschrieben (angeblich, obwohl es mich nicht überraschen würde, stderr zu sehen). Dies ist ideal zum Debuggen, wenn Sie es manuell starten. Sie sehen alle Protokollmeldungen sofort im Terminal.

Wenn Sie den Einstiegspunkt einrichten und den Container manuell im interaktiven Modus starten, ist das gleiche Problem. Wenn Sie ihn als Hintergrundcontainer starten (entschuldigen Sie meine Ungenauigkeit), wird die Ausgabe für erfasst docker logs. Es ist dieselbe Technik, die von modernen Init-Systemen wie systemd (und dem systemd-Protokollierungssystem „Journal“) bevorzugt wird.

Nachdem Sie den Daemon nach Wunsch eingerichtet haben, sind Sie möglicherweise an individuelleren Systemen zum Erfassen von Protokollen interessiert, wie in den anderen Antworten.

Docker verfügt laut Manpage für über steckbare Protokollierungstreiber docker logs. Es gibt einen „Syslog“-Treiber, der angibt, dass er in das Host-Syslog schreibt. Da steht, docker logsdass es nicht funktioniert, aber ich glaube nicht, dass das für Sie ein Problem darstellt.

WARNUNG: docker logsfunktioniert, wenn Sie den Journald-Protokollierungstreiber verwenden. Ich gehe jedoch davon aus, dass dies bei den Debian-Standardeinstellungen dazu führen würde, dass Protokolle beim Neustart verloren gehen. Weil Debian kein persistentes Journal einrichtet. Es ist jedoch nicht schwer, dies zu ändern, wenn Sie das möchten.

Der andere Protokollierungstreiber, der den docker logsBefehl unterstützt, heißt „json-file“. Ich gehe davon aus, dass dieser dauerhaft ist, aber Sie bevorzugen möglicherweise eine der anderen Lösungen.

Die Frage nach dem „Warum“

Der Punkt ist, dass Docker-Container nicht unbedingt genauso funktionieren wie das Betriebssystem, auf dem sie basieren. Docker ist keine Betriebssystemvirtualisierung wie LXC, systemd-nspawn, oder eine virtuelle Maschine. Obwohl Docker von abgeleitet wurde LXC, wurde es speziell für „Anwendungscontainer“ entwickelt, die ein einzelnes Programm ausführen.

(Aktuelle) Serverdistributionen sind als Kombination mehrerer laufender Programme konzipiert. Man kann also nicht einfach ein Paket daraus nehmen und erwarten, dass es sich innerhalb eines dieser Anwendungscontainer genauso verhält.

Die Kommunikation mit einem Logging-Daemon ist ein gutes Beispiel. Daran wird sich nichts ändern, außer dass die Leute mit dem Konzept von Anwendungscontainern vertrauter werden. Und ob sie das wirklich verwenden wollen :). Ich vermute, dass viele Systemadministratoren mehr an einem Mashup von LXC (OS-Containern) mit etwas wie NixOS zum Teilen von Paketen zwischen Containern interessiert wären; es wurde meines Wissens nur noch nicht geschrieben. Oder einfach einbesser LXC.

verwandte Informationen