Use Docker Compose rather than Docker Swarm

[mtelvers]

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.

[talex5]

What's the advantage? Using host networking seems reasonable (should probably be doing that anyway).

[mtelvers]

The primary advantage is that the configuration of the service/application sits within the application repository rather than in a configuration repository. The docker-compose.yml file can be used (as a template) for local testing.

Side benefits are that ocurrent-deployer can deploy an application to a new machine without a stack deployment step and that the third-party images are updated when the service is updated.

Also a PR that updates the command line would also be able to update the parameters in the docker-compose.yml file at the same time. Currently, a command line change needs manual intervention to recreate the stack with the new command line.

[talex5]

The primary advantage is that the configuration of the service/application sits within the application repository rather than in a configuration repository.

That's already the case with some services (e.g. ocaml-ci has a stack.yml). That doesn't require compose.

and that the third-party images are updated when the service is updated.

I think that might be why I didn't do it that way for the stack files: I didn't want updating one service to also update any other services. But if you want that it's easy to do; it's the default behaviour for docker stack deploy.

If you just want to switch away from Swarm then that's fine, but it isn't necessary for the above changes. Having the stacks be deployed automatically sounds useful though and doing that instead of updating individual services might be better. It's just a little harder to know what version is actually deployed since it will just deploy whatever is the latest version rather than a specific hash. Possibly it should insert the desired hash into the stack file before deploying, but maybe it doesn't matter.

[mtelvers]

Thank you for your insight here. I really appreciate it. Switching from docker service update to docker stack deploy and using a file stack.yml in the repository seems like a good approach.