Docker - Enable Remote HTTP API with SystemD and “daemon.json”

Question

Disclaimer:

On a old machine with Ubuntu 14.04 with Upstart as init system I have enabled the HTTP API by defining DOCKER_OPTS on /etc/default/docker. It works.

$ docker version
Client:
 Version:      1.11.2
 (...)

Server:
 Version:      1.11.2
 (...)

---

Problem:

This does solution does not work on a recent machine with Ubuntu 16.04 with SystemD.

As stated on the top of the recent file installed /etc/default/docker:

# Docker Upstart and SysVinit configuration file

#
# THIS FILE DOES NOT APPLY TO SYSTEMD
#
#   Please see the documentation for "systemd drop-ins":
#   https://docs.docker.com/engine/articles/systemd/
#
(...)

As I checked this information on the Docker documentation page for SystemD I need to fill a daemon.json file but as stated on the reference there are some properties self-explanatory but others could be under-explained.

That being said, I'm looking for help to convert this:

DOCKER_OPTS="-H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock -G myuser --debug"

to the daemon.jsonobject?

---

Notes

PS1: I'm aware that the daemon.json have a debug: true as default.

PS2: Probably the group: "myuser" it will work like this or with an array of strings.

PS3: My main concern is to use SOCK and HTTP simultaneous.

---

EDIT (8/08/2017) After reading the accepted answer, check the @white_gecko answer for more input on the matter.

Answer 1

With a lot of fragmented documentation it was difficult to solve this.

My first solution was to create the daemon.json with

{
  "hosts": [
    "unix:///var/run/docker.sock",
    "tcp://127.0.0.1:2376"
  ]
}

This does not worked this error docker[5586]: unable to configure the Docker daemon with file /etc/docker/daemon.json after tried to restart the daemon with service docker restart. Note: There was more on the error that I failed to copy.

But what this error meant it at the start the daemon it a conflict with a flag and configurations on daemon.json.

When I looked into it with service docker status this it was the parent process: ExecStart=/usr/bin/docker daemon -H fd://.

What it was strange because is different with configurations on /etc/init.d/docker which I thought that were the service configurations. The strange part it was that the file on init.d does contain any reference to daemon argument neither -H fd://.

After some research and a lot of searches of the system directories, I find out these directory (with help on the discussion on this issue docker github issue #22339).

Solution

Edited the ExecStart from /lib/systemd/system/docker.service with this new value: /usr/bin/docker daemon

And created the /etc/docker/daemon.json with

{
  "hosts": [
    "fd://",
    "tcp://127.0.0.1:2376"
  ]
}

Finally restarted the service with service docker start and now I get the "green light" on service docker status.

Tested the new configurations with:

$ docker run hello-world

Hello from Docker!
(...)

And,

$ curl http://127.0.0.1:2376/v1.23/info
[JSON]

I hope that this will help someone with a similar problem as mine! :)

Answer 2

I had the same problem and actually in my eyes the easiest solution which should doesn't touch any existing files, which are managed by the system update process is, to use a systemd drop-in: Just create a file /etc/systemd/system/docker.service which overwrites the specific part of the service in /lib/systemd/system/docker.service.

In this case the content of /etc/systemd/system/docker.service would be:

[Service]
ExecStart=/usr/bin/dockerd --tlsverify --tlscacert=/etc/docker/ca.pem --tlscert=/etc/docker/server-cert.pem --tlskey=/etc/docker/server-key.pem -H=tcp://127.0.0.1:2375 -H=fd://

(You could even create a directory docker.service.d which contains multiple files to overwrite different parameters.)

After adding the file you just run:

$ sudo systemctl daemon-reload
$ sudo systemctl restart docker

Answer 3

The solution described at https://docs.docker.com/engine/admin/#troubleshoot-conflicts-between-the-daemonjson-and-startup-scripts works for me:

One notable example of a configuration conflict that is difficult to troubleshoot is when you want to specify a different daemon address from the default. Docker listens on a socket by default. On Debian and Ubuntu systems using systemd), this means that a -H flag is always used when starting dockerd. If you specify a hosts entry in the daemon.json, this causes a configuration conflict (as in the above message) and Docker fails to start.

To work around this problem, create a new file /etc/systemd/system/docker.service.d/docker.conf with the following contents, to remove the -H argument that is used when starting the daemon by default.

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd

Note that the line with ExecStart= is actually required, otherwise it'll fail with the error:

docker.service: Service has more than one ExecStart= setting, which is only allowed for Type=oneshot services. Refusing.

After creating the file you must run:

sudo systemctl daemon-reload
sudo systemctl restart docker

Answer 4

For me worked on Ubuntu 18.04.1 LTS and Docker 18.06.0-ce create /etc/systemd/system/docker.service.d/remote-api.conf with following content:

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock

then run sudo systemctl daemon-reload and sudo systemctl restart docker See result calling:

curl http://localhost:2376/info

You might need to configure proxy, if your docker is behind a proxy. To achiev this paste in /etc/default/docker file following:

http_proxy="http://85.22.53.71:8080/"
https_proxy="http://85.22.53.71:8080/"
HTTP_PROXY="http://85.22.53.71:8080/"
HTTPS_PROXY="http://85.22.53.71:8080/"
# below you can list some *.enterprise_domain.com as well
NO_PROXY="localhost,127.0.0.1,::1" 

Or Create /etc/systemd/system/docker.service.d/remote-api.conf with following content:

[Service]
Environment="HTTP_PROXY=http://<you_proxy_ip>:<port>"
Environment="HTTPS_PROXY=https://<you_proxy_ip>:<port>/"
Environment="NO_PROXY=localhost,127.0.0.1,::1"

I hope it helps someone...