Running docker-compose as a systemd service

README.md

Running docker-compose as a systemd service

Files

File	Purpose
/etc/compose/docker-compose.yml	Compose file describing what to deploy
/etc/systemd/system/docker-compose-reload.service	Executing unit to trigger reload on docker-compose.service
/etc/systemd/system/docker-compose-reload.timer	Timer unit to plan the reloads
/etc/systemd/system/docker-compose.service	Service unit to start and manage docker compose

Installation

Put the above mentioned files in the corresponding places and let systemd load them:

# systemctl daemon-reload
# systemctl enable --now docker-compose.service docker-compose-reload.timer

Ansible role

The method shown here is also available as an Ansible role here: luzifer-ansible/docker-compose

docker-compose-reload.service

[Unit]
Description=Refresh images and update containers

[Service]
Type=oneshot

ExecStart=/bin/systemctl reload-or-restart docker-compose.service

docker-compose-reload.timer

[Unit]
Description=Refresh images and update containers
Requires=docker-compose.service
After=docker-compose.service

[Timer]
OnCalendar=*:0/15

[Install]
WantedBy=timers.target

docker-compose.service

[Unit]
Description=Docker Compose container starter
After=docker.service network-online.target
Requires=docker.service network-online.target

[Service]
WorkingDirectory=/etc/compose
Type=oneshot
RemainAfterExit=yes

ExecStartPre=-/usr/local/bin/docker-compose pull --quiet
ExecStart=/usr/local/bin/docker-compose up -d

ExecStop=/usr/local/bin/docker-compose down

ExecReload=/usr/local/bin/docker-compose pull --quiet
ExecReload=/usr/local/bin/docker-compose up -d

[Install]
WantedBy=multi-user.target

@EugenMayer no, there were no considerations about using up & down instead of up & stop… One thing I'm asking myself: The documentation of stop talks about the containers will be re-startable using start: will up start them also?

If so, in the most cases stop will definitely the better solution than down especially as this is intended to be a solution for long-running containers / container orchestration in opposite to a pure development approach.

The only reason for down would be to have a clean system set up on boot instead of reviving the old state but I'm currently not able to imagine why someone wants to do this…

Anyway, thanks for this comment! I'm going to modify my ansible-role mentioned above to be configurable which command to use and test the changes from there for my usecases… That way both factions are able to use their preferred solution.

Note: there is one quirk with that pattern that has been a problem for me: if the ExecStartPre command fails, then the service is failed forever and will never start (Restart= is not supported on oneshot services, see systemd/systemd#2582).
I don't have a convincing alternative to offer though, maybe changing reload into reload-or-restart in the timer, at least it would be restarted periodically if it fails.

@Ricordel you're right, this leads to broken deployments in case for example the registry is not available (had exactly that case this morning). I've made two changes to this Gist and also to the Ansible role:

• Used reload-or-restart as you suggested
• Made the docker-compose pull call non-mandantory

That way the start will not fail over the pull (it might start slightly older images but hey, better not the recent image than no container, right?) and ensure the service is started…

Please raise the contents of docker-compose.service above the other two

or

Thank you. The first time I ran the last command, to start the services, I got this error:
sudo systemctl start docker-compose docker-compose-reload
docker-compose.service is not active, cannot reload.
Job for docker-compose-reload.service failed because the control process exited with error code.
See "systemctl status docker-compose-reload.service" and "journalctl -xe" for details.

Then I found out that docker-compose perfectly started. Then again I ran just the reload-service
sudo systemctl start docker-compose-reload

And it runs perfectly.

@GoSpursGoNL I've updated the README above. This should work better as the previous version started the docker-compose-reload.service instead as intended the docker-compose-reload.timer.

Thanks, looks good. Will the timer also pull image updates (so update software to newer versions)? I prefer to do that manually since some applcations that I use can be unstable until they provide a bugfix release. Should I disable the timer?

If you don't want automated updates you can either pin the specific image (image: alpine:3.9), then only that specific tag will be used (that's the way I'm using for unstable software) or you can disable the timer which does not fully save you from updates as docker-compose itself has update-checks built in and even though local versions are preferred there might be updates.

The most safe way to guarantee nothing changes is to use sha-pinning:
image: sha256:965ea09ff2ebd2b9eeec88cd822ce156f6674c7e99be082c7efac3c62f3ff652

(Though the last method is possible I wouldn't use it as then even security updates for the tag are no longer possible.)

I think I found a typo, ExecStartPre=-/usr/local/bin/docker-compose pull --quiet
should be this ExecStartPre=/usr/local/bin/docker-compose pull --quiet
shouldn't it?

@leeramsay Nah that's intentional. The - in front of the command tells systemd not to panic if the command exits non-zero (see systemd.service(5))… If an image cannot be pulled because of some registry had trouble that's okay at that point. The image will be updated later if it's already present on the machine. If not the next step will then cause an error…

Okie doke, thanks for the info!