Gunicorn: إضافة دعم ASGI؟

تم إنشاؤها على ٢ نوفمبر ٢٠١٦  ·  22تعليقات  ·  مصدر: benoitc/gunicorn

Django Daphne قيد التطوير لدعم ASGI ، لكن خادم Daphne جديد للغاية وغير مناسب بعد للإنتاج (على سبيل المثال ، لا يوجد دعم SSL ، وآلام النضج).

هل هناك أي اهتمام بإضافة دعم ASGI في GUnicorn للسماح باستخدام WSGI / ASGI السلس؟

- Mailing List -

التعليق الأكثر فائدة

حسنًا ، قم بتغطية هذا الآن. (كفئة عامل طرف ثالث.)

لم يعد Uvicorn 0.2 يعتمد على 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 الأساسية ، فأنا منفتح جدًا للنظر في ذلك.

ال 22 كومينتر

arcivanov سألقي نظرة فاحصة على هذا البروتوكول لمعرفة ما يجب القيام به من أجله :)

سيتم تحديث هذه التذكرة في أسرع وقت ممكن.

أي تحديثات؟

benoitcberkerpeksag وتحدثت عبر البريد الإلكتروني حول هذا الموضوع. لم يبدأ أي عمل حتى الآن أعرف عنه. لم يتح لي الوقت بعد لقراءة المزيد عن 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 كنت أحاول أن أشرح ، أنه إذا كان Daphne يدعم 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. قد يكون من المنطقي أن يعود هذا العمل إلى البونيكورن كفئة عاملة مدعومة في مرحلة ما.

(قد يكون من الجيد أن تصبح uvicorn خيارًا بسيطًا ، بدون مراقبة العملية وما إلى ذلك التي يوفرها gunicorn.)

وثائق مواصفات ASGI متاحة الآن هنا: https://asgi.readthedocs.io/en/latest/.

حسنًا ، قم بتغطية هذا الآن. (كفئة عامل طرف ثالث.)

لم يعد Uvicorn 0.2 يعتمد على 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 و / أو HTptools. أو قم بتكرار التنفيذ هنا.

قد يكون تكرار جزء محدود من التنفيذ لمنح Gunicorn المدمج دعم ASGI HTTP مع تبعية h11 أساسًا جيدًا؟

ربما استخراج البروتوكولات كحزمة أو حزم منفصلة؟

ليس هناك الكثير لاستخراجه من uvicorn - إذا أسقطنا click واستخدمنا فقط argparse ، وقمنا بتعديل تبعيات setup.py قليلاً ، فلن يكون هناك أي تبعيات صلبة ، مع خيارات مختلفة لـ تطبيقات HTTP مختلفة ، تطبيقات WS ، حلقات الأحداث.

أرغب في دعم ASGI من الدرجة الأولى ، سواء كان ذلك يعني إضافة تبعيات إضافية في Gunicorn ، عامل كعب يخبرك بما يجب تثبيته أو توثيقه أو أي شيء آخر.

نعم من فضلك. على وشك التحول إلى دافني من جونيكورن .. إذا كان بإمكان جونيكورن دعم آسجي
من شأنه أن يوفر لي الكثير من الوقت.

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

جانغو 3.0 (مجموعة لاطلاق سراح ديسمبر 2019) سوف يكون الدعم ASGI من خارج منطقة الجزاء ، حتى لا تكون سبب وجيه آخر ل gunicorn لدعم مباشرة. من المحتمل أن نرى ارتفاعًا كبيرًا في اهتمام المستخدم بعد إصدار ذلك.

johnthagen هذا على الأنبوب. ومع ذلك ، نحتاج إلى توضيح بعض التذاكر وإصدارها هذا الشهر قبل البدء.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات