Systemd service config clashes with daemon.json

[eightiescalling]

Hi.

There may not be a simple answer to this or (as I suspect) it may be unavailable based on package setup but…

I’ve been using whatsupdocker to track container versions across multiple hosts with the TCP connectivity. That works with the hosts option in daemon.json:

  "hosts": ["unix:///var/run/docker.sock", "tcp://127.0.0.1:2375", "tcp://1.2.3.4:2375"]

However Docker then doesn’t play nicely with systemd saying that conflicts with the -H parameter that’s part of the base config:

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H fd: --containerd=/run/containerd/containerd.sock
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutStartSec=0
RestartSec=2
Restart=always

It’s easy enough to workaround by editing the systemd service file to remove the -H however every time there is an update to the docker engine, the systemd service file gets restored and docker is broken until I go and re-edit it.

For what it’s worth, the behaviour is consistent across multiple Debian based distros - Linux Mint, Ubuntu Server and Raspberry Pi OS.

Is there an alternative approach I should use/could use here?

Thank you!

[meyay (Metin Y.)]

As you already figured out: you can either configure it through the systemd unit or the daemon,json:

@<https://docs.docker.com/reference/cli/dockerd/#daemon-configuration-file>

Note

You can’t set options in daemon.json that have already been set on daemon startup as a flag. On systems that use systemd to start the Docker daemon, -H is already set, so you can’t use the hosts key in daemon.json to add listening addresses. See custom Docker daemon options for an example on how to configure the daemon using systemd drop-in files.

Note: make sure you do not specify a public ip in your hosts like (I feel bind-socket would be a more appropriate name for this configuration element), unless you configure https://docs.docker.com/engine/security/protect-access/#use-tls-https-to-protect-the-docker-daemon-socket.

You might want to check if docker context over ssh isn’t a more suited and secure solution in your case.

[eightiescalling]

The systemd section of that link was interesting, thank you, but I couldn’t see a way to provide a list via a drop-in file. Although I suspect that would give a similar headache as the dockerd commandline from systemd would still be saying file but environment variables saying otherwise.

Whatsupdocker doesn’t (as far as I can tell) support the docker context approach suggested but from a bit more digging I did find an alternative using docker-socket-proxy which seems to facilitate the same connection on a Debian package systemd config through a layer of abstraction - with the added bonus of additional security and access limits. I’ll leave that running on the “dev” box for a while and see how it goes.

(And no, there are no relevant ports exposed on public IPs - dare I ask what crazy person would do that?)

[meyay (Metin Y.)]

The docker-socket-proxy is basically a reverse proxy for the unix domain socket, which allows filtering access to specific resource endpoints. If you lock it down to the required endpoints, It is definitely better than binding a listener on the host ip for the docker daemon.