How to maintain sticky session(session persistence) with docker swarm?

I have one Java based web application which is deployed in jboss-10.1.0(wildfly). I am using docker swarm mode(docker version 1.12.1) to scale my application everything works perfectly but the only issue I am facing is session management.

Now let’s take scenario.

  • Challenged to get ServiceStack self-hosted F# example that works on Windows, working on Docker
  • Connecting to ActiveMQ Artemis Docker Container with Core API
  • How to setup nginx as reverse proxy for Ruby application (all running inside Docker)
  • When using docker-compose to fire up containers how do I programatically get their ips?
  • Looking for ways and options to stop the worker process after task completion in celery?
  • Update docker container when new image is getting released
  • I have two instance is running for my application(i.e. App1 and App2).I am using default load balancer provided by docker swarm mode with nginx to redirect my application from to so that I don’t need to write down port with my url and I am able to access directly with this URL

    Now the default load balancer is using RR(Round-Robin algorithm) to serve my web request.So first time I visit the it goes to App1 instance and display login page I login with credentials and everything works perfectly after few minutes it’s switch to App2 and again the login page comes.

    Is there any way or tools(should be Open-source) through which I handle sessions ? So at least I login to App1 and stick to App1 until I logout.

    Thank you!

  • How to use Nomad with Nvidia Docker?
  • Dockerfile in a Amazon EB
  • Configuring wercker.yml to run unit tests in a python app requiring postgres service
  • Docker-compose does not install or run properly on boot2docker
  • How to dockerized java microservices efficiently
  • How can kubernetes dynamically expose my docker port?
  • 2 Solutions collect form web for “How to maintain sticky session(session persistence) with docker swarm?”

    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.

    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

    image: traefik
    command: --docker \
      --docker.swarmmode \ \
      --web \
      - 80:80
      - 9090:8080
      - /var/run/docker.sock:/var/run/docker.sock
        condition: any
      mode: replicated
      replicas: 1
        delay: 2s
         constraints: [node.role == manager]

    and then the Image for which you need session stickiness

    image: tutum/hello-world
      - net
      - "80"
        condition: any
      mode: replicated
      replicas: 5
        constraints: [node.role == worker]
        delay: 2s
        - ""
        - "traefik.port=80"
        - "traefik.frontend.rule=PathPrefix:/hello;"
        - "traefik.backend.loadbalancer.sticky=true"

    You can follow this link for a detailed explanation.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.