I want to deploy docker on a server, but I want all docker-related data to be in a separate partition from the base system. I have thus mounted said partition at '/srv' and made the following changes, according to the official documentation:
This is my '/usr/lib/systemd/system/docker.service' file:
[Unit]
Description=Docker Application Container Engine
Documentation=http://docs.docker.com
After=network.target docker.socket
Requires=docker.socket
[Service]
Type=notify
EnvironmentFile=-/srv/docker/docker.conf
ExecStart=/usr/bin/docker -d -H fd:// $OPTIONS
LimitNOFILE=1048576
LimitNPROC=1048576
[Install]
Also=docker.socket
WantedBy=multi-user.target
This is the '/srv/docker/docker.conf' file that is referenced inside the 'docker.service' file:
$OPTIONS="--graph /srv/docker --storage btrfs"
The docker daemon starts correctly and also PULLs images. The problem is that it still does not store anything inside the '/srv/docker' directory.
Also, when I run 'ps -aux | grep docker', what I get is this:
root 661 0.4 0.2 351080 17044 ? Ssl 19:33 0:00 /usr/bin/docker -d -H fd://
The command line stops at 'fd://'. It seems to me that '$OPTIONS' is being overlooked for one reason or another.
Now, is there a problem with the way I reference the files? Is there something else going on here? The reason I am doing all these configuration changes is that I would really like to keep all docker related data under the '/srv/docker/' directory.
Any ideas?
UPDATE 1:
I changed my 'docker.conf' file, as suggested in the answers section. Now:
$OPTIONS="--graph /srv/docker --storage btrfs"
became:
OPTIONS="--graph /srv/docker --storage btrfs"
This had the (unexpected) consequence of the docker daemon not starting. This is the debug message from 'systemctl status docker':
[root@V12 ~]# systemctl status docker ● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Thu 2015-02-05 20:13:31 EET; 14s ago Docs: http://docs.docker.com Process: 776 ExecStart=/usr/bin/docker -d -H fd:// $OPTIONS (code=exited, status=2) Main PID: 776 (code=exited, status=2)
You have an error in your
/srv/docker/docker.conf
file.The specification of a variable should not start with a $; the $ should only be used when using the variable later.
Change it to:
First off I want to thank @MichaelHampton for his answer. It was spot on, and I would have never spotted the typo with the '$' ('OPTIONS=...' instead of '$OPTIONS=...').
Now, the problem was with the command line options. In the docker documentation the argument for changing the storage driver is given as:
Keep in mind that this is the docs for version 1.4, which is the version I have. Alas, the correct syntax, as evidenced by 'docker --help' is:
So, after making the necessary change, the daemon starts correctly, the images are PULL-ed inside the '/srv/docker' directory, and everything is fine.
The moral is to always be a little mistrustful of official documentations, especially for projects under heavy development, like Docker. Again thanks to all for their contributions.
Initially I spent quite a bit of time fiddling with the previous upstart/sysv initscript from
/etc/init.d/docker
and its configuration file/etc/default/docker
. It was really strange that it just didn't work no matter what I tried, then eventually I realized thatsystemd
just ignores both of those, since I was using the legacy script directly.The proposed solution doesn't seem to work 100% on my 15.04 with
lxc-docker-1.7.0
installed from the official docker PPA, since theEnvironmentFile
seems to be missing from mydocker
'ssystemd
configuration file.An option would be to edit it in-place and add it using this command:
But this risks to be overridden by the next update, so my solution was to instead create an override, by running
Then I decided to just redefine the
ExecStart
command in the new configuration override, instead of also adding and referencing a new configuration file under/srv/docker/docker.conf
.There's no error in the snippet above, for some strange reason that has to do with the way
systemd
reads its configuration overrides, a value needs to be first defined with an empty value, then reassigned to the new value.Once I did this the daemon started happily and I was finally able to use it.