Adventure with Docker: Conflicts with UIDs of the container and the host
Arne Jul 16 '17
There are so days when you deal with problems you would never have expected.
We had the goal to operate an ElasticSearch Cluster in our Docker-Swarm. After some time, a finished image was found which makes this halfway possible (problematic is the discovery of other nodes, just as a hint).
To ensure that all containers in the ElasticSearch Clusters have all the data on the different Docker Swarm Nodes, we use GlusterFS as a distributed file system.
The whole construct was running very well, until we have noticed: Hey NTP is not running on our servers. Ok quickly thrown into the Ansible Playbook and run on the hosts. BAM! The ElasticSearch reports: I do not like you any more dude…
Now, of course, you wonder what happened here? A look at the hosts showed that now all the files of ElasticSearch belong to the user “systemd-timesync” .. eh? The first guess was, of course, the somewhat worn GlusterFS.
The actual error is in principle not an error. If you add a host volume to a container, all the files of the container are created with the user running inside the container. Normally many containers run with the user root, which causes no problems, but ElasticSearch after version 5.x does not run as root…
Now comes the chance in the game, the Image for the ElasticSearch is based on Alpine, here the users begin with the UID 100, unfortunately exactly the UID which has now used by our little friend the “systemd-timesync” user.
Unfortunately, a really good solution was not available for us, but as a Workaround, the Dockerfile was changed, and we assigned the ElasticSearch user a UID 1200+. Now the files are created with this UID.
If you find a more clever solution, I’m looking forward to a comment, and if you prefer this text in german, you can find it at the Geek Pub.