Доступ к статическому ip docker образа из хоста

У меня есть 2 docker образа у каждого из которых свой статический ip. Как получить к ним доступ с хоста? Чтобы была возможность пингануть каждый.

services:
  first_server:
    image: ubuntu:22.04
    container_name: first_server
    networks:
      main_network:
        ipv4_address: 192.168.0.197

  second_server:
    image: ubuntu:22.04
    container_name: second_server
    networks:
      main_network:
        ipv4_address: 192.168.0.198

Ответы (1 шт):

Автор решения: Pak Uula

Вы не привели подробности вашей системы, поэтому приходится догадываться.

  • какие настройки у main_network - это виртуальная сеть или macvlan/ipvlan?
  • какая операционная система на хосте - линукс или виндовс?

Виртуальная сеть

Докер подключает контейнеры к виртуальной сети.

Если вы в Линуксе, то докер поднимает на хосте виртуальный интерфейс и настраивает маршрутизацию, чтобы пакеты на адреса контейнеров ходили через него. На виндоуз докер это не делает. Поэтому если вы в Винде, то никак не пингуете.

Пруф. Вообще-то это очень плохой выбор статических адресов. Обычно 192.168.0.0/24 использут для адресов в физических локальных сетях, а контейнерам назначают адреса вида 10.xxx.xxx.xxx


services:
  first_server:
    image: alpine
    container_name: first_server
    command: sh -c 'sleep infinite'
    networks:
      main_network:
        ipv4_address: 192.168.0.197

  second_server:
    image: alpine
    container_name: second_server
    command: sh -c 'sleep infinite'
    networks:
      main_network:
        ipv4_address: 192.168.0.198

networks:
  main_network:
    ipam:
     config:
       - subnet: 192.168.0.128/25
         gateway: 192.168.0.129

Запустил docker compose в линуксе. На хосте появился виртуальный интерфейс

802: br-a958fa275ea4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:71:fe:71:99 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.129/25 brd 192.168.0.255 scope global br-a958fa275ea4
       valid_lft forever preferred_lft forever
    inet6 fe80::42:71ff:fefe:7199/64 scope link

Появилась запись в таблице маршрутизации

192.168.0.128   0.0.0.0         255.255.255.128 U     0      0        0 br-a958fa275ea4

Работает Ping

$ ping 192.168.0.197
PING 192.168.0.197 (192.168.0.197) 56(84) bytes of data.
64 bytes from 192.168.0.197: icmp_seq=1 ttl=64 time=0.125 ms
64 bytes from 192.168.0.197: icmp_seq=2 ttl=64 time=0.039 ms

Теперь посмотрим, что происходит в Windows.

  • новый сетевой интерфейс не появился,
  • таблица маршрутизации не изменилась.

Причем не изменились настройки сети не только в Windows, но и в WSL.

Поэтому на Windows не получится пинговать контейнеры - сетевая подсистема не знает, куда направлять пакеты. Поэтому сетевой драйвер отправит пакеты пинга на дефолтный гейтвей, который их дропнет, так как правила предписывают не маршрутизировать пакеты, направленные на локальные адреса. Как результат, никуда пинг не дойдёт.

Сеть macvlan/ipvlan

Драйверы macvlan и ipvlan поднимают на физическом интерфейсе дополнительные адреса. macvlan создаёт дополнительный случайный MAC адрес, ipvlan дополнительный ip адрес. Пакеты, адресованные на эти адреса, передаются докеру.

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

В Линуксе такие адреса пингуются с внешних машин. Я сейчас попробовал у себя в офисе - контейнер, подключенный к macvlan, отвечал на пинги с соседней машины.

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

Вот как-то так.

→ Ссылка