Локальное соединение ZeroMQ с сокетами PAIR испытывает конфликт портов, когда одна из сторон проходит через Docker - PullRequest
Новая
       7

Локальное соединение ZeroMQ с сокетами PAIR испытывает конфликт портов, когда одна из сторон проходит через Docker

0 голосов
/ 21 мая 2018

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

Это прекрасно работает, еслиЯ просто запускаю их нормально, однако недавно я попытался создать образ Python-скрипта для Docker, и, хотя он работает совершенно нормально, программа .NET не может привязаться к этому сокету, так как уже жалуется на адресиспользование, которое выглядит довольно странной жалобой на два сокета, которые должны связываться друг с другом.

И, чтобы уточнить, их запуск в обратном порядке заставляет Docker жаловаться на то, что порт уже используется.вместо этого.

Соответствующий код Python: 

context = zmq.Context()
socket = context.socket(zmq.PAIR)
socket.connect("tcp://127.0.0.1:6008")

Соответствующий код C #: 

public ClassName(){
        context = ZmqContext.Create();
        sendSocket = context.CreateSocket(SocketType.PAIR);
        sendSocket.Bind("tcp://127.0.0.1:6008");
}

Файл Docker: 

FROM python:3
ADD pythonscriptName.py ./
RUN pip install pyzmq
EXPOSE 6008
CMD [ "python", "./pythonscriptName.py" ]

Командыиспользуется для создания и запуска Docker-образа: 

docker build -t pythonscriptName .
docker run -p 6008:6008 -d pythonscriptName

1 Ответ

0 голосов
/ 21 мая 2018

Наблюдение:

Концепция Docker создает своего рода horizon-of-abstraction , чтобы позволить коду выполняться в «Dockerised» -моде, лучше всего без егокогда-либо зная, что он хранится и запускается внутри такого горизонта абстракции.

Быть " под " таким горизонтом- абстракция подходит для рассматриваемого кода, но мир " external " должен каким-то образом поддерживать такую ​​абстракцию, чтобы сосуществовать внутри другой O / S, где отображаются ресурсы,размещены и использованы без согласования с экосистемой, скрытой " под " горизонтом абстракции.

Это означает, что становится простым в монолитной экосистеме, такой как петляАбстрактный интерфейс с эмуляцией O / S, называемый адресом доставки TCP / IPv4 127.0.0.1, прост для «внешнего» O / S (который ничего не знает ни о чем «внутри» любого горизонта-абстракция, тем меньше ни о чем, что можно было бы оперировать "за "его зрением и запахом, внутри этих изолированных, вселенных O / S-вселенных).

ZeroMQ не волшебная палочка, если ему дают указание задать O / S (реальный хост-узел, виртуализированная машина, одна или та, которая абстрагируется "за" горизонтом абстракции (внутри "контейнера Docker), соответствующая абстракция сервисов O / S просто доставляет то, что было запрошено -реальный хост O / S использует этот эмулированный доступ через интерфейс обратной связи O / S, VM-ed O / S предоставит свой (эмулированный VM) доступ через эмулированный интерфейс обратной связи O / S, и никто не должен удивляться, что эмуляция " позади "горизонт абстракции будет обеспечивать аналогичную подготовку аналогично абстрагируемого интерфейса с эмуляцией обратной связи.

Кто бы здесь ожидал, что все эти" все те же самые"127.0.0.1 адресов, которые когда-либо должны быть" встречаются"и" говорят"каждый другому из этих трех, главным образом" disjunct"- система emulaабстракции?

Решение?

Лучшая настройка узлов инфраструктуры обмена сообщениями и сигнализации ZeroMQ на реальных IP-адресах физических устройств, которые могут быть сопоставлены, перекрестно соединеныи сообщать " через " горизонт абстракции, используя сервисы настройки и сопоставления Docker, адаптированные к имеющимся интерфейсам реального хоста + используемая адресация.

Таким образом ISO / OSI-Layer3 + сервисы будут должным образом опосредованы « через » любого типа горизонта абстракции, учитывая также надлежащую соответствующую настройку и координацию адресации хоста и сети и правила безопасности, применяемые для различных сервис-посредниковустройства разрешают настраивать и поддерживать такие типы связи между ними.

Лучше избегать использования абстракций, не являющихся " переведенными " localhost или 127.0.0.1, которые не должны работать одинаково " до"эти разные горизонты абстракции (который былКстати, самая причина для введения концепции разделения " позади " такого горизонта абстракции, не так ли?)

В случае, если сокет PAIR "сопротивляется", чтобы обеспечить справедливый канал "через", в противном случае правильно настроить службы, опосредующие соединения "через" горизонт абстракции,попробуйте сначала тест PUSH/PULL, чтобы доказать, что «видимость» работает «через горизонт абстракции».

Если канал PUSH/PULL работает,PAIR/PAIR не может, поскольку задокументировано, что это своего рода «экспериментальный» шаблон архетипа масштабируемой формальной связи, который не должен поддерживать все общие службы, как это делают другие архетипы ZeroMQ, как было выражено в нативном ZeroMQAPI начиная с версии 2.1 +

Превентивная проверка с настройкой PUSH/PULL принципиально изолирует этот аспект от любых проблем, связанных с Docker, с операциями, пересекающими горизонт абстракции в любом направлении, поэтому полезно предварительно проверить оба направления до прохождения PASS "до" перед тестированиемPAIR/PAIR setup.

И последнее, но не менее важное: порты могут использоваться в тех случаях, когда использовалась плохая практика управления ресурсами и выполнение кода было брошено в необработанное исключение,в то время как некоторые Context() -экземпляры все еще изящно отображают незавершенные каналы на port# (s).Такие ситуации могут возникать, приводя к «зависанию» или «зависанию» других сокетов, бесконечно ожидая события, которое никогда не наступит, до перезагрузки такой системы.Поэтому, если вы испытываете недоступность портов после некоторых предыдущих сбоев кода, это может быть еще одной причиной для отклоненных вызовов использовать такие (еще не выпущенные) port# (s).

Добро пожаловать в царства , где директива #ASSUME NOTHING, таким образом, является более верной для всей распределенной системы с точки зрения наилучшей практики проектирования систем.

...