Docker Swarm and Docker Compose File Reapply after Change

Hi everybody i am new to docker swarm and i am on my way to learn as mutch as i can.
so i have a question regarding to docker swarm and docker-compose.yml file.
i know i can deploy a compose.yml with the following command:

docker stack deploy --compose-file docker-compose.yml test

But what if for example i edit the docker-compose.yml and i want to apply the new configuration to the stack, how will i do this? or do i have to remove and deploy it again?
in kubernets i ca just apply the new config again and it will notice the old settings and just update the new or change things.
maybe someone can help me in this case.
thanks in advanced

The same command is used to deploy changes as well.

Be aware that changes to volumes, networks, configs and secrets will not be reflected back to the docker engine.

networks and volumes have immutable configurations: they can not be changed once created. In order to deploy configuration changes for them, the stack needs to be removed, then the volume/network needs to be removed (volumes need to be deleted on each node!). A redeployment of the stack will re-create the resources using the new configuration.

Updates to config or secrets either require the stack to be deleted and re-created, or a changed resource name (usually people append something like .vn to the end, where n is the version number).

ok that worked i don´t know why but in a test befor it did not work.
but now how do i update now if i use the image tage :latest and who do i config to stop a container befor creating the new one with the new image?

Great question.

I am not really sure, if it catches up when a mutable tag points to a different image digest. Though, since it checks for update images before deployment, I would imagine it would detect a changed image digest and start updating the service tasks one by one. But then again: I am not entirely sure about it.

It has been roughly 4 or 5 years since I used swarm in production, And even back then we always used immutable tags. It required tags to be changed in the deployment configurations, which resulted in a replacement of the service tasks based on the old tags, with new service tasks that base on the new tag.

An alternative to immutable tags is to pin mutable tags using the image digest. In this scenario people usually use something like dependabot or renovate to update their deployment confiugrations.

thanks for your input. i now tested it.
if you do a redeploy of the compose yml and the “latest” image is newer then the existing one it will pull it and deply it. you can controll the behavier of the update with start-first or stop-first. :slight_smile: