Связь TCP Socket между процессами на рабочем месте Heroku

Я хотел бы знать, как взаимодействовать между процессами на рабочем диване Heroku.

Мы хотим, чтобы работник Resque считывал очередь и отправлял данные другому процессу, работающему на одном и том же динодере. "Другой процесс" - это готовое программное обеспечение, которое обычно использует TCP-сокеты (порт xyz) для прослушивания команд. Он настроен на запуск в фоновом режиме до начала работы специалиста Resque.

Однако, когда мы пытаемся подключиться локально к этому сокету TCP, мы ничего не получаем.

Наша задача Rake для настройки очереди делает следующее:

task "resque:setup" do
  # First launch our listener process in the background
  `./some_process_that_listens_on_port_12345 &`

  # Now get our queue worker ready, set up Redis backing store
  port = 12345
  ENV['QUEUE'] = '*'  
  ENV['PORT'] = port.to_s
  Resque.redis = ENV['REDISTOGO_URL']

  # Start working from the queue
  WorkerClass.enqueue
end

И это работает - процесс нашего слушателя запускается, и Resque пытается обрабатывать задачи с очередью. Однако задания Resque не работают, потому что они не могут подключиться к localhost:12345 (в частности, Errno::ECONNREFUSED).

Возможно, Heroku блокирует связь сокетов TCP на одном и том же динамике. Есть ли способ обойти это?

Я попытался вывести "код" из ситуации и просто выполнил в командной строке (после того, как серверный процесс утверждает, что он должным образом привязан к 12345):

nc localhost 12345 -w 1 </dev/null

Но это тоже не связано.

В настоящее время мы изучаем изменение кода клиента/сервера для использования UNIXSocket с обеих сторон, в отличие от TCPSocket, но поскольку это готовое программное обеспечение, мы бы предпочли избежать нашей собственной вилки, если возможно.

Ответы

Ответ 2

Использовать очередь сообщений Дополнения Heroku...,

как IronMQ для exsample

Ответ 3

Считая свой вопрос, вы ответили на свой вопрос, вы не можете подключиться к localhost 12345.

Этот способ настройки ваших процессов является странным, поскольку вы запускаете два процесса в одном из процессоров Heroku, который удаляет много преимуществ Heroku, т.е. independent масштабирование процесса, изоляция и декларация чистой изоляции и изоляция.

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

Ответ 4

Heroku только позволяет слушать в данном порту ($ PORT) на дино, я думаю.

Здесь я вижу два решения:

  • Используйте Redis в качестве связующего ПО для связи, поэтому рабочий снова напишет на Redis, а процесс прослушивания вместо прослушивания в порту будет запрашивать redis для новых заданий.

  • Получите еще один диктор heroku (или, лучше, совершенно другое приложение) и запустите там процесс прослушивания (на $PORT) и обменивайтесь обоими приложениями

Ответ 5

@makdad, это "стороннее программное обеспечение", написанное на Ruby? Если это так, я запустил бы его с патчем обезьяны, который подделывает TCPSocket или любой класс, который он использует для доступа к сокету TCP. Поместите патч обезьяны в собственный файл, который потребуется только для процесса Ruby, на котором запущено стороннее программное обеспечение. Патч обезьяны мог даже считывать данные непосредственно из очереди и делать TCPSocket вести себя так, как если бы эти данные были получены.

Да, это не очень элегантно, и я уверен, что может быть лучший способ сделать это, но когда вы пытаетесь выполнить работу (не тратьте время на исследования), иногда вам просто нужно укусить пуля и сделать что-то некрасивое, но работает. Независимо от того, какое решение вы выбрали, обязательно задокументируйте его для тех, кто работает над проектом позже.