Gunicorn: ¿Agregando soporte ASGI?

@arcivanov Voy a

Actualizará este ticket lo antes posible.

¿alguna actualización?

@benoitc @berkerpeksag y yo charlamos por correo electrónico al respecto. Aún no ha comenzado ningún trabajo que yo sepa. Todavía no he tenido tiempo de leer más sobre ASGI, por lo que no puedo estimar la complejidad de implementar esto. Si alguien quiere contribuir con el trabajo hacia esto, con entusiasmo ayudaría, discutiría y revisaría.

De todos modos, estoy en el proceso de revisar la especificación ASGI para que tenga mucho más sentido para los servidores, por lo que le advierto que no debe hacer nada hasta que esté terminado (se está redactando una nueva especificación aquí, pero no es definitiva en absoluto: http: / /channels.readthedocs.io/en/2.0/asgi.html: básicamente se parece mucho más a WSGI)

@andrewgodwin cool no puedo esperar para probar gunicorn con asgi

@andrewgodwin ¿cuál es el estado ASGI?

Recientemente intenté probar una aplicación ASGI y esto es lo que obtuve:

import json

def app(scope):
    async def channel(receive, send):
        message = await receive()

        if scope['method'] == 'POST':
            response = message
        else:
            response = scope

        await send({
            'type': 'http.response.start',
            'status': 200,
            'headers': [
                [b'Content-Type', b'application/json'],
            ],
        })
        await send({
            'type': 'http.response.body',
            'body': json.dumps(response, default=bytes.decode).encode(),
        })
        await send({
            'type': 'http.disconnect',
        })
    return channel

> daphne app:app
2018-03-31 22:28:10,823 INFO     Starting server at tcp:port=8000:interface=127.0.0.1
2018-03-31 22:28:10,824 INFO     HTTP/2 support enabled
2018-03-31 22:28:10,824 INFO     Configuring endpoint tcp:port=8000:interface=127.0.0.1
2018-03-31 22:28:10,825 INFO     Listening on TCP address 127.0.0.1:8000
127.0.0.1:43436 - - [31/Mar/2018:22:28:17] "GET /" 200 347
127.0.0.1:43440 - - [31/Mar/2018:22:28:22] "POST /" 200 43
127.0.0.1:43446 - - [31/Mar/2018:22:28:42] "POST /" 200 54

> http -b get :8000/
{
    "type": "http"
    "http_version": "1.1",
    "method": "GET",
    "path": "/",
    "query_string": "",
    "root_path": "",
    "scheme": "http",
    "headers": [
        ["host", "localhost:8000"],
        ["user-agent", "HTTPie/0.9.9"],
        ["accept-encoding", "gzip, deflate"],
        ["accept", "*/*"],
        ["connection", "keep-alive"]
    ],
    "client": ["127.0.0.1", 43360],
    "server": ["127.0.0.1", 8000],
}

> http -b -f post :8000/ foo=bar
{
    "body": "foo=bar",
    "type": "http.request"
}

> http -b -j post :8000/ foo=bar
{
    "body": "{\"foo\": \"bar\"}",
    "type": "http.request"
}

https://github.com/django/asgiref/blob/master/specs/www.rst

@sirex ASGI es estable ahora. No estoy seguro de si está diciendo que Daphne cumple o no las especificaciones.

¿Es el enlace en django el último sobre la "especificación" de ASGI, o hay algo más que describa el flujo?

@andrewgodwin Estaba tratando de demostrar que si Daphne es compatible con ASGI, entonces ASGI debe estar listo para que lo adopten otros marcos / servidores.

@benoitc hay dos páginas de especificación ASGI:

https://github.com/django/asgiref/blob/master/specs/asgi.rst : especificación general de ASGI.

https://github.com/django/asgiref/blob/master/specs/www.rst : especificaciones que describen los protocolos HTTP y WebSockets y la compatibilidad con WSGI.

@sirex gracias. Aunque estas especificaciones no son muy útiles cuando se trata de implementar.

