Доступ к демону Docker на хосте, не зная хост-ОС

Question

Я использую docker -композицию для раскрутки нескольких контейнеров как части приложения, которое я разрабатываю. Один из контейнеров должен запустить службу роя docker на хост-компьютере. На Docker для Windows и Docker для Ma c я могу подключиться к демону docker хоста, используя REST Api, используя DNS-имя "host. docker .internal", и это прекрасно работает , Однако, если я запускаю тот же файл compose на linux, «host. docker .internal» не работает (пока, возможно, он появится в следующей версии docker). Что еще хуже, на Linux я могу использовать сетевой режим "host", чтобы обойти эту проблему, но это не поддерживается на Windows или Ma c.

Как можно:

1. Создать docker -компонентный файл или структурировать контейнерное приложение, чтобы оно немного отличалось в зависимости от платформы хоста (windows | mac | linux) ) без необходимости создания нескольких файлов docker -compose.yml или другого кода приложения?
2. Доступ к демону хоста docker согласованным образом независимо от ОС хоста?

Если это имеет значение, контейнер, который обращается к демону docker хоста, использует docker python sdk и делает вызовы API для docker через tcp без TLS (это используется только для разработки).

Обновление с подробным описанием решения

Для более подробной информации есть веб-приложение (например, pnet core / C#), которое позволяет пользователям загружать zip-архив файл. Этот zip-файл содержит, помимо прочего, экспортированный docker файл изображения. Перед всем этим также находится контейнер nginx, позволяющий выполнить ssl-завершение и распределение нагрузки. Веб-приложение извлекает образ docker, затем с помощью http api демона docker загружает изображение, повторно помечает изображение, а затем отправляет его в закрытое хранилище docker (которое работает где-то в сети разработчика). , внешний к docker). После этого он отправляет сообщение в очередь сообщений, где отдельное приложение python использует библиотеку python docker для развертывания образа docker в рое docker.

В целях разработки все приложения работают как контейнеры и, следовательно, должны взаимодействовать с docker, работающим на хост-машине, в качестве отдельного узла роя. Ответ SoftwareEngineer привел меня на правильный путь. Сначала я сопоставил сокет docker с хоста в контейнере веб-приложения, но столкнулся с ограничением ядра. net, которое не будет разрешено до. net 5, а именно, что нет чистого способа сделать http через unix гнездо.

Я решил эту проблему, в конце концов осознав, что nginx может преобразовать прокси http traffi c в unix сокет. Я настроил все контейнеры (включая динамически загружаемую службу Swarm из почтовых индексов), чтобы они были частью оверлейной сети, чтобы дать им всем доступ друг к другу и позволить мне подключиться к конечной точке http, чтобы управлять демоном docker / swarm хост-машины через http.

Последнее препятствие, с которым я столкнулся, заключалось в том, что nginx не удалось записать в сопоставленный файл /var/run/docker.sock, поэтому я изменил nginx .conf, чтобы он работал как root внутри контейнера.

Answer 1

Насколько я могу судить, сокет docker доступен по пути /var/run/docker.sock во всех системах. Я лично проверил это с недавним Linux дистрибутивом (Ubuntu), Windows 10 Pro, работающим Docker для Windows (2.2.0) с WSL2 (Ubuntu и Alpine) и windows cmd (cli ) и PowerShell. По памяти это работает и с OSX, и я делал то же самое в WSL1.

Отображение этого в контейнер достигается на любом терминале с -v, --volume или --mount флаги. Итак,

docker container run -v /var/run/docker.sock:/var/run/docker.sock

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