<p>gunicorn 20.0.0: - قم بلصق الوسائط التي لا تكتشف ضمن [server: main]</p>

اعتذاري. إدخال سجل التغيير يقول فقط "تبسيط وثائق نشر اللصق" ، وكان يجب أن أساعد في إعداد إدخال أخبار أفضل هنا.

العلاقات العامة لهذا هنا: https://github.com/benoitc/gunicorn/pull/1957

في السابق ، كنا قد أوقفنا استخدام use = egg:gunicorn#main لكن ذلك لم يعد مهملاً. يهدف التغيير إلى توضيح دور Gunicorn في بيئة متوافقة مع Paste Deploy.

هناك خياران لاستخدام Gunicorn بهذا النمط .ini ملف.

الخيار الأول هو استخدام CLI gunicorn . عند القيام بذلك ، يجب عليك استخدام علامات CLI الخاصة بـ Gunicorn أو وحدة التكوين الخاصة بـ Gunicorn (الافتراضي gunicorn.conf.py ) لتكوين وسيطات الخادم. Gunicorn Bind هو المقبس ، ويدير إعادة التحميل ، ويكتب ملفات PID وما إلى ذلك. يمكن لـ Gunicorn استخدام قسم app في .ini لتكوين التطبيق القابل للاستدعاء.

الخيار الثاني هو استخدام عداء Paste Script مثل pserve . في هذه الحالة ، يدير عداء البرنامج النصي هذا إعادة التحميل ويكتب ملفات PID وما إلى ذلك. يجب أن تظل معظم الخيارات الأخرى تعمل ، ولكن لاستخدام كتلة server لملفك .ini تحتاج إلى استدعاء عداء نصي متوافق مع اللصق. لم يعد Gunicorn عداء سيناريو من هذا القبيل.

اسمحوا لي أن أعرف إذا كان بإمكاني إضافة المزيد من الوضوح.

في حالتك ، يجب أن تكون قادرًا على المتابعة كما كان من قبل ، ولكن استخدم pserve raither من gunicorn لبدء تطبيقك. يمكن بعد ذلك أن تكون جميع تكوينات الخادم لـ Gunicorn في كتلة server الخاصة بك ، كما يبدو أنك فعلت ذلك بالفعل.

كان السلوك السابق محيرًا على الأرجح لأنه سمح بتحديد الخيارات في سطر الأوامر التي قد تتعارض مع الملف. لدينا أيضًا طلبات لإضافة القدرة على تحديد متغيرات التكوين للاستيفاء في ملف .ini وتحديد كتل server مختلفة (بالإضافة إلى كتل app مختلفة). نتيجةً لذلك ، تم اتخاذ قرار بإيقاف استخدام Gunicorn باعتباره عداء Paste _server_ بدلاً من محاولة إضافة دعم لجميع هذه الميزات. يدعم Gunicorn CLI الآن قراءة ملف Paste Deploy .ini لإنشاء تطبيق ، ولكن استخدام كتل server يترك لأدوات مخصصة في هذا النظام البيئي.

في حالتك ، يجب أن تكون قادرًا على المتابعة كما كان من قبل ، ولكن استخدم pserve raither من gunicorn لبدء تطبيقك.

شكرا للاستجابة السريعةtilgovi!

بعد توصيتك:

$ pserve development.ini
# ...
Starting server in PID 40148.
[2019-11-12 14:26:30 -0800] [40148] [INFO] Starting gunicorn 20.0.0
[2019-11-12 14:26:30 -0800] [40148] [INFO] Listening at: https://0.0.0.0:9090 (40148)
[2019-11-12 14:26:30 -0800] [40148] [INFO] Using worker: gevent
[2019-11-12 14:26:30 -0800] [40263] [INFO] Booting worker with pid: 40263

وهو أمر رائع ، نظرًا لأن جزءًا من العلاقات العامة الداخلية التي فتحتها تضمن الاضطرار إلى تغيير الأمر pserve إلى gunicorn ، وهو الأمر الذي كنت حذراً منه بعض الشيء لأنني لست المطور الأصلي لدينا خادم API الداخلي.

هذا يحل مشاكلي ، لا تتردد في إغلاق هذه المشكلة =)

شكرا،
كوري

ملاحظة أخيرة ، ثم أعتقد أنني أضفت كل التفاصيل التي يمكنني تذكرها. من المحتمل أن يكون الأمر محيرًا أن استدعاء gunicorn --paste production.ini سيستخدم Gunicorn كخادم _ حتى إذا كانت الكتلة server تحدد شيئًا آخر غير egg:gunicorn#main _!

