Gunicorn: Добавляете поддержку ASGI?

@arcivanov Я внимательно посмотрю на этот протокол, чтобы узнать, что для него нужно сделать :)

Обновим этот билет как можно скорее.

любые обновления?

Мы с @benoitc @berkerpeksag поговорили об этом по электронной почте. Насколько я знаю, работы еще не начались. У меня еще не было времени узнать больше об ASGI, поэтому я не могу оценить сложность реализации этого. Если кто-то хочет внести свой вклад в эту работу, я с энтузиазмом помогу, обсудю и рассмотрю.

Я нахожусь в процессе пересмотра спецификации ASGI, чтобы в любом случае иметь больше смысла для серверов, поэтому я бы предостерегал от любых действий, пока это не будет завершено (здесь разрабатывается новая спецификация, но она совсем не окончательная: http: / /channels.readthedocs.io/en/2.0/asgi.html - это в основном больше похоже на WSGI)

@andrewgodwin круто, не могу дождаться, чтобы попробовать Gunicorn с asgi

@andrewgodwin каков статус ASGI?

Недавно я попытался протестировать приложение ASGI, и вот что у меня получилось:

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 сейчас работает стабильно. Я не уверен, говорите ли вы, что Дафна соблюдает или не придерживается спецификации?

ссылка на django последняя о "спецификации" ASGI, или есть еще что-нибудь, что описывает поток?

@andrewgodwin Я пытался продемонстрировать, что если Дафна поддерживает ASGI, то ASGI должен быть готов для использования другими фреймворками / серверами.

@benoitc есть две страницы спецификации ASGI:

https://github.com/django/asgiref/blob/master/specs/asgi.rst - общая спецификация ASGI.

https://github.com/django/asgiref/blob/master/specs/www.rst - спецификации, описывающие протоколы HTTP и WebSockets и совместимость с WSGI.

@sirex спасибо. Хотя эти спецификации не очень полезны, когда речь идет о реализации.

В любом случае я нашел https://channels.readthedocs.io/en/latest/, что нормально. Думаю, я бы предпочел поддержку, но мы можем предложить что-нибудь, поддерживающее asgi, как только мы удалим поддержку python 2.

Кстати, выбран последний комментарий, поскольку он не имеет отношения к этому обсуждению.

Я не перешел к тому, чтобы сделать ASGI PEP, так как я хочу сначала убедиться, что он имеет достаточную общую поддержку (а этот процесс требует много времени и усилий), но это намерение, и он должен быть написан как один.

мы можем предложить что-то, поддерживающее asgi, как только мы удалим поддержку python 2.

Если вы начинаете думать о реализации, то стоит начать с uvicorn , который склеивает вместе gunicorn, uvloop и httptools. Возможно, в какой-то момент для этой работы имеет смысл откатиться к Gunicorn в качестве поддерживаемого рабочего класса.

(Было бы неплохо, если бы uvicorn стал более минималистичным вариантом, без мониторинга процесса и т. Д., Который обеспечивает Gunicorn.)

Документация по спецификации ASGI теперь доступна здесь: https://asgi.readthedocs.io/en/latest/.

Ладно, теперь это покрыто. (Как сторонний рабочий класс.)

Uvicorn 0.2 больше не зависит от Gunicorn для его прямого запуска, но включает два рабочих класса Gunicorn для запуска приложений ASGI.

Для локальных разработчиков или случаев, когда вы не заботитесь о надзоре за процессами, вы можете просто запустить uvicorn напрямую. Для производства мы документируем использование класса Gunicorn в качестве предпочтительного варианта.

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

Запустите приложение ASGI из Gunicorn, используя uvloop и httptools:

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

Запустите приложение ASGI из gunicorn, используя asyncio и h11 (для совместимости с pypy):

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

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

Теперь, когда gunicorn больше не поддерживает python 2 , технически возможно добавить поддержку ASGI

@tomchristie Мне интересно, как это будет выглядеть. В качестве альтернативы, может быть, распаковать протоколы в виде отдельного пакета или пакетов?

Мне интересно, как это будет выглядеть. В качестве альтернативы, может быть, распаковать протоколы в виде отдельного пакета или пакетов?

Я предполагаю, что это либо рабочий класс в Gunicorn, который зависит от uvicorn для протоколов h11 и / или httptools. Или продублируйте реализацию здесь.

Дублирование ограниченной части реализации для предоставления встроенной в Gunicorn поддержки ASGI HTTP с зависимостью h11 может быть хорошей базой?

может быть, распаковать протоколы как отдельный пакет или пакеты?

Из uvicorn особо нечего извлечь - если бы мы отбросили click и просто использовали argparse и немного изменили наши зависимости setup.py, то у него не было бы жестких зависимостей с различными вариантами для различные реализации HTTP, реализации WS, циклы событий.

Мне нужна первоклассная поддержка ASGI, означает ли это добавление дополнительных зависимостей в Gunicorn, рабочую программу-заглушку, которая сообщает вам, что устанавливать, документацию или что-то еще.

Да, пожалуйста. собираюсь переключиться на Дафну из Gunicorn .. если бы Gunicorn мог просто поддержать asgi
это сэкономило бы мне столько времени.

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

Django 3.0 (выпуск которого запланирован на декабрь 2019 года) будет иметь поддержку ASGI из коробки , так что это будет еще одна веская причина для gunicorn чтобы поддержать его напрямую. Мы, вероятно, увидим большой рост интереса пользователей после того, как это будет опубликовано.

@johnthagen , это на трубе. Однако нам нужно немного разобраться с билетами и выпустить релиз в этом месяце перед началом.