Tried using Nginx and HA-Proxy but none of them seems to be work well in SWARM mode. Then I used Traefik in Docker Swarm and it did the trick for me.The only constraint is that Traefik should run on manager node as it needs to be aware of new worker nodes being added or removed. It doesn't require restart also even if you scale up service, add nodes etc.

I have tested the configuration with Docker compose version 3 which is the latest and deployed using Docker stack deploy.Step by step instructions are over here

To start off you need to create a docker-compose.yml (version 3) and add the load balancer Traefik Image. This is how it looks like

   loadbalancer:
image: traefik
command: --docker \
  --docker.swarmmode \
  --docker.watch \
  --web \
  --loglevel=DEBUG
ports:
  - 80:80
  - 9090:8080
volumes:
  - /var/run/docker.sock:/var/run/docker.sock
deploy:
  restart_policy:
    condition: any
  mode: replicated
  replicas: 1
  update_config:
    delay: 2s
  placement:
     constraints: [node.role == manager]

and then the Image for which you need session stickiness

whoami:
image: tutum/hello-world
networks:
  - net
ports:
  - "80"
deploy:
  restart_policy:
    condition: any
  mode: replicated
  replicas: 5
  placement:
    constraints: [node.role == worker]
  update_config:
    delay: 2s
  labels:
    - "traefik.docker.network=test_net"
    - "traefik.port=80"
    - "traefik.frontend.rule=PathPrefix:/hello;"
    - "traefik.backend.loadbalancer.sticky=true"

You can follow this link for a detailed explanation.

Docker swarm does not currently support sticky sessions, round robin is the only way to reach services by their exposed ports.

To implement sticky sessions, you would need to implement a reverse proxy inside of docker that supports sticky sessions and communicates directly to the containers by their container id (rather than doing a DNS lookup on the service name which would again go to the round robin load balancer). Implementing that load balancer would also require you to implement your own service discovery tool so that it knows which containers are available.

I think the best way to implement sticky sessions in a scaled environment is through database sessions storage. This will untie your application to specific nodes.

I think this is an easier and more cost-effective setup than relying on Docker Enterprise Sticky sessions (https://docs.docker.com/datacenter/ucp/2.2/guides/user/services/use-domain-names-to-access-services/#sticky-sessions).

Of course, this imply a couple of application adjustments like:

• minimise sessions requests for performances reasons (in particular for anonymous users to avoid DoS)
• I would store session data in a separate database (not the main application database)
• Session data should be removed after some time, so you should have some job deleting old session data regularly
• Etc.

This technique may also provide other benefits:

• May improve security if you also match user IP's/user agent
• May improve performances (because a database will be able to avoid disks accesses)

Hope this will help.