Open mtelvers opened 4 months ago
What's the advantage? Using host networking seems reasonable (should probably be doing that anyway).
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.
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.
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.
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 usingdocker service update --image <new-sha>
. The YAML description can be trivially refactored into adocker-compose.yml
file, which can be stored in the Git repository along with the service.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.docker compose pull && docker compose up -d
updates all images within the compose file. Withdocker service update
, we specifically update the OCaml service we just rebuilt: new releases of other components, such as the Caddy proxy, are not managed.