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 |
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
The method shown here is also available as an Ansible role here: luzifer-ansible/docker-compose
@EugenMayer no, there were no considerations about using
up & down
instead ofup & stop
… One thing I'm asking myself: The documentation ofstop
talks about the containers will be re-startable usingstart
: willup
start them also?If so, in the most cases
stop
will definitely the better solution thandown
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.