Работа с сокетами в Bitrix при использовании Docker

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

Дано:
0) httpd-сервер в докере, nginx проксирует в докер с хост-машины с IP-адресом 10.222.128.6.
1) Более 150 доменов типа dom.2nd.lvl.ru, которые руками писать в файл hosts просто идиотизм, а wildcard-записи, к сожалению, не поддерживаются.

Для начала стоит проверить, что в принципе данный метод сработает. Для этого надо прописать в /etc/hosts контейнера нужный домен, с которого идёт проверка, и IP-адрес хост-машины (не localhost):

/etc/hosts

10.222.128.6 dom.2nd.lvl.ru

Если проверка Bitrix успешно проходит, то можно продолжать дальше городить костыли!

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

Установка и настройка простая:

yum -y install dnsmasq

Создается 2 файла конфигурации. В первом прописываем wildcard для нужных доменов:

/etc/dnsmasq.conf

address=/.2nd.lvl.ru/10.222.128.6

Запись выше будет отдавать А-запись на все домены *.2nd.lvl.ru на сервер 10.222.128.6.

Следующий файл конфигурации содержит адреса вышестоящих DNS-форвардеров:

/etc/resolv.dnsmasq

nameserver 8.8.8.8
nameserver 8.8.4.4

Осталось сделать рестарт и проверить, что сервис успешно запустился без ошибок:

systemctl enable dnsmasq.service
systemctl start dnsmasq.service

После этого в контейнере в /etc/resolv.conf должен быт прописан этот новый DNS-сервер:

nameserver 10.222.128.1

Теперь осталось проверить:

ping dom2.2nd.lvl.ru

Ответом будет IP-адрес 10.222.128.6.

Но проверка системы всё равно ругается на Работа с сокетами Ошибка!

Для проверки, куда же битрикс долбится, запустить tcpdump в контейнере:

tcpdump -nn port 53

И параллельно снова стартовать проверку системы.

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

Если сделать рестарт контейнера, то можно наблюдать, что он перезаписал resolv.conf, чего не очень бы хотелось лицезреть.

Поэтому достаточно прописать в resolv.conf хост-машины 10.222.128.6 nameserver 10.222.128.1 первой строкой, перезапустить контейнер и проверить, что resolv.conf подсосался с нужным сервером, а проверка проходит успешно.

Схематически в конечном итоге это выглядит так: