Proxy docker что это
Использование HAProxy и Docker на машине разработчика при разработке сайтов
Написанию этого небольшого руководства предшествовало нескольких недель мучений с попытками работы над проектами, когда было необходимо чтобы был запущен контейнер с сайтом для работы, контейнеры с тестовыми сборками, чтобы тестировщики могли безопасно для основных данных проверить новые возможности системы, а так же сборки техподдержке для изучения работы с системой в условиях приближенных к «боевым».
Помимо этого должен был работать служебный web-интерфейс для членов моей группы разработки. При этом часть систем должна работать на одной версии php, часть на другой. При этом есть различия в окружении в котором работают сайты, начиная с операционной системы и http-сервера обрабатывающего запросы, и заканчивая установленными модулями php.
Вроде бы ничего сложного, подними контейнеры и пробрасывай порты наружу. Но для каждого контейнера нужно указать свои внешние порты, которые нужно запоминать, а потом передать их, например, бухгалтеру (это тоже тестировщик), чтобы он проверил доработки в используемой им системе. Иногда я и сам не мог понять, почему только что исправленные скрипты работают не так как положено или почему сайт вообще не открывается.
После раздумий было решено пробрасывать все запросы через HAPRoxy на фронтенде, который доступен по портам 80 и 443, и в зависимости от имени хоста направляет запросы на нужный контейнер.
Конфигурация docker
Начнем настройку с конфигурации docker сети, потому что нам нужен контроль над сетевыми адресами которые будут выделены контейнерам.
Создаем docker сеть с указанием подсети. Указать подсеть необходимо для направления запросов с HAProxy на определенные ip-адреса чтобы не было проблем с разрешением имен доменов, если какой-то из контейнеров не запущен.
Чтобы запускаемые контейнеры работали в нужной нам сети и получали ip адреса из нее в docker-compose.yml будем напрямую указывать сеть:
а в конфигурации контейнеров, на которые будут перенаправляться запросы с HAProxy, жестко задавать ip-адрес.
Сертификат для работы https
Для работы HAProxy по https необходимо создать самоподписанный сертификат или подключить готовый от удостоверяющего центра.
Создание самоподписанного сертификата
Для создания самоподписанного сертификата необходимо выполнить ряд команд, после которых вы получите файл сертификата который можно использовать для работы HAProxy.
Путь к полученному файлу сертификата необходимо будет прописать в конфигурации HAProxy.
Подготовительны шаги закончены, дальше объединяем все в конфигурациях HAProxy и Docker.
Ниже приведены примеры файлов конфигурации haproxy.cfg и docker-compose.yml.
Подробно останавливаться на каждом пункте конфигураций не буду, они хорошо описаны в документации. Я сделаю только краткие примечания для тех, что еще не использовал HAProxy и docker-compose.
Конфигурация HAPRoxy
Приведенная конфигурация для HAProxy перенаправляет все запросы с порта 80 на порт 443, а затем, основываясь на имени запрошенного хоста, направляет на один из сайтов которые работают по 80 порту. Для сайтов нет необходимости настраивать работу по https.
Запросы пришедшие на 443 порт будут сразу направлены на соответствующие сайты.
В понятиях HAProxy разделы описанные как frontend представляют внешние интерфейсы, куда приходят запросы.
В настройках frontend указываются условия, при удовлетворении которым запрос будет переадресован на заданный backend.
Backend, соответственно, интерфейсы куда запросы перенаправляются.
Раздел defaults задает общие параметры для всех разделов описанных в конфигурации.
По умолчанию в официальных docker образах HAProxy файл конфигурации располагается в /usr/local/etc/haproxy/haproxy.cfg
Конфигурации docker-compose.yml
Для запуска docker контейнеров будем использовать docker-compose, что позволит описать все необходимые настройки в одном или в нескольких yml файлах конфигурации которые можно будет объединить при запуске.
Приведенная конфигурация запускает контейнеры для сайтов microbase.localhost и coordinator.localhost на которые будут направлены запросы с HAProxy.
Так же в конфигурации задан контейнер c самим HAProxy который будет обрабатывать запросы.
По умолчанию docker-compose будет использовать файл docker-compose.yml в папке из которой запущен.
Передать имя другого файла можно при помощи параметра -f.
При вызове docker-compose может быть указано несколько параметров -f. При этом, каждый последующий файл конфигурации будет дополнять предыдущие.
Тестирование
Тестирование производилось утилитой siege с настройками по умолчанию и с 25 конкурирующими подключениями. Каждый тест был ограничен по времени 1-ой минутой.
В качестве теста использовался php файл со следующим кодом:
Сайты работали под управлением apache 2.4 и php как модуль.
Запуск производился на ноутбуке с процессором Intel Core i5-8250U 1.60GHz, оперативной памятью 8Гб и SSD диском. В качестве системы использовался Linux Mint 20 Cinnamon
Ниже приведены результаты тестирования.
Разница в производительности
Разница в производительности
Как и предполагалось, наблюдается падение производительности при использовании решения с HAProxy, но оно не критическое для использования данной конфигурации в процессе разработки сайтов и обеспечения доступа к тестовым сборкам.
Docker + IPv6 = ❦
Немного текста про поддержку IPv6 в докере и ещё кой-какие нюансы docker networking.
Теперь представим, что мы должны научить наше приложение обращаться к IPv6-хостам. Допустим, что наша хост-машина теперь помимо IPv4- адреса на eth0 получила и IPv6-адрес (глобально маршрутизируемый, link-local адреса не в счёт). Также у нас вместо IPv4-DNS сервера теперь имеется IPv6-сервер (было бы странно иметь DNS-сервер, доступный по IPv4, который умеет отвечать на AAAA-запросы). Если мы захотим, чтобы наши контейнеры тоже могли ходить по IPv6, нам нужно:
DNS стоит крайним пунктом, потому что сначала нужно научиться ходить по IP-адресам, а потом уже добавлять поддержку DNS
1) Реальная подсеть от провайдера размера /80 и больше
2) NDP proxying
Если в вашем распоряжении нет достаточно большой подсети, а есть, к примеру, только 16 адресов (/124), то можно воспользоваться NDP проксированием. При этом адреса контейнерам придётся указывать самостоятельно (либо явно с использованием кастомной сети, либо неявно в дефолтной, используя тот факт, что адреса докер выдаёт предсказуемо, на базе MAC-адреса, а MAC-адрес можно указать руками). Ещё придётся добавить каждый такой адрес в список neighbors и включить несколько флагов ядра. Этот вариант неудобен из-за большого количества ручной работы. Подробнее про этот способ можно почитать в документации.
3) IPv6 NAT
Если же провайдер выделяет только один адрес (или не хочется возиться с NDP), то можно взять и настроить NAT. При этом в качестве подсети можно взять любую ULA-подсеть (https://en.wikipedia.org/wiki/Unique_local_address) (аналог 10.0.0.0/8 в IPv4) и настроить ip6tables. Добрые люди сделали контейнер (https://github.com/robbertkl/docker-ipv6nat), который достаточно просто запустить, и всё заработает: он будет автоматически редактировать правила ip6tables при создании новых контейнеров. В принципе, этот вариант кажется предпочтительным, потому что в этом случае вы никак не зависите от поведения провайдера (или IaaS), тем самым нивелируя риски по переходу к другому поставщику услуг. Для функционирования IPv6 в этом режиме достаточно лишь прописать подсеть в конфиг (или добавить свою новую сеть) и запустить маленький контейнер. Всё остальное сделает он сам.
Далее нужно настроить сеть выбранным способом и проверить работоспособность собранной схемы.
После этого наш контейнер снова может успешно резолвить доменные имена, т.к. конфигурация скопирована с хост-машины.
Далее нужно разобраться, как правильно слушать сокеты в приложении, если хотите открыть порт для подключений снаружи и что делать, если приложение написано криво и не поддерживает ipv6.
Открытие портов наружу
Если всё (и хост машина, и докер) IPv4-only, проблем вроде бы возникнуть не должно. Просто приложение должно уметь байндиться на 0.0.0.0. Если приложение умеет слушать только на локалхосте, то тут спасёт только кастомная tcp proxy, запущенная в том же контейнере. Она будет слушать на всех интерфейсах, а транслировать данные в локалхост. socat вполне должен подойти для этой задачи.
В принципе, особой разницы между dual-стеком и IPv6-only стеком нет. Внутри всё равно будет dual stack так как докер использует в своей основе IPv4, а IPv6 рассматривает только как дополнение. Единственное, что нужно будет сделать дополнительно, – проверить, что порт доступен снаружи по обоим протоколам.
С использованием userland proxy в dual-стеке нужно помнить ещё и о том, что хоть слушает он порт на всех интерфейсах, пробрасывать траффик он может только на один IP-адрес (он ведь не балансер). Какой из них будет выбран, если у контейнера их два: IPv4 и IPv6? В исходниках видно, что IP-адрес выбирается один:
https://github.com/docker/libnetwork/blob/master/portmapper/mapper.go#L96
Но какой из них действительно будет выбран? Экспериментально выяснено, что всегда выбирается IPv4-адрес. Для точного ответа нужно будет исследовать кодЗаключение
В целом, поддержка IPv6 в докере выглядит не до конца готовой. Однако, уже есть наработки, позволяющие вполне сносно жить. Поэтому берите и пользуйтесь, новая эра не за горами.
Docker и аутентификация через Nginx
Одна из досадных проблем, которые встают при создании NAS, заключается в том, что не всякое программное обеспечение может работать с LDAP, а некоторое вообще не содержит механизмов аутентификации.
Решением является сквозная аутентификация через обратный прокси.
Пример того, как это сделать, весьма подробно разобран, например в этой статье.Поскольку данная статья является частью NAS цикла,
здесь я остановлюсь на том, как приспособить данное решение к сервисам в Docker-контейнерах.Решение основывается на примере реализации аутентификации через внешнего агента Nginx LDAP Auth, но я использую контейнеризованный вариант от LinuxServer.io потому, что это готовый образ, соответствующий определённым стандартам.
Единственная проблема заключалась в том, что патчи LinuxServer.io сломали базовую HTTP аутентификацию, но после того, как влили багфикс, пользоваться этим стало опять возможно.
Аутентификация в общем случае
Как показано в статьях, аутентификация производится по следующей схеме:
Альтернативным вариантом может являться использование компилируемого модуля для nginx, но я данный вариант здесь не рассматриваю с силу некоторых проблем с данным модулем и меньшей его гибкости.
Доработанный образ для OpenLDAP сервера есть здесь.
Аутентификация контейнеров
В рамках NAS, сервисы работают в контейнерах, поэтому есть желание сделать так, чтобы возможно было переключать режимы аутентификации, просто установив переменные внутри контейнера.
Такой механизм уже есть в используемом образе ngingx-proxy и реализован он через шаблоны, которые обрабатывает docker-gen.
Он подставляет в шаблон метаданные, которые содержат описание запущенных в данный момент контейнеров Docker.
Таким образом, всё что надо сделать — это доработать шаблон конфигурации обратного прокси так, чтобы при наличии условной переменной в контейнере, было включено перенаправление на сервис сквозной аутентификации, который также работает в контейнере.
Затем, внести соответствующие коррективы в конфигурацию docker-compose.
Реализация аутентификации
Модификация шаблона конфигурации nginx-proxy
В первую очередь добавляется новый upstream, который позволяет обращаться к сервису аутентификации в конфиге:
Путь /auth-proxy — это и есть перенаправление на сервис аутентификации.
Параметры будут переданы через заголовки HTTP.
Какие параметры и для чего нужны, вполне подробно описано в комментариях.И последнее, когда LDAP аутентификация для сервиса включена, добавляется auth_request в его location:
Ниже приведён полный листинг шаблона.
Модификация конфигурации docker-compose
В docker-compose.yml были добавлены:
То что записано в переменных, nginx передаст сервису аутентификации через HTTP заголовки.
Назначение параметров ясно из названий переменных, так что останавливаться я на них не буду.
Полный конфиг смотрите ниже.Использование сервисом
Сквозная аутентификация по умолчанию выключена.
Для её включения достаточно установить в окружении нужного контейнера переменные:Заключение
В целом, решение уже длительное время работает и обеспечивает не только аутентификацию, но и авторизацию.
Что позволяет использовать в NAS любые сервисы в контейнерах, независимо от того поддерживают ли они аутентификацию через LDAP.Хотя имеются некоторые проблемы:
Конфигурацию NAS вы можете найти в репозитории.
The docker-proxy
Containers created and managed by the Docker platform, are able to provide the service that is running inside the container, not only to other co-located containers, but also to remote hosts. Docker achieves this with port forwarding. For a brief introduction to containers, take a look at a previous article.
When a container starts with its port forwarded to the Docker host on which it runs, in addition to the new process that runs inside the container, you may have noticed an additional process on the Docker host called docker-proxy :
In order to understand why this process exists, we first need to understand a little about Docker’s networking configuration. The default modus operandi for a Docker host is to create a virtual ethernet bridge (called docker0 ), attach each container’s network interface to the bridge, and to use network address translation (NAT) when containers need to make themselves visible to the Docker host and beyond:
Controlling access to a container’s service is controlled with rules associated with the host’s netfilter framework, in both the NAT and filter tables. The general processing flow of packets by netfilter is depicted in this diagram.
Netfilter is stateful, which means that it can track connections that have already been established, and in such circumstances it bypasses the NAT table rules. But in order for a connection to be established in the first place, packets are subjected to the scrutiny of the rules in the NAT and filter tables.
The first rule applies, which forces a jump to the DOCKER chain, and the single rule in the chain matches the characteristics of the packet, and ‘accepts’ the packet for forwarding on to the container’s socket. Hence, a remote service consuming process thinks it is communicating with the Docker host, but is being serviced by the container instead.
Similarly, when a container initiates a dialogue with a remote service provider, netfilter’s NAT POSTROUTING chain changes the source IP address of packets from the container’s IP address, to the address of the host’s network interface that is responsible for routing the packets to their required destination. This is achieved with netfilter’s MASQUERADE target.
A Docker host makes significant use of netfilter rules to aid NAT, and to control access to the containers it hosts, and the docker-proxy mechanism isn’t always required. However, there are certain circumstances where this method of control is not available, which is why Docker also creates an instance of the docker-proxy whenever a container’s port is forwarded to the Docker host.
Nginx как обратный прокси на Docker
О nginx
Nginx — веб-сервер с открытыми исходными кодами наподобие Apache. Несмотря на то что nginx и Apache могут использоваться в качестве веб-серверов, их функциональность и архитектура отличаются. Ниже приведены основные функции nginx.
В этой статье я расскажу, как использовать nginx в качестве обратного прокси. Вся конфигурация nginx выполнена через Docker.
Об обратном прокси
Обратный прокси — промежуточный сервер, который принимает запрос клиента, ретранслирует его на backend-серверы и затем передает ответ сервера обратно клиенту.
С помощью обратного прокси можно обслуживать несколько веб-приложений (с разными доменами) на одном сервере с общедоступным IP-адресом.
Обслуживание веб-приложений с помощью nginx имеет множество преимуществ.
Сценарий
«У меня есть веб-приложение, написанное на языке Scala и запущенное в Docker. Я использую его с помощью обратного прокси. Я купил домен (www.bankz.com), который будет обслуживать это веб-приложение.
Все запросы сперва поступают в nginx, затем nginx перенаправляет их в приложение Scala. В этом сценарии я использую докеризированный nginx, так как все мои веб-приложения запускаются с помощью Docker.»
Ниже перечислены шаги, которые я предпринял для внедрения и конфигурации приложения:
1. Докеризированный nginx:
Так выглядит Dockerfile для nginx-сервера
2. Nginx-конфиг
Здесь представлена самая простая конфигурация nginx-файла.
3. Docker-compose
Я запускаю веб-приложение с помощью Docker-compose. Ниже вы увидите простейший Docker-compose-файл.
Обратите внимание, что links определяется в nginx. Связывая веб-контейнер с nginx, Docker добавляет запись хоста для web в /etc/hosts nginx- контейнера.
4. Как запустить
После этого нужно добавить домен www.bankz.com в DNS сервер с IP машины, которая запускает nginx контейнер.
Если вы хотите протестировать контейнер в вашем локальном окружении (без DNS), добавьте запись хоста в файл /etc/hosts как показано снизу:
192.168.59.103 — IP Docker хоста, так как я запускаю Docker с помощью boot2docker на OSX. Если вы запускаете Docker без boot2docker, то можете просто дать IP машине, которая запускает nginx-контейнер.
