Abenteuer mit Docker: Konflikte mit UIDs des Containers und dem Host

By | 15. Juli 2017

Es gibt so Tage, da beschäftigt man sich mit Problemen welche man nie erwartet hättet. Wir hatten uns das Ziel gesetzt in unserem Docker-Swarm auch einen ElasticSearch Cluster zu betreiben. Nach einiger Zeit wurde auch ein fertiges Image gefunden welches das halbwegs ermöglicht (problematisch ist das Discovery der anderen Nodes, nur so als Hinweis). Damit alle Container des ElasticSearch Clusters auch immer alle Daten auf den unterschiedlichen Docker Swarm Nodes haben, nutzen wir GlusterFS als verteiltes Dateisystem.

Das ganze lief auch wirklich sehr gut, bis wir bemerkt haben: Hey NTP läuft ja nicht auf den Servern. Ok schnell in das Ansible Playbook geworfen und über die Hosts laufen lassen. BAM! Die ElasticSearch vermeldet: Ich mag euch jetzt nicht mehr…

Nun fragt man sich natürlich, was ist hier passiert? Ein Blick auf die Hosts zeigte das nun alle Dateien der ElasticSearch dem Benutzer „systemd-timesync“ gehören.. eh? Die erste Vermutung war natürlich das etwas abgefahrene GlusterFS.. Fehlanzeige. Der eigentliche Fehler ist im Prinzip keiner. Mounted man sich ein Host-Volume in seinen Container werden die Dateien des Containers mit dem Benutzer angelegt welcher im Container läuft, normalerweise laufen viele Container mit dem Benutzer root, was dann keine Probleme verursacht, nur ElasticSearch läuft ab Version 5.x nicht mehr als root. Nun kommt der Zufall in’s Spiel, dass Image für die ElasticSearch basiert auf Alpine, hier beginnen die Benutzer mit der UID 100, leider genau die UID welche jetzt unser kleiner Freund der „systemd-timesync“ Benutzer bekommen hat.

Eine richtig elegante Lösung gab es bisher für uns leider nicht, als Workaround wurde das Dockerfile geändert, und dem ElasticSearch Benutzer eine UID 1200+ verpasst – dann gibt es keinen Konflikt mehr.

Falls dir da eine schlauere Lösung einfällt, freue mich auf ein Kommentar.