Here is a small script which compares the version of the running service and the version in the docker-compose file, if they are different it runs an update.

REDIS_VERSION=$(docker service ls | grep "redis" | awk '{print $5}')
REDIS_NEW_VERSION=$(grep -Po "image:\s*\Kredis:.*" docker-compose.yml)
if [ "$REDIS_VERSION" != "$REDIS_NEW_VERSION" ]; then
    echo "update $REDIS_VERSION -> $REDIS_NEW_VERSION"
    docker service update --image $REDIS_NEW_VERSION app_redis
fi

There is a long standing issue for this task. The logs looks like: 10.255.0.2 - - [15/Mar/2018:15:32:15 +0000] “GET / HTTP/2.0” 200

One of the solutions, from the issue’s comments, is to run a service in the host mode, the swarm load balancing for this service will not work. But if there is a load balancer behind the swarm cluster, it seems not a big problem.

Socket.IO requires the sticky sessions, so when it’s runned in Docker Swarm environment, the Swarm load balancer can forward the request to any node where the service is launched and there will be the 400 errors. The solution is to limit the number of nodes for Socket.IO service to one or to use another load balancer like Traefik or HAProxy.

Suppose there is an application which uses docker-compose to run and you want to try it in swarm mode.

First of all you need to initialize swarm nodes.

When you have several Nginx replicas in Docker Swarm and you need to share SSL certificate, you can use secrets.

Here is a short extract:

I have nginx as a proxy for a python application. To launch them I have a docker-compose.