Django Channels + Elastic Beanstalk

Question

J'ai configuré un programme d'équilibrage de charge d'applications qui redirige les requêtes /ws/ vers le port 5000 sur lequel Daphné est en cours d'exécution avec 4 travailleurs (qui rechargent via Supervisord). Cependant, dans la console Chrome je reçois l'erreur

WebSocket connection to 'wss://api.example.com/ws/' failed: WebSocket is closed before the connection is established.

lors d'une tentative de se connecter à mon WebSocket par simple code JavaScript (voir Multichat quelque chose assez proche). Des idées?

Routing.py

websocket_routing = [ 
# Called when WebSockets connect 
route("websocket.connect", ws_connect), 

# Called when WebSockets get sent a data frame 
route("websocket.receive", ws_receive), 

# Called when WebSockets disconnect 
route("websocket.disconnect", ws_disconnect), 
] 

Settings.py

# Channel settings 
CHANNEL_LAYERS = { 
"default": { 
    "BACKEND": "asgi_redis.RedisChannelLayer", 
    "CONFIG": { 
     "hosts": ["redis://:xxxxx@xxxx-redis.xxxxx.1234.usxx.cache.amazonaws.com:6379/0"], 
    }, 
    "ROUTING": "Project.routing.channel_routing", 
}, 

} 

Supervisord.conf

[program:Daphne] 
environment=PATH="/opt/python/run/venv/bin" 
environment=LD_LIBRARY_PATH="/usr/local/lib" 
command=/opt/python/run/venv/bin/daphne -b 0.0.0.0 -p 5000 Project.asgi:channel_layer 
directory=/opt/python/current/app 
autostart=true 
autorestart=true 
redirect_stderr=true 
stdout_logfile=/tmp/daphne.out.log 
[program:Worker] 
environment=PATH="/opt/python/run/venv/bin" 
environment=LD_LIBRARY_PATH="/usr/local/lib" 
command=/opt/python/run/venv/bin/python manage.py runworker -v2 
directory=/opt/python/current/app 
process_name=%(program_name)s_%(process_num)02d 
numprocs=4 
autostart=true 
autorestart=true 
redirect_stderr=true 
stdout_logfile=/tmp/workers.out.log 

daphne.out.log

2017-03-05 00:58:24,168 INFO  Starting server at tcp:port=5000:interface=0.0.0.0, channel layer Project.asgi:channel_layer. 
2017-03-05 00:58:24,179 INFO  Using busy-loop synchronous mode on channel layer 
2017-03-05 00:58:24,182 INFO  Listening on endpoint tcp:port=5000:interface=0.0.0.0 

workers.out.log

2017-03-05 00:58:25,017 - INFO - runworker - Using single-threaded worker. 
2017-03-05 00:58:25,019 - INFO - runworker - Using single-threaded worker. 
2017-03-05 00:58:25,010 - INFO - runworker - Using single-threaded worker. 
2017-03-05 00:58:25,020 - INFO - runworker - Running worker against channel layer default (asgi_redis.core.RedisChannelLayer) 
2017-03-05 00:58:25,020 - INFO - worker - Listening on channels chat.receive, http.request, websocket.connect, websocket.disconnect, websocket.receive 
2017-03-05 00:58:25,021 - INFO - runworker - Running worker against channel layer default (asgi_redis.core.RedisChannelLayer) 
2017-03-05 00:58:25,021 - INFO - worker - Listening on channels chat.receive, http.request, websocket.connect, websocket.disconnect, websocket.receive 
2017-03-05 00:58:25,021 - INFO - runworker - Running worker against channel layer default (asgi_redis.core.RedisChannelLayer) 
2017-03-05 00:58:25,022 - INFO - worker - Listening on channels chat.receive, http.request, websocket.connect, websocket.disconnect, websocket.receive 
2017-03-05 00:58:25,029 - INFO - runworker - Using single-threaded worker. 
2017-03-05 00:58:25,029 - INFO - runworker - Running worker against channel layer default (asgi_redis.core.RedisChannelLayer) 
2017-03-05 00:58:25,030 - INFO - worker - Listening on channels chat.receive, http.request, websocket.connect, websocket.disconnect, websocket.receive 

code JavaScript qui fonctionne avant l'échec

// Correctly decide between ws:// and wss:// 
var ws_scheme = window.location.protocol == "https:" ? "wss" : "ws"; 
var ws_path = ws_scheme + '://' + window.location.host + "/ws/"; 
console.log("Connecting to " + ws_path); 
var socket = new ReconnectingWebSocket(ws_path); 

De toute évidence, il n'y a pas de sortie pertinente dans les journaux daphné/travailleur qui implique la connexion est potentiellement ne pas être correctement mis en déroute en premier lieu.

Answer 1

Tout a été configuré correctement - c'était un problème d'autorisations. Portez une attention particulière à tous les groupes de sécurité AWS pertinents (à la fois l'équilibreur de charge et les instances membres du groupe cible).