This repository contains a set of files which can be used to reproduce a problem where the docker stack deploy
command does not correctly orchestrate the rollout of a service update when the com.docker.ucp.mesh.http
label is present on a service.
- Build and push the images
docker image build -f black.Dockerfile -t "path/to/registry/docker-stack-deploy-demo:black" . docker image push path/to/registry/docker-stack-deploy-demo:black docker image build -f red.Dockerfile -t "path/to/registry/docker-stack-deploy-demo:red" . docker image push path/to/registry/docker-stack-deploy-demo:red
- Update the
docker-stack-black.yml
anddocker-stack-red.yml
files to reference your version of these two images. You may also want to update the routes used indocker-stack.yml
to something that can be used in your UCP instance, though that part doesn't matter to reproduce this issue. - Source a UCP client bundle
- Deploy a stack using the stack files:
The containers should take 10 seconds to become healthy.
docker stack deploy -c docker-stack.yml -c docker-stack-black.yml demo
- Start a second shell session, source your UCP client bundle again and run the following to start watching the containers involved in the stack above:
watch docker container ls -f name=demo_nginx
- Run another deployment using the opposite stack file (e.g.
red
vsblack
):docker stack deploy -c docker-stack.yml -c docker-stack-red.yml demo
- Switch back to the tab where the watch command is executing. You will see both replicas of the service get stopped at the same time instead of deploying the replicas one at a time and waiting for the health checks like it is supposed to.
- Open
docker-stack.yml
, comment out thecom.docker.ucp.mesh.http
label, and uncomment thecom.docker.lb.hosts
,com.docker.lb.network
, andcom.docker.lb.port
labels (the new version for UCP 3.x). - Run another deployment using the opposite stack file and monitor the containers. This time they will correctly deploy one-by-one.