Zeiteinstellungen in Docker

25.08.2018

Wer nicht extra darauf achtet, findet sich meistens in Containern wieder, in denen die Zeiteinstellung nicht stimmt. 

Typischerweise fragen die Installer der gängigen Linux-Distributionen im Lauf der Installation die Zeitzone ab und machen dabei meistens sogar die richtigen Vorschläge. Anders bei Containern: Da die zugrunde liegenden Images meistens von irgendjemanden auf irgendeinem anderen Kontinent gebaut wurde, kann man nicht davon ausgehen, dass die Zeiteinstellungen automatisch stimmen. Und die meisten Anwender achten vermutlich auch nicht darauf - bis eventuell etwas nicht funktioniert oder ein Eintrag in einer Logdatei nicht auffindbar ist, weil die Uhr einige Stunden nachgeht, wie ein Vergleich von Host und Container beweist:

$ date
Mo 27. Aug 09:51:05 CEST 2018
$ docker run -ti --rm ubuntu:18.04 date
Mon Aug 27 07:51:08 UTC 2018

Im Prinzip gibt es hierzu nicht viel zu sagen, außer, dass man bei Containern die richtige Zeitzone einstellen sollte, wenn man die korrekte Zeit angezeigt bekommen möchte. Allerdings ist das nicht so einfach, wie man sich vielleicht denken würde, wenn man eine normale Linux-Distribution gewohnt ist, weil oft die nötigen Tools oder Dateien gar nicht installiert sind. Ansonsten muss man die jeweilige Vorgehensweise der Distribution (und natürlich Version!) beachten, die einem Image zugrunde liegt.

Unter Ubuntu/Debian sind dafür die beiden Dateien respektive Symlinks "/etc/timezone" und "/etc/localtime" nötig. Fragt mich nicht, was der Unterschied ist und wofür die beiden jeweils gut sind. Ich werde der Einfachheit beide ändern, statt Stunden für die nötige Recherche zu verschwenden ... Moderne Ubuntu-Systeme bringen für die Einstellung der Zeitzone ein Tool namens "timedatectl" mit, das sich aber in einem Container nicht verwenden lässt, weil bekanntlich ein Container kein komplettes OS ist, aber "timedatectl" einen laufenden D-Bus benötigt – ein weiteres Beispiel für den Mismatch zweckentfremdeter Linux-Distributionen als Basis von Containern...

Natürlich kann man auch leicht in die Datei "/etc/timezone" die passende Zeitzone eintragen und den entsprechenden Symlink zu "/etc/localtime" anlegen. Typischweise wird es mit letzterem aber nichts, weil die Timezones gar nicht installiert sind. Also muss zuerst das Paket "tzdata" installiert werden. Dann die Konfiguration:

cat "Europe/Berlin" > /etc/timezone
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime

Diese Schritte muss man natürlich sinnvollerweise (außer zum Testen) nicht auf einen laufenden Container anwenden, sondern beim Erstellen eines Images in das Dockerfile schreiben. Wie praktisch wäre es hier, wenn das Dockerfile einen Mechanismus zur Vererbung oder wenigstens zum Einbinden anderer Dateien oder Templates besäße ... Als Krücke ist es natürlich möglich, seine Image-Konfiguration in anderen Textdateien zu schreiben, die solchen Luxus bieten, und am Ende eines selbstgestrickten Build-Prozesses daraus erst die Dockerfiles zu generieren. 

Möglich ist es auch, die beiden oben geänderten Dateien per Bind-Mount in jeden laufenden Container einzubinden, aber das setzt voraus, dass Host und Container hinsichtlich des Betriebssystem so ähnlich sind, dass dies funktioniert. Eigentlich sollte jedes im Docker Hub bereitgestellte Image eine Möglichkeit besitzen, zur Laufzeit die Zeitzone zu übergeben. Möglich wäre etwa eine Umgebungsvariable, die aber dann das im Image enthaltene Startup-Skript auch (einmalig) auswerten müsste. Dies ist nur eine von vielen Unzulänglichkeiten, die noch zu lösen sind, damit Images von der Stange für eine breite Masse von Anwendern nützlich sein können.

Eine Zeitsynchronisierung des Docker-Containers per NTP ist übrigens weder nötig noch ohne Nebenwirkungen möglich. Die zugrundeliegende Clock gehört letztlich dem Container-Host und wenn auf diesem die Zeit stimmt, dann passt sie auch im Container. Wer in einem mit den entsprechenden Privilegien ausgestatteten Container ("--cap-add SYS_TIME") die Zeit ändert, tut dies letzten Endes auf dem darunterliegenden Host. Die gilt aber, wie gezeigt, nicht für die Zeitzone. 

comments powered by Disqus

Artikel der Woche

Loadtests ohne Server

Für Loadtests der eigenen Server bietet sich die Cloud an, denn kurz getaktet lassen sich dort viele Rechnerinstanzen starten, die das eigene Budget nur wenig belasten. Noch flexibler, günstiger und besser skalierbar sind Tests mit einer Serverless-Infrastruktur wie AWS Lambda. Wir führen vor, wie Sie dort mit Serverless Artillery eigene Loadtests starten. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite