Docker compose create containers without starting them

dockersystemd

My docker containers are build with docker-compose and I automatically start them container on my CentOS 7 system using derivatives from the documentation example::

[Unit]
Description=condb container
Requires=docker.service
After=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/docker start -a condb
ExecStop=/usr/bin/docker stop -t 2 condb

[Install]
WantedBy=local.target

Everything is working fine except for the fact that every time I want to change the container, I stop the services, run docker-compose up to create the container and then start the services, I forget that up already starts the containers.

I can adapt my script around this to stop the containers after running docker-compose, but starting/shutdown takes time and I wonder if there is a way to just create the container without starting it (the build command just builds, up does build-create-start according to its help)?

Best Answer

The sources for docker compose already have a create command, but it is not in 1.5.2 yet, nor documented on the website. You can of course try and install from the github source and get the latest (unreleased) features.

Alternatively you can try and change your systemd files to not start the individual containers using docker, but run docker-compose on the YAML files:

[Service]
Restart=always
ExecStart=/opt/util/docker-compose/bin/docker-compose -f /opt/docker/mongo/docker-compose.yml up --no-recreate
ExecStop=/opt/util/docker-compose/bin/docker-compose -f /opt/docker/mongo/docker-compose.yml stop

then you can just stop using systemctl stop ..., change the docker-compose.yml file, and start using systemctl start .... I am not sure though if the correct restarting is done in case one of the containers in the compose setup goes down.

Related Solutions

Linux – How to run systemd services in Arch Linux Docker container

I ran into the same problem testing my Ansible playbooks which require systemd. And as you said, docker seems like the best approach here as it is much easier to bring up and down a container rather than a virtual machine.
First of all base/archlinux image is deprecated - you should use archlinux/base instead. Then, to run systemd totally unprivileged, number of things should be done:

provide a container= variable, so systemd won't try to do number of things it usually does booting a hardware machine
systemd actively uses cgroups, so bind mount /sys/fs/cgroup file system from a host
bind mounting /sys/fs/fuse is not required but helps to avoid issues with fuse-dependent software
systemd thinks that using tmpfs everywhere is a good approach, but running unprivileged makes it impossible for it to mount tmpfs where ever it wants, so pre-mount tmpfs to /tmp, /run and /run/lock
as the last bit you need to specify sysinit.target as default unit to boot instead of multi-user.target or whatever, as you really do not want to start graphical things inside a container

The resulting command line is

docker run \
  --entrypoint=/usr/lib/systemd/systemd \
  --env container=docker \
  --mount type=bind,source=/sys/fs/cgroup,target=/sys/fs/cgroup \
  --mount type=bind,source=/sys/fs/fuse,target=/sys/fs/fuse \
  --mount type=tmpfs,destination=/tmp \
  --mount type=tmpfs,destination=/run \
  --mount type=tmpfs,destination=/run/lock \
    archlinux/base --log-level=info --unit=sysinit.target

If we are talking about running particular service there like ntpd from your example you will need to add

--cap-add=SYS_TIME

otherwise ntpd will fail with permission deny as nobody wants a container to set system time by default.

P.s I spent quite a while learning how systemd behaves and managed to get it working on number of operating system images. I described my experience in an article Running systemd in docker container. It is in Russian but I believe google translate should work in your browser. Thanks

Why is systemd stopping service immediately after it is started

Environment="USER=ubuntu" "Path=/home/ubuntu/console/bin" 
WorkingDirectory=/home/ubuntu/console/bin
ExecStart=/bin/sh -ec "exec /sbin/start-stop-daemon -S -c ${USER} -d ${Path} --pidfile=/var/run/console.pid --oknodo  --exec consoleExecutable " #2>/dev/null
ExecStop=/bin/sh -ec "exec /sbin/start-stop-daemon -K --quiet -c ${USER} -d ${Path} --pidfile=/var/run/console.pid  --retry=TERM/30/KILL/5 --oknodo --exec consoleExecutable" #2>/dev/null

This is almost worthy of the systemd House of Horror. Were it not the case that there's a horror story already in there that does this.

Do not use start-stop-daemon in a service unit to do all of the things that a service unit already does. With unnecessary PID files and the wrongheaded assumption that ExecStart accepts shell syntax comments, no less.

And do not do what the other answer says and try to bodge it with Type=forking. That makes things worse, not better.

The nonsense with start-stop-daemon is why things are going wrong. Because the process running start-stop-daemon does not become the service, but in fact exits pretty much imediately, systemd is thinking that your service is terminating. In your first systemctl status output, you can see that systemd is in the middle of sending SIGTERM to clean up all left-over running processes after running the ExecStop action, which is what it does when it thinks that a service has terminated.

Just do things simply:

Type=simple
WorkingDirectory=/home/ubuntu/console/bin
User=ubuntu
ExecStart=/home/ubuntu/console/bin/consoleExecutable

No ExecStop nor Environment is actually required.

Best Answer

Related Solutions

Linux – How to run systemd services in Arch Linux Docker container

Why is systemd stopping service immediately after it is started

Further reading

Related Question