/ cc @aluzzardi @mrjana спросила

@PanJ, не могли бы вы поделиться некоторыми подробностями о том, как debugging-simple-server определяет ip ? Также каковы ожидания, если услуга масштабируется до более чем одной реплики на нескольких хостах (или в глобальном режиме)?

@mavenugo - это объект запроса koa, который использует узел remoteAddress из модуля net . Результат должен быть таким же для любых других библиотек, которые могут получать удаленный адрес.

Ожидается, что поле ip всегда должно быть удаленным адресом независимо от какой-либо конфигурации.

@PanJ, вы все еще используете обходной путь или нашли лучшее решение?

@PanJ Когда я запускаю ваше приложение как автономный контейнер ...

docker run -it --rm -p 80:3000 --name test panj/debugging-simple-server

и получить доступ к опубликованному порту с другого хоста, я получаю это

vagrant@net-1:~$ curl 192.168.33.12
{"method":"GET","url":"/","header":{"user-agent":"curl/7.38.0","host":"192.168.33.12","accept":"*/*"},"ip":"::ffff:192.168.33.11","ips":[]}
vagrant@net-1:~$

192.168.33.11 - это IP-адрес хоста, на котором я запускаю curl. Это ожидаемое поведение?

@sanimej Да, это ожидаемое поведение, которое также должно быть в режиме роя.

@marech Я все еще использую автономный контейнер в качестве

В моем случае есть 2 экземпляра nginx, standalone и swarm. Завершение SSL и обратный прокси выполняется на автономном nginx. Экземпляр Swarm используется для маршрутизации к другим службам на основе хоста запроса.

@PanJ Способ ingress . 10.255.0.x - это адрес сетевого интерфейса ingress на узле в кластере, из которого вы пытаетесь получить доступ к опубликованному порту.

@sanimej Я как бы увидел, как это работает, когда

У меня ограниченные знания о том, как это исправить. Может быть, особый тип сети, которая не меняет исходный IP-адрес?

Rancher похож на режим Docker swarm и, похоже, имеет ожидаемое поведение. Может быть, это хорошее место для начала.

@sanimej - хорошая идея - добавить все IP-адреса в заголовок X-Forwarded-For, если это возможно, тогда мы сможем увидеть всю цепочку.

@PanJ хм, а как ваш автономный контейнер nignx взаимодействует с экземпляром swarm через имя службы или ip? Возможно, вы можете поделиться частью конфигурации nginx, где вы передадите ее экземпляру swarm.

Автономный контейнер @marech прослушивает порт 80 а затем прокси на localhost:8181

server {
  listen 80 default_server;
  location / {
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Proto $scheme;
    proxy_pass          http://localhost:8181;
    proxy_read_timeout  90;
  }
}

Если вам нужно выполнить завершение SSL, добавьте еще один блок сервера, который прослушивает порт 443 , затем выполните завершение SSL и прокси на localhost:8181

Nginx в режиме Swarm публикует 8181:80 и перенаправляет на другой сервис на основе хоста запроса.

server {
  listen 80;
  server_name your.domain.com;
  location / {
    proxy_pass          http://your-service:80;
    proxy_set_header Host $host;
    proxy_read_timeout  90;
  }
}

server {
  listen 80;
  server_name another.domain.com;
  location / {
    proxy_pass          http://another-service:80;
    proxy_set_header Host $host;
    proxy_read_timeout  90;
  }
}

В нашем случае наш API RateLimit и другие функции зависят от IP-адреса пользователя. Есть ли способ пропустить проблему в режиме роя?

Я также столкнулся с проблемой при попытке запустить logstash в режиме роя (для сбора сообщений системного журнала с различных хостов). Поле logstash «host» всегда отображается как 10.255.0.x вместо фактического IP-адреса подключающегося хоста. Это делает его совершенно непригодным для использования, поскольку вы не можете определить, с какого хоста приходят сообщения журнала. Есть ли способ избежать перевода исходного IP-адреса?

+1 за решение этой проблемы.

Отсутствие возможности получения IP-адреса пользователя мешает нам использовать решения для мониторинга, такие как Prometheus.

Возможно, здесь пригодятся возможности IPVS ядра Linux. Я предполагаю, что смена IP-адреса происходит потому, что соединения проксируются в пользовательском пространстве. IPVS, с другой стороны, может перенаправлять и балансировать нагрузку запросы в пространстве ядра без изменения исходного IP-адреса. IPVS также может быть полезен в будущем для создания более продвинутых функций, таких как различные алгоритмы балансировки нагрузки, плавающие IP-адреса и прямая маршрутизация.

Для меня было бы достаточно, если бы я мог каким-то образом выяснить связь между виртуальным IP-адресом и IP-адресом сервера, которому принадлежит конечная точка. Таким образом, когда Prometheus отправляет предупреждение, относящееся к некоторому виртуальному IP-адресу, я мог узнать, какой сервер затронут. Это не было бы хорошим решением, но лучше, чем ничего.

@vfarcic Я не думаю, что это возможно с тем, как это работает сейчас. Все клиентские подключения происходят с одного и того же IP-адреса, поэтому вы не можете перевести его обратно. Единственный способ, который будет работать, - это если все, что делает прокси / нат для соединений, сохранит журнал соединений с меткой времени, исходным IP-адресом и исходным портом. Даже в этом случае это не поможет в большинстве случаев использования, когда требуется исходный IP-адрес.

Я, вероятно, не очень хорошо объяснил вариант использования.

Я использую Prometheus, который настроен на удаление экспортеров, работающих как глобальные службы Swarm. Он использует задачи.чтобы получить IP-адреса всех реплик. Таким образом, он использует не службу, а конечные точки реплик (без балансировки нагрузки). Что мне нужно, так это каким-то образом выяснить IP-адрес узла, с которого происходит каждый из этих IP-адресов реплик.

Я только что понял, что "проверка сети докеров""предоставляет информацию о контейнерах и IPv4-адресах отдельного узла. Можно ли расширить это, чтобы информация о сети вместе с узлами содержала общекластерную информацию?

Что-то вроде:

       "Containers": {
            "57bc4f3d826d4955deb32c3b71550473e55139a86bef7d5e584786a3a5fa6f37": {
                "Name": "cadvisor.0.8d1s6qb63xdir22xyhrcjhgsa",
                "EndpointID": "084a032fcd404ae1b51f33f07ffb2df9c1f9ec18276d2f414c2b453fc8e85576",
                "MacAddress": "02:42:0a:00:00:1e",
                "IPv4Address": "10.0.0.30/24",
                "IPv6Address": "",
                "Node": "swarm-4"
            },
...

Обратите внимание на добавление «Узла».

Если бы такая информация была бы доступна для всего кластера, а не только для одного узла с добавлением аргумента --filter , у меня было бы все необходимое для выяснения связи между IPv4-адресом контейнера и узел. Это было бы не лучшим решением, но все же лучше, чем ничего. Прямо сейчас, когда Prometheus обнаруживает проблему, мне нужно выполнить «проверку сети докеров» на каждом узле, пока я не выясню местоположение адреса.

Я согласен с @dack , учитывая, что

Решение должно работать на уровне IP, чтобы любая служба, не основанная на HTTP, могла работать должным образом (нельзя полагаться на заголовки http ...).

И я не могу подчеркнуть, насколько это важно, без него есть много сервисов, которые просто не могут работать в режиме роя.

Вот как HaProxy решает эту проблему: http://blog.haproxy.com/2012/06/05/preserve-source-ip-address-desITE-reverse-proxies/

@kobolog мог бы пролить свет на этот вопрос, если бы он рассказал о IPVS на DockerCon.

Просто добавляю себя в список. Я использую logstash для приема сообщений системного журнала, и все они помещаются в elasticsearch с IP-адресом хоста, установленным на 10.255.0.4, что делает его непригодным для использования, и мне придется вернуться к моему неконтейнерному развертыванию logstash если для этого нет исправления.

@mrjana не могли бы вы добавить предложение, которое у вас было для решения этой проблемы?

IPVS не является обратным прокси-сервером пользовательского пространства, который может исправлять ошибки на уровне HTTP. В этом разница между прокси-сервером пользовательского пространства, таким как HAProxy, и этим. Если вы хотите использовать HAProxy, вы можете сделать это, поместив HAProxy в кластер, и все ваши экземпляры службы и HAProxy будут участвовать в одной сети. Таким образом, HAProxy может исправить HTTP header.x-forwarded-for . Или, если балансировщик нагрузки L7 является внешним по отношению к кластеру, вы можете использовать предстоящую (в 1.13) функцию для нового PublishMode называемого Host PublishMode, который будет отображать каждый из отдельных экземпляров службы. в его собственный индивидуальный порт, и вы можете указать на него свой внешний балансировщик нагрузки.

@mrjana Вся идея использования IPVS (вместо того, что в настоящее время делает докер в режиме роя) заключается в том, чтобы избежать преобразования исходного IP-адреса с самого начала. Добавление X-Forwarded-For может помочь некоторым HTTP-приложениям, но бесполезно для всех других приложений, которые не работают из-за текущего поведения.

@dack, насколько я понимаю,

Если вы хотите использовать HAProxy, вы можете сделать это, поместив HAProxy в кластер, и все ваши экземпляры службы и HAProxy будут участвовать в одной сети. Таким образом, HAProxy может исправить HTTP-заголовок. X-forwarded-for

Это не сработает либо @mrjana , единственный способ для HAProxy получить IP-адрес клиента - это запустить за пределами входной сети с помощью docker run или непосредственно на хосте, но тогда вы не можете использовать какие-либо из своих сервисов, поскольку они находятся в другой сети и вы не можете получить к ним доступ.

Проще говоря, насколько я знаю, нет никакого способа справиться с этим, как только вы используете службы докеров и режим роя.

Было бы интересно, если бы авторы входной сети докеров могли присоединиться к обсуждению, поскольку они, вероятно, имели бы некоторое представление о том, как IPVS настроен / работает под капотом (есть много режимов для IPVS) и как мы можем исправить проблема.

@tlvenn Вы знаете, где это в исходном коде? Я могу ошибаться, но я не верю, что он использует IPVS, основываясь на некоторых наблюдениях:

• Исходный порт переведен (вся причина этой проблемы). IPVS этого не делает. Даже в режиме NAT он транслирует только адрес назначения. Вам необходимо использовать маршрут по умолчанию или маршрутизацию политики для отправки ответных пакетов обратно на хост IPVS.
• Когда порт публикуется в режиме роя, все экземпляры dockerd в рое прослушивают опубликованный порт. Если бы использовался IPVS, это происходило бы в пространстве ядра, и dockerd не слушал бы порт.

Привет @dack!

Из их блога:

Внутренне мы делаем эту работу с помощью Linux IPVS, встроенного в ядро ​​многопротокольного балансировщика нагрузки уровня 4, который присутствует в ядре Linux более 15 лет. Благодаря пакетам маршрутизации IPVS внутри ядра сетка маршрутизации swarm обеспечивает высокопроизводительную балансировку нагрузки с учетом контейнеров.

Исходный код должен находиться в проекте swarmkit, если я не ошибаюсь.

Интересно, может ли @stevvooe помочь нам понять, в чем заключается основная проблема.

Хорошо, я бегло просмотрел код и думаю, что теперь я немного лучше его понимаю. Похоже, что он действительно использует IPVS, как указано в блоге. SNAT выполняется с помощью правила iptables, настроенного в service_linux.go. Если я правильно понимаю, логика этого будет примерно такой (при условии, что узел A получает клиентский пакет для службы, работающей на узле B):

• Узел Swarm A получает клиентский пакет. IPVS / iptables переводит (src ip) -> (node ​​a ip) и (dst ip) -> (node ​​B ip)
• Пакет пересылается на узел B
• Узел B отправляет ответ узлу A (так как он видит его как src ip)
• Узел A переводит src и dst обратно в исходные значения и пересылает ответ клиенту.

Я думаю, что аргумент SNAT заключается в том, что ответ должен проходить через тот же узел, через который пришел исходный запрос (поскольку именно там хранится состояние NAT / IPVS). Поскольку запросы могут поступать через любой узел, SNAT используется, чтобы сервисный узел знал, через какой узел направить запрос обратно. В настройке IPVS с одним узлом балансировки нагрузки это не будет проблемой.

Таким образом, возникает вопрос, как избежать SNAT, при этом позволяя всем узлам обрабатывать входящие клиентские запросы. Я не совсем уверен, какой подход лучше всего. Возможно, есть способ иметь таблицу состояний на сервисном узле, чтобы он мог использовать маршрутизацию политики для прямых ответов вместо того, чтобы полагаться на SNAT. Или может помочь какая-то инкапсуляция (VXLAN?). Или можно использовать метод прямой маршрутизации IPVS. Это позволит узлу службы отвечать напрямую клиенту (а не через узел, получивший исходный запрос) и позволит добавлять новые плавающие IP-адреса для служб. Однако это также будет означать, что со службой можно связаться только через плавающий IP-адрес, а не через IP-адреса отдельных узлов (не уверен, что это проблема для каких-либо вариантов использования).

Довольно интересное открытие @dack !

Надеюсь, будет найдено решение полностью пропустить этот SNAT.

Между тем, возможно, есть обходной путь, который был применен не так давно, который вводит публикацию порта на уровне хоста с помощью PublishMode , эффективно обходя входную сеть.

https://github.com/docker/swarmkit/pull/1645

Привет, спасибо за большое количество отзывов - мы подробно рассмотрим этот вопрос после выходных.

Некоторая информация тем временем:

@tlvenn : @mrjana - главный автор функции входящей сети. Источник в основном живет в docker / libnetwork, некоторые в SwarmKit

@dack : он действительно поддерживается IPVS

@tlvenn, насколько мне известно, Docker Swarm использует маскарадинг, поскольку это наиболее простой способ и гарантированно работает в большинстве конфигураций. Кроме того, это единственный режим, который на самом деле позволяет маскировать порты [re: @dack], что очень удобно. Теоретически эту проблему можно решить, используя режим инкапсуляции IPIP - тогда поток пакетов будет таким:

• Пакет поступает на сервер шлюза - в нашем случае любой узел роя - и IPVS на этом узле определяет, что это на самом деле пакет для виртуальной службы, на основе его IP-адреса и порта назначения.
• Пакет инкапсулируется в другой IP-пакет и отправляется на реальный сервер, который был выбран на основе алгоритма балансировки нагрузки.
• Реальный сервер получает закрывающий пакет, декапсулирует его и видит реальный IP-адрес клиента в качестве источника и IP- адрес
• Реальный сервер обрабатывает пакет и отправляет ответ напрямую клиенту. Исходным IP-адресом в этом случае будет IP- адрес

Конечно, есть много предостережений и вещей, которые могут пойти не так, но в целом это возможно, и режим IPIP широко используется в производстве.

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

Смотрю. Наш продукт использует исходную IP-информацию для обеспечения безопасности и аналитики.

@aluzzardi есть какие-нибудь обновления для нас?

bump, нам это нужно, чтобы работать над очень большим проектом, который мы начинаем в начале следующего года.

Изучая поток, кажется, что в настоящее время он работает следующим образом (в этом примере узел A принимает входящий трафик, а узел B запускает контейнер службы):

• узел A выполняет DNAT для направления пакета в сетевое пространство имен ingress_sbox (/ var / run / docker / netns / ingress_sbox)
• ingress_sbox на узле A запускает IPVS в режиме NAT, который выполняет DNAT для направления пакета в контейнер на узле B (через входящую оверлейную сеть), а также SNAT для изменения исходного IP-адреса на входной оверлейный IP-адрес узла A.
• пакет направляется через оверлей на реальный сервер
• возвращаемые пакеты следуют по тому же пути в обратном порядке, перезаписывая адреса источника / назначения обратно к исходным значениям

Я думаю, что SNAT можно было бы избежать примерно так:

• узел A передает пакет в ingress_sbox без NAT (iptables / policy routing?)
• узел A ingress_sbox запускает IPVS в режиме прямой маршрутизации, который отправляет пакет на узел B через входящую оверлейную сеть
• контейнер на узле B получает неизмененный пакет (контейнер должен принимать пакеты для всех общедоступных IP-адресов, но не отправлять для них ARP. Есть несколько способов сделать это, см. документацию IPVS).
• ответные пакеты отправляются напрямую от узла B к клиенту (нет необходимости возвращаться через оверлейную сеть или узел A)

В качестве дополнительного бонуса нет необходимости сохранять состояние NAT и сокращается оверлейный сетевой трафик.

@aluzzardi @mrjana Есть поводу, пожалуйста? Мы будем очень признательны за небольшую обратную связь от Docker.

Смотрю. без исходной IP-информации большинство наших сервисов не могут работать должным образом

Как это случилось ?

@tlvenn кажется ошибкой в ​​Github?

@PanJ @tlvenn @vfarcic @dack и другие, PTAL # 27917. Мы представили возможность включить режим публикации службы = host который предоставит службе возможность обходить IPVS и вернуть поведение, подобное docker run -p и сохранит исходный IP-адрес для случаев, когда нужно это.

Пожалуйста, попробуйте 1.13.0-rc2 и оставьте отзыв.

ты довольно странный @mavenugo ..

Что касается режима публикации, я уже связал это из набора swarm выше, это может быть обходным путем, но я искренне надеюсь, что в Docker 1.13 появится правильное решение, чтобы навсегда решить эту проблему.

Эта проблема в значительной степени может быть отнесена к категории ошибок, потому что сохранение исходного IP-адреса - это поведение, которого мы, как пользователи, ожидают, и это очень серьезное ограничение для служб докеров прямо сейчас.

Я считаю, что и @kobolog, и @dack предложили некоторые потенциальные

Не могли бы мы рассказать, кто занимается этой проблемой в Docker, и сообщить об обновлении статуса? Заранее спасибо.

Кроме # 27917 другого решения для 1.13 нет. Функциональность прямого возврата должна быть проанализирована для различных вариантов использования, и ее не следует воспринимать легкомысленно, чтобы рассматривать ее как исправление ошибки. Мы можем изучить это для версии 1.14. Но это также подпадает под категорию настраиваемого поведения LB, которое включает алгоритм (rr против 10 других методов), Data-path (LVS-DR, LVS-NAT и LVS-TUN). Если кто-то желает внести свой вклад в это, пожалуйста, поставьте PR, и мы сможем сдвинуть его с мертвой точки.

Достаточно честно , я думаю,

По крайней мере, можем ли мы изменить документ для версии 1.13, чтобы в нем четко указывалось, что при использовании служб докеров с режимом публикации входящего трафика по умолчанию исходный IP-адрес не сохраняется, и намекать на использование режима хоста, если это является требованием для запуска службы. ?

Я думаю, это поможет людям, которые переходят на сервисы, не обжечься таким неожиданным поведением.

Конечно и да, обновление документации, чтобы указать на это поведение и обходной путь использования публикации mode=host будет полезен для таких случаев использования, которые не работают в режиме LVS-NAT.

Просто проверяю, нет ли новых разработок в выяснении этой реальной вещи? Для нас это определенно огромное ограничение.

Планируется ли решение для docker 1.14? Мы задерживаем развертывание наших решений с использованием докеров отчасти из-за этой проблемы.

Хотелось бы, чтобы к запросу http / https был добавлен настраиваемый заголовок, который сохраняет IP-адрес клиента. Это должно быть возможно, не так ли? Я не возражаю, когда X_Forwarded_for перезаписывается, я просто хочу иметь настраиваемое поле, которое устанавливается только в самый первый раз, когда запрос попадает в рой.

Хотелось бы, чтобы к запросу http / https был добавлен настраиваемый заголовок, который сохраняет IP-адрес клиента. Это должно быть возможно, не так ли? Я не возражаю, когда X_Forwarded_for перезаписывается, я просто хочу иметь настраиваемое поле, которое устанавливается только в самый первый раз, когда запрос попадает в рой.

Балансировка нагрузки выполняется на L3 / 4. Добавление заголовка http невозможно.

Исправление будет включать удаление перезаписи исходного адреса.

@mavenugo Сегодня я обновился до docker 1.13 и использовал mode=host в своей прокси-службе. В настоящее время он работает, IP клиента сохраняется, но я надеюсь на лучшее решение :) Спасибо за вашу работу!

Извините за двойной пост ...
Как я могу использовать файл стека (yml v3), чтобы получить такое же поведение, как если бы я использовал --publish mode=host,target=80,published=80 через docker service create?

Я пытался

...
services:
  proxy:
    image: vfarcic/docker-flow-proxy:1.166
    ports:
      - "80:80/host"
      - "443:443/host" 
...

но это не работает (используется тот же шаблон, что и в https://docs.docker.com/docker-cloud/apps/stack-yaml-reference/#/ports)

Как я могу использовать файл стека (yml v3), чтобы получить такое же поведение, как если бы я использовал --publish mode = host, target = 80, published = 80 через docker service create?

@hamburml - следите за https://github.com/docker/docker/issues/30447, это открытая проблема / функция.

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

@ tkeeler33 Я думаю, вы сможете развернуть службу как службу global (которая развертывает экземпляр на каждом узле в рое) и подключить его к сети роя для связи с другими службами в рое

@thaJeztah - Да, но я не могу подключить контейнер одновременно к сети оверлея / роя и хосту mode=host . На данный момент это мое самое большое ограничение.

@ tkeeler33, похоже, у меня работает;

$ docker network create -d overlay swarm-net

$ docker service create \
  --name web \
  --publish mode=host,published=80,target=80 \
  --network swarm-net \
  --mode=global \
  nginx:alpine

$ docker service create --name something --network swarm-net nginx:alpine

Проверить, может ли служба web подключиться к службе something в той же сети;

docker exec -it web.xczrerg6yca1f8ruext0br2ow.kv8iqp0wdzj3bw7325j9lw8qe sh -c 'ping -c3 -w1 something'
PING something (10.0.0.4): 56 data bytes
64 bytes from 10.0.0.4: seq=0 ttl=64 time=0.251 ms

--- something ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.251/0.251/0.251 ms

@thaJeztah - Спасибо! Покопавшись глубже, я понял, что моя проблема заключалась в том, что я создал свою сеть докеров, используя параметр --opt encrypted , из-за чего контейнер отказывался от соединений с хостом. Попробовав ваши шаги, я смог быстро сузить основную причину. Этот вариант может быть хорошим временным обходным решением, мне просто нужно обдумать любые последствия для безопасности.

Очень ценю информацию!

@ tkeeler33 --opt encrypted не должен влиять на сопоставление хост-порт. Единственная цель опции encrypted - зашифровать трафик туннеля vxlan между узлами. Из документации: «Если вы планируете создать оверлейную сеть с шифрованием (--opt encrypted), вам также необходимо убедиться, что трафик протокола 50 (ESP) разрешен». Можете ли вы проверить свои конфигурации, чтобы убедиться, что ESP разрешен?
Кроме того, опция --opt encrypted - это чисто шифрование плоскости данных. Весь трафик уровня управления (обмен маршрутизацией, распределение Service Discovery и т. Д.) По умолчанию зашифрован даже без этой опции.

@mavenugo Ты прав. Когда я создал новую сеть с --opt encrypted она работала нормально. Когда я сравнил недавно созданную сеть с моей существующей, я заметил, что установлено значение "Internal": true . Вероятно, это была проблема и была ошибка во время первоначального создания сети ... Спасибо за вашу помощь и разъяснения, это был долгий день ...

@dack @kobolog В типичных развертываниях режима LVS-Tunnel и LVS-DR IP-адрес назначения во входящем пакете будет VIP-адресом службы, который также запрограммирован как IP-адрес без ARP на реальных серверах. Сетка маршрутизации работает принципиально иначе, входящий запрос может быть направлен на любой из хостов. Чтобы реальный сервер принял пакет (в любом режиме LVS), IP-адрес назначения должен быть изменен на локальный IP-адрес. Ответный пакет из внутреннего контейнера не может вернуться с правильным исходным адресом. Вместо прямого возврата мы можем попытаться получить ответный пакет обратно на входящий хост. Но нет чистого способа сделать это, кроме как изменить исходный IP-адрес, который возвращает нас к исходной точке.

@thaJeztah Я думаю, нам следует пояснить это в документации, предложить использовать мод хоста, если IP-адрес клиента необходимо сохранить, и закрыть эту проблему.

@sanimej Я до сих пор не понимаю, почему это невозможно без NAT. Не могли бы мы просто иметь возможность использовать, например, обычный поток LVS-DR? Docker добавляет не-arp vip к соответствующим узлам, LVS направляет входящие пакеты на узлы, а исходящие пакеты возвращаются напрямую. Почему имеет значение то, что входящий пакет может попасть на любой хост? Это ничем не отличается от стандартного LVS с несколькими интерфейсами и несколькими внутренними серверами.

@thaJeztah спасибо за обходной путь :)
Если вы развертываете свой прокси с помощью Compose версии 3, новый синтаксис публикации не поддерживается, поэтому мы можем исправить развернутую службу с помощью этой команды (замените nginx_proxy именем службы)

