RabbitMQ не может присоединиться к кластеру

Я пытаюсь изучить кластеризацию узлов rabbitmq и следую это руководство, а также официальная документация.

У меня есть 2 физические машины с развернутым на них rabbitmq через докер. машина1 (192.168.1.2) должна быть кластером, а машина2 (192.168.1.3) — присоединиться к нему.

Когда я пытаюсь запустить rabbitmqctl join_cluster [email protected] с машины2, происходит сбой со следующим сообщением.

Clustering node [email protected] with [email protected]
Error: unable to perform an operation on node '[email protected]'. Please see diagnostics information and suggestions below.

Most common reasons for this are:

 * Target node is unreachable (e.g. due to hostname resolution, TCP connection or firewall issues)
 * CLI tool fails to authenticate with the server (e.g. due to CLI tool's Erlang cookie not matching that of the server)
 * Target node is not running

In addition to the diagnostics info below:

 * See the CLI, clustering and networking guides on https://rabbitmq.com/documentation.html to learn more
 * Consult server logs on node [email protected]
 * If target node is configured to use long node names, don't forget to use --longnames with CLI tools

DIAGNOSTICS
===========

attempted to contact: ['[email protected]']

[email protected]:
  * connected to epmd (port 4369) on 192.168.1.2
  * epmd reports node 'rabbit' uses port 25672 for inter-node and CLI tool traffic
  * TCP connection succeeded but Erlang distribution failed
  * suggestion: check if the Erlang cookie identical for all server nodes and CLI tools
  * suggestion: check if all server nodes and CLI tools use consistent hostnames when addressing each other
  * suggestion: check if inter-node connections may be configured to use TLS. If so, all nodes and CLI tools must do that
   * suggestion: see the CLI, clustering and networking guides on https://rabbitmq.com/documentation.html to learn more


Current node details:
 * node name: '[email protected]'
 * effective user's home directory: /var/lib/rabbitmq
 * Erlang cookie hash: XXXXXXXXXXXXX

Журналы ошибок на машине1 не показывают ничего, связанного с такой попыткой подключения. Я проверил md5sum файлов cookie в обоих контейнерах докеров, и они абсолютно одинаковы. Так же и разрешения.

Я предположил, что порт 4369 недоступен, но это так.

Я не уверен, что я делаю неправильно. Может ли кто-нибудь помочь здесь?

Дополнительная информация:

Я использую изображение управления rabbitmq:3.85. Он использует Erlang/OTP 23 [erts-11.0.3].

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


person stonecharioteer    schedule 02.08.2020    source источник
comment
Что-то кажется странным в архитектуре, в том смысле, что два докерных движка работают автономно... но тем не менее это должно работать в любом случае. Вы пытались получить доступ к node-1.rabbit:15672 и node-2.rabbit:15672 с вашей VM2?   -  person Neo Anderson    schedule 02.08.2020
comment
Я не могу связаться с ними по этим именам. этот учебник утверждает, что я должен быть в состоянии, но нет, это не так. Должны ли узлы, открытые через имена хостов, иметь доступ друг к другу через специальное имя хоста за пределами хоста докера?   -  person stonecharioteer    schedule 02.08.2020
comment
Как насчет попытки доступа с VM2 192.168.1.2:15672?   -  person Neo Anderson    schedule 02.08.2020
comment
Когда вы говорите, что :4369 доступен, я предполагаю, что вы проверили подключение от VM2 к VM1, но проверили ли вы также из (VM2-rabbit-container) доступ к тому же порту на VM1? Держу пари, здесь глюк.   -  person Neo Anderson    schedule 02.08.2020
comment
Я пробовал netcat как на машине2, так и внутри контейнера машины2.   -  person stonecharioteer    schedule 02.08.2020
comment
Кажется, что единственная недостающая часть — это имена, которые не разрешаются. Попробуйте вручную добавить записи DNS в соответствующие etc/hosts файлы на каждой виртуальной машине. Затем повторите netcat/nslookup, но на этот раз с полными доменными именами, указанными в руководстве, как из виртуальной машины, так и из контейнера.   -  person Neo Anderson    schedule 02.08.2020
comment
Для успешной кластеризации erlang вам необходимо следующее: одинаковый файл cookie везде, правильные имена узлов и одинаковая опция «длинные имена/короткие имена» везде. Имейте в виду, что узлы [email protected] и [email protected] различны на уровне Erlang, поэтому убедитесь, что оба узла начинаются с имени [email protected],X или [email protected] и nodeX.rabbit разрешаются.   -  person José M    schedule 02.08.2020
comment
@ ХосеМ, ты прав. При кластеризации из двух контейнеров на отдельных машинах мне нужно убедиться, что служба доступна через имя узла, которое Erlang использует в сети. Поэтому быть доступным по имени хоста узла недостаточно. Простое решение — отредактировать файл хоста в самих контейнерах. Спасибо.   -  person stonecharioteer    schedule 05.08.2020
comment
@NeoAnderson не смог отметить вас в ответе. Спасибо.   -  person stonecharioteer    schedule 05.08.2020


Ответы (1)


Так что благодаря @NeoAnderson и @José M я смог понять, что произошло.

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

Простым решением будет отредактировать файл /etc/hosts в контейнерах, чтобы он указывал IP-адрес на ведущий узел.

Я просто делал это, чтобы избежать установки RMQ, а не потому, что думал, что это лучший способ сделать это. С другой стороны, docker swarm или k8s предоставили бы мне подходящую сеть.

Но основной причиной определенно была проблема с именем узла.

person stonecharioteer    schedule 05.08.2020