Use Docker Compose rather than Docker Swarm

Consider switching from Docker Swarm to Docker Compose.

Currently, the applications this deployer manages are deployed using Ansible. Ansible runs docker stack create to define the stack based on the YAML description. Subsequently, ocurrent-deployer will update the running instance using docker service update --image <new-sha>. The YAML description can be trivially refactored into a docker-compose.yml file, which can be stored in the Git repository along with the service.

• Docker Swarm gives us a headache with respect to IPv6. Entry point services need to be defined with host networking to listen on IPv6.
• All services are deployed as a single instance to a single host where Swarm's magic networking sauce isn't relevant.
• Docker Swarm gives us access to Docker secrets. Docker secrets are encrypted on disk and held on a tmpfs volume within the container. They can easily be accessed via docker exec <container_id> cat /run/secrets/mysecret. With Docker Compose, secrets are typically held in plain text files. Alternatives would be a vault sidecar.
• Both Swarm and Compose automatically start the services on reboot.
• docker compose pull && docker compose up -d updates all images within the compose file. With docker service update, we specifically update the OCaml service we just rebuilt: new releases of other components, such as the Caddy proxy, are not managed.

Start by tracing the Ansible deployment flow around docker stack create and the docker service update --image call. Compare the existing YAML description with the proposed docker-compose.yml approach, including IPv6, secret handling, reboot behavior, and updating all images. Done means the deployment path uses Compose without losing the required operational behavior.