docker service update nginx_proxy \
    --publish-rm 80 \
    --publish-add "mode=host,published=80,target=80" \
    --publish-rm 443 \
    --publish-add "mode=host,published=443,target=443"

@dack В обычном потоке LVS-DR IP-адрес назначения будет служебным VIP. Таким образом, LB может отправить пакет на серверную часть без изменения IP-адреса назначения. Это не относится к сетке маршрутизации, потому что IP-адрес получателя входящего пакета будет одним из IP-адресов хоста.

@sanimej какие-либо отзывы о предложении выше использовать режим инкапсуляции IPIP для решения этой проблемы?

@tlvenn LVS-IP-туннель работает очень похоже на LVS-DR, за исключением того, что серверная часть получает пакет через IP-адрес в IP-туннеле, а не при перезаписи Mac. Таким образом, у него та же проблема для варианта использования сетки маршрутизации.

Из предложения, которое вы упомянули ..
The real server receives the enclosing packet, decapsulates it and sees real client IP as source and virtual service IP as destination.

IP-адрес назначения пакета будет IP-адресом хоста, на который клиент отправил пакет, а не VIP. Если его не переписать, реальный сервер сбросит его после удаления внешнего IP-заголовка. Если IP-адрес назначения перезаписан, ответ реального сервера клиенту будет иметь неверный IP-адрес источника, что приведет к сбою соединения.

Спасибо за разъяснение @sanimej. Не могли бы вы реализовать протокол PROXY ? Это не обеспечит единого решения, но, по крайней мере, предложит сервису решение для разрешения IP-адреса пользователя.

Существует сложный способ сохранить исходный IP-адрес, разделив диапазон исходных портов на блоки и назначив блок для каждого хоста в кластере. Тогда можно использовать гибридный подход NAT + DR, когда входящий хост выполняет обычный SNAT и отправляет пакет на реальный сервер. На хосте, на котором работает реальный сервер, на основе IP-адреса источника выполните SNAT, чтобы изменить порт источника на порт в диапазоне, назначенном для входящего хоста. Затем в возвращаемом пакете из контейнера совпадение с диапазоном портов источника (и целевым портом) и изменение IP-адреса источника на IP-адрес входящего узла.

Технически это будет работать, но непрактично и непрочно в реальных развертываниях, когда элементы кластера добавляются и удаляются быстро. Это также значительно уменьшает пространство порта.

Подход NAT + DR, о котором я упоминал, не будет работать, потому что исходный IP-адрес не может быть изменен на входном узле. Возможным вариантом может быть изменение только исходного порта на один в диапазоне для этого конкретного хоста и использование политики маршрутизации с внутреннего хоста для возврата пакета на входной хост. Здесь все еще есть другие проблемы, о которых я упоминал ранее.

@thaJeztah
Есть ли какое-либо обходное решение для пересылки реального IP-адреса из контейнера Nginx в веб-контейнер?
У меня есть контейнер Nginx, работающий в режиме global и опубликованный в host , поэтому контейнер Nginx получает правильный IP-адрес. Оба контейнера прекрасно видят друг друга, однако веб-контейнер получает IP-адрес контейнера Nginx, а не клиентский.
Nginx - это обратный прокси-сервер для Интернета, а веб-сервер запускает uwsgi на порту 8000:

