Gunicorn: Ajout de la prise en charge ASGI ?

@arcivanov je vais regarder de plus près ce protocole pour voir ce qu'il faut faire pour cela :)

Mettra à jour ce ticket dès que possible.

les mises à jour?

@benoitc @berkerpeksag et j'en ai discuté par e-mail. Aucun travail n'a encore commencé à ma connaissance. Je n'ai pas encore eu le temps d'en savoir plus sur ASGI, je ne peux donc pas estimer la complexité de sa mise en œuvre. Si quelqu'un souhaite contribuer au travail dans ce sens, je l'aiderai, discuterais et réviserais avec enthousiasme.

Je suis en train de réviser la spécification ASGI pour qu'elle ait de toute façon beaucoup plus de sens pour les serveurs, donc je vous déconseille de faire quoi que ce soit jusqu'à ce que ce soit terminé (une nouvelle spécification est en cours de rédaction ici, mais n'est pas du tout définitive : http:/ /channels.readthedocs.io/en/2.0/asgi.html - cela ressemble beaucoup plus à WSGI)

@andrewgodwin cool a hâte d'essayer gunicorn avec asgi

@andrewgodwin quel est le statut ASGI ?

J'ai récemment essayé de tester une application ASGI et voici ce que j'ai obtenu :

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 est stable maintenant. Je ne sais pas si vous dites que Daphne respecte ou non les spécifications ?

le lien sur django est-il le dernier à propos de la "spec" ASGI, ou y a-t-il autre chose qui décrit le flux ?

@andrewgodwin J'essayais de démontrer que si Daphne prend en charge ASGI, alors ASGI doit être prêt à être adopté par d'autres frameworks/serveurs.

@benoitc il y a deux pages de spécifications ASGI :

https://github.com/django/asgiref/blob/master/specs/asgi.rst - spécification générale ASGI.

https://github.com/django/asgiref/blob/master/specs/www.rst - spécifications décrivant les protocoles HTTP et WebSockets et la compatibilité avec WSGI.

@sirex merci. Bien que ces spécifications ne soient pas très utiles lorsqu'il s'agit de mettre en œuvre.

Quoi qu'il en soit, j'ai trouvé https://channels.readthedocs.io/en/latest/ qui est ok. Je pense que je préférerais un pep, mais nous pouvons proposer quelque chose qui supporte asgi dès que nous avons supprimé le support de python 2.

btw J'ai supprimé le dernier commentaire car il n'est pas lié à cette discussion.

Je n'ai pas bougé pour faire d'ASGI un PEP car je veux d'abord m'assurer qu'il bénéficie d'un soutien général suffisant (et ce processus prend beaucoup de temps et d'efforts), mais c'est l'intention et il devrait être écrit comme tel.

nous pouvons proposer quelque chose supportant asgi dès que nous avons supprimé le support de python 2.

Si vous commencez à penser à la mise en œuvre, cela vaut la peine de commencer par uvicorn , qui colle ensemble gunicorn, uvloop et httptools. Il serait peut-être logique que ce travail soit réintégré dans le gunicorn en tant que classe ouvrière soutenue à un moment donné.

(Il serait peut-être bien qu'uvicorn devienne alors une option plus minimale, sans la surveillance du processus, etc. fournie par gunicorn.)

La documentation des spécifications ASGI est désormais disponible ici : https://asgi.readthedocs.io/en/latest/.

D'accord, couvrez-le maintenant. (En tant que classe ouvrière tierce.)

Uvicorn 0.2 ne dépend plus de gunicorn pour l'exécuter directement, mais inclut deux classes de travailleurs gunicorn pour exécuter des applications ASGI.

Pour le développement local, ou les cas où vous ne vous souciez pas assez de la supervision des processus, vous pouvez simplement exécuter uvicorn directement. Pour la production, nous documentons en utilisant une classe gunicorn comme option préférée.

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

Exécutez l'application ASGI depuis gunicorn, en utilisant uvloop et httptools :

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

Exécutez l'application ASGI à partir de gunicorn, en utilisant asyncio et h11 (pour la compatibilité pypy):

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

Si vous souhaitez intégrer l'une ou l'autre des implémentations de protocole dans le package de base de gunicorn, je suis très ouvert à l'envisager.

Maintenant que gunicorn ne supporte plus python 2 , il est techniquement faisable d'ajouter le support ASGI

@tomchristie Je suis intéressé par ce à quoi cela ressemblerait. Comme alternative, peut-être extraire les protocoles en tant que package ou packages distincts ?

Je suis intéressé par ce à quoi cela ressemblerait. Comme alternative, peut-être extraire les protocoles en tant que package ou packages distincts ?

Je suppose soit une classe ouvrière dans gunicorn qui dépendait de uvicorn pour les protocoles h11 et/ou httptools. Ou bien dupliquer l'implémentation ici.

Dupliquer une partie limitée de l'implémentation pour donner à Gunicorn le support HTTP ASGI intégré avec une dépendance h11 pourrait être une bonne base de référence ?

peut-être extraire les protocoles en tant que package ou packages distincts ?

Il n'y a pas vraiment grand-chose à extraire de uvicorn - Si nous supprimions click et utilisions simplement argparse, et ajustions un peu nos dépendances setup.py, il n'y aurait aucune dépendance dure, avec diverses options pour différentes implémentations HTTP, implémentations WS, boucles d'événements.

J'aimerais un support ASGI de première classe, que cela signifie ajouter des dépendances supplémentaires dans Gunicorn, un stub worker qui vous dit quoi installer, de la documentation ou autre chose.

Oui s'il vous plaît. sur le point de passer de gunicorn à daphne .. si gunicorn pouvait simplement supporter asgi
ça me ferait gagner beaucoup de temps.

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

Django 3.0 (qui sortira en décembre 2019) aura un support ASGI prêt à l'emploi , ce sera donc une autre bonne raison pour gunicorn de le prendre en charge directement. Nous verrons probablement une forte augmentation de l'intérêt des utilisateurs après sa sortie.

@johnthagen c'est sur le tuyau. Cependant, nous devons éclaircir un peu les tickets et faire une sortie ce mois-ci avant de commencer.