نظرًا لأن Gunicorn هو في الأساس خادم ومدير عمليات ، فليس من المنطقي أن يكون Gunicorn عبارة عن CLI عام لاستدعاء الخوادم المتوافقة مع Paste التعسفية. بدلاً من ذلك ، Gunicorn هو خادم يدعم تطبيقات Paste Deploy وهو خادم متوافق مع Paste. إنه _not_ عداء Paste Script CLI ، بالرغم من ذلك!

فتحت مشكلة في كتاب طبخ الهرم لهذا: https://github.com/Pylons/pyramid_cookbook/issues/222

اعتقدت أنني قمت بتوثيق هذا بدقة في Gunicorn نفسها ، لكنني لم أتمكن من العثور على المرجع في البداية. إنه هنا: http://docs.gunicorn.org/en/stable/run.html#paste -deployment

tilgovi مجرد تنبيه ، كان هذا تغييرًا جذريًا لفريقي أيضًا. ربما يستحق الانتقال إلى جزء التغيير الكسر من سجل التغيير؟

سأعيد فتح المشكلة والتخصيص الذاتي. سأغلقه عندما أقوم بتحديث سجل التغيير ليكون أكثر وضوحًا هنا.

مرة أخرى ، أعتذر عن عدم ذكرها بشكل أوضح في التغيير في البداية.

تضمين التغريدة

يرجى إعلامي إذا كان يجب فتح هذا كمسألة منفصلة.

قد تكون هذه مشكلة منعزلة في قاعدة الشفرة الخاصة بنا ، ولكن بعد إجراء المزيد من الاختبارات ، لاحظ فريقي أنه بالنسبة لخادم API الخاص بنا ، فإن gunicorn 20.0.0 يقطع الوظيفة pyramid_ldap3.get_ldap_connector .

gunicorn 20.0.0 :

بطريق الانطلاق:

$ pip list | grep gunicorn
gunicorn             20.0.0
$ pserve bioapps/development.ini
[2019-11-20 15:55:30 -0800] [9902] [INFO] Starting gunicorn 20.0.0
[2019-11-20 15:55:30 -0800] [9902] [INFO] Listening at: https://0.0.0.0:10999 (9902)
[2019-11-20 15:55:30 -0800] [9902] [INFO] Using worker: gevent
[2019-11-20 15:55:30 -0800] [10034] [INFO] Booting worker with pid: 10034
/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:53: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. It may also silently lead to incorrect behaviour on Python 3.7. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016. Modules that had direct imports (NOT patched): ['urllib3.util.ssl_ (/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/urllib3/util/ssl_.py)', 'urllib3.util (/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/urllib3/util/__init__.py)'].
  monkey.patch_all()

بعد محاولة المصادقة:

