Docker -компонент: для чего используются сокеты прослушивания, «внедренные» в контейнеры по IP 127.0.0.11? - PullRequest
Новая
       22

Docker -компонент: для чего используются сокеты прослушивания, «внедренные» в контейнеры по IP 127.0.0.11?

0 голосов
/ 23 января 2020

Совершенно случайно я заметил, что контейнеры, запущенные как сервисы через docker-compose, содержат два сокета, которые подключены к процессу dockerd хоста, но, похоже, не являются "Docker сокетом" для связи с * 1044. * демон API. Эти сокеты не отображаются для контейнеров, запущенных с обычным docker run ....

. Для воспроизведения сначала создайте файл yaml * compose docker, composer-woes.yaml со следующим содержимым: 

version: '3'
services:
  ubuntu:
    image: 'ubuntu'
    pid: host
    command: ['/bin/sleep', '100000000']

Затем откройте сервис «ubuntu»: docker-compose -f composer-woes.yaml up.

Затем войдите в контейнер сервисов, установите инструменты и проверьте, что открыто: 

$ docker exec -it ${PWD##*/}_ubuntu_1 /bin/bash
# apt-get update && apt-get install -y net-tools iproute2
# netstat -tulp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.11:39627        0.0.0.0:*               LISTEN      -                   
udp        0      0 127.0.0.11:58047        0.0.0.0:*                           -
# ss -tulp
Netid           State             Recv-Q            Send-Q                          Local Address:Port                          Peer Address:Port            
udp             UNCONN            0                 0                                  127.0.0.11:58047                              0.0.0.0:*               
tcp             LISTEN            0                 128                                127.0.0.11:39627                              0.0.0.0:*
# cat /proc/self/net/tcp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     
   0: 0B00007F:9ACB 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 139272 1 0000000000000000 100 0 0 10 0

Обратите внимание, как оба netstat и ss не могут найти процесс, открыв эти сокеты. Мы видим, что у странного сокета есть индекс # 139272. Теперь нам понадобится сканировать хост на наличие процесса с помощью fd, ссылающегося на этот инод.

На вашем хосте, наконец, выполните этот код magi c bash; не забудьте заменить inode #, который вы видите в своем тесте: 

sudo bash -c "sock=socket:[139272]; for proc in /proc/*; do for fd in \$proc/fd/*; do readlink \$fd | grep -q -F \$sock && echo \$proc: \$sock ... \$(cat \$proc/cmdline|sed 's/\o0/ /g'); done; done"
/proc/1375: socket:[139272] ... /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

Итак, два сокета UDP / TCP внутри Docker контейнера, выданного docker-compose, на самом деле принадлежат dockerd процесс хоста вне контейнера Docker.

  • часть вопроса 1: для чего используются эти сокеты? Единственная ссылка на 127.0.0.11 Я могу найти информацию о Встроенный DNS-сервер в пользовательских сетях .
  • вопрос часть 2: как эти сокеты на самом деле попадают в контейнер? Обратите внимание, что они принадлежат dockerd, а не containerd-shim.

1 Ответ

0 голосов
/ 07 февраля 2020

После еще нескольких копаний, пробуя множество различных поисковых запросов, я наконец нашел две записи как работает Docker Встроенный преобразователь DNS? , Ответ на: Пересылать входящие внешние пакеты DNS на встроенный docker DNS , который косвенно объясняет, что происходит, подробности см. в ссылках ниже.

Вкратце: порты udp и tcp, которые мы видим, на самом деле являются встроенным DNS-сервером механизма Docker. порты. Дополнительные правила переадресации портов iptables гарантируют, что клиенты, обращающиеся к 127.0.0.11:53, «подключены» к этим динамически назначенным портам встроенного DNS-сервера.

...