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 в докере выглядит не до конца готовой. Однако, уже есть наработки, позволяющие вполне сносно жить. Поэтому берите и пользуйтесь, новая эра не за горами.
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.
Использование 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, но оно не критическое для использования данной конфигурации в процессе разработки сайтов и обеспечения доступа к тестовым сборкам.
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-контейнер.
Using Docker Behind a Proxy
March 28, 2017
Stay connected
In today’s article, I am going to explore a common pain point for anyone running Docker in a large corporate environment. Today I’ll show how to use Docker without direct internet access.
By default, Docker assumes that the system running Docker and executing Docker commands has general access to the internet. Often in large corporate networks this is simply not the case. More often than not, a corporate network will route all internet traffic through a proxy.
While this setup is generally transparent to the end user, this type of network environment often neglects command line tools such as Docker. For today’s article, we will use Docker to build and run a simple container within a «locked down» network.
A Simple Example of Working with a Proxy
Before jumping into the proxy settings however, let’s take a quick look at the Dockerfile we will be building from.
Let’s go ahead and attempt to execute a docker build to see what happens by default in a «locked down» network.
From the above execution, we can see that the docker build results in a download error of the base ubuntu image. The reason is also pretty obvious: access to docker.io was blocked.
Configuring Docker to Use a Proxy
On Ubuntu (which is the OS our Docker host is running), we can configure Docker to do this by simply editing the /etc/default/docker file.
Within the /etc/default/docker file, there is a line that is commented by default which specifies the http_proxy environmental variable.
In order to route Docker traffic through a proxy, we will need to uncomment this line and replace the default value with our proxy address.
This proxy is not currently set up for username— or password— based authentication. However, if it was we could add those details using the https://username:password@192.168.33.10:3128/ format.
We can do this by executing the service command.
With our changes in effect, let’s go ahead and see what happens when executing a docker build command.
From the above build output, we can see that Docker was able to pull the ubuntu image successfully. However, our build still failed due to connectivity issues.
Specifically, our build failed during the apt-get command execution.
The reason the build failed is because even though we configured Docker itself to use a proxy, the operating environment within the container is not configured to use a proxy. This means when apt-get was executed within the container, it attempted to go directly to the internet without routing through the proxy.
In cases like this, it is important to remember that sometimes containers need to be treated in the same way we would treat any other system. The internal container environment works as if it is independent of the host system. That means configurations that exist on the host do not necessarily exist within the container. Our proxy is a prime example of that in practice.
To that end, if we were to stand up a physical or virtual machine with Ubuntu installed in this network environment, we would need to configure apt-get on that system to utilize a proxy. Just like we configured Docker to utilize a proxy.
The same is true for the container we are building. Luckily, configuring a proxy for apt-get is pretty easy.
Configuring apt-get to Use a Proxy
We simply need to set the http_proxy and https_proxy environmental variables during build time. We can do this with the docker build command itself.
Testing the proxy settings
With the http_proxy and https_proxy environmental variables added, let’s rerun our build.
From the above, it appears our build was successful. Let’s go ahead and run this container.
It is important to remember that these values not only affect the container during build but also during execution. If for some reason we did not want to use this proxy during the execution of the container, we would need to reset the http_proxy and https_proxy values by either passing new values during docker run execution or by changing our Dockerfile to match the below.
Summary
In this article, we covered how to configure Docker (on Ubuntu) to use a proxy to download container images. We also explored how to configure apt-get within the container to use a proxy and why it is necessary.
While this is useful for Ubuntu laptops and hosts running Docker, many people use the Docker for Mac & Windows application. Luckily, the proxy configuration for Docker for Mac & Windows is pretty easy as well. In fact, it is part of the Docker preferences configuration.
In the Docker preferences, there is an option for Proxies. If you simply click this option, you can add both an HTTP and HTTPS proxy using the Manual proxy configuration option.
