Узел роя Docker не может обнаружить службу с другого хоста в рое

Моя цель — настроить рой докеров на группе из 3 физических рабочих станций Linux (ubuntu) и запустить dask на этом кластере.

$ docker --version
Docker version 17.06.0-ce, build 02c1d87

Я могу запустить рой докеров и добавить все машины в рой.

cordoba$ docker node ls
ID                            HOSTNAME    STATUS    AVAILABILITY MANAGER STATUS
j8k3hm87w1vxizfv7f1bu3nfg     box1        Ready     Active              
twg112y4m5tkeyi5s5vtlgrap     box2        Ready     Active              
upkr459m75au0vnq64v5k5euh *   box3        Ready     Active              Leader

Затем я запускаю docker stack deploy -c docker-compose.yml dask-cluster на поле лидера.

Вот docker-compose.yml:

version: "3"

services:

  dscheduler:
    image: richardbrks/dask-cluster
    ports:
     - "8786:8786"
     - "9786:9786"
     - "8787:8787"
    command: dask-scheduler
    networks:
      - distributed
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
      placement:
        constraints: [node.role == manager]

  dworker:
    image: richardbrks/dask-cluster
    command: dask-worker dscheduler:8786
    environment:
      - "affinity:container!=dworker*"
    networks:
      - distributed
    depends_on:
      - dscheduler
    deploy:
      replicas: 3
      restart_policy:
        condition: on-failure

networks:
  distributed:

а вот richardbrks/dask-cluster:

# Official python base image
FROM python:2.7    
# update apt-repository
RUN apt-get update
# only install enough library to run dask on a cluster (with monitoring)
RUN pip install --no-cache-dir \
    psutil \
    dask[complete]==0.15.2 \
    bokeh

Когда я развертываю рой, узлы dworker, которые не находятся на той же машине, что и dscheduler, не знают, что такое dscheduler. Я подключился к одному из этих узлов и посмотрел в env, но dscheduler там не было. Я также пытался пропинговать dscheduler и получил "пинг: неизвестный хост".

Я думал, что докер должен был предоставить внутренний DNS на основе обнаружения службы, так что вызов dscheduler приведет меня к адресу узла dschedler.

Есть ли какие-то настройки на моих компьютерах, которые мне не хватает? или в каком-то из моих файлов чего-то не хватает?

Весь этот код также находится в https://github.com/MentalMasochist/dask-swarm


person Rich    schedule 14.09.2017    source источник
comment
Не могли бы вы описать, как вы пытаетесь получить доступ к другому сервису? Вы делаете внутри контейнера dworker?   -  person herm    schedule 14.09.2017
comment
@герм Да. Я подключаюсь по ssh к компьютеру, на котором работает узел dworker, использую docker ps, чтобы получить идентификатор работающего контейнера, а затем набираю docker exec -ti <docker id> /bin/bash, чтобы войти в узел. Вот где я пытаюсь пропинговать dscheduler.   -  person Rich    schedule 14.09.2017
comment
Вы путаете термины. Узел в рое — это компьютер. с docker exec вы вводите контейнер, а не узел. Вы использовали неправильные имена, но поступили правильно :)   -  person herm    schedule 14.09.2017
comment
Я проверил, и ваша установка работает нормально, и я могу подключиться по телнету от рабочего к планировщику на другой машине.   -  person Tarun Lalwani    schedule 14.09.2017


Ответы (2)


Согласно этой проблеме в рое:

Из-за некоторых сетевых ограничений (я думаю, связанных с виртуальными IP-адресами) инструмент ping не будет работать с оверлейной сетью. Можно ли разрешить имена сервисов с помощью других инструментов, таких как dig?

Лично я всегда мог подключиться от одного сервиса к другому, используя curl. Ваши настройки кажутся правильными, и ваши службы должны иметь возможность обмениваться данными.


FYI зависит от не поддерживается в рое


Обновление 2: я думаю, что вы не используете порт. Servicename не является заменой порта. Вам нужно использовать порт, поскольку контейнер знает его внутри.

person herm    schedule 14.09.2017
comment
Я установил и запустил dig внутри контейнера, но получил ошибку NXDOMAIN, что означает, что не удалось найти хост. Ваша ссылка на проблему показала некоторые другие возможные причины невозможности подключения других служб на других хостах. Я прочитаю проблему и посмотрю, решит ли какое-либо из их предложений мою проблему. Кроме того, спасибо, что сообщили мне о depends_on. - person Rich; 14.09.2017
comment
Тарун Лалвани подтвердил правильность вашего файла компоновки. Какую именно команду вы используете для подключения контейнеров? Для curl это будет: curl dscheduler:8786/path - person herm; 14.09.2017
comment
Контейнерный dworker должен подключиться к dscheduler из команды dask-worker dscheduler:8786 из файла компоновки, где dscheduler должен быть ip планировщика, а 8786 — порт. Отвечает ли это на ваш вопрос? - person Rich; 15.09.2017
comment
да. Можете ли вы связаться с другой машиной по IP? возможно, порты не открыты или вмешивается брандмауэр. - person herm; 15.09.2017
comment
Я могу пропинговать машину главного узла с рабочего узла и из контейнера на рабочем узле. - person Rich; 15.09.2017
comment
Я понятия не имею, почему это не сработает для вас. Мне жаль - person herm; 15.09.2017
comment
Кроме того, с рабочего узла (хотя и не в контейнере) netcat может подключаться к следующим портам на главном узле: 2377 (tcp), 7946 (tcp), 7946 (udp) и 4789 (udp). - person Rich; 15.09.2017
comment
а 8786? Поскольку вы публикуете этот порт (8786:8786), он также должен быть доступен - person herm; 15.09.2017
comment
Я думаю, что я нашел что-то. Когда я нахожусь внутри контейнера на рабочем узле, я получаю следующую ошибку: root@adc78cf2c38d:/# netcat -vz cordoba.<company>.com 8786 DNS fwd/rev mismatch: cordoba.<company>.com != <ip-address>-static.hfc.comcastbusiness.net cordoba.company.com [<ip-address>] 8786 (?) open Значения с ‹› вокруг них анонимизируют вывод. - person Rich; 15.09.2017
comment
Ваша сеть, кажется, ваша проблема, а не рой докеров - person herm; 15.09.2017
comment
Нашел проблему: В прошивке роутера нашего офиса был баг. Как только я вернулся к предыдущей версии прошивки, все заработало нормально. @herm: спасибо за помощь! - person Rich; 25.09.2017

Не было ничего плохого в dask или docker swarm. Проблема была в плохой прошивке роутера. После того, как я вернулся к предыдущей версии прошивки маршрутизатора, кластер работал нормально.

person Rich    schedule 25.09.2017