Add doker-compose as a systemd unit

README.md

Docker compose as a systemd unit

Create file /etc/systemd/system/docker-compose@.service. SystemD calling binaries using an absolute path. In my case is prefixed by /usr/local/bin, you should use paths specific for your environment.

[Unit]
Description=%i service with docker compose
PartOf=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=true
WorkingDirectory=/etc/docker/compose/%i
ExecStart=/usr/local/bin/docker-compose up -d --remove-orphans
ExecStop=/usr/local/bin/docker-compose down

[Install]
WantedBy=multi-user.target

Place your docker-compose.yml into /etc/docker/compose/myservice and call

systemctl start docker-compose@myservice

Docker cleanup timer with system

Create /etc/systemd/system/docker-cleanup.timer with this content:

[Unit]
Description=Docker cleanup timer

[Timer]
OnUnitInactiveSec=12h

[Install]
WantedBy=timers.target

And service file /etc/systemd/system/docker-cleanup.service:

[Unit]
Description=Docker cleanup
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
WorkingDirectory=/tmp
User=root
Group=root
ExecStart=/usr/bin/docker system prune -af

[Install]
WantedBy=multi-user.target

run systemctl enable docker-cleanup.timer for enabling the timer

JournalD support

Just add the following line to the /etc/docker/daemon.json:

{
    ...
    "log-driver": "journald",
    ...
}

And restart your docker service.

@dcd-arnold It's simple, at the time of writing this note, the docker daemon storage all container logs in plain JSON files in the /var/lib/docker, which quite often grew to a rather indecent size if you do not does something for control them separately. Now the question is, why do you have to monitor this separately if there is already a daemon in the operating system that can effectively read/write/compress/sign structured log records? Thus, transferring responsibility for all logs to the JournalD level allows them to be efficiently stored, rotated, and read using journalctl filters (e.g. CONTAINER_ID or CONTAINER_NAME).

@so-jelly fixed thank you.

It's simple, at the time of writing this note, the docker daemon storage all container logs in plain JSON files in the /var/lib/docker, which quite often grew to a rather indecent size if you do not does something for control them separately. Now the question is, why do you have to monitor this separately if there is already a daemon in the operating system that can effectively read/write/compress/sign structured log records? Thus, transferring responsibility for all logs to the JournalD level allows them to be efficiently stored, rotated, and read using journalctl filters (e.g. CONTAINER_ID or CONTAINER_NAME).

@mosquito But docker-compose would not run in background, hence pushing its stdout to systemd, which is build to take such data in and store it. What am i missing here?

@dcd-arnold but /usr/local/bin/docker-compose up -d ... in the ExecStart=

@mosquito That was the original question:

Would it be better to remove -d after docker-compose up so logs get saved by systemctl?

If you omit -d, docker-compose pushes its stdout to systemd to do with it as it sees fit.

@dcd-arnold if you omit something from this recipe, you have to resolve following troubles :-).

@mosquito @dcd-arnold if you omit something from this recipe, you have to resolve following troubles :-).

sure thing.

@dcd-arnold moreover, having docker-compose printing logs on stdout doesn't stop Docker daemon from saving logs. So you would end up using twice as much space -- once in Docker daemon and once in systemd -- as required for your logs