400 неправильных запросов на сокетное соединение, размещенное на балансировщике нагрузки приложения amazon

Фон

Я работаю над администратором kong для подключения к шлюзу kong api

Я использую файл docker, предоставленный администратором kong.

проблема

Контейнер Docker работает нормально на моей локальной машине, и пользовательский интерфейс загружается, как и ожидалось

Однако, когда я пытаюсь получить доступ к тому же докеру, размещенному на Amazon ECS, он не работает. Просто продолжает показывать загрузчик.

инфраструктура

Док-контейнер размещается за балансировщиком нагрузки amazon и прослушивает порт 80. Затем трафик через порт 80 перенаправляется на порт 1337 внутри контейнера докера

URL-адрес балансировщика нагрузки - http://staging.host.internal/

ошибка

Запрос

Request URL: http://staging.host.internal/socket.io/?__sails_io_sdk_version=0.13.8&__sails_io_sdk_platform=browser&__sails_io_sdk_language=javascript&EIO=3&transport=polling&t=MTvxlu9&sid=lH69C1E52B3aGVIwAANl
Request Method: GET
Status Code: 400 Bad Request
Remote Address: xx.xx.xx.xx:xx
Referrer Policy: no-referrer-when-downgrade
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Type: application/json
Date: Tue, 04 Dec 2018 15:56:05 GMT
Transfer-Encoding: chunked
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Connection: keep-alive
Cookie: io=lH69C1E52B3aGVIwAANl

отклик

{"code":1,"message":"Session ID unknown"}

Я получаю ошибку ниже в консоли

WebSocket connection to 'ws://staging.host.internal/socket.io/?__sails_io_sdk_version=0.13.8&__sails_io_sdk_platform=browser&__sails_io_sdk_language=javascript&EIO=3&transport=websocket&sid=j-RcLmqGi5bZoQ4YAAPF' failed: WebSocket is closed before the connection is established.

В журналах сервера дляDEBUG=socket.io.* Я получаю приведенный ниже журнал

Tue, 04 Dec 2018 15:07:26 GMT socket.io-parser encoding packet
{
    "type": 0,
    "nsp": "/"
}

Может кто-нибудь, пожалуйста, укажите правильное направление для его отладки.У меня нет начальной точки.

Источник

2 ответа

Мне пришлось включить липкий сеанс на ALB, так как у меня было несколько контейнеров Docker, размещенных за балансировщиком нагрузки

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

https://www.looklinux.com/enable-sticky-session-application-load-balancer-aws/

Источник

Есть несколько способов решить эту проблему:

  1. Уменьшите количество модулей/контейнеров/реплик до 1.
  2. Используйте Memcached в качестве централизованного хранилища сеансов
  3. Настройте использование закрепленного сеанса.
Источник
Другие вопросы по тегам