De todos modos, he encontrado https://channels.readthedocs.io/en/latest/ que está bien. Creo que preferiría un impulso, pero podemos proponer algo que admita asgi tan pronto como eliminemos el soporte de Python 2.

Por cierto, ideé el último comentario ya que no está relacionado con esa discusión.

No me he movido para hacer de ASGI un PEP ya que primero quiero asegurarme de que tenga suficiente apoyo general (y ese proceso requiere mucho tiempo y esfuerzo), pero esa es la intención y debería escribirse como tal.

podemos proponer algo que admita asgi tan pronto como eliminemos el soporte de python 2.

Si comienza a pensar en la implementación, entonces valdría la pena comenzar con uvicorn , que une gunicorn, uvloop y httptools. Bien podría tener sentido que ese trabajo regrese a gunicorn como una clase de trabajadores asistidos en algún momento.

(Podría ser bueno que uvicorn se convierta en una opción más mínima, sin el monitoreo de procesos, etc.que proporciona gunicorn).

La documentación de especificaciones de ASGI ahora está disponible aquí: https://asgi.readthedocs.io/en/latest/.

Bien, tenga esto cubierto ahora. (Como una clase de trabajadores externos).

Uvicorn 0.2 ya no depende de gunicorn para ejecutarlo directamente, sino que incluye dos clases de trabajador de gunicorn para ejecutar aplicaciones ASGI.

Para los desarrolladores locales, o los casos en los que no le importa lo suficiente la supervisión de procesos, puede ejecutar uvicorn directamente. Para la producción, documentamos utilizando una clase gunicorn como la opción preferida.

http://www.uvicorn.org/#running -with-gunicorn

Ejecute la aplicación ASGI desde gunicorn, usando uvloop y httptools:

gunicorn app:App -w 4 -k uvicorn.workers.UvicornWorker

Ejecute la aplicación ASGI desde gunicorn, usando asyncio y h11 (para compatibilidad con pypy):

gunicorn app:App -w 4 -k uvicorn.workers.UvicornH11Worker

Si hay algún deseo de incorporar cualquiera de las implementaciones del protocolo al paquete central de gunicorn, entonces estoy muy abierto a considerarlo.

Ahora que gunicorn ya no admite python 2 , es técnicamente factible agregar ASGI soporte

@tomchristie Estoy interesado en cómo se vería. Como alternativa, ¿tal vez extraer los protocolos como un paquete o paquetes separados?

Estoy interesado en cómo se vería eso. Como alternativa, ¿tal vez extraer los protocolos como un paquete o paquetes separados?

Supongo que una clase de trabajador en gunicorn que dependía de uvicorn para los protocolos h11 y / o httptools. O bien, duplique la implementación aquí.

¿Duplicar una parte limitada de la implementación para dar soporte HTTP ASGI integrado a Gunicorn con una dependencia h11 podría ser una buena línea de base?

tal vez extrayendo los protocolos como un paquete o paquetes separados?

Realmente no hay mucho que extraer de uvicorn : si eliminamos click y usamos argparse, y ajustamos un poco nuestras dependencias setup.py, entonces no tendría dependencias estrictas, con varias opciones para diferentes implementaciones HTTP, implementaciones WS, bucles de eventos.

Me gustaría soporte ASGI de primera clase, ya sea que eso signifique agregar dependencias adicionales en Gunicorn, un trabajador auxiliar que le dice qué instalar, documentación u otra cosa.

sí, por favor. a punto de cambiar a daphne de gunicorn .. si gunicorn pudiera soportar asgi
eso me ahorraría mucho tiempo.

@japrogramer http://www.uvicorn.org/#running -with-gunicorn

Django 3.0 (que se lanzará en diciembre de 2019) tendrá soporte ASGI listo para usar, por lo que será otra gran razón para que gunicorn admita directamente. Probablemente veremos un gran aumento en el interés de los usuarios después de que se publique.

@johnthagen que está en la tubería. Sin embargo, necesitamos aclarar un poco las entradas y hacer un lanzamiento este mes antes de comenzar.