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

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!