[2019-11-20 15:57:54,189] INFO  [access:342][DummyThread-1] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:10999/session HTTP/1.1" {'username': 'colim', 'password': ''}
[2019-11-20 15:57:57,276] ERROR [exc_logger:114][DummyThread-1] 'https://bioappsdev02.bcgsc.ca:10999/session'
Traceback (most recent call last):
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/tweens.py", line 39, in excview_tween
    response = handler(request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/router.py", line 156, in handle_request
    view_name
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/view.py", line 642, in _call_view
    response = view_callable(context, request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/config/views.py", line 181, in __call__
    return view(context, request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/viewderivers.py", line 390, in attr_view
    return view(context, request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/viewderivers.py", line 368, in predicate_wrapper
    return view(context, request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/viewderivers.py", line 439, in rendered_view
    result = view(context, request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/viewderivers.py", line 148, in _requestonly_view
    response = view(request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/cornice/service.py", line 493, in wrapper
    response = view_(request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/bioapps/api/endpoints/session.py", line 139, in session_post
    username, request.validated['password'], request,
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/bioapps/api/endpoints/session.py", line 27, in get_ldap_groups
    auth = connector.authenticate(username, password)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid_ldap3/__init__.py", line 208, in authenticate
    password=escape_for_search(password))
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid_ldap3/__init__.py", line 82, in execute
    with manager.connection() as conn:
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid_ldap3/__init__.py", line 165, in connection
    auto_bind=True, lazy=False, read_only=True)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/ldap3/core/connection.py", line 326, in __init__
    self.do_auto_bind()
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/ldap3/core/connection.py", line 343, in do_auto_bind
    self.bind(read_server_info=True)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/ldap3/core/connection.py", line 585, in bind
    _, result = self.get_response(response)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/ldap3/strategy/base.py", line 370, in get_response
    raise LDAPResponseTimeoutError('no response from server')
ldap3.core.exceptions.LDAPResponseTimeoutError: no response from server
[2019-11-20 15:57:57,298] INFO  [access:362][DummyThread-1] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:10999/session HTTP/1.1" 500 206

gunicorn 19.9.0

بطريق الانطلاق:

$ pip install gunicorn==19.9.0
Collecting gunicorn==19.9.0
  Using cached https://files.pythonhosted.org/packages/8c/da/b8dd8deb741bff556db53902d4706774c8e1e67265f69528c14c003644e6/gunicorn-19.9.0-py2.py3-none-any.whl
Installing collected packages: gunicorn
  Found existing installation: gunicorn 20.0.0
    Uninstalling gunicorn-20.0.0:
      Successfully uninstalled gunicorn-20.0.0
Successfully installed gunicorn-19.9.0
$ pip list | grep unicorn
gunicorn             19.9.0
$ gunicorn --paste bioapps/development.ini
[2019-11-20 16:03:45 -0800] [12015] [INFO] Starting gunicorn 19.9.0
[2019-11-20 16:03:45 -0800] [12015] [INFO] Listening at: https://0.0.0.0:10999 (12015)
[2019-11-20 16:03:45 -0800] [12015] [INFO] Using worker: gevent
[2019-11-20 16:03:45 -0800] [12018] [INFO] Booting worker with pid: 12018

بعد محاولة المصادقة:

[2019-11-20 16:04:39,292] INFO  [access:342][DummyThread-1] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:10999/session HTTP/1.1" {'username': 'colim', 'password': ''}
[2019-11-20 16:04:39,527] INFO  [access:362][DummyThread-1] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:10999/session HTTP/1.1" 200 639

لم يتم إجراء أي تغييرات على development.ini بين gunicorn 20.0.0 و gunicorn 19.9.0 .

ومن المثير للاهتمام أنه يمكننا إيقاف الخطأ بـ gunicorn 20.0.0 إذا بدأنا الخادم بالأمر التالي:

$ pip list | grep unicorn
gunicorn             20.0.0
$ gunicorn --paste bioapps/development.ini -b 0.0.0.0:8999 --workers 1 --certfile /etc/ssl/certs/current/webserver.cer  --keyfile /etc/ssl/certs/current/private.key.u
[2019-11-20 16:14:27 -0800] [14783] [INFO] Starting gunicorn 20.0.0
[2019-11-20 16:14:27 -0800] [14783] [INFO] Listening at: https://0.0.0.0:8999 (14783)
[2019-11-20 16:14:27 -0800] [14783] [INFO] Using worker: sync
[2019-11-20 16:14:27 -0800] [14798] [INFO] Booting worker with pid: 14798

[2019-11-20 16:16:39,550] INFO  [access:342][MainThread] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:8999/session HTTP/1.1" {'username': 'colim', 'password': ''}
[2019-11-20 16:16:39,768] INFO  [access:362][MainThread] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:8999/session HTTP/1.1" 200 639

لست متأكدًا مما إذا كان مرتبطًا على الإطلاق ، ولكن بدء تشغيل الخادم باستخدام gunicorn 20.0.0 مع pserve هو المرة الوحيدة التي نرى فيها هذا التحذير:

/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:53: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. It may also silently lead to incorrect behaviour on Python 3.7. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016. Modules that had direct imports (NOT patched): ['urllib3.util.ssl_ (/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/urllib3/util/ssl_.py)', 'urllib3.util (/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/urllib3/util/__init__.py)'].
  monkey.patch_all()

tilgovi ماذا ستغير في سجل التغيير؟

benoitc أود استدعاء إزالة دعم تعريفات خادم Paste Deploy في Gunicorn CLI. أستطيع أن أفعل هذا اليوم.

هل من المقبول أن أقوم بتعديل سجل التغيير بأثر رجعي لجعله أكثر وضوحًا (إجراء قسم التغييرات الفاصلة في الإصدار 20.0)؟

تضمين التغريدة يمكنك بالتأكيد تشغيل gunicorn مع الخيارات المحددة في سطر الأوامر من هذا القبيل. أعتقد أن هذه هي الطريقة المفضلة والأكثر أمانًا لتشغيل gunicorn . يعد التكامل مع pserve ملائمًا ، ولكن من الجيد معرفة أنه يسبب مشكلات هنا. آمل ألا أخطئ في عدم إهماله.

هل من المقبول أن أقوم بتعديل سجل التغيير بأثر رجعي لجعله أكثر وضوحًا (إجراء قسم التغييرات الفاصلة في الإصدار 20.0)؟

tilgovi نعم بالتأكيد

tilgovi هل يمكنك إضافة هذا التغيير اليوم؟ سيكون من الرائع الحصول عليه مقابل 20.0.1 :)

تمت إضافة ملاحظة سطر واحد إلى c25563f. تم تحديث الوثائق بالفعل منذ حدوث التغيير. نأمل أن يتمكن أي شخص يرى هذه الملاحظة من العثور على الوثائق وهذه المشكلات. 😅

tilgovi شكرا

أردت فقط إضافة تأكيد آخر للتأثر بشكل مفاجئ بهذا. لم يكن ذلك مهمًا جدًا في حالتي ، لكنني كنت في حيرة من أمري حول سبب توقف برنامج gunicorn عن إعادة التحميل التلقائي في dev منذ الترقية بالإضافة إلى بعض التغييرات السلوكية البسيطة الأخرى. قضيت بعض الوقت في محاولة اكتشاف ذلك اليوم وأدركت أن الإعدادات الموجودة في ملفات INI --paste لم تعد تعمل ، مما ساعدني في إيجاد طريقي لحل هذه المشكلة.

ليس لدي أي فكرة عما إذا كان هذا ممكنًا ، ولكن هل من الممكن أن يكون لديك إخراج gunicorn تحذير إذا اكتشف أنك ما زلت تحاول تعيين وسيطات الخادم من خلال ملف Paster؟

اعتذاري عن الانقطاع ،Deimos. سأراجع العلاقات العامة ، لكن ليس لدي خطط محددة لإضافة المزيد هنا.

ماذا عن حالة تريد بالفعل استخدام - معجون مع --config؟ وهو في حالتنا (RhodeCode) مطلب كبير للمنطق الخاص لمراقبة الذاكرة الذي حصلنا عليه في التكوين gunicorn.

marcinkuzminski هذه هي حالة الاستخدام المثالية. فقط حدد كلاً من --paste و --config . ومع ذلك ، لن يقرأ Gunicorn قسم "الخادم" من ملف لصق ini لأن التوقع هو أنك ستقوم بتكوين الخادم في ملف تكوين gunicorn.

هذا مؤسف.

نقوم بشحن gunicorn إلى العملاء في برنامج التثبيت ، وتم تفويض كل المنطق والتكوين إلى ملفات .ini. هذه هي الطريقة التي تحدد بها معظم الأمثلة عبر الإنترنت لمشاريع الهرم.

هذا التغيير يكسر ذلك ، وربما يكون من الأسهل بالنسبة لنا تفرع gunicorn لإعادة ذلك ، ثم تغيير المنطق وتكوين التفويض إلى gunicorn_conf.py :(

ماذا لو قرأت خيارات اللصق ببادئة خاصة. على سبيل المثال ، يمكنك تكوين برنامج gunicorn باستخدام --paste ولكنه سيقرأ فقط خيارات التكوين التي ستبدأ بـ gunicorn.

على سبيل المثال

gunicorn.workers = 2
gunicor.XXX = YYY

لا تحتاج إلى استخدام --config . يمكنك استخدام معجون INI بالكامل. لذلك استخدم pserve بدلاً من gunicorn . راجع الوثائق: https://docs.gunicorn.org/en/stable/run.html#paste -deployment

كان التغيير الذي تم إجراؤه لإزالة الدعم لاستخدام Gunicorn باعتباره CLI Paste Deployment العام الذي يمكنه تشغيل الخوادم. Gunicorn لا يزال a_ لصق الخادم نفسه المتوافق.

تم إجراء هذا التغيير لإزالة الالتباس المحتمل حيث يحدد ملف .ini نادلة ، أو أي خادم آخر ، في كتلة server الخاصة به ، ولكن تشغيله باستخدام gunicorn --paste production.ini لن يتم استخدامه في الواقع نادلة على الإطلاق. كثيرًا ما يطلب الأشخاص أيضًا القدرة على تحديد مجموعة بديلة server بخلاف server:main . لا يبدو أن الحفاظ على دعم هذه الميزات عند وجود CLIs جيدة تمامًا مثل pserve لهذا الأمر غير منطقي.

يمكن لـ gunicorn CLI قراءة تعريف التطبيق من ملف INI ، لكنه يستخدم ملف التكوين الخاص به لتكوين الخادم. استخدم أداة أخرى (مثل pserve ) كبرنامج نصي / عداء للعملية إذا كنت تريد استخدام ملف INI لتكوين خادم Gunicorn.

ولكن علينا استخدام --config مع - لصق ، حسب تعليقي الأول.
في مشروعنا ، تتم إدارة كل شيء بواسطة ملف تكوين واحد (.ini) هناك الكثير من منطق الترقية / مقياس تلقائي الذي يضبط فقط ملف .ini. ثم نستخدم أيضًا --config لتحديد تهيئة Python المخصصة التي تعين

• تنسيق مسجل مخصص (لا يمكن تحديد هذا تقنيًا باستخدام ملف .ini)
• إدارة ذاكرة العامل (كود Python)

Gunicorn متوافق مع اللصق ، لكن الوظائف محدودة بهذه الطريقة ، وقد خلقت مشكلة بالنسبة لنا لا يمكننا التعافي منها لأنه لا يمكننا الحصول على ملفي تكوين ، كما أن الانتقال إلى التهيئة في ملف آخر يعد مزيدًا من العمل ثم في الواقع Gunicorn والحفاظ على تلك الشوكة فقط لإعادة هذا السلوك.

أعرف الأساس المنطقي لهذه التذكرة ، لكننا اعتدنا استخدام gunicorn والنادلة معًا ، وأعتقد أن تشغيل gunicorn binary واضح بما فيه الكفاية ، IMHO. بالإضافة إلى ذلك ، أعتقد أنه يمكنك حتى اكتشاف ما إذا كان المستخدمون يستخدمون بيضة مختلفة وتجعل ذلك خطأً صعبًا.

لم نفكر في مثل هذا الاستخدام إذا كنت أتذكر. ربما يمكننا العودة
دعمها لأن حالة الاستخدام تبدو جيدة. هل سيكون من الجيد أن يكون لديك ملف
تحذير تسجيل لذلك؟

يوم الجمعة 16 أكتوبر 2020 الساعة 08:28 Marcin Kuźmiński [email protected]
كتب:

لكن يتعين علينا استخدام --config مع - لصق ، وفقًا لما ورد في 1 st
تعليق.
في مشروعنا ، تتم إدارة كل شيء بواسطة ملف تكوين واحد (.ini)
هناك الكثير من منطق الترقية / مقياس تلقائي يقوم فقط بضبط ملف .ini.
ثم نستخدم أيضًا --config لتحديد تهيئة Python المخصصة التي تعين

• تنسيق مسجل مخصص (هذا من الناحية الفنية لا يمكن أن يكون
  محدد باستخدام ملف .ini)
• إدارة ذاكرة العامل

Gunicorn متوافق مع اللصق ، لكن الوظائف محدودة بهذه الطريقة ،
وتسبب لنا في مشكلة لا يمكننا التعافي منها.

أنا أعرف الأساس المنطقي ، لكننا اعتدنا استخدام البونيكورن والنادلة معًا ،
وأعتقد أن تشغيل برنامج gunicorn binary واضح بما فيه الكفاية ، IMHO.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/benoitc/gunicorn/issues/2169#issuecomment-709838842 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAADRIQR2CLVUOYK6FDY2ZDSK7RZFANCNFSM4JMI65YA
.

>

مرسلة من هاتفي المحمول

لقد فكرت بالفعل في حل آخر إذا كان ذلك ممكنًا. عند استخدام pserve مع unicorn egg ، سيكون من الجيد أيضًا تعيين ملف التكوين داخل ملف .ini.

على سبيل المثال

use = egg:gunicorn#main
workers = 2
config = /path/to/gunicorn_conf.py

لذلك سيتم تحميل gunicorn_conf.py تمامًا مثل --config = / path / to / gunicorn_conf.py يفعل

إذن ، ما سبق سيعمل معنا ، كما أنه يحل مشكلة هذه البطاقة. لست متأكدًا من مدى سهولة وإمكانية تنفيذ ذلك.

خلاف ذلك ، إذا كان بإمكانك إحضار وظيفة تحميل التكوين من ملف .ini عند تشغيل برنامج gunicorn binary ، فسيكون ذلك رائعًا ، وسيوفر لنا الكثير من المتاعب. وجود تحذير حول ذلك ليس مشكلة

لقد فكرت بالفعل في حل آخر إذا كان ذلك ممكنًا. عند استخدام pserve مع unicorn egg ، سيكون من الجيد أيضًا تعيين ملف التكوين داخل ملف .ini.

يجب أن يعمل وموثق. إذا لم يحدث ذلك ، يرجى تقديم خطأ!

حسنًا ، سوف نتحقق من هذا. لكن AFAIR كانت هناك تغييرات طفيفة في كيفية عمل ثنائيات gunicorn و pserve. إذا كنت أتذكر ، فإن gunicorn --paste كان له حق الوصول إلى مسار ملف .ini ، بينما لم يفعل pserve باستخدام gunicorn egg. سوف نتحقق من ذلك ونفتح تذكرة ذات صلة إذا لزم الأمر.