How to make systemd run containers via docker-compose?

Question

linux

Given:
CoreOS Linux 4.7.0 v1122.2.0 Stable
Docker version 1.10.3, build 1f8f545
docker-compose version 1.7.1, build 0a9ab35
The essence of the problem:
There are several groups of containers, let's call from PR1 and PR2 there is a ststemd service that runs bash in which docker-compose commands are written. If the project does not have data volume containers PR1, the service works and everything is fine, I can start or stop the service. But as soon as the second PR2 project is added in which there is a container with data, I get an exit-code at the output, after which all containers are extinguished, although Exit 0 does not mean that the data has not been mapped, the container works.
I read in the CoreOS documentation that containers are launched with the docker run command ... but this method of launch is not suitable, there are a lot of containers, and there is no desire to push each one into the service. Docker-compose contains all the parameters for the operation of containers, networks, and so on.
In general, the task was to start the containers themselves when the machine was restarted, but since everything was cut out in CoreOS, including cron, I did not figure out how to do this except for writing a systemd service .

● docker-project.service - Docker containers start
   Loaded: loaded (/etc/systemd/system/docker-project.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2016-10-20 14:02:18 UTC; 5min ago
   Process: 4941 ExecStop=/home/coreos/docker-stop.sh (code=exited, status=0/SUCCESS)
   Process: 805 ExecStart=/home/coreos/docker-up.sh (code=exited, status=1/FAILURE)
   Main PID: 805 (code=exited, status=1/FAILURE)

All listings are below:

PR1
Name  Command  State       Ports
-------------------------------------------------------
rp_nginx_web_1  nginx -g daemon off;  Up  443/tcp, 80/tcp
rp_php_1        php-fpm               Up  9000/tcp

PR2
Name  Command  State       Ports
-------------------------------------------------------
rps_app_1           sh        Up          9000/tcp
rps_code_source_1   true     Exit 0

systemd config

[Unit]
Description=Docker containers start
Requires=docker-project.service
After=docker-project.service

[Service]
ExecStart=/home/coreos/docker-up.sh
ExecStop=/home/coreos/docker-stop.sh

[Install]
WantedBy=multi-user.target

Contents of the docker-up.sh script

#!/bin/bash
/opt/bin/docker-compose -f /home/coreos/PR1/docker-compose.yml up --no-recreate --no-build
/opt/bin/docker-compose -f /home/coreos/PR2/docker-compose.yml up --no-recreate --no-build

Thanks to everyone who will take part in solving the problem.

Answer 1

1. In order for the containers to start themselves when the machine is restarted, you just need to make the corresponding systemd service enabled. Cron is not needed here.
2. Any systemd service is just an abstraction. And what exactly he does - it's up to you. What you ExecStartwill start one container through docker run, what a bunch of containers through docker-compose up, there is no fundamental difference for systemd and CoreOS.
3. In the systemd service declaration you provided, the section [Unit]contains the following lines:

Requires=docker-project.service
After=docker-project.service

They mean that the service you declare should only be started after the docker-project.service. But, as far as I understand from your description, this is the declaration docker-project.service. That is, you tell systemd that the service should be started after starting itself. This is not gud. These lines should look like this:

Requires=docker.service
After=docker.service

In order for systemd to try to start this service only after the Docker daemon is started.
4. In docker-up.shthe file you docker-compose uprun in foreground'e. The first bunch of containers will then start, but what about the second one is not clear. Probably, it was still worth launching them with a -dkey, and [Service]specify in the systemd declaration in the section Type=forkingif it is necessary to run both bundles of containers with one systemd service. But in general, IMHO, each docker-compose.ymlshould have its own separate systemd service, and no forking.
Also, wrapping docker-composecommands inside docker-up.shwas not a good idea. Nothing stopped you from writing a few ExecStart's in a row, thereby not spreading the declaration over several files, and it would be clear at which step it falls off when systemctl start docker-project.service.
5. Logs are our everything. Use journalctl --unit=docker-project.serviceit to see what happened there at all, and who swears at whom.
In conclusion:
In general, to be honest, you can see the complete profanity on your part on this issue. This is normal, because it is impossible to know all the technologies and tools, and you constantly have to learn something. What is not normal is that nothing prevents you from looking into the official documentation for the same systemd. 20-30 minutes of reading at least this page , and there would simply be no such misunderstanding.
Please don't be lazy, take some time and read the docs. Systemd can do a lot more that can help you solve your problems, and give you an understanding of what, where, and how.
Thought:
Since you are using CoreOS, look towards Kubernetes to run services/containers. It is put on CoreOS in half a turn, and there are much more opportunities, flexibility and tasty abstractions than systemd/fleet.

Answer 2

But docker itself knows how to restart containers. Docker-compose.yml simply adds restart: always for each service. Keywords to search for "docker restart policy"