Как развернуть кластер распределенного потока h2o с докером?

Могут ли контейнеры пинговать друг друга по IP?

При запуске h2o вы заставляете интерфейс использовать IP-адрес контейнера? java -jar h2o.jar -flatfile плоский файл -ip -port

Эти док-контейнеры при запуске открывают друг другу порт 54321? докер запустить -it -p 54321:54321

В текущей версии H2O (3.18.0.8) вы можете:

1) Поместите список частных IP-адресов и портов экземпляра EC2 в плоский файл:

private-ip-1:54321
private-ip-2:54321
private-ip-3:54321

private-ip-1 должен быть в стандартной форме сетевого адреса из четырех октетов abcd.

2) укажите параметр --network host для запуска докера:

docker run --network host [... rest of run command ...]

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

Я бы на самом деле считал это ошибкой.

В конечном счете, решением для запуска H2O в докере может быть использование сетевого плагина, такого как weave, потому что weave может использовать многоадресную рассылку (в отличие от оверлея Docker).

Но мне удалось собрать решение для запуска H2O в docker swarm в оверлейной сети и плоском файле. Проблема с запуском в рое заключается в том, что докер назначает каждому экземпляру H2O два IP-адреса: один разрешается как stack_service, а другой виден как $HOSTNAME внутри экземпляра. H2O должен использовать IP-адрес $HOSTNAME, но заранее определить этот IP-адрес для плоского файла сложно. Поэтому вместо этого передайте файл конфигурации с именами stack_service, а затем измените их на IP-адреса с помощью сценария перед запуском H2O в каждом экземпляре.

Так, например, используйте файл docker-compose, определяющий три службы:

services:
  h2o_worker1:
    image: [h2o image]
    configs:
      - source: flatfile
        target: /flatfile
    deploy:
      placement:
        constraints:
          - node.hostname == [node1]
    ... 
  h2o_worker2:
    image: [h2o image]
    configs:
      - source: flatfile
        target: /flatfile
    deploy:
      placement:
        constraints:
          - node.hostname == [node1]
    ... 
  h2o_worker3:
    image: [h2o image]
    configs:
      - source: flatfile
        target: /flatfile
    deploy:
      placement:
        constraints:
          - node.hostname == [node1]
    ... 

##### Configs #####
configs:
  flatfile:
    file: flatfile

Где ... — это другие параметры компоновки докера, которые вам нужно ввести, а [] представляет то, что вам нужно определить для вашей установки.

Теперь создайте плоский файл на основе имен сервисов, которые будут импортированы конфигурацией:

h2o_worker1:54321
h2o_worker2:54321
h2o_worker3:54321

Очевидно, измените порты, если это необходимо. Затем используйте сценарий точки входа для поиска IP-адреса каждого имени службы, а затем добавьте 1, чтобы получить IP-адрес $HOSTNAME для каждой службы. Я просто использую сон здесь, чтобы убедиться, что все службы запущены, чтобы поиск IP работал. Docker всегда последовательно назначает две IPS для каждой службы, но YMMV. Как я уже сказал, это хак и, вероятно, не очень хорошее решение для производственного уровня. Мой сценарий точки входа выглядит примерно так:

echo "Moving flatfile to ${H2O_HOME}"
cp /flatfile ${H2O_HOME}

sleep 60
echo "Replacing hostnames in flatfile with IP addresses."
grep -o -P '.*(?=:)' ${H2O_HOME}/flatfile > ${H2O_HOME}/hostnames
grep -o -P '(?<=:).*' ${H2O_HOME}/flatfile > ${H2O_HOME}/ports
dig +short $(cat ${H2O_HOME}/hostnames) > ${H2O_HOME}/hostnames_ip
cat ${H2O_HOME}/hostnames_ip | awk -F"." '{printf "%d.%d.%d.%d\n", $1, $2, $3, $4 + 1}' > ${H2O_HOME}/new_ips
paste -d ":" ${H2O_HOME}/new_ips ${H2O_HOME}/ports > ${H2O_HOME}/new_flatfile

echo "Starting H2O..."
bash -c "java -Xmx${H2O_NODE_MEMORY:-1g} -jar ${H2O_HOME}/h2o.jar -flatfile ${H2O_HOME}/new_flatfile"

Ключевым моментом здесь является использование dig для получения IP-адресов для каждого узла службы, а затем увеличение на единицу, чтобы получить вторичный адрес, который нам нужно передать в H2O. Примечание. Я определяю переменную среды в своем Dockerfile, чтобы я мог изменять память узла в файле компоновки docker. Вам не нужно этого делать. И Dockerfile также устанавливает переменную для места установки H2O, чтобы упростить ситуацию.

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