server {
    resolver 127.0.0.11;
    set $web_upstream http://web:8000;

    listen 80;
    server_name domain.com;
    location / {
        proxy_pass $web_upstream;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        proxy_redirect off;
        proxy_buffering off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

@lpakula Пожалуйста, проверьте мой ответ выше + эта рабочая конфигурация nginx

@ pi0 Спасибо за ответ

Я использую конфигурацию nginx из ссылки, но IP-адрес все еще неверен, в моей конфигурации что-то не хватает

У меня есть кластер роя докеров (

    docker service create --name nginx --network overlay_network --mode=global \
        --publish mode=host,published=80,target=80 \
        --publish mode=host,published=443,target=443 \
        nginx:1.11.10

    docker service create --name web --network overlay_network \
        --replicas 1 \
        web:newest

Контейнер Nginx использует последний официальный контейнер https://hub.docker.com/_/nginx/
Веб-контейнер запускает сервер uwsgi на порту 8000

Я использую глобальный nginx.conf из ссылки, а conf.d/default.conf выглядит следующим образом:

   server {
       resolver 127.0.0.11;
       set $web_upstream http://web:8000;

       listen 80;
       server_name domain.com;
       location / {
        proxy_pass $web_upstream;
      }
  }

А затем логи контейнера nginx:

  194.168.X.X - - [17/Mar/2017:12:25:08 +0000] "GET / HTTP/1.1" 200

Журналы веб-контейнера:

  10.0.0.47 - - [17/Mar/2017 12:25:08] "GET / HTTP/1.1" 200 -

Чего там не хватает?

IP-адрес все равно будет неправильным. Но он добавит заголовки HTTP, которые
содержат реальный IP-адрес. Вы должны настроить свой веб-сервер по вашему выбору
доверять прокси (использовать заголовок вместо исходного IP)
В пятницу, 17 марта 2560, в 19:36 Лукаш Пакула [email protected]
написал:

@ pi0 https://github.com/pi0 Спасибо за ответ

Я использую конфигурацию nginx из ссылки, но IP-адрес все еще
неправильно, у меня должно быть что-то не хватает в моей конфигурации

У меня есть кластер роя докеров (
Сервисы

docker service create --name nginx --network overlay_network --mode=global \
    --publish mode=host,published=80,target=80 \
    --publish mode=host,published=443,target=443 \
    nginx:1.11.10

docker service create --name web --network overlay_network \
    --replicas 1 \
    web:newest

Контейнер Nginx использует последний официальный контейнер
https://hub.docker.com/_/nginx/ http: // url
Веб-контейнер запускает сервер uwsgi на порту 8000

Я использую глобальный nginx.conf из ссылки и выглядит conf.d / default.conf
следующим образом:

server {
резольвер 127.0.0.11;
установить $ web_upstream http: // web : 8000;

   listen 80;
   server_name domain.com;
   location / {
    proxy_pass $web_upstream;
  }

}

А затем логи контейнера nginx:

194.168.XX - - [17 марта 2017: 12: 25: 08 +0000] «GET / HTTP / 1.1» 200

Журналы веб-контейнера:

10.0.0.47 - - [17 марта 2017 12:25:08] «GET / HTTP / 1.1» 200 -

Чего там не хватает?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/docker/issues/25526#issuecomment-287342795 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ABtu97EFaCmLwAZiOrYT4nXi4oXPCbLQks5rmn43gaJpZM4Jf2WK
.

>

PanJ,
Panjamapong Sermsawatsri
Тел. (+66) 869761168

@lpakula Ах, есть еще одна вещь, которую ваше изображение web:newest должно также учитывать заголовок X-Real-IP . nginx не будет автоматически менять IP-адрес отправителя, он просто отправляет заголовок подсказки.

@ pi0 @PanJ
В этом есть смысл, спасибо, ребята!

Привяжите порт, используя режим хоста.

nginx поддерживает прозрачность IP с помощью модуля ядра TPROXY .

@stevvooe Может ли Docker делать что-то подобное?

nginx поддерживает прозрачность IP с помощью модуля ядра TPROXY.
@stevvooe Может ли Docker делать что-то подобное?

Маловероятно, поскольку запись необходимо отслеживать по узлам. Я разрешаю @sanimej или @mavenugo.

Может ли swarm предоставить REST API для получения IP-адреса клиента?

@tonysongtl , не

Еще кое-что, что следует учитывать, - это то, как ваш трафик доставляется на ваши узлы в высокодоступной настройке. Узел должен иметь возможность отключаться, не создавая ошибок для клиентов. Текущая рекомендация заключается в использовании внешнего балансировщика нагрузки (ELB, F5 и т. Д.) И балансировки нагрузки на уровне 4 для каждого узла Swarm с простой проверкой работоспособности уровня 4. Я считаю, что F5 использует SNAT, поэтому лучший случай в этой конфигурации - захватить единственный IP-адрес вашего F5, а не реальный IP-адрес клиента.

Использованная литература:
https://docs.docker.com/engine/swarm/ingress/#configure -an-external-load-balancer
https://success.docker.com/Architecture/Docker_Reference_Architecture%3A_Docker_EE_Best_Practices_and_Design_Considerations
https://success.docker.com/Architecture/Docker_Reference_Architecture%3A_Universal_Control_Plane_2.0_Service_Discovery_and_Load_Balancing

отражение комментария выше - можно ли не использовать протокол прокси? Все облачные балансировщики нагрузки и haproxy используют это для сохранения исходного IP-адреса.

В Calico также есть режим ipip - https://docs.projectcalico.org/v2.2/usage/configuration/ip-in-ip - это одна из причин, по которой github его использует. https://githubengineering.com/kubernetes-at-github/

Привет.

Для понимания и полноты позвольте мне подвести итог и, пожалуйста, поправьте меня, если я ошибаюсь:

Основная проблема заключается в том, что контейнеры не получают исходный src-IP, а рой VIP. Я воспроизвел эту проблему по следующему сценарию:

create docker swarm
docker service create --name web --publish 80:80 nginx
access.log source IP is 10.255.0.7 instead of client's browser IP

Похоже, что это:

Когда службы внутри роя используют сетку (по умолчанию), роя выполняет NAT, чтобы гарантировать, что трафик из одного источника всегда отправляется на одну и ту же запущенную службу хоста?
Следовательно, он теряет исходный src-IP и заменяет его служебным VIP-адресом swarm.

Кажется, предложения @kobolog https://github.com/moby/moby/issues/25526#issuecomment -258660348 и @dack https://github.com/moby/moby/issues/25526#issuecomment -260813865 были отклонены @sanimej https://github.com/moby/moby/issues/25526#issuecomment -280722179 https://github.com/moby/moby/issues/25526#issuecomment -281289906 но, TBH, его аргументы не совсем ясны для я еще не понимаю, почему поток не был закрыт, если это окончательно невозможно.

@sanimej , разве это не сработает ?:

1. Swarm получает сообщение с src-IP = A и destination = "my-service-virtual-address"
2. Пакет отправляется на узел роя, на котором запущена эта служба, инкапсулируя исходное сообщение msg.
3. Узел переадресовывает задачу, меняя место назначения на IP-адрес контейнера, выполняющего эту службу
   Swarm и узлы могут поддерживать таблицы, чтобы гарантировать, что трафик из одного источника перенаправляется на один и тот же узел, когда это возможно.

Разве возможность включения «обратного прокси вместо NAT» для определенных сервисов не решила бы все эти проблемы, устраивая всех?

С другой стороны, IIUC, единственный оставшийся вариант - использовать https://docs.docker.com/engine/swarm/services/#publish -a-services-ports-direct-on-the-swarm-node, который -again IIUC- похоже, что я вообще не использую сетку, поэтому

Спасибо за вашу помощь и терпение.
С Уважением

@sanimej
Более того ... почему Docker не просто выполняет NAT с переадресацией портов (меняя только IP / порт назначения)?

1. Swarm получает сообщение "от A до myservice"
2. Swarm пересылает сообщение на хост, на котором запущена эта служба, устанавливая dest = node1
3. Узел 1 получает сообщение «от А к узлу 1» и пересылает настройку dest = container1
4. Container1 получает сообщение «от A до container1»
5. Для ответа контейнер использует маршрут шлюза по умолчанию

Я просто хочу вмешаться; хотя я понимаю, что нет простого способа сделать это, отсутствие сохранения исходного IP-адреса каким-либо образом серьезно затрудняет ряд сценариев использования приложений. Вот некоторые из них, которые я могу придумать в своей голове:

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

• Во многих приложениях безопасности вам необходимо иметь доступ к исходному IP-адресу, чтобы разрешить динамическое занесение в черный список на основе злоупотребления услугами.

• Службам определения местоположения часто требуется доступ к IP-адресу, чтобы определить общее местоположение пользователя, когда другие методы не работают.

Из того, что я читал в этой теме, мне не кажется, что данный обходной путь работает очень хорошо, когда вы хотите иметь масштабируемые службы в Docker Swarm. Ограничение одного экземпляра на рабочий узел значительно снижает гибкость предложения. Кроме того, поддержка гибридного подхода, когда LB / Proxy на границе работает как неорганизованный контейнер, не связанный с Swarm, перед подачей в оркестрованные контейнеры Swarm кажется возвращением во времени. Почему пользователю необходимо поддерживать 2 разные парадигмы для оркестровки сервисов? Как насчет возможности динамического масштабирования LB / Proxy на границе? Это нужно делать вручную, верно?

Может ли команда Docker рассмотреть эти комментарии и посмотреть, есть ли способ реализовать эту функциональность, сохранив при этом качество и гибкость, присутствующие в экосистеме Docker?

Кроме того, я сейчас страдаю от этого. У меня есть веб-приложение, которое перенаправляет авторизованные / аутентифицированные запросы на следующий веб-сервер. Наши специалисты по обслуживанию должны иметь возможность проверять, достигли ли люди подчиненного сервера, для которого они хотели бы использовать журналы веб-доступа. В текущем сценарии у меня нет возможности предоставить эту функциональность, поскольку мой прокси-сервер никогда не видит исходный IP-адрес. Я хочу, чтобы мое приложение было легко масштабируемым, и не похоже, что я смогу сделать это с помощью представленных обходных путей, по крайней мере, без добавления новых виртуальных машин для каждого масштабируемого экземпляра.

@Jitsusama может ли Kubernetes решить вашу проблему?

@thaJeztah есть ли способ

Я пытался

`services:
  math:
    build: ./math
    restart: always
    ports:
    - target: 12555
      published: 12555
      mode: host

Но, похоже, в качестве исходного IP-адреса используется 172.xx1.

@trajano , я понятия не имею. Удалось ли Kubernetes как-то обойти эту проблему?

@Jitsusama
Да, у них есть документация о том, как они сохраняют исходный IP . Это функционально, но не очень красиво, если вы не используете балансировщик нагрузки, поскольку пакет теряется на узлах без этих конечных точек. Если вы планируете использовать Rancher в качестве автономного балансировщика нагрузки, к сожалению, в настоящее время он еще не поддерживает его .

@trajano

Но, похоже, в качестве исходного IP-адреса используется 172.xx1.

Если вы обращаетесь к своему приложению локально, этот IP-адрес должен быть правильным (если вы используете swarm), поскольку docker_gwbridge - это интерфейс, который взаимодействует с вашим прокси-контейнером. Вы можете попробовать получить доступ к приложению с другого компьютера в вашей IP-сети, чтобы узнать, правильно ли оно улавливает адрес.

Что касается обходного пути Compose, это возможно. Здесь я использую изображение jwilder/nginx-proxy качестве обратного прокси-сервера внешнего интерфейса (для упрощения концепций) вместе с официальным образом сборки nginx в качестве серверной службы. Разворачиваю стек в Docker Swarm Mode:

version: '3.3'

services:

  nginx-proxy:
    image: 'jwilder/nginx-proxy:alpine'
    deploy:
      mode: global
    ports:
      - target: 80
        published: 80
        protocol: tcp
        mode: host
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro

  nginx:
    image: 'nginx:1.13.5-alpine'
    deploy:
      replicas: 3
    ports:
      - 80
      - 443
    environment:
      - VIRTUAL_HOST=website.local

$ echo '127.0.0.1 website.local' | sudo tee -a /etc/hosts

$ docker stack deploy --compose-file docker-compose.yml website

Это создаст для стека сеть website_default . Моя конечная точка определена в переменной среды VIRTUAL_HOST и доступ к http://website.local дает мне:

website_nginx-proxy.0.ny152x5l9sh7<strong i="30">@Sherry</strong>    | nginx.1    | website.local 172.18.0.1 - - [08/Sep/2017:21:33:36 +0000] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36"

website_nginx.1.vskh5941kgkb<strong i="33">@Sherry</strong>    | 10.0.1.3 - - [08/Sep/2017:21:33:36 +0000] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36" "172.18.0.1"

Обратите внимание, что конец заголовка для website_nginx.1.vskh5941kgkb содержит намек на исходный IP-адрес ( 172.18.0.1 ). X-Forwarded-For и X-Real-IP по умолчанию установлены в nginx.tmpl из jwilder/nginx-proxy .

Для порта 443 мне не удалось добавить оба порта в файл docker-compose, поэтому я просто использую:

docker service update website_nginx-proxy \
    --publish-rm 80 \
    --publish-add "mode=host,published=80,target=80" \
    --publish-rm 443 \
    --publish-add "mode=host,published=443,target=443" \
    --network-add "<network>"

а также добавление сетей, которые я хочу использовать для обратного прокси с приложениями, содержащими переменную среды VIRTUAL_HOST . Более подробные параметры доступны в документации для jwilder/nginx-proxy , или вы можете создать свою собственную настройку.

Контроллеры Ingress в Kubernetes, по сути, делают то же самое, поскольку диаграммы входа (обычно) имеют поддержку X-Forwarded-For и X-Real-IP с немного большей гибкостью с выбором и типом входов, а также их репликами развертывания.

Так что документация по кубернетам не полная. Другой способ, который
довольно часто это протокол ingress + proxy.

https://www.haproxy.com/blog/haproxy/proxy-protocol/

Протокол прокси - это широко распространенный протокол, сохраняющий исходный код.
Информация. Haproxy имеет встроенную поддержку протокола прокси. Nginx
может читать, но не может вводить протокол прокси.

После настройки протокола прокси вы можете получить доступ к этой информации из любого
нисходящие услуги, такие как
https://github.com/nginxinc/kubernetes-ingress/blob/master/examples/proxy-protocol/README.md

Даже openshift использует это для получения информации об исходном IP.
https://docs.openshift.org/latest/install_config/router/proxy_protocol.html

Это последний вход haproxy для k8s, который внедряет протокол прокси.

ИМХО, способ сделать это в рое - сделать входной доступ для чтения прокси
протокол (в случае, если он получает трафик от восходящего LB, имеющего
уже введенный протокол прокси), а также вводить протокол прокси
информация (в случае, если весь трафик действительно попадает на вход первым).

Я не сторонник того, чтобы делать это по-другому, особенно когда есть
общепринятый стандарт для этого.

Traefik добавил поддержку proxy_protocol несколько недель назад и доступен начиная с v1.4.0-rc1.

Это нужно сделать на уровне входа docker swarm. Если вход
не вводит данные протокола прокси, ни одна из нижестоящих служб
(включая traefix, nginx и т. д.) смогут его прочитать.

10 сентября 2017 г. в 21:42 "monotykamary" [email protected] написал:

Traefik добавил поддержку proxy_protocol
https://github.com/containous/traefik/pull/2004 несколько недель назад и
доступно начиная с v1.4.0-rc1.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-328352805 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsU3jj5dJcpMDysjIyGQK7SGx8GwWbks5shApqgaJpZM4Jf2WK
.

Я также не понимаю, как эта ошибка связана с инфракитом. например, https://github.com/docker/infrakit/pull/601 может кто-нибудь прокомментировать направление, в котором будет двигаться рой докеров?

Будет ли рой накапливаться в инфракит? Мне особенно нравится входящий поток.

Мы тоже сталкиваемся с этой проблемой. Мы хотим знать IP-адрес клиента и запрашиваемый IP-адрес для входящих подключений. Например, если пользователь выполняет необработанное TCP-соединение с нашим сервером, мы хотим знать, какой у него IP-адрес и к какому IP-адресу на нашей машине он подключился.

@blazedd Как

IIUC, есть некоторый прогресс в улучшении того, как ingress справляется с этим, но на самом деле это единственное решение.

Мы завершили развертывание нашей службы nginx, используя режим публикации и

@mostolog Спасибо за ответ. Несколько примечаний:

1. publishMode вообще не решает проблему. Входящее соединение сокета по-прежнему разрешается в локальную сеть, которую устанавливает роя. По крайней мере, когда вы используете список портов mode: host
2. nginx самом деле не лучшее решение. Наше приложение основано на TCP, но не является веб-сервером. Нет никаких заголовков, которые мы могли бы использовать без ручного кодирования.
3. Если я использую docker run --net=host ... все работает нормально.
4. Единственное решение, которое я видел до сих пор, - это использовать: https://github.com/moby/moby/issues/25873#issuecomment -319109840

@blazedd В нашем стеке есть:

    ports:
      - target: 80
        published: 80
        protocol: tcp
        mode: host

и поэтому я готов поспорить, что мы получаем реальные IP-адреса в наших журналах.

@mostolog Это не работает, по крайней мере, в Windows. Я все еще получаю адрес 172.0.0.x в качестве источника.

@mostolog mode: host не предоставляет ваш контейнер сети хоста. Он удаляет контейнер из входной сети, как обычно работает Docker при запуске контейнера. Это будет копировать --publish 8080:8080 используемое в команде запуска докера. Если nginx получает реальные IP-адреса, это не результат прямого подключения сокета к этим IP-адресам. Чтобы проверить это, вам следует серьезно подумать об использовании необработанной реализации TCP или HTTP-сервера без фреймворка и проверить указанный адрес.

Почему бы не использовать сеть маршрутов IPVS к контейнеру напрямую? связать все IP-адреса оверлейного интерфейса узла Swarm как виртуальные IP-адреса, использовать ip rule from xxx table xxx для создания мультишлюза, затем узлы Swarm могут направлять клиента в контейнер напрямую (DNAT), без какого-либо демона сетевого прокси-сервера в пользовательском пространстве (dockerd)

@blazedd Вы пробовали? Я получаю внешние IP-адреса, следуя примеру @mostolog .

Я снова сталкиваюсь с этой проблемой.

Моя установка выглядит следующим образом:

• балансировщик нагрузки ipvs в режиме DR (внешний по отношению к рою докеров)
• 3 узла докеров, с IP-адресом назначения, добавленным ко всем узлам, и arp, настроенным соответствующим образом для маршрутизации IPVS DR

Я хотел бы развернуть стек в рое и заставить его прослушивать порт 80 на виртуальном IP-адресе, не изменяя адреса.

Я почти могу добраться туда, сделав следующее:
порты:
- Цель: 80
опубликовано: 80
протокол: tcp
режим: хост

Проблема здесь в том, что он не позволяет вам указать, к какому IP-адресу привязываться - он просто привязывается ко всем. Это создает проблемы, если вы хотите запускать более одной службы, используя этот порт. Его нужно привязать только к одному IP. Использование разных портов не является вариантом с балансировкой нагрузки аварийного восстановления. Похоже, что разработчики сделали предположение, что один и тот же IP-адрес никогда не будет существовать на нескольких узлах, что не относится к использованию балансировщика нагрузки DR.

Кроме того, если вы используете короткий синтаксис, он проигнорирует привязанный IP-адрес и по-прежнему будет привязан ко всем адресам. Единственный способ привязки к одному IP-адресу, который я нашел, - запуск некластеризованного контейнера (не службы или стека).

Итак, теперь я вернулся к тому, чтобы использовать автономные контейнеры и управлять ими самостоятельно, вместо того, чтобы полагаться на функции службы / стека для этого.

У нас такая же проблема.
Я бы проголосовал за прозрачное решение в Docker Ingress, которое позволило бы всем приложениям (некоторые из которых использовали необработанный UDP / TCP, но не особенно HTTP) работать должным образом.

Я мог бы использовать обходной путь «режим = публикация порта хоста», поскольку моя служба развернута глобально.
Однако кажется, что это несовместимо с использованием сетевого драйвера macvlan, который мне нужен по другим причинам.
Мы получаем логи типа «драйвер macvlan не поддерживает сопоставление портов».
Я пробовал использовать несколько сетей, но это не помогло.

Я создал конкретный билет здесь: https://github.com/docker/libnetwork/issues/2050
На данный момент это не оставляет мне никакого решения: '(

Привет, народ
Есть ли на данный момент обходной путь? Без публикации порта хоста
порт?

11 января 2018 г., 00:03, «Оливье Вортман» [email protected] написал:

У нас такая же проблема.
Я бы проголосовал за прозрачное решение в Docker Ingress, которое позволило бы всем
приложения (некоторые используют необработанный UDP / TCP, не особенно HTTP) для работы как
ожидал.

Я мог бы использовать обходной путь "режим = публикация порта хоста", поскольку моя служба
развернуты по всему миру.
Однако кажется, что это несовместимо с использованием macvlan
сетевой драйвер, который мне нужен по другим причинам.
Мы получаем логи типа «драйвер macvlan не поддерживает сопоставление портов».
Я пробовал использовать несколько сетей, но это не помогло.

Я создал конкретный билет здесь: docker / libnetwork # 2050
https://github.com/docker/libnetwork/issues/2050
На данный момент это не оставляет мне никакого решения: '(

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-356693751 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsUzlM-BMbEsDYAiYH6hKLha-aRqerks5tJQJngaJpZM4Jf2WK
.

Очень жаль, что нет возможности получить IP клиента. это делает непригодными для использования большинство хороших функций docker swarm.

В моей настройке единственный способ получить IP-адрес клиента - использовать network_mode:host и вообще не использовать рой.

использование mode=host port publishing или традиционного docker run -p "80:80" ... не сработало

Некоторые решения были предложены в https://github.com/moby/moby/issues/15086, но единственное решение, которое сработало для меня, было "хост-сетью" ...

Другая проблема, связанная с отсутствием правильного IP-адреса, заключается в том, что ограничение скорости nginx не работает правильно и, следовательно, не может использоваться с балансировщиком нагрузки docker swarm, потому что запросы ограничены по скорости и отклоняются, поскольку nginx считает их все, поскольку они исходят от одного пользователя / IP. Таким образом, единственным обходным решением является использование mode = host, но в этом случае я теряю возможности балансировки нагрузки и мне приходится указывать DNS на определенные экземпляры.

Возможно, докер не идеальный инструмент для этой работы, я искал бродягу, чтобы настроить передние HTTP-серверы и поместить клиентский IP как часть заголовков HTTP-запросов.

Пока Docker не сможет передавать наложенные сети с информацией о клиентах, можно использовать прокси, например Docker Flow Proxy или Traefik, публиковать нужные порты в режиме хоста в этой службе и подключать к нему службы приложений. Не полное решение, но работает довольно хорошо и позволяет балансировать нагрузку служб приложений / получать IP-адрес клиента.

@ deeky666 Traefik и подобные работают, только если не докеризованы

Я не вижу поддержки удо на traefik

отправлено из моего Айфона

Наконец мы отказались от контейнера докеров. Это не готово к производству!

В среду, 24 января 2018 г., в 5:43, Efrain [email protected] написал:

Я не вижу поддержки удо на traefik

отправлено из моего Айфона

>

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-360091189 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AHf7rvMcH2iFBxcExfO_Ol0UttCspuTnks5tNwlkgaJpZM4Jf2WK
.

Проблема кажется частично решенной в 17.12.0-ce с помощью mode=host .

docker service create --publish mode=host,target=80,published=80 --name=nginx nginx

У него есть некоторые ограничения (нет сетки маршрутизации), но он работает!

@goetas mode=host какое-то время работал как обходной путь, поэтому я бы не сказал, что проблема каким-то образом решена. Использование mode = host имеет множество ограничений, порт открыт, нельзя использовать балансировку нагрузки роя и т. Д.

@darklow Я знаю ограничения, но для моего варианта использования это нормально (если не лучше!). В 17.09.1-ce вообще не работало, так что для меня это уже улучшение!

Большой недостаток этого обходного пути - невозможность избежать простоя во время обновления.
В настоящее время мы должны отказаться от стабильности или исходного IP-адреса.

Я согласен. Swarm нужен способ высокой доступности для сохранения исходного IP-адреса.

Вероятно, используя прокси-протокол. Я не думаю, что добавить
поддержка протокола прокси для docker swarm.

Кто-нибудь изучает это?

28 января 2018 г. в 22:39 «Генки Такиучи» [email protected] написал:

Большой недостаток этого обходного пути - невозможность избежать падения
время во время обновления.
В настоящее время мы должны отказаться от стабильности или исходного IP-адреса.
адрес.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-361078416 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsU-or7fnhKTg7fhjtZYjGYHBFRE7Dks5tPKnYgaJpZM4Jf2WK
.

@sandys Я согласен. Протокол прокси был бы отличной идеей.
@thaJeztah @aluzzardi @mrjana, пожалуйста, не могли бы вы обратить внимание на эту проблему? Некоторое время не было ответа от команды. Спасибо.

Протокол Proxy кажется мне лучшим решением. Надеюсь, команда его рассмотрит.

@goetas это сработало в какой-то момент, по крайней мере, я видел, как это работает, но, похоже, он снова вернулся к поведению 172.xxx в докере 1.12.6

Это ОЧЕНЬ плохо, это смягчает любые ограничения скорости, предотвращение мошенничества, регистрацию, безопасный вход, мониторинг сеансов и т. Д.!
Прослушивание в режиме: хост работает, но не является реальным решением, поскольку вы теряете балансировку нагрузки сетки, и только программное обеспечение loadbalanacer на хосте с общедоступным IP-адресом должно обрабатывать весь трафик в одиночку.

это очень критическая и важная ошибка для нас, которая мешает нам начать работу со Swarm. Мы также считаем, что протокол прокси - правильное решение для этого. Вход Docker должен передавать исходный IP-адрес по протоколу прокси.

В твиттере было предложено одно из решений - использовать Traefik в качестве входящего трафика, управляемого вне Swarm . Это крайне неоптимально для нас - и не является накладными расходами, которыми мы хотели бы управлять.

Если разработчики Swarm хотят узнать, как реализовать протокол прокси в Swarm-ingress, они должны проверить все ошибки, обсуждаемые в Traefik (например, https://github.com/containous/traefik/issues/2619)

Я добился того, чтобы это работало постоянно, используя режим «составить», а не режим роения. Может, над чем подумать.

Некоторые проблемы с протоколом прокси:

Он декодируется самим докером или приложением? Если мы полагаемся на приложение для реализации протокола прокси, то это не общее решение для всех приложений и работает только для веб-серверов или других приложений, реализующих протокол прокси. Если докер разворачивает протокол прокси и переводит адрес, ему также необходимо будет отслеживать состояние соединения и выполнять обратную трансляцию исходящих пакетов. Я не сторонник веб-решения (полагающегося на прокси-протокол в приложении), поскольку докер также полезен для многих не веб-приложений. Эта проблема должна быть решена для общего случая любого приложения TCP / UDP - ничто другое в докере не является веб-зависимостью.

Как и в случае любого другого метода инкапсуляции, существует проблема размера пакета / MTU. Однако я думаю, что это, вероятно, будет проблемой практически при любом решении этой проблемы. Ответом на этот вопрос, скорее всего, будет то, что ваша сеть роя поддерживает достаточно большой MTU, чтобы учесть накладные расходы. Я думаю, что большинство роев работают в локальных сетях, так что это, вероятно, не является серьезной проблемой.

@trajano - мы знаем, что это работает с сетью хостов (что, вероятно, делает ваше решение для создания сочинений). Однако это отбрасывает все преимущества роя кластерных сетей (например, балансировку нагрузки).

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

прокси-протокол получил широкое распространение. проверьте количество поддерживаемых инструментов - https://www.haproxy.com/blog/haproxy/proxy-protocol/
он даже не охватывает балансировщики облачной нагрузки (ELB, Google LB) и новые инструменты, такие как Traefik.

Также - это в значительной степени стандарт в кубернетах: https://github.com/kubernetes/ingress-nginx#proxy -protocol

На данный момент протокол прокси является наиболее широко распространенным стандартом для решения этой проблемы. Я не вижу большой ценности в том, чтобы изобретать это заново и нарушать совместимость с мировыми nginx.

Это протоколы L7. Вход в рой - L4. Здесь ничего не изобретается заново, это все IPVS с использованием DNAT.

@ cpuguy83 не понял, что вы только что имели в виду.

Протокол прокси - это уровень 4.
http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

Цель протокола PROXY - заполнить внутренние структуры сервера
информация, собранная прокси, которую сервер мог бы получить
сам по себе, если клиент подключается непосредственно к серверу, а не через
прокси. Информация, передаваемая протоколом, - это та информация, которую сервер может
используйте getsockname () и getpeername ():

• семейство адресов (AF_INET для IPv4, AF_INET6 для IPv6, AF_UNIX)
• протокол сокета (SOCK_STREAM для TCP, SOCK_DGRAM для UDP)
• адреса источника и назначения уровня 3
• порты источника и назначения уровня 4, если таковые имеются

http://cbonte.github.io/haproxy-dconv/1.9/configuration.html#5.1 -accept-proxy

accept-proxy

Обеспечивает использование протокола PROXY для любого соединения, принимаемого любым из
сокеты, объявленные в той же строке. Версии 1 и 2 протокола PROXY
поддерживаются и правильно обнаруживаются. Протокол PROXY определяет уровень
3/4 адреса входящего соединения, которые будут использоваться везде, где есть адрес.
используется, за исключением правил "TCP-запрос соединения", которые будут
видеть только реальный адрес подключения. Журналы будут отражать адреса
указывается в протоколе, если он не нарушен, и в этом случае реальный
адрес все равно будет использоваться. Это ключевое слово в сочетании с поддержкой со стороны
компоненты могут быть использованы как эффективная и надежная альтернатива
X-Forwarded-For механизм, который не всегда надежен и даже не всегда
годный к употреблению. См. Также «Ожидаемый прокси-сервер соединения tcp-запроса» для более подробной информации.
настройка клиента, которому разрешено использовать протокол.

Вы имели в виду, что есть способ лучше, чем прокси-протокол? это вполне возможно, и хотелось бы узнать больше в контексте сохранения исходного IP-адреса в Docker Swarm. Однако протокол прокси более широко поддерживается другими инструментами (такими как nginx и т. Д.), Которые будут ниже по течению для входа роя ... а также такими инструментами, как AWS ELB, которые будут восходящим потоком для входа роя. Это были мои всего 0,02 доллара.

@sandys Протокол прокси выглядит как инкапсуляция (по крайней мере, при инициации соединения), которая требует знания инкапсуляции от получателя на всем протяжении стека. У этого подхода есть много компромиссов.

Я бы не хотел поддерживать это в ядре, но, возможно, стоит сделать подключаемый вход Ingress.

@sandys https://github.com/sandys Протокол прокси выглядит так:
инкапсуляция (по крайней мере, при инициации соединения), требующая знаний
инкапсуляции от приемника до конца стека. Там
есть много компромиссов для этого подхода.

Это правда. В значительной степени поэтому это стандарт RFC. Есть
тем не менее, за этим стоит импульс - практически каждый компонент важен
поддерживает это. ИМХО неплохое решение поддержать его.

Я бы не хотел поддерживать это в ядре, но, возможно, сделаю вход
pluggable будет стоящим подходом.

Это более широкое обсуждение, однако я могу добавить, что самый большой
Преимущество Docker Swarm перед другими в том, что в нем есть все батарейки
встроенный.

Я все еще прошу вас рассматривать протокол прокси как отличное решение для
эта проблема имеет поддержку в отрасли.

Невозможно смоделировать маршрутизатор L3 на Linux и LxC (не конкретно на докере)

@trajano Для решения этой проблемы не требуется симуляция, а инкапсуляция.
Например, опция (например: --use-proxy-protocol ) может быть предоставлена ​​для служб, которым нужен IP-адрес клиента и которые знают, как обращаться с инкапсулированными пакетами, такими как nginx.

В настоящее время узел докера, который получает пакет, выполняет SNAT и пересылает пакет на узел с контейнером приложения. Если вместо SNAT использовалась какая-либо форма туннелирования / инкапсуляции, тогда должна быть возможность передать исходный неизмененный пакет приложению.

Это решенная проблема в других проектах. Например, с OpenStack вы можете использовать такие туннели, как GRE и VXLAN.

Есть ли здесь кто-нибудь из недавней части этой темы, чтобы представлять команду докеров и, по крайней мере, сказать, что «мы вас слышим»? Кажется, что функция, которую вы ожидали увидеть «из коробки» и представляющая такой интерес для сообщества, все еще не решена после первого сообщения о ней 9 августа 2016 года, примерно 18 месяцев назад.

Есть ли здесь кто-нибудь из недавней части этой темы, чтобы представлять команду докеров и, по крайней мере, сказать, что «мы вас слышим»?

/ cc @GordonTheTurtle @thaJeztah @riyazdf @aluzzardi

@bluejaguar @ruudboon Я являюсь частью Docker. Это хорошо известная проблема. Прямо сейчас сетевая команда сосредоточена на давних ошибках с наложенной сетевой стабильностью. Вот почему в последних нескольких выпусках действительно не было новых сетевых функций.

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

@ cpuguy83 Я https://github.com/kubernetes/kubernetes/issues/42616 (PS, что интересно, прокси-протокол здесь поступает из Google Kubernetes Engine, который изначально поддерживает протокол прокси в режиме HTTPS).

Кроме того, в ноябре 2017 года ELB добавила поддержку Proxy Protocol v2 (https://docs.aws.amazon.com/elasticloadbalancing/latest/network/doc-history.html)

Openstack Octavia LB-as-a-service (аналогично нашему входу) объединенный протокол прокси в апреле прошлого года - http://git.openstack.org/cgit/openstack/octavia/commit/?id=bf7693dfd884329f7d1169eec33eb03d2ae81ace

Вот часть документации по протоколу прокси в openstack - https://docs.openshift.com/container-platform/3.5/install_config/router/proxy_protocol.html
Некоторые нюансы связаны с прокси-протоколом для https (в обоих случаях, когда вы завершаете сертификаты при входе или нет).

Есть какие-нибудь обновления / обходные пути по этой проблеме? нам действительно нужно знать ip клиента в режиме docker swarm.
Любая помощь приветствуется.

Моя версия:

Клиент:
Версия: 18.02.0-ce
Версия API: 1.36
Версия Go: go1.9.3
Git commit: fc4de44
Построен: Ср 7 Фев 21:16:33 2018
ОС / Arch: Linux / amd64
Экспериментальный: ложь
Оркестратор: рой

Сервер:
Двигатель:
Версия: 18.02.0-ce
Версия API: 1.36 (минимальная версия 1.12)
Версия Go: go1.9.3
Git commit: fc4de44
Построен: 7 фев, среда, 21:15:05 2018
ОС / Arch: Linux / amd64
Экспериментальный: ложь

@adijes и другие пользователи, столкнувшиеся с этой проблемой. Вы можете привязать контейнеры к сети bridge (как упомянуто кем-то в этом потоке).

version: "3.4"

services:
  frontend:
    image: nginx
    deploy:
      placement:
        constraints:
          - node.hostname == "prod1"
    networks:
      - default
      - bridge
  # backed services...
  # ...

networks:
  bridge:
    external:
      name: bridge

Наш frontend привязан к bridge и всегда остается на конкретном хосте, чей IP привязан к нашему общедоступному домену. Это позволяет ему получать реальный IP-адрес пользователя. И поскольку он также привязан к сети default , он сможет подключаться к поддерживаемым службам.

Вы также можете масштабировать frontend , пока вы сохраняете его живым на этом единственном хосте. Это делает хост единственной точкой отказа, но (я думаю) это нормально для небольшого сайта.

Отредактировано для добавления дополнительной информации:

Мои контейнеры nginx находятся за https://github.com/jwilder/nginx-proxy , я также использую https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion для включения SSL. Nginx-proxy запускается с помощью команды docker run , а не с помощью службы docker swarm. Возможно, поэтому я получил от клиентов настоящий IP. Сеть bridge необходима для того, чтобы мои контейнеры nginx могли взаимодействовать с nginx-proxy.

FWIW, я использую:

Client:
 Version:      17.09.1-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   19e2cf6
 Built:        Thu Dec  7 22:23:40 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.1-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   19e2cf6
 Built:        Thu Dec  7 22:25:03 2017
 OS/Arch:      linux/amd64
 Experimental: false

Вышеупомянутая установка также работает с другой установкой, которая работает:

Client:
 Version:      17.09.1-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   19e2cf6
 Built:        Thu Dec  7 22:23:40 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.1-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   19e2cf6
 Built:        Thu Dec  7 22:25:03 2017
 OS/Arch:      linux/amd64
 Experimental: false

@ letientai299 , который у меня не работает, я получаю

сетевой «мост» объявлен как внешний, но он не попадает в нужную область: «локальный» вместо «рой»

у меня есть мастер и три рабочих узла

@trajano , смотрите мое обновление.

@ letientai299 на самом деле мне было интересно, как вы заставили bridge работать в режиме роя . т.е. вы не получили ошибку, которая у меня есть.

@dack, когда вы говорите "сеть хостов", я полагаю, вы имеете в виду наличие

ports:
- target: 12555
  published: 12555
  protocol: tcp
  mode: host

К сожалению, при запуске в режиме docker stack deploy он не работает и по-прежнему теряет исходный IP-адрес, тогда как docker-compose up работает правильно.

Я также пробовал следующее на основе @goetas

docker service create --constraint node.hostname==exposedhost \
  --publish published=12555,target=12555,mode=host \
  trajano.net/myimage

По-прежнему не удается получить исходный IP-адрес, это на Server Version: 17.12.0-ce

Похоже, что в какой-то момент все захотят, и поскольку использование оверлейных сетей вместе с сетью мост / хост на самом деле невозможно, это блокировщик в тех случаях, когда вам действительно нужен IP-адрес клиента по разным причинам.

Клиент:
Версия: 17.12.0-ce
Версия API: 1.35
Версия Go: go1.9.2
Git commit: c97c6d6
Построен: Ср 27 Дек, 20:03:51 2017
ОС / Arch: darwin / amd64

Сервер:
Двигатель:
Версия: 17.12.1-ce
Версия API: 1.35 (минимальная версия 1.12)
Версия Go: go1.9.4
Git commit: 7390fc6
Построен: Вт 27 Фев, 22:17:54 2018
ОС / Arch: Linux / amd64
Экспериментально: правда

Сейчас 2018 год. Что-нибудь новенькое по этому поводу?
В режиме роя я не могу использовать ограничение nginx req. $ remote_addr всегда ловил 10.255.0.2.
Это действительно серьезная проблема с докером.
Возможно, с сегодняшнего дня мне стоит попробовать кубернеты.

@Maslow Я разместил там, где мы всего несколькими комментариями выше.

Можем ли мы расслабить чек на

networks:
  bridge:
    external:
      name: bridge

или расширить его как

networks:
  bridge:
    external:
      name: bridge
      scope: local

и scope: local сети разрешены, только если сетевой режим host

сетевой «мост» объявлен как внешний, но он не попадает в нужную область: «локальный» вместо «рой»

или разрешить

networks:
  bridge:
    driver: bridge

Чтобы не потерпеть неудачу с

не удалось создать службу trajano_serv: ответ об ошибке от демона: сетевой trajano_bridge не может использоваться со службами. Могут использоваться только сети, относящиеся к рою, например, созданные с помощью драйвера оверлея.

при наличии mode: host на опубликованных портах.

ports:
- target: 32555
  published: 32555
  protocol: tcp
  mode: host

@trajano. Вы можете использовать сети без области видимости с роем ... например, это работает:

version: '3.4'

services:
  test:
    image: alpine
    command: top
    ports:
      - target: 32555
        published: 32555
        protocol: tcp
        mode: host
    networks:
      - bridge

networks:
  bridge:
    external:
      name: bridge

Вы тестировали это на рое с более чем одним воркером с развертыванием стека докеров. Я знаю, что это работает с compose.

18 марта 2018 г. в 20:55 Брайан Гофф [email protected] написал:

@trajano. Вы можете использовать сети без области видимости с роем ... например, это работает:

версия: '3.4'

Сервисы:
тестовое задание:
изображение: альпийский
команда: сверху
порты:
- Цель: 32555
опубликовано: 32555
протокол: tcp
режим: хост
сети:
- мост

сети:
мост:
внешний:
имя: мост
-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

Да, через рой делаю ...

В пн, 19 марта 2018 г., в 9:12, Архимед Траяно <
[email protected]> написал:

Вы тестировали это на рое с более чем одним воркером со стеком докеров?
развертывать. Я знаю, что это работает с compose.

18 марта 2018 г., в 20:55, Брайан Гофф [email protected]
написал:

@trajano Вы уже можете использовать сети без
например, это работает:

версия: '3.4'

Сервисы:
тестовое задание:
изображение: альпийский
команда: сверху
порты:

• цель: 32555
  опубликовано: 32555
  протокол: tcp
  режим: хост
  сети:
• мост

сети:
мост:
внешний:
имя: мост
-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-374206587 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAwxZsm3OohKL0sqUWhlgUNjCrqR0OaVks5tf67YgaJpZM4Jf2WK
.

-

• Брайан Гофф

+1

Имея эту проблему со следующей балансировкой нагрузки роя докеров с 3 узлами:

наложение сети <-> nginx proxy jwilder docker <-> nginx web head docker

Я следил за предложениями, и журналы продолжают возвращать IP-адрес сети докеров 10.255.0.3 вместо реального IP-адреса клиента.

+1

@ cpuguy83, это стало

Вы имеете представление о расчетном времени прибытия? это нам очень поможет.

@sandys Расчетное время прибытия для чего именно?

@ cpuguy83 привет, спасибо за ответ. Я знаю, что нет широкого согласия о том, как вы хотите решить эту проблему. Я как бы комментирую, как команда была занята проблемами стабильности и не освобождена от этой проблемы.
Когда вы думаете, что этот вопрос будет рассмотрен (если вообще)?

Обратите внимание, что вы можете решить эту проблему, запустив глобальную службу и опубликовав порты с помощью PublishMode = host. Если вы знаете, к какому узлу будут подключаться люди, вам это даже не нужно, просто используйте ограничение, чтобы привязать его к этому узлу.

@kleptog Частично нет. Это не может избежать простоев при обновлении сервиса.

Тестовый сценарий - подробнее lvs / ipvs.

• nsenter в скрытый входящий контейнер и удалите правило snat
• nsenter в службу с опубликованными портами, удалите gw по умолчанию и добавьте маршрут по умолчанию для IP-адресов входящих контейнеров.

Теперь исходный ip будет сохранен.

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

Извините за мою наивность, но может ли кто-нибудь ( @dack ?)

Ах, теперь я понял. В многоузловом рое IP должен быть директором lvs, чтобы найти путь обратно к нужному узлу, на который пришел запрос ...

Хотя было бы интересно увидеть код в любом случае. Это могло бы сэкономить мне время, если бы кто-нибудь уже знал. Спасибо

Любые обновления по этому поводу, наличие трех кластеров в разных странах, и даже диспетчер трафика Azure нуждается в реальном IP-адресе пользователя, если нет, он не будет перенаправлять пользователя в хороший кластер и т. Д. Кто-нибудь, скоро или когда-либо, проверит это? Спасибо

Также нужно обновить это - это огромная ошибка - единственный способ, который я нашел вокруг этого, - это добавить еще один прокси впереди и отправить x-forwarded-for в стек, что означает, что Swarm не является вариантом для общедоступных столкновение с трафиком для многих сценариев.

@ cpuguy83 @trajano
Я могу подтвердить, что следующее не работает

version: '3.4'
services:
  nginx:
    ports:
      - mode: host
        protocol: tcp
        published: 80
        target: 80
      - mode: host
        protocol: tcp
        published: 443
        target: 81
networks:
  bridge:
    external:
      name: bridge

Это не удается с network "bridge" is declared as external, but it is not in the right scope: "local" instead of "swarm" .

версия докера

Client:
 Version:       18.03.0-ce-rc4
 API version:   1.37
 Go version:    go1.9.4
 Git commit:    fbedb97
 Built: Thu Mar 15 07:33:59 2018
 OS/Arch:       windows/amd64
 Experimental:  false
 Orchestrator:  swarm

Server:
 Engine:
  Version:      18.03.0-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.4
  Git commit:   0520e24
  Built:        Wed Mar 21 23:08:31 2018
  OS/Arch:      linux/amd64
  Experimental: false

@ Mobe91
Попробуйте воссоздать рой. У меня тоже была ошибка. После повторной инициализации у меня все заработало.
Мой docker-compose.yml файл:

version: "3.6"

services:
    nginx:
        image: nginx:latest
        depends_on:
            - my-app
            - my-admin
        ports: 
            - target: 80
              published: 80
              protocol: tcp
              mode: host
            - target: 443
              published: 443
              protocol: tcp
              mode: host
            - target: 9080
              published: 9080
              protocol: tcp
              mode: host
        volumes:
            - /etc/letsencrypt:/etc/letsencrypt:ro
            - /home/project/data/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
            - /home/project/data/nginx/conf.d:/etc/nginx/conf.d
            - /home/project/public:/var/public
        networks:
            - my-network
            - bridge
        deploy:
            placement:
                constraints: [node.role == manager]

    my-app:
        image: my-app
        ports:
            - 8080:8080
        volumes:
            - /usr/src/app/node_modules
            - /home/project/public:/usr/src/app/public
        networks:
            - my-network

    my-admin:
        image: my-admin
        ports:
            - 9000:9000
        networks:
            - my-network

networks:
    my-network:
    bridge:
        external: true
        name: bridge

мой docker version :

Client:
 Version:   18.03.0-ce
 API version:   1.37
 Go version:    go1.9.4
 Git commit:    0520e24
 Built: Wed Mar 21 23:10:01 2018
 OS/Arch:   linux/amd64
 Experimental:  false
 Orchestrator:  swarm

Server:
 Engine:
  Version:  18.03.0-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.4
  Git commit:   0520e24
  Built:    Wed Mar 21 23:08:31 2018
  OS/Arch:  linux/amd64
  Experimental: false

Извините за мой английский.

@ Mobe91 это то, что я использовал, но развертываю из «portainer» или на машине Linux. Я не могу правильно развернуть его из Windows.

version: '3.4'
services:
  hath:
    image: trajano.net/hath
    deploy:
      placement:
        constraints:
        - node.hostname==docker-engine
    networks:
    - host
    ports:
    - target: 12555
      published: 12555
      protocol: tcp
      mode: host
    secrets:
    - hath_client_login
    volumes:
    - hath:/var/lib/hath
volumes:
  hath:
    name: 'noriko/s/hath'
    driver: cifs
networks:
  host:
    external:
      name: host
secrets:
  hath_client_login:
    external:
      name: hath_client_login

Ключевое отличие заключается в том, что я использую host а не bridge В моем случае я также использую свои хосты как виртуальные машины VirtualBox, и я использую маршрутизатор, который выполняет маршрутизацию NAT и полностью сохраняет входящий IP-адрес. контейнер.

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

@trajano прав, проблема была с клиентом Windows, развертывание с клиентом Linux сработало.

Но я не понимаю, зачем вам вообще нужна сеть host или bridge ?
Для меня отлично работает следующее, т.е. я получаю реальные IP-адреса клиентов в nginx:

version: '3.4'
services:
  nginx:
    ports:
      - mode: host
        protocol: tcp
        published: 80
        target: 80

@ Mobe91, спасибо. Я хотел поднять вопрос по этому поводу. В основном связывайтесь с https://github.com/moby/moby/issues/32957, поскольку это все еще происходило с клиентом 18.03-ce для Windows.

кто-нибудь использовал ресничку? http://cilium.readthedocs.io/en/latest/gettingstarted/docker/ .

Кажется, что это можно исправить, не привязывая службы к хосту.

@sandys хорошая находка - собираюсь начать тестировать, у вас сработало? Я собираюсь вытащить nginx из своего роя, если не смогу это исправить ...

Мы достигли этого при перепроектировании нашего развертывания, чтобы избежать привязки прокси к отдельным хостам (которые в производственной среде привязываются к интерфейсу по другим причинам и, следовательно, «забирают» клиентский IP-адрес в качестве побочного продукта).

В нашей тестовой среде мы можем улучшить только путем развертывания для менеджеров по ограничению и установки mode = global чтобы гарантировать, что каждый менеджер получит работающий экземпляр. Это все еще дополнительные накладные расходы, о которых нужно знать, особенно если мы потеряем узел-менеджер, и что-то направляет на него наш трафик. Однако это лучше, чем быть привязанным к одному хосту.

@sandys вы пробовали Cilium? Похоже на Weave, который, похоже, страдает той же проблемой, по крайней мере, с k8s: https://github.com/kubernetes/kubernetes/issues/51014

Мне не удалось использовать ресничку, но я обратился к ресничке
разработчикам, чтобы помочь в конфиге роя. Но я очень взволнован по поводу реснички
потому что проникновение - это заявленная проблема, которую он хочет решить (в отличие от плетения)

10 мая 2018 г., 17:24 Джеймс Грин, [email protected] написал:

Мы достигли этого, изменив наше развертывание, чтобы избежать привязки прокси к
отдельные хосты (которые в процессе производства привязываются к интерфейсу для других
причин и, следовательно, "подцепить" клиентский IP как побочный продукт).

В нашей тестовой среде мы можем улучшить, только развернув менеджерам
ограничение и установка mode = global, чтобы каждый менеджер получил
запущенный экземпляр. Это все еще лишние накладные расходы, о которых нужно знать,
особенно если мы потеряем узел-менеджер и что-то направляет наши
трафик к нему. Однако это лучше, чем быть привязанным к одному хосту.

@sandys https://github.com/sandys вы пробовали Cilium? Похоже на
Weave, который, похоже, страдает той же проблемой, по крайней мере, с k8s:
кубернетес / кубернетес # 51014
https://github.com/kubernetes/kubernetes/issues/51014

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-388032011 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsUzQCgIeTenQIHIERxOfHKCzn1O6Aks5txCpogaJpZM4Jf2WK
.

10 мая 2018 г. в 17:24 "Джеймс Грин" на [email protected] написал:

Мы достигли этого, изменив наше развертывание, чтобы избежать привязки прокси к
отдельные хосты (которые в процессе производства привязываются к интерфейсу для других
причин и, следовательно, "подцепить" клиентский IP как побочный продукт).

В нашей тестовой среде мы можем улучшить, только развернув менеджерам
ограничение и установка mode = global, чтобы каждый менеджер
пример. Это все еще дополнительные накладные расходы, о которых нужно знать, особенно если
мы теряем узел-менеджер, и что-то направляет на него наш трафик.
Однако это лучше, чем быть привязанным к одному хосту.

@sandys https://github.com/sandys вы пробовали Cilium? Похоже на
Weave, который, похоже, страдает той же проблемой, по крайней мере, с k8s:
кубернетес / кубернетес # 51014
https://github.com/kubernetes/kubernetes/issues/51014

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-388032011 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsUzQCgIeTenQIHIERxOfHKCzn1O6Aks5txCpogaJpZM4Jf2WK
.

• 1

Привет, народ,
если вам нужна поддержка Docker Swarm в Cilium (особенно для ingress и
вокруг этой конкретной проблемы), прокомментируйте / поставьте лайк по этой ошибке -
https://github.com/cilium/cilium/issues/4159

Пт, 11 мая 2018 г., в 00:59, McBacker [email protected] написал:

>

• 1

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-388159466 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsU_18F_cNttRUaAwaRF3gVpMZ-3qSks5txJUfgaJpZM4Jf2WK
.

у меня с текущей версией это работает так:
Затем я могу получить доступ к другим узлам в рое, поскольку он также находится в сети по умолчанию

  web-server:
    image: blabla:7000/something/nginx:latest
    #ports:
    #  - "80:80"
    #  - "443:443"
    ports:
      - target: 80
        published: 80
        protocol: tcp
        mode: host
      - target: 443
        published: 443
        protocol: tcp
        mode: host        
    deploy:
      mode: global
      restart_policy:
        condition: any
      update_config:
        parallelism: 1
        delay: 30s

Я могу подтвердить, что ключ заключается в использовании ports.mode: host . Из документации (https://docs.docker.com/compose/compose-file/#long-syntax-1):

режим: хост для публикации порта хоста на каждом узле или вход для порта режима роя для балансировки нагрузки.

Затем, используя mode: host перестанет балансировать нагрузку по входу, и появится реальный IP-адрес. В качестве примера, вот мои логи nginx:

• с mode: host
metrics-agents_nginx.1.pip12ztq3y1h<strong i="14">@xxxxxxxx</strong> | 62.4.X.X - - [12/Jun/2018:08:46:04 +0000] "GET /metrics HTTP/1.1" 200 173979 "-" "Prometheus/2.2.1" "-" [CUSTOM] "request_time: 0.227" remote_addr: 62.4.X.X proxy_add_x_forwarded_for: 62.4.X.X

• без mode: host
metrics-agents_nginx.1.q1eosiklkgac<strong i="20">@xxxxxxxx</strong> | 10.255.0.2 - - [12/Jun/2018:08:50:04 +0000] "GET /metrics HTTP/1.1" 403 162 "-" "Prometheus/2.2.1" "-" [CUSTOM] "request_time: 0.000" remote_addr: 10.255.0.2 proxy_add_x_forwarded_for: 10.255.0.2

И если вам интересно, почему последний журнал является ответом 403 Forbidden, это связано с использованием белого списка на nginx ( allow 62.4.X.X и deny all ).

Контекст:
Description: Debian GNU/Linux 9.4 (stretch)
Docker version 18.03.0-ce, build 0520e24

Я подтверждаю то, что сказал @nperron .
Использование режима хоста позволяет получить IP-адрес клиента.

Докер версии 18.03.1-ce, сборка 9ee9f40
Ubuntu 16.04.4 LTS

Я могу подтвердить, что он работает.

Докер версии 18.03.1-ce, сборка 9ee9f40
Ubuntu 16.04.4 LTS

ПРЕДОСТЕРЕЖЕНИЕ: ЭТО НЕ БУДЕТ РАБОТАТЬ, ЕСЛИ ВЫ УСТАНОВИЛИ IPTABLES = FALSE!
Возможно, вы сделали это (или, по крайней мере, это сделал я), если вы используете UFW для защиты портов и обнаружили, что рой докеров переопределяет эти настройки UFW.

Есть несколько руководств, в которых предлагается установить iptables = false с помощью команды или в /etc/docker/daemon.json.

Надеюсь, это избавит кого-то от разочарования, которое я только что пережил!

люди действительно должны перестать говорить «Mode: host» = работает, потому что он не использует Ingress. Это делает невозможным иметь только один контейнер со службой, работающей в рое, но при этом иметь возможность доступа к нему через любой хост. Вы должны либо сделать службу «глобальной», либо получить к ней доступ только на том хосте, на котором она запущена, что в некотором роде противоречит цели Swarm.

TL; DR: "Mode: Host" - это обходной путь, а не решение

@ r3pek Хотя я согласен с вами, что вы теряете Ingress, если используете режим Host для решения этой проблемы, я бы сказал, что он вряд ли побеждает всю цель Swarm, который делает гораздо больше, чем общедоступная входящая сеть. В нашем сценарии использования мы имеем тот же наложенный рой:
реплицированные контейнеры для управления, доступ к которым должен осуществляться только через интрасеть -> им не нужен IP-адрес вызывающего абонента, поэтому они настроены «нормально» и используют входящий трафик.
неоткрытые контейнеры -> нечего сказать о них (я полагаю, вы недооцениваете возможность доступа к ним через их имя службы).
общедоступная служба -> это прокси-сервер nginx, который выполняет маршрутизацию на основе https и URL-адресов. Он был определен как глобальный еще до того, как потребовалось выполнить x-forward для реального IP-адреса клиента, поэтому реальной проблемы здесь нет.

Наличие глобального nginx и отсутствие входа означает, что вы можете получить к нему доступ через любой IP-адрес кластера, но он не сбалансирован по нагрузке и не устойчив к сбоям, поэтому мы добавили очень, очень дешевый и простой в настройке L4 Azure Load Balancer перед nginx. услуга.

Как вы говорите, Host - это обходной путь, но сказать, что его включение полностью противоречит цели Docker Swarm, немного преувеличено.

Привет Роберто
Я не думаю, что это преувеличение - потому что режим хоста показывает отдельные точки
неудачи. Более того, он ожидает дополнительных уровней управления нагрузкой.
балансировка вне экосистемы роя.

Сказав, что вы сами использовали azure lb, вы как бы подтвердили, что
аргумент.

Это равносильно тому, чтобы сказать, что «для запуска роя с распространением клиентского IP,
убедитесь, что вы используете внешний балансировщик нагрузки, который вы настроили ... Или используйте
один из облачных сервисов ».

Мы не говорим, что это не временный обходной путь ... Но это было бы
игнорируя обещание Swarm, если мы все категорически не признаем
недостаток.

Вт, 5 июля 2018 г., 14:16 Роберто Фабрици, [email protected]
написал:

@ r3pek https://github.com/r3pek Пока я согласен с вами, что вы проигрываете
Ingress, если вы используете режим хоста для решения этой проблемы, я бы сказал, что это
вряд ли побеждает всю цель Swarm, который делает гораздо больше, чем
общедоступная входная сеть. В нашем сценарии использования мы имеем тот же
оверлейный рой:
управление реплицированными контейнерами, доступ к которым должен осуществляться только через
интрасеть -> им не нужен ip звонящего, поэтому они настроены
"нормально" и воспользуйтесь входом.
закрытые контейнеры -> об этом нечего сказать (я полагаю, что вы
недооценивают силу возможности получить к ним доступ через их службу
имя хоть).
публичный контейнер -> это прокси nginx, который делает https и url
маршрутизация на основе. Он был определен как глобальный еще до того, как возникла необходимость в x-forward-for.
реальный ip клиента, так что проблем нет.

Наличие глобального nginx и отсутствие входа означает, что вы можете получить к нему доступ через
любой IP-адрес кластера, но он не сбалансирован по нагрузке, поэтому мы добавили очень-очень
дешево и легко настроить L4 Azure Load Balancer перед nginx
услуга.

Как вы говорите, Host - это обходной путь, но говоря, что включение его полностью
поражение цели Docker Swarm немного преувеличено imo.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-402650066 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsU_ogRzwM6X0PMknXxsxmZLLTtfraks5uDdJlgaJpZM4Jf2WK
.

Понятно, что для входа Docker Swarm был выбран плохой балансировщик нагрузки (IPVS). Если бы он поддерживал хотя бы протокол прокси L4, это не было бы проблемой. За исключением того, что это все равно будет балансировщик нагрузки L4 (TCP) без всех дополнительных функций, которые может дать L7 lb.

В Kubernetes есть балансировщики нагрузки L4 (TCP) -L7 (HTTP), такие как nginx ingress , haproxy ingress, которые позволяют использовать прокси-протокол L4 или HTTP-заголовки L7, чтобы гарантировать, что X-Forwarded-For используется для передачи реального пользователя. IP на бэкэнд.

Мне интересно, что сказали бы разработчики Docker Swarm ingress. Наверное, кому-то нужно перенести этот кейс на https://github.com/docker/swarmkit/issues ?

В Kubernetes есть балансировщики нагрузки L4 (TCP) -L7 (HTTP), такие как вход nginx, вход haproxy, которые позволяют использовать протокол прокси L4 или заголовки HTTP L7, чтобы гарантировать, что X-Forwarded-For используется для передачи реального IP-адреса пользователя. на бэкэнд.

AFAICS, эти LB-сервисы не встроены в K8s, а сервисы, которые необходимо явно развернуть. То же самое можно сделать

Насколько мне известно, разница в том, что даже если вы развернете такую ​​службу балансировки нагрузки, она будет «вызываться» из балансировщика нагрузки swarmkit, и вы потеряете IP-адрес пользователей. Таким образом, вы не можете отключить балансировщик нагрузки swarmkit, если не используете hostmode.

честно говоря - в k8s возможен кастомный вход. в рое это
не является.

swarm утверждает, что все «встроено». То же самое и с
сетей - в k8s нужно настроить weave и т.д ... в swarm он встроен.

Итак, вопрос, который подчеркивает Андрей (и я вроде как согласен с ним), заключается в том, что -
swarm должен сделать эти функции частью входящего трафика, поскольку у пользователя есть
нет контроля над этим.

В субботу, 28 июля 2018 г., в 17:07 Seti [email protected] написал:

Насколько я знаю, разница в том, что если вы развернете такой
сервис балансировки нагрузки, он будет `` вызван '' из балансировщика нагрузки swarmkit
и так вы теряете айпи пользователей. Значит вы не можете отключить роевой набор
loadbalancer, если не используется hostmode.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-408601274 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsU1-Ism_S1Awml8lO8N0Aq6rtrLH4ks5uLEzugaJpZM4Jf2WK
.

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

Я использую свой стек в рое с одним узлом и буду делать это по крайней мере в течение следующих нескольких месяцев. Можете ли вы порекомендовать наименее плохой обходной путь для нашего текущего варианта использования (рой с одним узлом)? Я не могу обойтись без клиентского IP - слишком много на него полагается.

Наш временный подход заключался в том, чтобы запустить простой прокси-контейнер в «глобальном» режиме (который IIRC может получить фактический IP-адрес сетевой карты), а затем перенаправить все подключения к внутренней службе, работающей в оверлейной сети Swarm, с добавленными заголовками прокси.

Если вам достаточно получить заголовок x-forwarded-for, эта настройка должна работать AFAICT.

Спасибо, @maximelb. Что у вас получилось (например, nginx, haproxy)?

@jamiejackson , вот где все будет по-другому. В нашем случае мы запускаем сервер, на котором размещаются длительные SSL-соединения и настраиваемый двоичный протокол под ним, поэтому HTTP-прокси были невозможны. Поэтому мы создали простой сервер пересылки TCP и использовали заголовок «msgpack», который можно было распаковать вручную на внутреннем сервере.

Я не очень хорошо знаком с HTTP-прокси, но подозреваю, что большинство из них подойдут для вас. : - /

привет Максим,
это очень интересно для нас. Можете ли вы поделиться своими docker-compose любыми
шанс ?

Я пытаюсь понять, как это работает. Сегодня у нас nginx как реверс
прокси (как услуга) и несколько сервисов докеров, стоящих за ним.

В вашем случае - становится ли nginx прокси "глобального режима"? или это
специальный перенаправитель TCP. Таким образом, при масштабировании количества узлов прокси-сервер пересылки
идет на каждом узле. Я как-то подумал, что в этой ситуации х-форвард для
заголовок теряется .. потому что входящая сеть убивает внешний IP
(поскольку прокси-протокола нет).

Мы будем очень благодарны, если вы поможете нам с более подробной информацией.

С уважением
Sandeep

В среду, 8 августа 2018 г., 7:18 Максим Ламот-Брассар <
[email protected]> написал:

Наш временный подход заключался в запуске простого прокси-контейнера в
«Глобальный» режим (который IIRC может получить фактический IP-адрес сетевой карты), а затем его
перенаправить все соединения на внутреннюю службу, работающую в рое
наложенная сеть с добавленными заголовками прокси.

Если вам достаточно заголовка x-forwarded-for, эта настройка должна
работать AFAICT.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-411257087 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsUx3DOjXb79FNjsuZ-RZVqkkhHAbYks5uOkOHgaJpZM4Jf2WK
.

@sandys конечно, вот отрывок из нашей docker-compose с соответствующими контейнерами.

Это запись для создания докеров обратного прокси:

reverseproxy:
    image: yourorg/repo-proxy:latest
    networks:
      - network_with_backend_service
    deploy:
      mode: global
    ports:
      - target: 443
        published: 443
        protocol: tcp
        mode: host

Это запись серверной службы:

backendservice:
    image: yourorg/repo-backend:latest
    networks:
      - network_with_backend_service
    deploy:
      replicas: 2

Целью обратного прокси (серверной части) будет tasks.backendservice (у которого есть записи A для каждой реплики). Вы можете пропустить часть networks если серверная служба находится в оверлейной сети роя по умолчанию.

Бит global говорит: «Разверните этот контейнер ровно один раз на каждом узле роя Docker. Порты mode: host говорят« привязать к собственному сетевому адаптеру узла ».

Надеюсь, это поможет.

Вы используете режим хоста. Итак, у вас есть внешний балансировщик нагрузки
перед всем этим.
Вы больше не можете зависеть от Swarm, потому что находитесь в режиме хоста.

На самом деле это проблема, о которой мы говорим некоторое время :(

В среду, 8 августа 2018 г., 20:47 Максим Ламот-Брассар, <
[email protected]> написал:

@sandys https://github.com/sandys конечно, вот выдержка из нашего
docker-compose с соответствующими контейнерами.

Это запись для создания докеров обратного прокси:

обратный прокси:
изображение: yourorg / repo- прокси: последний
сети:
- network_with_backend_service
развертывать:
режим: глобальный
порты:
- Цель: 443
опубликовано: 443
протокол: tcp
режим: хост

Это запись серверной службы:

бэкэндсервис:
изображение: yourorg / repo- backend: latest
сети:
- network_with_backend_service
развертывать:
реплик: 2

Целью обратного прокси (серверной части) будет
tasks.backendservice (у которого есть записи A для каждой реплики). Вы можете
пропустите сетевую часть, если серверная служба находится в рое по умолчанию
наложенная сеть.

Глобальный бит говорит: «Разверните этот контейнер ровно один раз на каждом Docker.
узел роя. Режим портов: host - это тот, который говорит "привязать к родному
NIC узла ».

Надеюсь, это поможет.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-411442155 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsU8N7KAFtOp_cPO8wpbBQqzDfpBWOks5uOwEkgaJpZM4Jf2WK
.

Не на 100% уверен в том, что вы имеете в виду, но внешне мы используем DNS с записью A для каждого узла кластера. Это обеспечивает дешевую «балансировку» без внешней подвижной части. Когда клиент делает запрос, он выбирает случайную запись A и подключается к 443 на одном из узлов кластера.

Там обратный прокси, который работает на этом конкретном узле и прослушивает 443, получает собственное соединение, включая фактический IP-адрес клиента. Затем этот обратный прокси-контейнер добавляет заголовок и перенаправляет соединение другому внутреннему контейнеру, используя наложенную сеть роя (tasks.backend). Поскольку он использует цель tasks.backend, он также получит случайную запись A для внутренней службы.

Таким образом, в строгом смысле, это обход магии оверлейной сети, которая перенаправляет соединение. Вместо этого он как бы воспроизводит это поведение с обратным прокси-сервером и добавляет заголовок. Конечный эффект тот же (в широком смысле), что и магия оверлейной сети. Он также делает это параллельно с запуском роя, что означает, что я могу запускать все мои другие службы, которым не требуется клиентский IP-адрес в том же кластере, не делая для них ничего другого.

Ни в коем случае не идеальное решение, но до тех пор, пока не будет исправлено (если вообще когда-либо), оно обойдется без внешних компонентов или основной конфигурации докеров.

@jamiejackson "наименее плохой" обходной путь, который мы нашли, - это использование Traefik в качестве глобальной службы в режиме хоста. В их документации есть хороший
https://github.com/containous/traefik/issues/1880

Надеюсь это поможет. Мы также не можем использовать решение, которое не позволяет нам проверять фактические IP-адреса запрашивающего, поэтому мы застреваем с этим исправлением kludge, пока что-то не изменится. Похоже, это довольно распространенная потребность, по крайней мере, из соображений безопасности.

Понятно (и мы используем это в сокращенной версии).

Однако повестка дня этой конкретной ошибки заключалась в том, чтобы запросить разработчиков
чтобы встроить это в волшебную оверлейную сеть (возможно, используя прокси
протокол или другие механизмы)

В среду, 8 августа 2018 г., 21:22 Максим Ламот-Брассар, <
[email protected]> написал:

Не на 100% уверен в том, что вы имеете в виду, но внешне мы используем DNS с буквой A.
запись на узел кластера. Это обеспечивает дешевую «балансировку» без
внешняя подвижная часть. Когда клиент делает запрос, он выбирает случайный A
запись и подключиться к 443 на одном из узлов кластера.

Там обратный прокси, который работает на этом конкретном узле, и
прослушивание 443 получает собственное соединение, включая фактический IP-адрес клиента.
Затем этот обратный прокси-контейнер добавляет заголовок и перенаправляет соединение.
в другой внутренний контейнер с использованием оверлейной сети роя
(tasks.backend). Поскольку он использует цель tasks.backend, он также получит
random Запись для внутренней службы.

Таким образом, в строгом смысле, это обход магии оверлейной сети, которая
перенаправляет соединение. Вместо этого он как бы воспроизводит это поведение с помощью
обратный прокси и добавляет заголовок. Конечный эффект тот же (в
свободный смысл) как магия оверлейной сети. Он также делает это в
параллельно с запуском роя, то есть я могу запускать все остальные службы, которые
не требовать IP-адрес клиента в том же кластере, ничего не делая
остальное для тех.

Ни в коем случае не идеальное решение, но до тех пор, пока не будет исправлено (если вообще когда-либо), оно получит
без внешних компонентов или основной конфигурации докеров.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-411455384 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsU5RKjGc3hEk6bk-doicDa1MbYGAyks5uOwlIgaJpZM4Jf2WK
.

TBH Я не уверен, почему входная сеть не исправляется для добавления IP
данные в протоколе прокси.

Он инкрементный, он не сломает существующие стеки, это хорошо определенный
стандарт, он широко поддерживается даже крупными поставщиками облачных услуг, он широко
поддерживается фреймворками приложений.

Это значительные усилия разработчиков?

В среду, 8 августа 2018 г., 21:30 Мэтт Глейзер, [email protected] написал:

@jamiejackson https://github.com/jamiejackson "наименее плохой"
Обходной путь, который мы нашли, - использование Traefik в качестве глобальной службы в режиме хоста.
В их документах есть хороший общий пример
https://docs.traefik.io/user-guide/cluster-docker-consul/#full-docker-compose-file_1 .
Мы видели некоторые ошибки, которые могут быть связаны, а могут и не быть связаны с этой настройкой, но
Traefik - отличный проект, и он кажется довольно стабильным на Swarm. Есть
целая ветка на странице их проблем (которая возвращается сюда :)), с
похожие обходные пути:
содержит / traefik # 1880
https://github.com/containous/traefik/issues/1880

Надеюсь это поможет. Мы также не можем использовать решение, которое не позволяет нам
проверьте фактические IP-адреса запрашивающих, чтобы мы застряли с этим исправлением kludge, пока
что-то меняется. Кажется, это довольно распространенная потребность из соображений безопасности.
по меньшей мере.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-411458326 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsU7NNbsW44L95VYCvlyL_Bje-h6L9ks5uOwsUgaJpZM4Jf2WK
.

Что ж, Docker в настоящее время не затрагивает входящий трафик, так что, по крайней мере, его можно добавить.
Имейте в виду, что это проект с открытым исходным кодом, если вы действительно чего-то хотите, то, как правило, вам решать, как это реализовать.

+1, это действительно остановка.
Я считаю, что большинству приложений нужен реальный IP-адрес клиента. Просто подумайте о стеке почтовых серверов - вы не можете позволить себе принимать почту с произвольных хостов.

Мы переключились в режим хоста экземпляра глобального потока proxy_protocol nginx, который перенаправляет реплицируемое приложение proxy_nginx. На данный момент это работает достаточно хорошо.

глобальный сервис nginx_stream

stream {
    resolver_timeout 5s;
    # 127.0.0.11 is docker swarms dns server
    resolver 127.0.0.11 valid=30s;
    # set does not work in stream module, using map here
    map '' $upstream_endpoint {
        default proxy_nginx:443;
    }

    server {
        listen 443;
        proxy_pass $upstream_endpoint;
        proxy_protocol on;
    }
}

служба реплицирована nginx_proxy

server {
    listen 443 ssl http2 proxy_protocol;
    include /ssl.conf.include;

    ssl_certificate /etc/nginx/certs/main.crt;
    ssl_certificate_key /etc/nginx/certs/main.key;

    server_name example.org;

    auth_basic           "closed site";
    auth_basic_user_file /run/secrets/default.htpasswd;

    # resolver info in nginx.conf
    set $upstream_endpoint app;
    location / {
        # relevant proxy_set_header in nginx.conf
        proxy_pass http://$upstream_endpoint;
    }
}

Можно ли пропустить всю конфигурацию nginx для nginx_stream и
nginx_proxy со своими конфигами Swarm?

Это здорово, если работает!

Вт, 11 сентября 2018 г., 17:14 rubot, [email protected] написал:

Мы перешли на экземпляр глобального потока proxy_protocol nginx, который
перенаправление в реплицированное приложение proxy_nginx. Это работает достаточно хорошо
на момент.

глобальный сервис nginx_stream

транслировать {
resolver_timeout 5 с;
# 127.0.0.11 это dns сервер docker swarms
резолвер 127.0.0.11 действительный = 30 с;
# set не работает в модуле потока, здесь используется карта
map '' $ upstream_endpoint {
по умолчанию proxy_ nginx: 443;
}

server {
    listen 443;
    proxy_pass $upstream_endpoint;
    proxy_protocol on;
}

}

служба реплицирована nginx_proxy

server {
прослушать 443 ssl http2 proxy_protocol;
включить /ssl.conf.include;

ssl_certificate /etc/nginx/certs/main.crt;
ssl_certificate_key /etc/nginx/certs/main.key;

server_name example.org;

auth_basic           "closed site";
auth_basic_user_file /run/secrets/default.htpasswd;

# resolver info in nginx.conf
set $upstream_endpoint app;
location / {
    # relevant proxy_set_header in nginx.conf
    proxy_pass http://$upstream_endpoint;
}

}

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-420244262 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsU5K-gK09XdI9NxLlT36IrJP7U7_cks5uZ6IrgaJpZM4Jf2WK
.

@sandys У меня есть решение на основе haproxy для части протокола прокси, которое настраивается с помощью переменных среды.

Можно ли пропустить всю конфигурацию nginx для nginx_stream и nginx_proxy с их конфигурациями Swarm? Это здорово, если работает!

@sandys Примерно так:
https://gist.github.com/rubot/10c79ee0086a8a246eb43ab631f3581f

столкнувшись с той же проблемой, будет ли это решено? похоже на базовую функциональность, которую следует запланировать к выпуску.

развертывать:
режим: глобальный
порты:

• цель: 443 опубликовано: 443 протокол: tcp режим: хост

Следование этому совету устраняет проблему, поскольку балансировщик роя докеров теперь не участвует в уравнении.
Для меня это правильное решение, так как это все еще HA, и у меня уже был haproxy (внутри прокси-контейнера потока докеров).
Единственная проблема заключается в том, что статистика haproxy распределяется между всеми репликами, поэтому мне нужно как-то агрегировать эту информацию при мониторинге трафика для всего кластера. Раньше у меня был только один экземпляр haproxy, который стоял за балансировщиком docker swarm.
Ваше здоровье,
Жак

При чтении запроса OP ( @PanJ ) кажется, что текущие функции теперь решают эту проблему, как предлагалось в течение нескольких месяцев. OP не запрашивал входящую маршрутизацию + клиентский IP-адрес AFAIK, они запрашивали способ иметь службу роя в реплике / глобальном получении IP-адресов клиента, что теперь возможно. Этому способствуют две основные области улучшения:

1. Теперь мы можем создать службу Swarm, которая «публикует» порт для IP-адреса хоста, пропуская уровень входящей маршрутизации.
2. Эта же служба может одновременно подключаться к другим сетям, например, к наложению, поэтому она может получать доступ к другим службам с дополнительными преимуществами.

Для меня с двигателем 18.09 я получил лучшее из обоих миров при тестировании. Одна служба может подключаться к внутренним оверлейным сетям, а также публиковать порты на сетевом адаптере хоста и видеть реальный IP-адрес клиента, поступающий на IP-адрес хоста. Я использую это с обратным прокси-сервером traefik для регистрации клиентского IP-трафика в traefik, предназначенном для внутренних служб . Я чувствую, что это может решить большинство запросов, которые я видел для «регистрации реального IP».

@PanJ это решает за вас?

Ключ состоит в том, чтобы публиковать порты в mode: host а не в mode: ingress (по умолчанию).

Плюс к этому режиму заключается в том, что вы получаете реальный IP-адрес клиента и производительность NIC собственного хоста (поскольку он находится вне инкапсуляции IPVS AFAIK). Минус в том, что он будет прослушивать только узлы, на которых запущены реплики.

Для меня запрос «Я хочу использовать входящую IPVS-маршрутизацию, а также видеть IP-адрес клиента» - это другой запрос функции libnetwork.

Что здесь изменилось? Поскольку мы использовали режим хоста, чтобы сделать это для
уже давно. Фактически, это обходной путь, предложенный в этой теме как
хорошо.

Проблема в том, что, конечно, вы должны привязать эту службу к определенному
host, поэтому Swarm не может запланировать его в другом месте. Вот в чем была проблема
полностью - этот прокси-протокол / IPVS и т. д. решают эту проблему.

Пт, 4 января 2019 г., 09:34 Брет Фишер < [email protected] написал:

При чтении запроса OP ( @PanJ https://github.com/PanJ ) он
похоже, что текущие функции теперь решают эту проблему, как было предложено для
месяцы. OP не запрашивал входящую маршрутизацию + клиентский IP AFAIK, они спросили
для способа иметь службу роя в реплике / глобальном получении IP-адресов клиентов,
что теперь выполнимо. Этому способствуют две основные области улучшения:

1. Теперь мы можем создать сервис Swarm, который «публикует» порт для
   IP-адрес хоста, пропуская уровень входящей маршрутизации
2. Эта же услуга может подключаться к другим сетям, например наложением на
   в то же время, поэтому он может получить доступ к другим службам с дополнительными преимуществами

Для меня с двигателем 18.09 я получил лучшее из обоих миров при тестировании. А
единый сервис может подключаться к внутренним оверлейным сетям, а также публиковать
портов на сетевом адаптере хоста и увидеть реальный IP-адрес клиента, поступающий на IP-адрес хоста. я
используя это с обратным прокси traefik для регистрации клиентского IP-трафика в traefik
это предназначено для серверных служб
https://github.com/BretFisher/dogvscat/blob/7e9fe5b998f2cf86951df3f443714beb413d63fb/stack-proxy-global.yml#L75-L83 .
Я чувствую, что это могло бы решить большинство запросов, которые я видел для "регистрации реального
IP ".

@PanJ https://github.com/PanJ это решит для вас?

Ключ в том, чтобы публиковать порты в режиме: хост, а не в режиме: вход (
дефолт).

Плюсом этого режима является то, что вы получаете настоящий IP-адрес клиента и сетевой адаптер собственного хоста.
производительность (поскольку это вне инкапсуляции IPVS AFAIK). Минус это
будет прослушивать только узлы, на которых выполняются реплики.

Для меня запрос «Я хочу использовать входящую маршрутизацию IPVS, а также посмотреть
клиентский IP "- это запрос другой функции libnetwork.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451348906 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsUzs15UVWOVl54FLwBJSZJKX-9D0jks5u_tLPgaJpZM4Jf2WK
.

@BretFisher mode: host - это только обходной путь, но не решение. Поскольку @sandys сказал, что обходной путь имеет несколько предостережений, мы не должны рассматривать эту проблему как исправленную.

Я не уверен, есть ли какие-либо улучшения с тех пор, как было обнаружено обходное решение. Я перешел на Kubernetes довольно давно и до сих пор удивляюсь, что вопрос остается открытым более двух лет.

Я все еще удивлен, почему люди думают, что это ошибка. От моего
перспектива даже заявление о переходе на кубернетес не является адекватным
отвечать. Как я вижу, у Kubernetes точно такая же проблема / поведение. Вы либо
иметь внешний LB или использовать что-то вроде прокси-сервера nginx, который должен
запустить как демон. Пожалуйста, поправьте меня, если я ошибаюсь, но у нас то же самое
здесь точная ситуация, но здесь нет готового авторешения. Кто-нибудь мог
проверьте и упакуйте предложенное мной решение для потока TCP, описанное выше, чтобы получить
что-то вроде поведения прокси nginx. Просто прими, что рой должен быть
настроенный самостоятельно

PanJ [email protected] schrieb am Fr., 4 января 2019, 09:28:

@BretFisher https://github.com/BretFisher режим: host - это только
обходной путь, но не решение. Как @sandys https://github.com/sandys
сказал, что обходной путь имеет несколько предостережений, мы не должны рассматривать эту проблему
как исправлено.

Я не уверен, есть ли какие-либо улучшения, так как обходной путь был
обнаруженный. Я переехал в Kubernetes довольно давно и до сих пор остаюсь
удивлен, что вопрос все еще открыт более двух лет.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451382365 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK
.

Вы даже можете расширить проект dockerflow и добавить вариант nginx для запуска
kubernetes-ingressproxy для swarn. Определенно все это набито роем
поднял бы дополнительный системный контейнер, поскольку вы знаете, что есть куча
их с кубернетами. Разве это не сила роя за тонкий ресурс?
проекты быть бережливыми?

Ruben Nicolaides [email protected] schrieb am Fr., 4 января 2019 г., 09:48:

Я все еще удивлен, почему люди думают, что это ошибка. От моего
перспектива даже заявление о переходе на кубернетес не является адекватным
отвечать. Как я вижу, у Kubernetes точно такая же проблема / поведение. Вы либо
иметь внешний LB или использовать что-то вроде прокси-сервера nginx, который должен
запустить как демон. Пожалуйста, поправьте меня, если я ошибаюсь, но у нас то же самое
здесь точная ситуация, но здесь нет готового авторешения. Кто-нибудь мог
проверьте и упакуйте предложенное мной решение для потока TCP, описанное выше, чтобы получить
что-то вроде поведения прокси nginx. Просто прими, что рой должен быть
настроенный самостоятельно

PanJ [email protected] schrieb am Fr., 4 января 2019, 09:28:

@BretFisher https://github.com/BretFisher режим: host - это только
обходной путь, но не решение. Как @sandys https://github.com/sandys
сказал, что обходной путь имеет несколько предостережений, мы не должны рассматривать эту проблему
как исправлено.

Я не уверен, есть ли какие-либо улучшения, так как обходной путь был
обнаруженный. Я переехал в Kubernetes довольно давно и до сих пор остаюсь
удивлен, что вопрос все еще открыт более двух лет.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451382365 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK
.

Это сложные решения - протокол прокси просто добавляет дополнительный заголовок
информации и это очень известный стандарт - haproxy, nginx, AWS elb,
и т. д. все следуют за ним. https://www.haproxy.com/blog/haproxy/proxy-protocol/

Поверхность изменения будет ограничена встроенным Swarm.
ingress (где бы эта поддержка была добавлена). И у всех сервисов это будет
доступный.

Пт, 4 января 2019 г., 14:36 ​​rubot < [email protected] написал:

Вы даже можете расширить проект dockerflow и добавить вариант nginx для запуска
kubernetes-ingressproxy для swarn. Определенно все это набито роем
поднял бы дополнительный системный контейнер, поскольку вы знаете, что есть куча
их с кубернетами. Разве это не сила роя за тонкий ресурс?
проекты быть бережливыми?

Ruben Nicolaides [email protected] schrieb am Fr., 4 января 2019 г., 09:48:

Я все еще удивлен, почему люди думают, что это ошибка. От моего
перспектива даже заявление о переходе на кубернетес не является адекватным
отвечать. Как я вижу, у Kubernetes точно такая же проблема / поведение. Ты
или
иметь внешний LB или использовать что-то вроде прокси-сервера nginx, который должен
запустить как демон. Пожалуйста, поправьте меня, если я ошибаюсь, но у нас то же самое
здесь точная ситуация, но здесь нет готового авторешения. Кто-нибудь мог
проверьте и упакуйте предложенное мной решение для потока TCP, описанное выше, чтобы получить
что-то вроде поведения прокси nginx. Просто прими, что рой должен быть
настроенный самостоятельно

PanJ [email protected] schrieb am Fr., 4 января 2019, 09:28:

@BretFisher https://github.com/BretFisher режим: host - это только
обходной путь, но не решение. Как @sandys https://github.com/sandys
сказал, что обходной путь имеет несколько предостережений, мы не должны рассматривать это
проблема
как исправлено.

Я не уверен, есть ли какие-либо улучшения, так как обходной путь был
обнаруженный. Я перешел на Kubernetes довольно давно и до сих пор
быть
удивлен, что вопрос все еще открыт более двух лет.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451382365 или
немой
нить
<
https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK

.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451389574 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsU2FCEGFs5v6IOEy6AqjcBMl7IqEiks5u_xmTgaJpZM4Jf2WK
.

Как я уже сказал, проверьте решение потока tcp выше, которое уже использует прокси.
протокол.
Добавление прокси-протокола потребует также настройки внутри контейнера, если
добавлен в рой вверх по течению. Я не вижу никакой ценности, кроме чистящего средства, а может и лучше
задокументированная цель в вашем запросе

Сандип Сриниваса [email protected] schrieb am Fr., 4 января 2019 г.,
11:37:

Это сложные решения - протокол прокси просто добавляет дополнительный заголовок
информации и это очень известный стандарт - haproxy, nginx, AWS elb,
и т. д. все следуют за ним. https://www.haproxy.com/blog/haproxy/proxy-protocol/

Поверхность изменения будет ограничена встроенным Swarm.
ingress (где бы эта поддержка была добавлена). И у всех сервисов это будет
доступный.

Пт, 4 января 2019 г., 14:36 ​​rubot < [email protected] написал:

Вы даже можете расширить проект dockerflow и добавить вариант nginx в
Начните
kubernetes-ingressproxy для swarn. Определенно все это набито роем
поднял бы дополнительный системный контейнер, поскольку вы знаете, что есть куча
их с кубернетами. Разве это не сила роя за тонкий ресурс?
проекты быть бережливыми?

Ruben Nicolaides [email protected] schrieb am Fr., 4 января 2019 г., 09:48:

Я все еще удивлен, почему люди думают, что это ошибка. От моего
перспектива даже заявление о переходе на кубернетес не является адекватным
отвечать. Как я вижу, у Kubernetes точно такая же проблема / поведение. Ты
или
иметь внешний LB или использовать что-то вроде прокси-сервера nginx, который
должен
запустить как демон. Пожалуйста, поправьте меня, если я ошибаюсь, но у нас то же самое
здесь точная ситуация, но здесь нет готового авторешения. Кто-нибудь мог
проверьте и упакуйте предложенное мной решение для потока TCP, описанное выше, чтобы получить
что-то вроде поведения прокси nginx. Просто прими, что рой нужно
быть
настроенный самостоятельно

PanJ [email protected] schrieb am Fr., 4 января 2019, 09:28:

@BretFisher https://github.com/BretFisher режим: host - это только
обходной путь, но не решение. Как @sandys <
https://github.com/sandys>
сказал, что обходной путь имеет несколько предостережений, мы не должны рассматривать это
проблема
как исправлено.

Я не уверен, есть ли какие-либо улучшения, так как обходной путь был
обнаруженный. Я перешел на Kubernetes довольно давно и до сих пор
быть
удивлен, что вопрос все еще открыт более двух лет.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451382365 ,
или
немой
нить
<

https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK
>

.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451389574 или
немой
нить
<
https://github.com/notifications/unsubscribe-auth/AAEsU2FCEGFs5v6IOEy6AqjcBMl7IqEiks5u_xmTgaJpZM4Jf2WK

.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451409453 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAPgu83fSrSzfopOlDXsDooN1tMboGZaks5u_y8EgaJpZM4Jf2WK
.

Приведенное выше решение требует привязки к режиму хоста. Это большая проблема. Это
исключает возможность использования планировщика докеров для выделения контейнеров
к разным хостам - я больше не являюсь частью ячеистой сети.

Пт, 4 января 2019 г., 17:28 rubot < [email protected] написал:

Как я уже сказал, проверьте решение потока tcp выше, которое уже использует прокси.
протокол.
Добавление прокси-протокола потребует также настройки внутри контейнера, если
добавлен в рой вверх по течению. Я не вижу никакой ценности, кроме чистящего средства, а может и лучше
задокументированная цель в вашем запросе

Сандип Сриниваса [email protected] schrieb am Fr., 4 января 2019 г.,
11:37:

Это сложные решения - протокол прокси просто добавляет дополнительный заголовок
информации и это очень известный стандарт - haproxy, nginx, AWS elb,
и т. д. все следуют за ним. https://www.haproxy.com/blog/haproxy/proxy-protocol/

Поверхность изменения будет ограничена встроенным Swarm.
ingress (где бы эта поддержка была добавлена). И все сервисы будут
Это
доступный.

Пт, 4 января 2019 г., 14:36 ​​rubot < [email protected] написал:

Вы даже можете расширить проект dockerflow и добавить вариант nginx в
Начните
kubernetes-ingressproxy для swarn. Определенно все это упаковано
роиться
поднимет дополнительный системный контейнер, поскольку вы знаете, что есть куча
из
их с кубернетами. Разве это не сила роя за тонкий ресурс?
проекты быть бережливыми?

Ruben Nicolaides [email protected] schrieb am Fr., 4 января 2019 г., 09:48:

Я все еще удивлен, почему люди думают, что это ошибка. От моего
перспектива даже заявление о переходе на кубернетес не является
адекватный
отвечать. Как я вижу, у Kubernetes точно такая же проблема / поведение. Ты
или
иметь внешний LB или использовать что-то вроде прокси-сервера nginx, который
должен
запустить как демон. Пожалуйста, поправьте меня, если я ошибаюсь, но у нас есть
тем же
здесь точная ситуация, но здесь нет готового авторешения. Кто-то
мог
проверьте и упакуйте предложенное мной решение для потока TCP, описанное выше, чтобы получить
что-то вроде поведения прокси nginx. Просто прими, что рой нужно
быть
настроенный самостоятельно

PanJ [email protected] schrieb am Fr., 4 января 2019, 09:28:

@BretFisher https://github.com/BretFisher режим: хост только
а
обходной путь, но не решение. Как @sandys <
https://github.com/sandys>
сказал, что обходной путь имеет несколько предостережений, мы не должны рассматривать
это
проблема
как исправлено.

Я не уверен, есть ли какие-либо улучшения, поскольку обходной путь
был
обнаруженный. Я перешел на Kubernetes довольно давно и
еще
быть
удивлен, что вопрос все еще открыт более двух лет.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451382365 ,
или
немой
нить
<

https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK

>

.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451389574 или
немой
нить
<

https://github.com/notifications/unsubscribe-auth/AAEsU2FCEGFs5v6IOEy6AqjcBMl7IqEiks5u_xmTgaJpZM4Jf2WK
>

.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451409453 или
немой
нить
<
https://github.com/notifications/unsubscribe-auth/AAPgu83fSrSzfopOlDXsDooN1tMboGZaks5u_y8EgaJpZM4Jf2WK

.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451424992 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsU-q-I3fXVAP9JcGgTdJJOzI7b575ks5u_0HIgaJpZM4Jf2WK
.

Как я уже сказал, kubernetes nginx ingress также требует привязки к режиму хоста, называемого
демонсет. Внешний LB подключается к nodeports, для которых также требуется режим хоста
в сервисе или вручную настроить протокол прокси в сервисе. Kubernetes
по-прежнему решает те же проблемы.
С моей точки зрения, одним из возможных запросов функции для роя было бы:
сделать сетевого провайдера подключаемым. Это позволило бы использовать
другие методы, кроме lvs / iptables

Сандип Сриниваса [email protected] schrieb am Fr., 4 января 2019 г.,
13:05:

Приведенное выше решение требует привязки к режиму хоста. Это большая проблема. Это
исключает возможность использования планировщика докеров для выделения контейнеров
к разным хостам - я больше не являюсь частью ячеистой сети.

Пт, 4 января 2019 г., 17:28 rubot < [email protected] написал:

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

Сандип Шриниваса [email protected] schrieb am Fr., 4 января.
2019,
11:37:

Это сложные решения - протокол прокси просто добавляет дополнительные
заголовок
информации и это очень известный стандарт - haproxy, nginx, AWS
эльб
и т. д. все следуют за ним.
https://www.haproxy.com/blog/haproxy/proxy-protocol/

Поверхность изменения будет ограничена встроенным Swarm.
ingress (где бы эта поддержка была добавлена). И все сервисы будут
Это
доступный.

Пт, 4 января 2019 г., 14:36 ​​rubot < [email protected] написал:

Вы даже можете расширить проект dockerflow и добавить вариант nginx в
Начните
kubernetes-ingressproxy для swarn. Определенно все это упаковано
роиться
поднимет дополнительный системный контейнер, поскольку вы знаете, что есть куча
из
их с кубернетами. Разве это не сила роя для стройных
ресурс
проекты быть бережливыми?

Рубен Николаидес [email protected] schrieb am Fr., 4 января 2019 г.,
09:48:

Я все еще удивлен, почему люди думают, что это ошибка. Из
мой
перспектива даже заявление о переходе на кубернетес не является
адекватный
отвечать. Как я вижу, у Kubernetes точно такая же проблема / поведение.
Ты
или
иметь внешний LB или использовать что-то вроде входящего прокси nginx
который
должен
запустить как демон. Пожалуйста, поправьте меня, если я ошибаюсь, но у нас есть
тем же
здесь точная ситуация, но здесь нет готового авторешения. Кто-то
мог
проверьте и упакуйте предложенное мной решение для потока TCP, описанное выше, в
получать
что-то вроде поведения прокси nginx. Просто прими, что рой нужен
к
быть
настроенный самостоятельно

PanJ [email protected] schrieb am Fr., 4 января 2019 г.,
09:28:

@BretFisher https://github.com/BretFisher режим: host
Только
а
обходной путь, но не решение. Как @sandys <
https://github.com/sandys>
сказал, что обходной путь имеет несколько предостережений, мы не должны рассматривать
это
проблема
как исправлено.

Я не уверен, есть ли какие-либо улучшения, поскольку обходной путь
был
обнаруженный. Я перешел на Kubernetes довольно давно и
еще
быть
удивлен, что вопрос все еще открыт более двух лет.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
< https://github.com/moby/moby/issues/25526#issuecomment -451382365
,
или
немой
нить
<

https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK

>

.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451389574 ,
или
немой
нить
<

https://github.com/notifications/unsubscribe-auth/AAEsU2FCEGFs5v6IOEy6AqjcBMl7IqEiks5u_xmTgaJpZM4Jf2WK

>

.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451409453 или
немой
нить
<

https://github.com/notifications/unsubscribe-auth/AAPgu83fSrSzfopOlDXsDooN1tMboGZaks5u_y8EgaJpZM4Jf2WK
>

.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451424992 или
немой
нить
<
https://github.com/notifications/unsubscribe-auth/AAEsU-q-I3fXVAP9JcGgTdJJOzI7b575ks5u_0HIgaJpZM4Jf2WK

.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451426276 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAPguw88UN68sw_TNTunZpuAGqgvexxMks5u_0NxgaJpZM4Jf2WK
.

И чтобы уточнить, в приведенном выше решении есть поток tcp перед службой
прокси. Итак, ваш запрос определенно не ошибка, а запрос функции. А также
эта функция могла быть реализована только в рое, если бы сетевой режим
изменить, так как основная проблема остается в потере ip на уровне Nat / host

Ruben Nicolaides [email protected] schrieb am Fr., 4 января 2019 г., 13:11:

Как я уже сказал, kubernetes nginx ingress также требует привязки к режиму хоста, называемого
демонсет. Внешний LB подключается к nodeports, для которых также требуется режим хоста
в сервисе или вручную настроить протокол прокси в сервисе. Kubernetes
по-прежнему решает те же проблемы.
С моей точки зрения, одним из возможных запросов функции для роя было бы:
сделать сетевого провайдера подключаемым. Это позволило бы использовать
другие методы, кроме lvs / iptables

Сандип Шриниваса [email protected] schrieb am Fr., 4 января.
2019, 13:05:

Приведенное выше решение требует привязки к режиму хоста. Это большая проблема. Это
исключает возможность использования планировщика докеров для выделения
контейнеры
к разным хостам - я больше не являюсь частью ячеистой сети.

Пт, 4 января 2019 г., 17:28 rubot < [email protected] написал:

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

Сандип Шриниваса [email protected] schrieb am Fr., 4 января.
2019,
11:37:

Это сложные решения - протокол прокси просто добавляет дополнительные
заголовок
информации и это очень известный стандарт - haproxy, nginx, AWS
эльб
и т. д. все следуют за ним.
https://www.haproxy.com/blog/haproxy/proxy-protocol/

Поверхность изменения будет ограничена встроенным Swarm.
ingress (где бы эта поддержка была добавлена). И все услуги будут
имеют
Это
доступный.

Пт, 4 января 2019 г., 14:36 ​​rubot < [email protected] написал:

Вы даже можете расширить проект dockerflow и добавить вариант nginx в
Начните
kubernetes-ingressproxy для swarn. Определенно все это упаковано
роиться
поднимет дополнительный системный контейнер, поскольку вы знаете, что есть
связка
из
их с кубернетами. Разве это не сила роя для стройных
ресурс
проекты быть бережливыми?

Рубен Николаидес [email protected] schrieb am Fr., 4 января 2019 г.,
09:48:

Я все еще удивлен, почему люди думают, что это ошибка. Из
мой
перспектива даже заявление о переходе на кубернетес не является
адекватный
отвечать. Как я вижу, у Kubernetes точно такая же проблема / поведение.
Ты
или
иметь внешний LB или использовать что-то вроде входящего прокси nginx
который
должен
запустить как демон. Пожалуйста, поправьте меня, если я ошибаюсь, но у нас есть
тем же
здесь точная ситуация, но здесь нет готового авторешения. Кто-то
мог
проверьте и упакуйте предложенное мной решение для потока TCP, описанное выше, в
получать
что-то вроде поведения прокси nginx. Просто прими этот рой
нуждается в
быть
настроенный самостоятельно

PanJ [email protected] schrieb am Fr., 4 января 2019 г.,
09:28:

@BretFisher https://github.com/BretFisher режим: host
Только
а
обходной путь, но не решение. Как @sandys <
https://github.com/sandys>
сказал, что обходной путь имеет несколько предостережений, мы не должны рассматривать
это
проблема
как исправлено.

Я не уверен, есть ли какие-либо улучшения, поскольку обходной путь
был
обнаруженный. Я перешел на Kubernetes довольно давно и
еще
быть
удивлен, что вопрос все еще открыт более двух лет.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
<
https://github.com/moby/moby/issues/25526#issuecomment-451382365>,
или
немой
нить
<

https://github.com/notifications/unsubscribe-auth/AAPgu40OJ-uNKORD-LAD12m1lafxzMiSks5u_xCcgaJpZM4Jf2WK

>

.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451389574 ,
или
немой
нить
<

https://github.com/notifications/unsubscribe-auth/AAEsU2FCEGFs5v6IOEy6AqjcBMl7IqEiks5u_xmTgaJpZM4Jf2WK

>

.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451409453 ,
или
немой
нить
<

https://github.com/notifications/unsubscribe-auth/AAPgu83fSrSzfopOlDXsDooN1tMboGZaks5u_y8EgaJpZM4Jf2WK
>

.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451424992 или
немой
нить
<
https://github.com/notifications/unsubscribe-auth/AAEsU-q-I3fXVAP9JcGgTdJJOzI7b575ks5u_0HIgaJpZM4Jf2WK

.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-451426276 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAPguw88UN68sw_TNTunZpuAGqgvexxMks5u_0NxgaJpZM4Jf2WK
.

1. после такой длинной беседы я пытался задокументировать текущий набор функций с полным примером.
2. Я не вижу вашей конкретной потребности в запросе OP. @PanJ попросил увидеть IP-

Назовете ли вы это ошибкой или запросом функции, Ingress Mesh без исходной nat (на мой взгляд) важен. Есть много приложений, которые ломаются, когда не могут увидеть истинный IP-адрес источника. Конечно, в случае веб-серверов вы можете использовать обратный прокси-сервер с помощью узла хоста и добавлять заголовки IP-адресов клиентов. Однако это увеличивает накладные расходы и, вероятно, не подходит для не веб-приложений. Для приложения, которому действительно нужен правильный IP-адрес источника в пакете, единственный вариант - не использовать входящую сетку. Это, в первую очередь, сводит на нет большую часть преимуществ использования роя.

Пожалуйста, дайте нам знать, когда эта проблема будет исправлена ​​или нет ?!
должны ли мы использовать вместо этого кубернетики?

Я столкнулся с той же проблемой ... на данный момент я не нашел исправления.

Если кто-то найдет решение этой проблемы, сообщите об этом здесь.

Спасибо!

У меня такая же проблема. У меня есть сервер apache httpd, и я хочу регистрировать весь доступ, чтобы позже получать статистику о том, из каких стран мы получаем запросы.

Я сам наткнулся на эту проблему, пытаясь понять, почему php: apache неправильно регистрирует поле заголовка хоста. Я шокирован и разочарован, что спустя столько лет это все еще не работает. Как мы должны использовать Swarm Mode для веб-хостинга, когда в поле host сохраняется IP-адрес прокси-сервера пользователя? Я не смог найти способ обойти это с помощью режима Swarm Mode. Полагаю, я мог бы использовать Classic Swarm (на основе контейнера) и что-то вроде Consul, но я чувствую, что это идет вспять.

Я нашел приемлемое решение для своего сценария:

services:
  server:
    image: httpd:2
    deploy:
      mode: global
    ports:
      - target: 80
        published: 80
        protocol: tcp
        mode: host
      - target: 443
        published: 443
        protocol: tcp
        mode: host
    networks:
      - my_second_service
      - another_great_software

Это приведет к тому, что apache будет прослушивать хост-компьютер, а не за перекрывающейся сетью (считывая правильный удаленный IP-адрес), при этом по-прежнему проксируя запросы к другим службам с помощью параметров networks и достигая "высокой доступности", имея его. бегает везде

@rafaelsierra - вот у меня проблема (и поправьте меня, если я ошибаюсь), но эта конфигурация позволяет запускать только один контейнер Apache / PHP и привязываться к порту 80 на узле хоста. Мне нужно запускать много-много контейнеров Apache с контейнером Nginx, привязанным к порту 80/443, а затем размещать их.

@SysEngDan да, это правда, что у вас может быть только одна привязка контейнера к портам 80/443, но в моем случае это не проблема, потому что контейнер, который привязывается к этому порту, отвечает только за проксирование всех запросов к другим контейнерам которые работают за оверлейной сетью.

Вероятно, вы можете использовать то же решение, имея один контейнер nginx / apache, получающий все запросы и проксирующий в соответствующий контейнер на основе vhost, и эти контейнеры не должны связываться с хостом.

@rafaelsierra - С уважением, я не уверен, что вы понимаете проблему, задокументированную в этом тикете. Если я настрою службы, как вы упомянули в последнем абзаце, проблема в том, что IP-адрес клиента не передается в контейнеры, только прослушивающие в оверлейной сети. Если я привяжусь напрямую к хосту, это не проблема. Если мы полагаемся на проксирование сети докеров с внешнего (хоста) на внутреннее (оверлей), целевой контейнер Apache не получит исходный IP-адрес клиента, а вместо этого IP-адрес прокси (из сети докеров).

@SysEngDan Я понимаю, в чем проблема, и, поскольку за последние 2 года не было решения (и я, честно говоря, не уверен, что это «поправимо»), мне пришлось придумать альтернативное решение, которое соответствует моим потребностям (ограничить доступ на основе удаленного IP-адреса).

Наличие одного контейнера, прослушивающего порт 80/443 на хосте, а затем проксирования на другие контейнеры (с соответствующими заголовками HTTP, которые я не упомянул, потому что это выходит за рамки этой проблемы) решило мою проблему, и я хотел поделиться этим решением для людей, которые сталкиваются с подобной проблемой из-за того, что наложенные сети не могут передать удаленный IP-адрес

О, я вижу, что ты там делал ... извини, я это пропустил. Вы вырезаете оверлейную сеть и вместо этого присоединяете свой внешний контейнер непосредственно к сервисной сети (которая создается автоматически, когда вы запускаете новую службу без указания сети). Хорошо, я думаю, это работает. Дополнительные накладные расходы - это задача добавления служебной сети в файл docker-compose. Интересно, что происходит, когда запускается хост-контейнер, а одна из этих служб недоступна?

В этом случае вы получите 502.

У меня нет одного docker-compose.yml, у меня есть несколько стеков с несколькими службами, которые общаются друг с другом через наложенную сеть, а затем у меня есть общедоступная служба, которая привязана к хост-серверу, но все еще имеет доступ к все другие наложенные сети, чтобы он мог проксировать все запросы.

Временное решение этой проблемы в режиме хоста уже обсуждалось несколько раз. Хотя это может быть нормально для некоторых ограниченных сценариев (например, определенных настроек обратного прокси-веб-трафика), это не общее решение этой проблемы. Пожалуйста, прочтите предыдущие сообщения, а не переделывайте одни и те же «решения» заново.

@darrellenns здесь более 200 комментариев, я думаю, было бы лучше заблокировать и очистить эту проблему, предоставив базовое решение «просто использовать привязку хоста, если оно применимо к вам», в то время как официального решения, если оно предоставлено, не будет, иначе больше людей, таких как я, пропустят это и просто продолжайте комментировать одно и то же снова и снова

Итак, я считаю, что эта ошибка влияет на способность traefiks заносить IPS в белый список. Это верно?

В любом случае, для тех, кто хочет запустить режим роя, это пример использования режима хоста для публикации портов.

docker service create \
--name traefik \
--constraint=node.role==manager \
--publish mode=host,target=80,published=80 \
--publish mode=host,target=443,published=443 \
--mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock \
--mount type=bind,source=/home/$USER/dev-ops/logs,target=/dev-ops/logs \
--mount type=bind,source=/opt/data/traefik/traefik.toml,target=/traefik.toml \
--mount type=bind,source=/opt/data/traefik/acme.json,target=/acme.json \
--network traefik \
--label traefik.frontend.rule=Host:traefik.example.com \
--label traefik.port=8080 \
traefik \
--docker \
--docker.swarmMode \
--docker.watch \
--docker.exposedByDefault

@coltenkrauter Я точно не знаю, на что это влияет, но в режиме хоста я могу запустить только одну реплику службы traefik, и я не думаю, что это только я. Таким образом, я должен полностью доверять стабильности traefik, не прибегая к функции режима роя для сервисов.

Кроме того, как впервые сообщалось, это не столько связано с особыми потребностями traefik, оно было протестировано с общей службой http, которая не получает исходный IP-адрес, что означает, что режим роя докеров нарушен (эта важная функция отсутствует), и похоже, что это никого не волнует.

И я хочу продолжать комментировать этот материал, потому что я надеюсь, что шум беспокоит кого-то, кто предпочел бы это исправить :) (извините, это касается меня от моих пользователей)

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

Вы можете запустить один экземпляр на каждом хосте

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

Вы можете запустить один экземпляр на каждом хосте

да, но traefik вынужден работать на узле менеджера, потому что это необходимо для правильной работы. Итак, один управляющий узел, один хост, один экземпляр

traefik может работать с управляющими узлами разными способами, в том числе с помощью
прокси сокета докера, удаленный сокет или предприятие traefik. вот
пример файла стека, как это сделать:
https://github.com/BretFisher/dogvscat/blob/master/stack-proxy-global.yml

В сб, 16 марта 2019 г., в 17:25 Даниэле Крусиани [email protected]
написал:

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

Вы можете запустить один экземпляр на каждом хосте

да, но traefik вынужден работать на узле менеджера, потому что ему это нужно
работать правильно. Итак, один управляющий узел, один хост, один экземпляр

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-473593956 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAwW31DHIwEJE1EqN3-8qj44WopocuQTks5vXWE_gaJpZM4Jf2WK
.

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

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

С другой стороны, если такая функция является проблемой безопасности для модели роя докеров, просто отметьте ее как wontfix, и я бы планировал перейти на кубернетес, если это так, я не думаю, что между проектами существует конфликт, он просто ясно говорит, что этого никогда не произойдет, и поэтому каждый может принять меры, если это возможно, до выбора режима роя докеров для любого типа роя узлов

В кубернетах есть множество функций, которых нет в рое, и наоборот. Все мы принимаем решения о том, какой оркестратор использовать для конкретного решения, на основе многих факторов, в том числе функций. Ни один инструмент не решит все проблемы / потребности.

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

Исторически сложилось так, что сопровождающие moby и swarm не закрывают подобные проблемы как wontfix, потому что завтра кто-нибудь из сообщества может оставить PR с решением этой проблемы. Кроме того, я думаю, что обсуждение способов решения этой проблемы до тех пор является допустимым использованием этой темы. :)

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

Я забыл сказать, что, конечно, ваш комментарий приветствуется (или я сказал это непонятно, извините). Но мне нравится усиливать исходный отчет @PanJ :

Между тем, я думаю, что мне нужно сделать обходной путь, который запускает прокси-контейнер вне режима роя и позволяет ему пересылать его на опубликованный порт в режиме роя (завершение SSL должно выполняться и в этом контейнере), что нарушает цель роя. режим самовосстановления и оркестровки.

Я имею в виду, что это «нарушает цель режима роя», конечно, только по этой конкретной теме, и этого достаточно, чтобы заслужить более пристального внимания.

Я пытаюсь заставить свою команду создать PR, который добавляет протокол прокси в
входная сеть. Мы не программисты Golang, поэтому находим это немного
сложный.

Но я очень надеюсь, что команда Docker согласится с тем, что лучшие и самые
совместимое (во всей экосистеме) решение на уровне прокси-протокола
поддержка входящей сети.

Сложность заключается в том, что входящая сеть не только должна
вводить свои собственные заголовки, но он должен подтверждать тот факт, что могут быть
заголовки восходящего протокола прокси уже вставлены (например, Google LB или
AWS ELB).

Вск, 17 марта 2019 г., 12:17 Даниэле Кручиани, [email protected]
написал:

Я забыл сказать, что, конечно, ваш комментарий приветствуется (или я сказал это в
непонятным образом, извините). Но мне нравится усиливать оригинальный @PanJ
https://github.com/PanJ report:

А пока я думаю, что мне нужно найти обходной путь, который запускает
прокси-контейнер вне режима роя и пусть он перенаправляется на опубликованный порт
в режиме роя (завершение SSL должно быть выполнено и на этом контейнере), что
нарушает цель режима роя для самовосстановления и оркестровки.

Я имею в виду, что это "нарушает цель режима роя", конечно, только на этом
конкретной темы, достаточно, чтобы заслужить более пристальное внимание.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-473621667 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsUwNWJsGKlLejcNzS2pR0awBB4OVlks5vXeTugaJpZM4Jf2WK
.

https://stackoverflow.com/questions/50585616/kubernetes-metallb-traefik-how-to-get-real-client-ip
Как и просили для k8s, где он многоуровневый, полностью и настраиваемый

Для тех, кто запускает nginx в digitalocean с docker swarm и пытается получить реальный $remote_addr вместо простого 10.255.0.2 в журналах nginx; вы можете использовать решение от @coltenkrauter. Загвоздка в том , что вы можете только запустить один Nginx контейнер на хосте с этим решением, которое должно быть нормально для большинства людей.

Просто измените свой docker-compose.yml файл:

НЕПРАВИЛЬНО

services:
  nginx:
    ports:
      - "80:80"
      - "443:443"

ВЕРНЫЙ

services:
  nginx:
    ports:
      - target: 80
        published: 80
        mode: host
      - target: 443
        published: 443
        mode: host

_edit: теперь мы все гарантированно получим правильный ответ_

Отказ от использования входящего трафика ( mode: host ) не является обходным решением, если в проблеме указано, что проблема связана с входящей сетью.
Никто не станет использовать только один хост в качестве обратного прокси. Вам нужно несколько хостов с плавающим IP-адресом, и рой-сетка является обязательной для достижения этой настройки.

Возможно, это невозможно, но я подумал, что изменение правил iptables для выполнения MASQUERADE на каком-то этапе в цепочках INGRESS будет обходным путем, чтобы сохранить реальный исходный IP-адрес. Нет рядом экспертов по iptables / netfilter?

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-INGRESS  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (2 references)
target     prot opt source               destination         

Chain DOCKER-INGRESS (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-USER (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            

В качестве альтернативы, нельзя просто взять исходный IP-адрес и создать заголовок X-Forwarded-For ?

Никто не станет использовать только один хост в качестве обратного прокси. Вам нужно несколько хостов с плавающим IP-адресом, и рой-сетка является обязательной для достижения этой настройки.

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

Обязательно прочитайте всю ветку (я вижу, что GitHub скрывает довольно много полезных комментариев, поэтому вам придется их расширить: разочарован :);

В качестве альтернативы, нельзя просто взять исходный IP-адрес и создать заголовок X-Forwarded-For ?

См. Https://github.com/moby/moby/issues/25526#issuecomment -367642600; X-Forwarded-For - протокол L7; Вход в Swarm - L4, с использованием IPVS с DNAT

@ port22 в целом мы согласны , что обходной путь не является решением проблемы, решение, чтобы сделать его layerable см @sandys предлагают на # 25526 комментарий

В качестве альтернативы нельзя роиться, просто возьмите исходный исходный ip и создайте

заголовок X-Forwarded-For?
См. # 25526 (комментарий)
https://github.com/moby/moby/issues/25526#issuecomment-367642600 ;
X-Forwarded-For - протокол L7; Вход в Swarm - L4, с использованием IPVS с DNAT

правильным решением здесь является прокси-протокол, введенный на L4. есть некоторые
соответствующие обсуждения за и против в Envoy для одного и того же сценария использования
https://github.com/envoyproxy/envoy/issues/4128 и
https://github.com/envoyproxy/envoy/issues/1031

В среду, 10 апреля 2019 г., в 01:40 Себастьян ван Стейн <
[email protected]> написал:

Никто не станет использовать только один хост в качестве обратного прокси. Вы хотите несколько
хосты с плавающим IP-адресом, и рой-сетка обязательна для достижения этого
настраивать.

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

Обязательно прочитайте всю цепочку (я вижу, что GitHub скрывает довольно полезные
комментарии, так что вам придется их расширять 😞);

В качестве альтернативы нельзя роиться, просто возьмите исходный исходный ip и создайте
заголовок X-Forwarded-For?

См. # 25526 (комментарий)
https://github.com/moby/moby/issues/25526#issuecomment-367642600 ;
X-Forwarded-For - протокол L7; Вход в Swarm - L4, с использованием IPVS с DNAT

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-481415217 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsU5KdnWQ21hJx_xzc-QROJiWbAlulks5vfPOigaJpZM4Jf2WK
.

Каждый узел в рое может запускать экземпляр обратного прокси.

Это устраняет функцию балансировщика нагрузки роя, в которой и заключается эта проблема.
И моя проблема, если быть точной, заключается в том, что traefik не является кластерно-гибким. Его нужно запускать автономно, если вы не используете consul в качестве серверной части конфигурации, которая затем ограничивает максимальное количество сертификатов ~ 100, что для меня неприменимо. Конечно, можно сказать, что это проблема не роя, а проблема траэфика. Интересный факт: traefik заявляет, что это проблема консула. консул заявляет: траэфик делает это неправильно.

@ port22 в целом мы согласны с тем, что обходной путь не является решением

Я хочу сказать, что НЕ использование входа - это не обходной путь, когда вам НУЖЕН вход. Обходным путем может быть что-то, что позволит по-прежнему использовать балансировщик нагрузки swarm при сохранении исходного IP-адреса, даже если для этого потребуется некоторый взлом.

использование IPVS с DNAT

таким образом, я подумал, что это можно сделать с помощью MASQUERADE внутри правила / цепочки DNAT. ?

@ port22 Я понял вашу точку зрения, но докер сам управляет своими сетями, я пытался заставить его работать с shorewall, но единственный способ - создать исключения для правил / цепочек докеров, и у меня не было успеха с режимом роя докеров (но он подходит для докеров в режиме роя, пока я отключаю все службы, кроме тех, которые работают в рое)
Может быть, должны быть варианты, такие как для сети моста https://docs.docker.com/network/overlay/#customize -the-docker_gwbridge-interface
чтобы упростить настройку, но все же основная проблема - это отсутствие поддержки в оверлейной сети. Таким образом, параметров нет, потому что они будут проигнорированы, а dockerd перезапишет правила, если они будут изменены извне.

Я подал запрос функции поддержки протокола прокси для решения
проблема в этой ошибке.

На всякий случай кто-нибудь захочет добавить свои комментарии.

https://github.com/moby/moby/issues/39465

В среду, 10 апреля 2019 г., 21:37 Даниэле Крусиани, [email protected]
написал:

@ port22 https://github.com/port22 Я понял вашу точку зрения, но докеры управляют
его сети, я пытался заставить его работать с shorewall, но
единственный способ - создать исключения для правил / цепочек докеров, а у меня не было
успех с режимом роя докеров (но это нормально для докеров в режиме роя, так как
далеко отключаю все сервисы кроме запущенных в рой)
Может быть, должны быть варианты, такие как для мостовой сети
https://docs.docker.com/network/overlay/#customize -the-docker_gwbridge-interface
поэтому, чтобы упростить настройку, но все же основная проблема - это
отсутствует поддержка в оверлейной сети. Так что вариантов нет, потому что
они будут проигнорированы, и dockerd перепишет правила, если они будут изменены из
вне.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526#issuecomment-481754635 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAEsUxsVQ7m9uiYbHhNKMMtkhTZV6iTNks5vfgwygaJpZM4Jf2WK
.

Через 3 года ничего не исправить?

У меня такая же проблема, но с haproxy. Хотя нормально иметь прокси-серверы в режиме хоста и HA с использованием keepalived, единственной недостающей частью будет балансировка нагрузки, которая, я думаю, не является большой проблемой для простого веб-прокси. Если не включены сложные сценарии или прокси и серверная часть не находятся на одной физической машине, а сетевой трафик слишком высок для одной сетевой карты и ...

Неужели действительно невозможно увидеть исходный IP-адрес запроса извне Docker Swarm, а не частный адрес внутренней оверлейной сети? Еще?

@thaJeztah Может ли кто-нибудь из команды Docker Inc

@thaJeztah https://github.com/thaJeztah Может кто-нибудь в Docker Inc
команда сообщает нам о статусе этой проблемы. Это все еще рассматривается
и / или работали? Любое расчетное время прибытия? Или это полностью игнорируется, поскольку Docker
интеграция с Kubernetes? Об этом сообщалось почти 3 года назад: /

Было бы неплохо получить это утверждение ("не исправлю"), чтобы я мог полностью
оправдать переход на кубернеты. Такой позор.

Спасибо.

>

Может, ответят в твиттере?

https://twitter.com/suretec/status/1160496779386904576?s=19

есть предлагаемый запрос на улучшение, который должен это исправить - https://github.com/moby/moby/issues/39465

пожалуйста, добавьте туда свои мысли и комментарии

Я уже комментировал этот вопрос :-)

Это уже какое-то время блокирует меня. Мне нужно пройти через IP-адреса, и после долгого поиска (вау, почти 3 года поиска вместе с другими в этом потоке ...) я еще не нашел никакого решения, которое могло бы работать с роем.

Мне не удалось использовать рой в продакшене из-за этой проблемы, и я жду официального ответа, можно ли его добавить или нет. Если это не добавляется, приветствуются альтернативные предлагаемые решения.

Мы сталкиваемся с той же проблемой, используя traefik за haproxy. Я был удивлен, увидев 254 комментария с 2016 года.

@Betriebsrat Почему нельзя сразу разрешить traefik обрабатывать запросы? Действительно ли haproxy необходим, или это просто привычка? Если выставить траэфик в режиме хоста, то увидишь IP адреса клиентов, а дальше все нормально :)

Я считаю, что это «решение» упоминалось несколько раз, но люди упускают его из виду.

Я также знаю, что иногда это не вариант, но я считаю, что в большинстве случаев это должно быть возможно.

@ajardan, это решение, которое я пробовал, не является жизнеспособным для меня, поскольку я более одного хоста, чтобы отвечать на фронтенде. В идеале я хочу, чтобы весь рой мог маршрутизировать запросы. Я согласен с тем, что для небольших операций можно просто переключить одну службу в режим host и использовать ее в качестве сервера приема.

Размещение чего-то вроде traefik в режиме хоста сводит на нет те преимущества, которые мы пытаемся использовать от использования swarm, хотя в большинстве случаев :(

@pattonwebz Режим хоста можно включить для службы, запускающей несколько контейнеров на нескольких хостах, вы даже можете сделать это с помощью mode = global. Затем traefik будет работать на всех ваших узлах роя и принимать соединения с указанными портами, а затем направлять запросы внутри службам, которым необходимо видеть эти соединения.

Я использовал эту настройку со службой в глобальном режиме, но ограничился узлами диспетчера, и она отлично работала для десятков тысяч запросов / с.

Я буду рад уточнить, если потребуются более подробные сведения.

@pattonwebz @ajardan Я использую настраиваемую службу haproxy для всех этих случаев. В моем случае haproxy использует всего 2 МБ ОЗУ. Я считаю, что это ничтожно мало.

@pattonwebz В дополнение к описанному выше решению https://hub.docker.com/r/decentralize/swarm-tcp-proxy в глобальном режиме с сетью хоста, чтобы добавить поддержку протокола PROXY во входящий трафик, а затем направить его в Traefik, настроенный для декодирования заголовков протокола прокси.

Это должен быть просто флаг как часть самого Docker Swarm, а не все эти
запутанные решения ИМХО.

Мы просто используем haproxy для управления сертификатами и разгрузки ssl.
Люди упускают из виду, что решение «работает в режиме хоста» не является решением.
Они хотят, чтобы он работал с входящей сетью, чтобы использовать балансировку нагрузки докеров.
Весь поток в основном представляет собой круг «использовать режим хоста» -> «невозможно из-за причин», который длится уже 3 года.

Я снова буду рассматривать swarm-tcp-proxy как жизнеспособную альтернативу здесь, однако, глядя на похожие вещи в прошлом, что-то всегда оказывалось для меня предметом обсуждения с такими идеями.

В идеальном мире мой существующий (и хорошо работающий, за исключением отсутствия возможности получить реальный IP-адрес клиента) рой будет просто работать и проходить через IP-данные без необходимости в каких-либо дополнительных уровнях обслуживания или дополнительных прокси-серверах через прокси.

Люди упускают из виду, что решение «работает в режиме хоста» не является решением.

Это не решение само по себе , но может быть очень успешно использовано (и используется) в качестве временного решения. Вы по-прежнему можете использовать собственный балансировщик нагрузки Docker - все, что вы делаете, это добавляете слой в стек сети хоста, прежде чем попадете в сервисную сетку Docker.

@Betriebsrat traefik очень хорошо умеет делать сертификаты и SSL, поэтому я до сих пор не уверен, зачем это нужно.

Также, как упоминалось ранее @matthanley , балансировка нагрузки

Это даже настраивается для каждой службы, поэтому вы достаточно гибки.

Вы можете попробовать установить другой сервер Nginx вне кластера docker swarm и перенаправить запрос в службу swarm. в этой конфигурации Niginx просто добавьте заголовки вперед. например.
место нахождения / {
proxy_pass http: // phpestate;

    #Proxy Settings
    proxy_redirect     off;
    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-IP        $remote_addr;
    proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;

Вроде нет решения получить реальный ip клиента в режиме docker swarm.

Мы увидели ту же проблему и решили ее решить, реализовав:
https://github.com/moby/moby/issues/25526#issuecomment -475083415

Это неидеальное решение, поскольку мы не можем запускать несколько входных контейнеров на одном узле (думаю, теперь они глобальные).

Сложность в том, что Docker работает с TCP / UDP, тогда как это проблема протокола HTTP. Как минимум, я бы хотел, чтобы докер «подделывал» исходный IP-адрес в качестве удаленного хоста, а не давал ему собственный внутренний IP-адрес из Swarm Mesh ... но это, скорее всего, сломало бы ситуацию, поскольку обратный трафик будет идти не в то место.

Самый простой способ - добавить заголовок исходного IP-адреса для каждого HTTP-запроса.

Верный. Чтобы быть конкретным - в качестве заголовка протокола прокси, который работает на l4
и l7 и поддерживается большинством известных прикладных программ (а также
крупные облачные провайдеры).

Я зарегистрировал для этого отдельную ошибку, на которую ссылаются несколько комментариев.
выше. Добавьте к этой ошибке, если вам интересно

Чт, 5 сен 2019, 18:56 Владимир, [email protected] написал:

Самый простой способ - добавить заголовок исходного IP-адреса для каждого
HTTP-запрос.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/25526?email_source=notifications&email_token=AAASYU7APUNJPLZ6AJ6XXMDQIECIJA5CNFSM4CL7MWFKYY3PNVWWK3TUL52HS4DFVREXueG43VLWWK3TUL52HS4DFVREXG43V2HS4DFVREXG43VLH4DFVREXG43VL
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAASYU4VZGKUFLL5STZ44GDQIECIJANCNFSM4CL7MWFA
.

Его 2019 год, и это все еще проблема ?? Это делает занесение IP в белый список на traefik проблемой. Мне не нужны хост-порты на каждом узле.

@kaysond наша позиция заключалась в том, чтобы отказаться от Swarm. Мы переходим на AWS и ECS. Мне просто жаль, что я не могу опубликовать что-то более конструктивное, но в конечном итоге нам нужно что-то, что работает; это не единственная серьезная ошибка Swarm (или отсутствие функции), затрагивающая нас и других, не получивших видимых исправлений / отзывов за последние годы. Очень досадно, но есть.

@jmkgreen, мы находимся в том же положении, и последние 6+ месяцев мы уходили от роя докеров к другим вещам, потому что эта проблема все еще не решена. Я уже потратил на это десятки часов и сотни часов работы членов команды, но так и не нашел приемлемого обходного пути. Привязка ко всем портам хоста полностью сводит на нет цель наших плавающих LB :(

В чем проблема с обходным путем? Вы объявляете свой сервис в режиме хоста + глобальный и настраиваете свой LB для попадания во все узлы, он работает. Поскольку прокси-сервер легкий (я использую nginx, потому что я выполняю разгрузку https и другие вещи), тот факт, что он развернут на каждом сервере, не является проблемой, он использует менее 1% ресурсов сервера. Я могу помочь вам, если вы столкнетесь с какой-либо ошибкой в ​​процессе ([email protected]).

В чем проблема с обходным путем? Вы объявляете свой сервис в режиме хоста + глобальный и настраиваете свой LB для попадания во все узлы, он работает.

@RemiBou Когда необходимо обновить / перезапустить прокси-сервер, внешний балансировщик нагрузки не сразу обнаруживает сбой и продолжает отправлять запросы на узел (а), где прокси все еще перезагружается. Таким образом, в зависимости от внешней конфигурации LB происходит отключение на ~ 30 секунд.

В Swarm также нет возможности включить в процесс обновления службы перехватчик, чтобы вызвать внешний балансировщик нагрузки и вывести узел из строя во время обновления. Вы также не можете запустить скрипт внутри контейнера до его обновления (например, чтобы удалить флаг « i_am_healthy » и позволить внешнему LB обнаружить, что он выходит из строя посредством опроса).

В чем проблема с обходным путем?

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

В самом деле, но разве вы не можете развернуть прокси-службу, которая будет делать только это, а затем, когда ip находится внутри роя. Вы можете перенаправить его как заголовок http на другие ваши службы?

В самом деле, но разве вы не можете развернуть прокси-службу, которая будет делать только это, а затем, когда ip находится внутри роя. Вы можете перенаправить его как заголовок http на другие ваши службы?

Да ... и до тех пор, пока этот тонкий прокси-сервис никогда не нуждается в перенастройке или обновлении, можно обновить компоненты, стоящие за ним, с помощью Swarm LB, чтобы избежать простоев.

Кто-то указал на https://hub.docker.com/r/decentralize/swarm-tcp-proxy, который для этого использует haproxy.

Хотя какая-то боль. И если вам нужно обновить прокси, у вас все равно будет простой.

@ ms1111 Образ докера Nginx

В чем проблема с обходным путем?

В нашем случае это сочетание этого обходного пути с невозможностью привязать доступный хосту порт к определенному IP-адресу. Вместо этого все внутренние службы, которым нужен IP-адрес реального посетителя и поддерживают протокол PROXY, имеют свой порт, выставленный на 0.0.0.0 на хосте, что не является оптимальным.

Еще одна проблема - существенное снижение производительности, когда у вас есть сотни новых подключений в секунду - все открытые порты на самом деле являются правилами DNAT в iptables, которые требуют conntrack и имеют другие проблемы (также попадает в k8s, но у Swarm есть это дополнительный уровень NAT, который усугубляет ситуацию).

В Докер,

Просыпайся! Существует очевидная проблема, учитывая, сколько людей вовлечено в эту проблему (есть и другие с той же причиной). Все, что мы получаем, - это люди, которые снова и снова повторяют, что есть обходной путь, хотя довольно много раз объясняли, почему этот обходной путь не является решением. Само слово «обходной путь» указывает на то, что это временная проблема, которая будет решена позже. С момента создания проблемы прошло более 3 лет, и за все это время был получен ответ «есть обходной путь».

Всем пользователям Swarm,

Будем реалистами. Печальная правда заключается в том, что никого, включая Докера, по-настоящему не волнует Swarm. Все перешли на k8s, а «настоящих» вложений в Swarm нет. Проект находится в режиме жизнеобеспечения, ожидая смерти, поэтому не ждите, что эта проблема будет исправлена. Будьте умны и переходите на k8s.

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

@leojonathanoh, не могли бы вы уточнить, как именно k8s решает эту конкретную проблему :)?

Просто: протокол прокси

@ajatkj Как сказано. Или, если это невозможно, используйте внешний балансировщик нагрузки и externalTrafficPolicy: Local на ресурсе Service . Это все, что я здесь скажу. А я от ветки отписываюсь.

Почему люди ожидают, что другие люди сделают за них работу?

Я бы хотел стать героем и позаботиться об этом, но на самом деле я работаю над многими другими вещами, и это не влияет на мою повседневную жизнь. Это влияет на вашу повседневную жизнь? Нам нужна помощь в решении этой проблемы!

Я также смотрел на это несколько раз, и действительно не похоже, что есть способ заставить это работать с IPVS NAT, что и используется в волшебной роевой маршрутизации.

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

Люди помогают своими знаниями. Не все обладают навыками, позволяющими самостоятельно изменять код, поэтому они создают подобные проблемы, чтобы помочь достичь консенсуса по поводу необходимого изменения.

Никто здесь не утверждает, что вы должны вносить изменения конкретно, но даже по вопросам, открытым @sandys относительно протокола прокси, основная команда согласилась с изменениями. Так как же кто-то может работать над этим, если он не знает, будет ли принято изменение?

Лучше всего выступить с предложением, т.е. как вы ожидаете, что архитектура будет выглядеть после завершения работы. Что это приносит? Что мы теряем?

попробуйте host-mode-network

Лучше всего выступить с предложением, т.е. как вы ожидаете, что архитектура будет выглядеть после завершения работы. Что это приносит? Что мы теряем?

Уже сделано здесь: # 39465

попробуйте host-mode-network

Пожалуйста, прочтите всю цепочку перед тем, как комментировать

«Использовать протокол прокси», пока действительно интересно не выложить, что
необходимо внести изменения в кодовую базу.

Может это наивный вопрос, но зачем вообще переписывать исходный ip? В любом случае, не будет ли трафик возвращаться через шлюз интерфейса по умолчанию? Даже если он пришел через балансировщик нагрузки Swarm, шлюз мог просто вернуть его через балансировщик нагрузки, который уже знает, откуда пришел трафик ...

Может это наивный вопрос, но зачем вообще переписывать исходный ip? В любом случае, не будет ли трафик возвращаться через шлюз интерфейса по умолчанию? Даже если он пришел через балансировщик нагрузки Swarm, шлюз мог просто вернуть его через балансировщик нагрузки, который уже знает, откуда пришел трафик ...

Необходимо знать, с какого IP идет запрос. Возможно, конкретный пользователь хочет ограничить IP-адрес, и вы не можете сделать это вне запущенной службы, т.е. traefik не знает содержимое запроса, который может указывать, какой пользователь его делает, поэтому он не может исключить какого-то пользователя и принимает другое основано только на ip (поскольку политика в этом примере - ip + request-content => allow / disallow).

Или, чаще, просто для логирования соединения. Мне нужно выставить счет клиенту за использование моих услуг, и мне нужно предоставить в табличной форме: время запроса, количество ресурса, IP-адрес источника запроса. Такой отчет предоставляется почти во всех выставленных услугах.

Я думаю, вы неправильно поняли мой вопрос. Я понимаю, почему службы хотят видеть истинный IP-адрес источника. Я хочу знать, почему Docker меняет его до того, как попадет в контейнер

1 ноября 2019 г., в 1:47, в 1:47, Даниэле Крусиани [email protected] написал:

Может это наивный вопрос, но зачем переписывать
исходный ip для начала? Разве трафик не будет возвращен через
шлюз интерфейса по умолчанию в любом случае? Даже если это пришло через роевую нагрузку
балансировщик, шлюз может просто вернуть его через балансировщик нагрузки, который
уже знает откуда пришел трафик ...

Необходимо знать, с какого IP идет запрос. Может быть
конкретный пользователь хочет ограничить IP, и вы не можете сделать это вне
служба запущена, т.е. траэфик не знает содержание запроса
который может указывать, какой пользователь делает это, поэтому он не может исключить некоторые
пользователь и принимает другие только на основе ip (потому что политика в этом
пример: ip + request-content => allow / disallow).

Или, чаще, просто для логирования соединения. Мне нужно выставить счет клиенту
для моего использования услуг, и мне нужно предоставить в табличной форме: время
запрос, количество ресурса, IP-адрес источника запроса. Практически все услуги
выставлен счет для предоставления такого отчета.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/moby/moby/issues/25526#issuecomment -548711563

@kaysond Не

По сути, вы задаете два вопроса,

1. Как IPVS работает технически, и
2. Почему libnetwork для начала выбирает IPVS

На них обоих сложно ответить по-разному.

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

@kaysond Не

По сути, вы задаете два вопроса,

1. Как IPVS работает технически, и
2. Почему libnetwork для начала выбирает IPVS

На них обоих сложно ответить по-разному.

какое-нибудь обновление?

Я слежу за этой веткой уже некоторое время, потому что я наткнулся на ту же проблему, но после раскрутки нескольких

Просто попробовал это еще раз с помощью:

Client: Docker Engine - Community
 Version:           19.03.5
 API version:       1.40
 Go version:        go1.12.12
 Git commit:        633a0ea838
 Built:             Wed Nov 13 07:29:52 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.5
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.12
  Git commit:       633a0ea838
  Built:            Wed Nov 13 07:28:22 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.10
  GitCommit:        b34a5c8af56e510852c35414db4c1f4fa6172339
 runc:
  Version:          1.0.0-rc8+dev
  GitCommit:        3e425f80a8c931f88e6d94a8c831b9d5aa481657
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

и следующий докер составляют:

version: "3.3"

services:

  traefik:
    image: "traefik:v2.0.0-rc3"
    container_name: "traefik"
    command:
      #- "--log.level=DEBUG"
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.swarmMode=true"
      - "--providers.docker.endpoint=unix:///var/run/docker.sock"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  whoami:
    image: "containous/whoami"
    container_name: "simple-service"
    deploy:
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.whoami.rule=HostRegexp(`{any:.*}`)"
        - "traefik.http.routers.whoami.entrypoints=web"
        - "traefik.http.services.whoami.loadbalancer.server.port=80"

Вывод whoami был:

Hostname: 085c373eb06d
IP: 127.0.0.1
IP: 10.0.1.10
IP: 172.19.0.4
RemoteAddr: 10.0.1.11:51888
GET / HTTP/1.1
Host: testserver.nub.local
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Dnt: 1
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 10.0.0.2
X-Forwarded-Host: testserver.nub.local
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Server: ad14e372f6e9
X-Real-Ip: 10.0.0.2

Так что нет. это все еще не работает

Из любопытства .... может ли какой-нибудь разработчик указать мне на код, который управляет сетью роя?

https://github.com/docker/libnetwork

Просто попробовал это еще раз с помощью:

Client: Docker Engine - Community
 Version:           19.03.5
 API version:       1.40
 Go version:        go1.12.12
 Git commit:        633a0ea838
 Built:             Wed Nov 13 07:29:52 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.5
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.12
  Git commit:       633a0ea838
  Built:            Wed Nov 13 07:28:22 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.10
  GitCommit:        b34a5c8af56e510852c35414db4c1f4fa6172339
 runc:
  Version:          1.0.0-rc8+dev
  GitCommit:        3e425f80a8c931f88e6d94a8c831b9d5aa481657
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

и следующий докер составляют:

version: "3.3"

services:

  traefik:
    image: "traefik:v2.0.0-rc3"
    container_name: "traefik"
    command:
      #- "--log.level=DEBUG"
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.swarmMode=true"
      - "--providers.docker.endpoint=unix:///var/run/docker.sock"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  whoami:
    image: "containous/whoami"
    container_name: "simple-service"
    deploy:
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.whoami.rule=HostRegexp(`{any:.*}`)"
        - "traefik.http.routers.whoami.entrypoints=web"
        - "traefik.http.services.whoami.loadbalancer.server.port=80"

Вывод whoami был:

Hostname: 085c373eb06d
IP: 127.0.0.1
IP: 10.0.1.10
IP: 172.19.0.4
RemoteAddr: 10.0.1.11:51888
GET / HTTP/1.1
Host: testserver.nub.local
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Dnt: 1
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 10.0.0.2
X-Forwarded-Host: testserver.nub.local
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Server: ad14e372f6e9
X-Real-Ip: 10.0.0.2

Так что нет. это все еще не работает

вы можете использовать traefik в режиме хоста, чтобы получить реальный IP

ports:
      - target: 80
        published: 80
        mode: host
      - target: 443
        published: 443
        mode: host

все еще открыт?
2020-05-08

все еще открыт?
2020-05-08

Ага, все еще открыт. В ветке отмечены архитектурные проблемы, которые подчеркивают, почему это не может быть решено так легко, как кажется, что должно быть на поверхности. На данный момент, вероятно, эти проблемы невозможно решить.

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

Нам удалось успешно использовать протокол PROXY с контейнером DigitalOcean LB -> Traefik -> Apache. Контейнер Apache мог регистрировать реальные IP-адреса пользователей, обращающихся к сервису. Теоретически должен работать, если все прокси-уровни поддерживают протокол PROXY.

https://docs.traefik.io/v1.7/configuration/entrypoints/#proxyprotocol

Служба Traefik находится в одной сети Docker с именем «ingress», служба Apache имеет свою собственную стековую сеть, но также является частью «входящей» сети в качестве внешней.

https://autoize.com/logging-client-ip-addresses-behind-a-proxy-with-docker/

2020 год и до сих пор не исправлен, какое сопротивление. кажется очень важной особенностью

Это очень нужно. Поставить какой-то режим хоста - это просто патч, иногда необходимо запускать NGINX за сетью (в зависимости от использования и настройки). Пожалуйста, исправьте это.

Я думаю, что обходной путь для этого и для запуска роя докеров без настройки хоста - это получить IP на стороне клиента. бывший. использовать js для веб-клиентов и мобильных клиентов и принимать только из надежных источников. бывший. js -> get ip, backend принимает только IP-адреса, которые включают токен пользователя и т. д. ip может быть установлен в заголовке и зашифрован через https. однако я не знаю о производительности

@ Damidara16 Это именно то, чего мы не хотим делать. Это действительно небезопасно. Вы можете обходить это как хотите.

К сожалению, это все еще нерешенная проблема ... не похоже, что скоро она будет исправлена.

К сожалению, это все еще нерешенная проблема ... не похоже, что скоро она будет исправлена.

Думаю, скоро бот закроет. С тех пор, как github запустил эту функцию, многие ошибки можно игнорировать.

К сожалению, это все еще нерешенная проблема ... не похоже, что скоро она будет исправлена.

Думаю, скоро бот закроет. С тех пор, как github запустил эту функцию, многие ошибки можно игнорировать.

Это лучшая возможность для раздутых команд предприятий получить контроль над сообществом.

Очень мало шансов, что это когда-либо будет исправлено. AFAIK все считают, что k8s выиграли «гонку», и рой не нужен, но я бы сказал, что оба они могут сосуществовать и использоваться должным образом в зависимости от потребностей и навыков команды, использующей их. RIP рой :)

Я использую управляемый HAIP, но вы можете использовать что-то еще перед роем, автономный балансировщик нагрузки nginx, который указывает на IP-адреса вашего роя.
https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/

В вашем рое обратный прокси-сервер нуждается в этом:

server {
        listen 443 ssl proxy_protocol;
        location / {
        proxy_set_header   X-Real-IP $proxy_protocol_addr;  # this is the real IP address 

Если вы запускаете рой, вам понадобится балансировщик нагрузки для циклического перебора запросов к вашему рою (или липких и т. Д.).

Пока это архитектурное решение может показаться «недостающим элементом», однако оно добавляет гибкости, предоставляя опции и устраняя необходимость отключать встроенные функции, чтобы заменить их на что-то более подходящее для нужд приложения.

Я считаю, что, возможно, нашел обходной путь для этой проблемы, с ограничением _current_, что все реплики контейнеров служб должны быть развернуты на одном узле, например, с помощью --constraint-add = 'node.hostname == mynode' или с помощью набор роев, каждый из которых состоит из одного узла.

Эта проблема

Основная проблема вызвана правилом SNAT в таблице iptables nat в пространстве имен ingress_sbox, которое заставляет контейнеры видеть все входящие запросы с IP-адресом узла во входной сети (например, 10.0.0.2, 10.0.0.3,. .., в конфигурации входящей сети по умолчанию), например:

iptables -t nat -A POSTROUTING -d 10.0.0.0/24 -m ipvs --ipvs -j SNAT --to-source 10.0.0.2

Однако удаление этого правила SNAT означает, что, хотя контейнеры по-прежнему получают входящие пакеты - теперь исходящие от исходного IP-адреса источника - исходящие пакеты, отправленные обратно на исходный IP-адрес источника, отправляются через шлюз по умолчанию контейнера, который находится не в той же входящей сети, а на сеть docker_gwbridge (например, 172.31.0.1), и эти пакеты затем теряются.

Обходной путь

Таким образом, обходной путь включает: 1. удаление (фактически запрещение) этого правила SNAT в пространстве имен ingress_sbox; и 2. создание правила маршрутизации политики для служебных контейнеров роя, которое заставляет эти исходящие пакеты возвращаться на входящий сетевой IP-адрес узла, на который он должен был бы вернуться (например, 10.0.0.2); 3. автоматизировать добавление правил маршрутизации политики, чтобы каждый новый контейнер службы устанавливал их сразу после создания.

1. Чтобы запретить правило SNAT, мы создаем правило ранее в таблице, которое предотвращает доступ к обычному SNAT:

nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t nat -I POSTROUTING -d $INGRESS_SUBNET -m ipvs --ipvs -j ACCEPT

(Мы делаем это таким образом, а не просто удаляем существующее правило SNAT, поскольку докер, кажется, воссоздает правило SNAT несколько раз в процессе создания службы. Такой подход просто заменяет это правило, что делает его более устойчивым).

1. Чтобы создать правило маршрутизации контейнерной политики:

docker inspect -f '{{.State.Pid}}' <container-id>
nsenter -n -t $NID bash -c "ip route add table 1 default via 10.0.0.2 && ip rule add from 10.0.0.0/24 lookup 1 priority 32761"

1. Наконец, объединяя вышеперечисленное с docker event мы автоматизируем процесс изменения правил SNAT, отслеживание вновь запущенных контейнеров и добавление правил маршрутизации политики с помощью этого сценария ingress-routing-daemon :

#!/bin/bash

# Ingress Routing Daemon
# Copyright © 2020 Struan Bartlett
# --------------------------------------------------------------------
# Permission is hereby granted, free of charge, to any person 
# obtaining a copy of this software and associated documentation files 
# (the "Software"), to deal in the Software without restriction, 
# including without limitation the rights to use, copy, modify, merge, 
# publish, distribute, sublicense, and/or sell copies of the Software, 
# and to permit persons to whom the Software is furnished to do so, 
# subject to the following conditions:
#
# The above copyright notice and this permission notice shall be 
# included in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 
# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS 
# BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN 
# ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 
# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
# SOFTWARE.
# --------------------------------------------------------------------
# Workaround for https://github.com/moby/moby/issues/25526

echo "Ingress Routing Daemon starting ..."

read INGRESS_SUBNET INGRESS_DEFAULT_GATEWAY \
  < <(docker inspect ingress --format '{{(index .IPAM.Config 0).Subnet}} {{index (split (index .Containers "ingress-sbox").IPv4Address "/") 0}}')

echo INGRESS_SUBNET=$INGRESS_SUBNET
echo INGRESS_DEFAULT_GATEWAY=$INGRESS_DEFAULT_GATEWAY

# Add a rule ahead of the ingress network SNAT rule, that will cause the SNAT rule to be skipped.
echo "Adding ingress_sbox iptables nat rule: iptables -t nat -I POSTROUTING -d $INGRESS_SUBNET -m ipvs --ipvs -j ACCEPT"
while nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t nat -D POSTROUTING -d 10.0.0.0/24 -m ipvs --ipvs -j ACCEPT; do true; done 2>/dev/null
nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t nat -I POSTROUTING -d $INGRESS_SUBNET -m ipvs --ipvs -j ACCEPT

# Watch for container start events, and configure policy routing rules on each container
# to ensure return path traffic from incoming connections is routed back via the correct interface.
docker events \
  --format '{{.ID}} {{index .Actor.Attributes "com.docker.swarm.service.name"}}' \
  --filter 'event=start' \
  --filter 'type=container' | \
  while read ID SERVICE
  do
    if [ -n "$SERVICE" ]; then

      NID=$(docker inspect -f '{{.State.Pid}}' $ID)
      echo "Container ID=$ID, NID=$NID, SERVICE=$SERVICE started: applying policy route."
      nsenter -n -t $NID bash -c "ip route add table 1 default via $INGRESS_DEFAULT_GATEWAY && ip rule add from $INGRESS_SUBNET lookup 1 priority 32761"
    fi
  done

Теперь, когда запросы поступают на опубликованные порты для одного узла, его контейнеры будут видеть исходный IP-адрес машины, выполняющей запрос.

использование

Запустите вышеуказанный ingress-routing-daemon как root на _каждом и каждом_ узле роя _перед_ созданием вашей службы. (Если ваша служба уже создана, убедитесь, что вы масштабируете ее до 0 перед масштабированием обратно до положительного числа реплик.) Демон инициализирует iptables, определяет, когда docker создает новые контейнеры, и применяет новые правила маршрутизации к каждому новому контейнеру.

Тестирование, варианты использования и ограничения

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

Он также был протестирован с использованием нескольких узлов, каждый из которых имеет отдельную службу для каждого узла, ограниченную этим узлом, но это связано с ограничением, заключающимся в том, что разные опубликованные порты должны использоваться для каждой службы для каждого узла. Тем не менее, это может сработать для некоторых случаев использования.

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

Улучшение обходного пути для решения дальнейших сценариев использования

При дальнейшем развитии этот метод должен иметь возможность масштабирования до нескольких узлов без необходимости в отдельных сервисах для каждого узла или разделении роя. Я могу придумать два возможных подхода: 1. Организация Docker или специального демона для удаления всех нелокальных IP-адресов из таблицы ipvsadm каждого узла. 2. Расширение правил маршрутизации политики для обеспечения маршрутизации выходных пакетов обратно на правильный узел.

Для 1 мы могли бы опросить ipvsadm -S -n, чтобы найти новые IP-адреса, добавленные к какой-либо службе, проверить, является ли каждый из них локальным, и удалить все, которые не являются. Это позволило бы каждому узлу функционировать как балансировщик нагрузки для своих собственных контейнеров в рамках общей службы, но без возможности пересылки запросов, достигающих одного узла, другому. Это, безусловно, удовлетворило бы мой собственный вариант использования, когда у нас есть собственный балансировщик нагрузки IPVS, расположенный перед набором серверов, каждый из которых запускает веб-приложение, которое мы хотели бы заменить несколькими контейнеризованными экземплярами с балансировкой нагрузки одного и того же приложения. , чтобы мы могли выпускать обновления без потери всего сервера.

Для 2 мы могли бы использовать iptables для назначения TOS для каждого узла в iptable ingress_sbox каждого узла (например, для последнего байта входящего сетевого IP-адреса узла); затем в контейнере организуйте отображение значения TOS на метку соединения, а затем от метки соединения к метке межсетевого экрана для исходящих пакетов, и для каждой отметки межсетевого экрана выберите другую таблицу маршрутизации, которая направляет пакеты обратно к исходному узлу. Правила для этого будут немного неуклюжими, но я полагаю, что они должны масштабироваться до 2-16 узлов.

Надеюсь, сказанное выше пригодится. Я также попробую (2), и, если я добьюсь прогресса, опубликую дальнейшее обновление.

Ниже представлена ​​улучшенная версия демона входящей маршрутизации, ingress-routing-daemon-v2 , которая расширяет модель правил маршрутизации политики, позволяя каждому контейнеру направлять свои выходные пакеты обратно на правильный узел без необходимости использования SNAT.

Улучшенная модель

Помимо запрета правила SNAT в соответствии с предыдущей моделью, для новой модели требуется правило iptables в пространстве имен ingress_sbox на каждом узле, который вы собираетесь использовать в качестве конечной точки балансировщика нагрузки IPVS (обычно это ваши управляющие узлы или их подмножество). менеджер узлов), который назначает значение TOS для каждого узла всем пакетам, предназначенным для любого узла во входной сети. (Мы используем последний байт IP-адреса входящей сети узла.)

Поскольку значение TOS хранится в пакете, оно может быть прочитано узлом назначения, которому был направлен входящий запрос, и пакет был отправлен.

Затем в контейнере на узле назначения мы организуем сопоставление значения TOS на всех входящих пакетах с меткой соединения с использованием того же значения.

Теперь, поскольку исходящие пакеты в одном и том же соединении будут иметь одинаковую метку подключения, мы сопоставляем метку подключения на всех исходящих пакетах метке межсетевого экрана, снова используя то же значение.

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

Теперь, когда клиентские запросы поступают на опубликованные порты для любого узла в рое, контейнер (будь то на том же и / или другом узлах), на который направлен запрос, увидит исходный IP-адрес клиента, выполняющего запрос, и иметь возможность направить ответ обратно к исходному узлу балансировки нагрузки; который, в свою очередь, сможет направить ответ обратно клиенту.

использование

Настройка

Сгенерируйте значение для INGRESS_NODE_GATEWAY_IPS специфичное для вашего роя, запустив ingress-routing-daemon-v2 как root на каждом из узлов вашего роя _, которое вы хотите использовать в качестве конечной точки балансировщика нагрузки_ (обычно только ваш менеджер узлов или подмножества ваших управляющих узлов), отмечая значения, указанные для INGRESS_DEFAULT_GATEWAY . Вам нужно сделать это только один раз или каждый раз, когда вы добавляете или удаляете узлы. Ваш INGRESS_NODE_GATEWAY_IPS должен выглядеть как 10.0.0.2 10.0.0.3 10.0.0.4 10.0.0.5 (в зависимости от подсети, определенной для входящей сети, и количества узлов).

Запуск демона

Запустите INGRESS_NODE_GATEWAY_IPS="<Node Ingress IP List>" ingress-routing-daemon-v2 --install от имени пользователя root на _ каждом и каждом_ узле вашего роя (менеджеры и рабочие) _ перед_ созданием службы. (Если ваша служба уже создана, убедитесь, что вы масштабируете ее до 0 перед масштабированием обратно до положительного числа реплик.) Демон инициализирует iptables, определяет, когда docker создает новые контейнеры, и применяет новые правила маршрутизации к каждому новому контейнеру.

Если вам нужно ограничить действия демона определенной службой, измените [ -n "$SERVICE" ] на [ "$SERVICE" = "myservice" ] .

Удаление правил iptables

Запустите ingress-routing-daemon-v2 --uninstall на каждом узле.

Тестирование

Сценарий ingress-routing-daemon-v2 был протестирован с 8 репликами веб-службы, развернутой в рое из четырех узлов.

Запросы Curl для службы, направленные на любой из указанных IP-адресов конечных точек с балансировкой нагрузки, вернули успешные ответы, а проверка журналов контейнеров показала, что приложение считало входящие запросы исходящими с IP-адреса клиента Curl.

Ограничения

Поскольку значение TOS может хранить 8-битное число, эта модель в принципе может поддерживать до 256 узлов конечных точек балансировщика нагрузки.

Однако, поскольку модель требует, чтобы каждый контейнер был установлен с одним правилом iptables mangle + одним правилом маршрутизации политик + одной таблицей маршрутизации политик на каждый узел конечной точки менеджера, возможно некоторое снижение производительности по мере увеличения количества таких узлов конечной точки (хотя опыт показывает, что это не так. вряд ли будет заметен с <= 16 конечными узлами балансировщика нагрузки на современном оборудовании).

Если вы добавляете узлы конечных точек балансировщика нагрузки в свой рой - или хотите начать использовать существующие узлы диспетчера в качестве конечных точек балансировщика нагрузки - вам нужно будет действовать осторожно, поскольку существующие контейнеры не смогут направлять трафик обратно на новые узлы конечных точек. Попробуйте перезапустить INGRESS_NODE_GATEWAY_IPS="<Node Ingress IP List>" ingress-routing-daemon-v2 с обновленным значением INGRESS_NODE_GATEWAY_IPS , затем выполните последовательное обновление всех контейнеров перед использованием новой конечной точки балансировщика нагрузки.

Возможности для встроенной интеграции Docker

Я не знаком с кодовой базой Docker, но я не вижу ничего из того, что делает ingress-routing-daemon-v2 , что в принципе не может быть реализовано Docker изначально, но я оставлю это команде Docker. рассмотрите, или как упражнение для тех, кто знаком с кодом Docker.

Сценарий демона входящей маршрутизации v2

Вот новый сценарий ingress-routing-daemon-v2 .

#!/bin/bash

# Ingress Routing Daemon v2
# Copyright © 2020 Struan Bartlett
# ----------------------------------------------------------------------
# Permission is hereby granted, free of charge, to any person 
# obtaining a copy of this software and associated documentation files 
# (the "Software"), to deal in the Software without restriction, 
# including without limitation the rights to use, copy, modify, merge, 
# publish, distribute, sublicense, and/or sell copies of the Software, 
# and to permit persons to whom the Software is furnished to do so, 
# subject to the following conditions:
#
# The above copyright notice and this permission notice shall be 
# included in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 
# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS 
# BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN 
# ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 
# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
# SOFTWARE.
# ----------------------------------------------------------------------
# Workaround for https://github.com/moby/moby/issues/25526

if [ "$1" = "--install" ]; then
  INSTALL=1
elif [ "$1" = "--uninstall" ]; then
  INSTALL=0
else
  echo "Usage: $0 [--install|--uninstall]"
fi

echo
echo "  Dumping key variables..."

if [ "$INSTALL" = "1" ] && [ -z "$INGRESS_NODE_GATEWAY_IPS" ]; then
  echo "!!! ----------------------------------------------------------------------"
  echo "!!! WARNING: Using default INGRESS_NODE_GATEWAY_IPS"
  echo "!!! Please generate a list by noting the values shown"
  echo "!!! for INGRESS_DEFAULT_GATEWAY on each of your swarm nodes."
  echo "!!!"
  echo "!!! You only have to do this once, or whenever you add or remove nodes."
  echo "!!!"
  echo "!!! Then relaunch using:"
  echo "!!! INGRESS_NODE_GATEWAY_IPS=\"<Node Ingress IP List>\" $0 -x"
  echo "!!! ----------------------------------------------------------------------"
fi

read INGRESS_SUBNET INGRESS_DEFAULT_GATEWAY \
  < <(docker inspect ingress --format '{{(index .IPAM.Config 0).Subnet}} {{index (split (index .Containers "ingress-sbox").IPv4Address "/") 0}}')

echo "  - INGRESS_SUBNET=$INGRESS_SUBNET"
echo "  - INGRESS_DEFAULT_GATEWAY=$INGRESS_DEFAULT_GATEWAY"

# We need the final bytes of the IP addresses on the ingress network of every node
# i.e. We need the final byte of $INGRESS_DEFAULT_GATEWAY for every node in the swarm
# This shouldn't change except when nodes are added or removed from the swarm, so should be reasonably stable.
# You should configure this yourself, but for now let's assume we have 8 nodes with IPs in the INGRESS_SUBNET numbered x.x.x.2 ... x.x.x.9
if [ -z "$INGRESS_NODE_GATEWAY_IPS" ]; then
  INGRESS_NET=$(echo $INGRESS_DEFAULT_GATEWAY | cut -d'.' -f1,2,3)
  INGRESS_NODE_GATEWAY_IPS="$INGRESS_NET.2 $INGRESS_NET.3 $INGRESS_NET.4 $INGRESS_NET.5 $INGRESS_NET.6 $INGRESS_NET.7 $INGRESS_NET.8 $INGRESS_NET.9"
fi

echo "  - INGRESS_NODE_GATEWAY_IPS=\"$INGRESS_NODE_GATEWAY_IPS\""

# Create node ID from INGRESS_DEFAULT_GATEWAY final byte
NODE_ID=$(echo $INGRESS_DEFAULT_GATEWAY | cut -d'.' -f4)
echo "  - NODE_ID=$NODE_ID"

if [ -z "$INSTALL" ]; then
  echo
  echo "Ingress Routing Daemon v2 exiting."
  exit 0
fi

# Add a rule ahead of the ingress network SNAT rule, that will cause the SNAT rule to be skipped.
[ "$INSTALL" = "1" ] && echo "Adding ingress_sbox iptables nat rule: iptables -t nat -I POSTROUTING -d $INGRESS_SUBNET -m ipvs --ipvs -j ACCEPT"
while nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t nat -D POSTROUTING -d 10.0.0.0/24 -m ipvs --ipvs -j ACCEPT; do true; done 2>/dev/null
[ "$INSTALL" = "1" ] && nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t nat -I POSTROUTING -d $INGRESS_SUBNET -m ipvs --ipvs -j ACCEPT

# 1. Set TOS to NODE_ID in all outgoing packets to INGRESS_SUBNET
[ "$INSTALL" = "1" ] && echo "Adding ingress_sbox iptables mangle rule: iptables -t mangle -A POSTROUTING -d $INGRESS_SUBNET -j TOS --set-tos $NODE_ID/0xff"
while nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t mangle -D POSTROUTING -d $INGRESS_SUBNET -j TOS --set-tos $NODE_ID/0xff; do true; done 2>/dev/null
[ "$INSTALL" = "1" ] && nsenter --net=/var/run/docker/netns/ingress_sbox iptables -t mangle -A POSTROUTING -d $INGRESS_SUBNET -j TOS --set-tos $NODE_ID/0xff

if [ "$INSTALL" = "0" ]; then
  echo
  echo "Ingress Routing Daemon v2 iptables rules uninstalled, exiting."
  exit 0
fi

echo "Ingress Routing Daemon v2 starting ..."

# Watch for container start events, and configure policy routing rules on each container
# to ensure return path traffic for incoming connections is routed back via the correct interface
# and to the correct node from which the incoming connection was received.
docker events \
  --format '{{.ID}} {{index .Actor.Attributes "com.docker.swarm.service.name"}}' \
  --filter 'event=start' \
  --filter 'type=container' | \
  while read ID SERVICE
  do
    if [ -n "$SERVICE" ]; then

      NID=$(docker inspect -f '{{.State.Pid}}' $ID)
      echo "Container ID=$ID, NID=$NID, SERVICE=$SERVICE started: applying policy routes."

      # 3. Map any connection mark on outgoing traffic to a firewall mark on the individual packets.
      nsenter -n -t $NID iptables -t mangle -A OUTPUT -p tcp -j CONNMARK --restore-mark

      for NODE_IP in $INGRESS_NODE_GATEWAY_IPS
      do
        NODE_ID=$(echo $NODE_IP | cut -d'.' -f4)

    # 2. Map the TOS value on any incoming packets to a connection mark, using the same value.
        nsenter -n -t $NID iptables -t mangle -A PREROUTING -m tos --tos $NODE_ID/0xff -j CONNMARK --set-xmark $NODE_ID/0xffffffff

    # 4. Select the correct routing table to use, according to the firewall mark on the outgoing packet.
        nsenter -n -t $NID ip rule add from $INGRESS_SUBNET fwmark $NODE_ID lookup $NODE_ID prio 32700

    # 5. Route outgoing traffic to the correct node's ingress network IP, according to its firewall mark
    #    (which in turn came from its connection mark, its TOS value, and ultimately its IP).
        nsenter -n -t $NID ip route add table $NODE_ID default via $NODE_IP dev eth0

      done

    fi
  done

Привет @struanb , я не понимаю, как в вашем скрипте v2 работает раздел удаления, чего-то не хватает?

Привет @jrbecart. Надеюсь нет. Перед установкой правил iptables вы увидите два цикла while, которые удаляют все ранее существовавшие правила, используя iptables -D . Это мера безопасности на случай, если сценарий запускается с --install несколько раз подряд, без каких-либо промежуточных вызовов с --uninstall .

Таким образом, когда сценарий вызывается с параметром --uninstall, к моменту выхода из сценария эти правила будут удалены, а новые правила еще не добавлены.

Надеюсь, что это ответ на ваш вопрос.

Всем привет, я хочу сказать вам, что я обнаружил исправление этой проблемы, не устанавливая и не настраивая ничего, кроме правильного определения конфигурации NGINX. Я знаю, что все мы пробовали разные подходы. Этот был обнаружен по ошибке. Если честно, я давно отказался от этого. Что ж, до сегодняшнего дня. Пока я внедрял систему мониторинга, я смог получить исходный IP-адрес, настоящий исходный IP-адрес, используя журнал NGINX, поэтому я начал отлаживать, как это было возможно.

Вот пример такого журнала

10.0.0.2 - - [19/Nov/2020:04:56:31 +0000] "GET / HTTP/1.1" 200 58 "-" req_t=0.003 upstream_t=0.004 "<browser-info>" "<source-ip-1,source-ip2,....>"

Примечание. Существует несколько исходных IP-адресов, если вы используете прокси (например, Cloudfare и другие).

Информация была там, мой настоящий IP был там. Затем я просмотрел формат журналирования NGINX, чтобы узнать, как это было возможно, и обнаружил следующее:

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      'req_t=$request_time upstream_t=$upstream_response_time '
                      '"$http_user_agent" "$http_x_forwarded_for"';

Значит, магия здесь -> $http_x_forwarded_for

После этого я изменил заголовки прокси, например proxy_set_header X-Real-IP $http_x_forwarded_for; .

И, наконец, последний тест, использующий эту информацию о проекте NodeJS, внутри производственной системы, с использованием Docker Swarm с наложенной сетью, примерно с 4 виртуальными машинами, и угадайте, что, это сработало! Наконец-то я смог получить настоящий IP-адрес.

Я так счастлив, потому что этот вопрос открыт уже давно, но я думаю, что это ответ. Я использовал следующие версии:

Docker version: 19.03.8
NGINX version: nginx/1.14.2

Буду ждать ваших отзывов. Надеюсь, у вас будут такие же результаты, как у меня.

Ваше здоровье!
Себастьян.

PS: Попробуйте это с помощью другого сетевого интерфейса, то есть вне localhost, потому что вы найдете в журнале «-» вместо своего реального IP-адреса. Попробуйте протестировать его через Интернет, полностью вне вашей домашней сети.

Бонус: я также мог сопоставить IP-адрес с геолокацией, используя таблицу поиска, посчитать их и нанести на карту, так что ответ - да, это то, что мы искали, ребята :)

@sebastianfelipe : после всех этих лет это большая претензия. Вы уверены, что не используете режим хоста или другие обходные пути в этой теме?

@sebastianfelipe : после всех этих лет это большая претензия. Вы уверены, что не используете режим хоста или другие обходные пути в этой теме?

Я уверен. Я не использую сетевой хост для всех подключенных служб. Я только что развернул стек с наложенной сетью в производственной среде, включая балансировщик нагрузки Digital Ocean, и это сработало. Я имею в виду, я не могу проверить это лучше, чем это. На 100% реально.

@sebastianfelipe Я предполагаю, что балансировщик нагрузки Digital Ocean

@beornf Я пытался заснуть, а затем прочитал ваше уведомление, поэтому мне пришлось проснуться и попробовать подход без балансировщика нагрузки Digital Ocean, и это не удалось. Вы правы, Digital Ocean добавляет волшебства, когда добавляется балансировщик нагрузки. Это происходит с переменной $http_x_forwarded_for . Балансировщик нагрузки Digital Ocean добавляет информацию в другую переменную NGINX, которая не добавляется непосредственно Docker Swarm. Вероятно, это может привести к «фиктивному» подходу, чтобы найти реальное решение для каждого случая. По крайней мере, клиенты Digital Ocean могут быть счастливы узнать, что с этим делать прямо сейчас.

@beornf @sebastianfelipe В дополнение к контексту CloudFlare также добавляет X-Forwarded-For и в основном бесплатен.

@beornf @sebastianfelipe В дополнение к контексту CloudFlare также добавляет X-Forwarded-For и в основном бесплатен.

Я думаю, что это может сработать для многих из нас, которым нужен выход, чтобы получить настоящий IP. Cloudfare можно настроить как прокси или только как DNS. Он идеально подходит для клиентов Digital Ocean. До сих пор это был более чистый обходной путь. Но я согласен с @beornf , нам нужно реальное решение, не зависящее от Digital Ocean или Cloudfare.

Спасибо!