izi DevOps

Что делать когда compose up поднялся, но сеть так и не работает

Ниже 4 инструмента и приёма чтобы понять, где именно проблема.

➖➖➖

▎1. docker network inspect

Посмотри что Docker реально создал:


docker network ls
docker network inspect myproject_default

Что важно увидеть в выводе:

▸ Containers. Кто реально подключён к этой сети. Если сервиса там нет, он в другой сети, и DNS его не увидит.
▸ Subnet и Gateway. Пригодится когда есть конфликт с корпоративной сетью (10.x / 172.x). У меня такое бывало пару раз.
▸ Driver. bridge, overlay или macvlan. Compose по умолчанию поднимает bridge user-defined.
▸ Internal: true. Сеть без выхода в интернет.

Чтобы увидеть к каким сетям подключён конкретный контейнер, кастуй команду ниже:


docker inspect web --format '{{json .NetworkSettings.Networks}}' | jq

Если у web сеть frontend, а у db сеть backend то они не увидят друга.

➖➖➖

▎2. Embedded DNS на 127.0.0.11

Когда контейнер делает nslookup db, запрос летит не в гугл и не в системный resolver. Он идёт на 127.0.0.11, встроенный DNS Docker. Этот резолвер живёт в каждом контейнере на user-defined bridge.

Внутри контейнера:


$ cat /etc/resolv.conf
nameserver 127.0.0.11

Что Docker делает с запросом:

1. Сначала смотрит, есть ли контейнер с таким именем в той же сети.
2. Если нет, форвардит на хостовый DNS.

Поэтому db резолвится в IP контейнера, а google.com уходит наружу.

На дефолтном bridge (без user-defined) этого DNS нет. Поэтому docker run без compose тебя по имени не свяжет, только по IP. Это одна из причин почему дефолтный bridge мертв.

Ещё про DNS: алиасы. У сервиса в compose можно задать дополнительные имена для сети:


services:
  db:
    image: postgres:16
    networks:
      app-net:
        aliases:
          - postgres
          - primary-db

И теперь db, postgres, primary-db резолвятся в один и тот же контейнер. Удобно при переименованиях, чтобы не трогать код приложения, если вдруг он у вас так отвратительно написан).

➖➖➖

▎3. nicolaka/netshoot

Не нужно ставить tcpdump в свой образ. Запускаешь сайдкар, который делит сетевой namespace с проблемным контейнером:


docker run -it --rm \
  --network container:web \
  nicolaka/netshoot

Внутри netshoot есть всё: dig, tcpdump, nmap, iperf, mtr, nslookup, tshark, iproute2.


# 1. Резолвится ли имя?
dig db

# 2. Слушает ли db нужный порт?
nc -zv db 5432

# 3. Доходит ли пакет?
tcpdump -i any -n host db

# 4. Есть ли вообще маршрут наружу?
ip route

➖➖➖

▎4. external: true для сетей между compose-проектами

Частый кейс: фронт в одном docker-compose.yml, бэк в другом, observability в третьем, и хочется чтобы они видели друг друга по имени сервиса.

Создаёшь сеть один раз руками:


docker network create shared-net

И в каждом compose-файле ссылаешься на неё как на внешнюю:


services:
  web:
    image: app:1.0
    networks:
      - shared-net

networks:
  shared-net:
    external: true

external: true означает "используй уже существующую сеть". Если её нет, compose упадёт с ошибкой network not found.

Когда это к месту:

▸ несколько compose-проектов и нужно чтобы они общались
▸ база живёт вечно, а сервисы пересобираются

Альтернатива: затащить всё в один compose-файл. Если проектов уже три и они растут, external чище.

@izi.devops

1👍8❤2

1.78K views14:32