2016-09-28 4 views
3

У меня есть веб-сервер, который требует подключения к Интернету в процессе производства. Я развертываю его с помощью docker-compose с nginx как прокси. Так что мой файл Compose выглядеть следующим образом:шкала для докеры с липкими сеансами

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

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

Теперь, если я масштабировать сервис «приложение» к нескольким экземплярам, ​​докер-Compose выступит круговой при каждом вызове внутреннего Dns «приложение».

Есть ли способ рассказать балансировщику нагрузки на докер, чтобы применить липкие сеансы?

Другое решение - есть ли способ решить его с помощью nginx?


Возможное решение, что мне не нравится:

несколько определений приложения

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

    app2: 
    restart: always 

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

(А потом на Nginx конфигурационный файл можно определить липкие сессии между App1 и app2) ,


Лучший результат я получил от поиска: https://github.com/docker/dockercloud-haproxy

Но это требует от меня, чтобы добавить другую службу (возможно заменить Nginx?) И документы довольно бедны о липких сессиях там.

Я хочу, чтобы докер просто разрешил настраивать его с помощью простой строки в файле компоновки.

Спасибо!

+0

есть способ решить это с помощью кубернетов. – Gabbax0r

+0

@ Gabbax0r Спасибо! Я бы попробовал, если бы исчерпал другие варианты, так как моя инфраструктура основана на Docker Swarm. –

ответ

3

Посмотрите на jwilder/nginx-proxy. Это изображение предоставляет обратный прокси nginx, который прослушивает контейнеры, которые определяют переменную VIRTUAL_HOST, и автоматически обновляет ее конфигурацию при создании и удалении контейнера. Вилка tpcwang позволяет использовать директиву IP_HASH на уровне контейнера, чтобы включить липкие сеансы.

Рассмотрим следующий Compose файл:

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 

Давайте получить его и работает, а затем масштабировать app на три экземпляра:

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

Если проверить файл конфигурации Nginx вы увидите что-то например:

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; 
    } 
} 

Контейнеравтоматически обнаружил три экземпляра и обновил свою конфигурацию для маршрутизации запросов ко всем из них с использованием липких сеансов.

Если мы попытаемся получить доступ к приложению, мы можем видеть, что он всегда сообщает одно и то же имя хоста при каждом обновлении. Если мы удалим переменную окружения USE_IP_HASH, мы увидим, что имя хоста действительно изменяется, это значит, что прокси-сервер nginx использует round robin для баланса наших запросов.

+0

Спасибо, что ответили! Следует также упомянуть единственный недостаток ip_hash; липкие сеансы. В среде разработки, где клиент обычно является только блоком разработчиков, все запросы будут иметь тот же серверный узел. Решением может быть наличие клиента в контейнерах докеров, масштабированных до того же или большего количества масштабирующего номера сервера ... – andreas