docker-komponieren Skala mit klebrigen Sitzungen

Question

Ich habe einen Webserver, der Websocket-Verbindung in der Produktion benötigt. Ich stelle es mithilfe von docker-compose mit nginx als Proxy bereit. Also meine compose Datei wie folgt aussehen:

version: '2' 
services: 
    app: 
    restart: always 

    nginx: 
    restart: always 
    ports: 
     - "80:80" 

Nun, wenn ich „app“ Dienst mehrere Instanzen skalieren, Docker-compose wird Round-Robin- bei jedem Aufruf an die interne dns „app“ durchführen.

Gibt es eine Möglichkeit, docker-compose load balancer anzuweisen, Sticky-Sitzungen anzuwenden?

Eine andere Lösung - gibt es eine Möglichkeit, es mit nginx zu lösen?

---

Mögliche Lösung, die Ich mag nicht:

mehrere Definitionen von App

version: '2' 
services: 
    app1: 
    restart: always 

    app2: 
    restart: always 

    nginx: 
    restart: always 
    ports: 
     - "80:80" 

(Und dann auf nginx Konfigurationsdatei I Sticky Sessions zwischen app1 definieren und app2) .

---

beste Ergebnis, das ich von der Suche bekam: https://github.com/docker/dockercloud-haproxy

Aber dies erfordert mir einen anderen Dienst hinzufügen (vielleicht nginx ersetzen?) Und die Dokumentation ist ziemlich schlecht über klebrigen Sitzungen gibt.

Ich wünschte, Docker würde nur erlauben, es mit einer einfachen Zeile in der Datei zu konfigurieren.

Danke!

Answer 1

Werfen Sie einen Blick auf jwilder/nginx-proxy. Dieses Image stellt einen Nginx-Reverse-Proxy bereit, der auf Container wartet, die die VIRTUAL_HOST-Variable definieren, und aktualisiert automatisch seine Konfiguration beim Erstellen und Entfernen von Containern. tpcwang Fork ermöglicht es Ihnen, die IP_HASH Direktive auf Container-Ebene zu verwenden, um Sticky-Sitzungen zu aktivieren.

Betrachten Sie die folgende Compose-Datei:

nginx: 
    image: tpcwang/nginx-proxy 
    ports: 
    - "80:80" 
    volumes: 
    - /var/run/docker.sock:/tmp/docker.sock:ro 
app: 
    image: tutum/hello-world 
    environment: 
    - VIRTUAL_HOST=<your_ip_or_domain_name> 
    - USE_IP_HASH=1 

Lassen Sie uns es aufstehen und laufen und dann app zu drei Instanzen skalieren:

docker-compose up -d 
docker-compose scale app=3 

Wenn Sie die nginx Konfigurationsdatei überprüfen Sie etwas sehen werden wie folgt:

docker-compose exec nginx cat /etc/nginx/conf.d/default.conf 

... 
upstream 172.16.102.132 { 
    ip_hash; 
      # desktop_app_3 
      server 172.17.0.7:80; 
      # desktop_app_2 
      server 172.17.0.6:80; 
      # desktop_app_1 
      server 172.17.0.4:80; 
} 
server { 
    server_name 172.16.102.132; 
    listen 80 ; 
    access_log /var/log/nginx/access.log vhost; 
    location/{ 
     proxy_pass http://172.16.102.132; 
    } 
} 

DieDer-Container hat die drei Instanzen automatisch erkannt und seine Konfiguration aktualisiert, um Anfragen an alle unter Verwendung von Sticky-Sitzungen weiterzuleiten.

Wenn wir versuchen, auf die App zuzugreifen, können wir sehen, dass bei jeder Aktualisierung immer derselbe Hostname angezeigt wird. Wenn wir die Umgebungsvariable USE_IP_HASH entfernen, sehen wir, dass sich der Hostname tatsächlich ändert, das heißt, der Nginx-Proxy verwendet Round-Robin, um unsere Anforderungen auszugleichen.