meinheld gunicorn flask docker
0.5.0
Dockerfile ذات الصلةpython3.9 ، latest (Dockerfile) لم تعد هذه العلامات مدعومة أو محافظة عليها ، تتم إزالتها من مستودع GitHub ، ولكن قد تظل الإصدارات الأخيرة التي تم دفعها متوفرة في Docker Hub إذا كان أي شخص يقوم بسحبها:
python3.9-alpine3.13python3.8python3.8-alpine3.11python3.7python3.7-alpine3.8python3.6python3.6-alpine3.8python2.7علامات التاريخ الأخيرة لهذه الإصدارات هي:
python3.9-alpine3.13-2024-03-11python3.8-2024-10-28python3.8-alpine3.11-2024-03-11python3.7-2024-10-28python3.7-alpine3.8-2024-03-11python3.6-2022-11-25python3.6-alpine3.8-2022-11-25python2.7-2022-11-25 ملاحظة : هناك علامات لكل تاريخ بناء. إذا كنت بحاجة إلى "تثبيت" إصدار صورة Docker الذي تستخدمه ، فيمكنك تحديد إحدى هذه العلامات. مثل tiangolo/meinheld-gunicorn-flask:python3.9-2024-11-02 .
صورة Docker مع Meinheld التي تديرها Gunicorn لتطبيقات الويب عالية الأداء في Flask باستخدام Python مع الأداء التلقائي.
github repo : https://github.com/tiangolo/meinheld-gunicorn-flask-docker
Docker Hub Image : https://hub.docker.com/r/tiangolo/meinheld-gunicorn-flask/
تطبيقات الويب Python Flask التي تعمل مع Meinheld التي تسيطر عليها Gunicorn لديها بعض من أفضل العروض التي يمكن تحقيقها بواسطة Flask (*).
إذا كان لديك تطبيق موجود بالفعل في Flask أو تقوم ببناء تطبيق جديد ، فستمنحك هذه الصورة أفضل أداء ممكن (أو بالقرب من ذلك).
تحتوي هذه الصورة على آلية "الضبط التلقائي" ، بحيث يمكنك فقط إضافة الرمز والحصول على أداء جيد تلقائيًا. ودون تقديم تضحيات (مثل قطع الأشجار).
الإصدار الأخير الحالي من MeinHeld الذي تم إصداره هو 1.0.2 ، من 17 مايو 2020. يتطلب هذا الإصدار من Meinheld إصدارًا قديمًا من Greenlet ( >=0.4.5,<0.5 ) غير متوافق مع Python 3.10 و 3.11. لهذا السبب فإن أحدث إصدار من Python المدعوم في هذه الصورة هو Python 3.9.
إذا كنت تبدأ مشروعًا جديدًا ، فقد تستفيد من إطار عمل أحدث وأسرع مثل Fastapi (استنادًا إلى ASGI بدلاً من WSGI مثل Flask و Django) ، وصورة Docker مثل Tiangolo/Uvicorn-gunicorn-fastapi .
سوف يمنحك حوالي 200 ٪ الأداء القابل للتحقيق مع Flask ، حتى عند استخدام هذه الصورة.
أيضًا ، إذا كنت ترغب في استخدام تقنيات جديدة مثل WebSockets ، فسيكون ذلك أسهل من خلال إطار عمل أحدث يعتمد على ASGI ، مثل Fastapi . نظرًا لأن ASGI القياسي تم تصميمه ليكون قادرًا على التعامل مع التعليمات البرمجية غير المتزامنة مثل الرمز المطلوب لـ WebSockets.
MeinHeld هو خادم ويب يتوافق مع WSGI عالي الأداء.
يمكنك استخدام Gunicorn لإدارة meinheld وتشغيل عمليات متعددة منه.
Flask عبارة عن عمل microframework لـ Python يعتمد على Werkzeug و Jinja 2 والنوايا الحسنة.
تم إنشاء هذه الصورة لتكون بديلاً لـ Tiangolo/UWSGI-NGINX-FLASK ، مما يوفر حوالي 400 ٪ من أداء تلك الصورة.
يعتمد على الصورة الأكثر عامة Tiangolo/Meinheld-Gunicorn . هذا هو الشخص الذي ستستخدمه في أطر WSGI الأخرى ، مثل Django.
ربما تستخدم kubernetes أو أدوات مماثلة. في هذه الحالة ، ربما لا تحتاج إلى هذه الصورة (أو أي صورة أساسية مماثلة أخرى). ربما تكون أفضل حالًا في بناء صورة Docker من الصفر .
إذا كان لديك مجموعة من الآلات التي تحتوي على Kubernetes أو وضع سرب Docker أو Nomad أو أي نظام معقد مشابه آخر لإدارة الحاويات الموزعة على أجهزة متعددة ، فربما ترغب في التعامل مع النسخ المتماثل على مستوى الكتلة بدلاً من استخدام مدير العملية في كل حاوية تبدأ عمليات العامل المتعددة ، وهو ما تفعله صورة Docker هذه.
في هذه الحالات (على سبيل المثال ، باستخدام kubernetes) ، ربما ترغب في إنشاء صورة Docker من نقطة الصفر ، وتثبيت تبعياتك ، وتشغيل عملية واحدة بدلاً من هذه الصورة.
على سبيل المثال ، باستخدام Gunicorn ، يمكن أن يكون لديك app/gunicorn_conf.py مع:
# Gunicorn config variables
loglevel = "info"
errorlog = "-" # stderr
accesslog = "-" # stdout
worker_tmp_dir = "/dev/shm"
graceful_timeout = 120
timeout = 120
keepalive = 5
threads = 3 وبعد ذلك يمكن أن يكون لديك Dockerfile مع:
FROM python:3.9
WORKDIR /code
COPY ./requirements.txt /code/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt
COPY ./app /code/app
CMD [ "gunicorn" , "--conf" , "app/gunicorn_conf.py" , "--bind" , "0.0.0.0:80" , "app.main:app" ]يمكنك قراءة المزيد حول هذه الأفكار في وثائق Fastapi حول: Fastapi في الحاويات - Docker كما تنطبق نفس الأفكار على تطبيقات الويب الأخرى في الحاويات.
قد ترغب في تشغيل مدير عملية يقوم بتشغيل عمليات عمل متعددة في الحاوية إذا كان تطبيقك بسيطًا بما يكفي لدرجة أنك لا تحتاج (على الأقل ليس بعد) لضبط عدد العمليات أكثر من اللازم ، ويمكنك فقط استخدام الافتراضي الآلي ، وأنت تقوم بتشغيله على خادم واحد ، وليس مجموعة.
يمكن أن تنشر على خادم واحد (وليس مجموعة) مع Docker Compose ، لذلك لن يكون لديك طريقة سهلة لإدارة تكرار الحاويات (مع تأليف Docker) مع الحفاظ على الشبكة المشتركة وموازنة التحميل .
بعد ذلك ، قد ترغب في الحصول على حاوية واحدة مع مدير عملية يبدأ العديد من عمليات العمال في الداخل ، كما تفعل صورة Docker هذه.
قد يكون لديك أيضًا أسباب أخرى من شأنها أن تجعل من السهل الحصول على حاوية واحدة مع عمليات متعددة بدلاً من وجود حاويات متعددة مع عملية واحدة في كل منها.
على سبيل المثال (اعتمادًا على الإعداد الخاص بك) ، يمكن أن يكون لديك أداة مثل مصدر Prometheus في نفس الحاوية التي يجب أن تتمكن من الوصول إلى كل من الطلبات التي تأتي.
في هذه الحالة ، إذا كان لديك حاويات متعددة ، بشكل افتراضي ، عندما جاء بروميثيوس لقراءة المقاييس ، فإنه سيحصل على الحاوية الواحدة في كل مرة (للحاوية التي تعاملت مع هذا الطلب المعين) ، بدلاً من الحصول على المقاييس المتراكمة لجميع الحاويات المتكررة.
بعد ذلك ، في هذه الحالة ، قد يكون من الأسهل أن يكون لديك حاوية واحدة مع عمليات متعددة ، وأداة محلية (مثل مصدر بروميثيوس) على نفس الحاوية التي تجمع مقاييس بروميثيوس لجميع العمليات الداخلية وفضح تلك المقاييس على تلك الحاوية الفردية.
اقرأ المزيد عن ذلك كله في وثائق Fastapi حول: Fastapi في الحاويات - Docker ، حيث تنطبق نفس المفاهيم على تطبيقات الويب الأخرى في الحاويات.
ليس عليك استنساخ هذا الريبو.
يمكنك استخدام هذه الصورة كصورة أساسية للصور الأخرى.
على افتراض أن لديك requirements.txt ملف. txt ، يمكن أن يكون لديك Dockerfile مثل هذا:
FROM tiangolo/meinheld-gunicorn-flask:python3.9
COPY ./requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /app سوف تتوقع ملفًا على /app/app/main.py main.py.
أو بطريقة أخرى ملف في /app/main.py .
ويتوقع أن يحتوي على app متغير مع تطبيق "WSGI" الخاص بك.
ثم يمكنك بناء صورتك من الدليل الذي يحتوي على Dockerfile ، على سبيل المثال:
docker build -t myimage ./هذه هي متغيرات البيئة التي يمكنك تعيينها في الحاوية لتكوينها وقيمها الافتراضية:
MODULE_NAMEبيثون "الوحدة النمطية" (ملف) ليتم استيرادها بواسطة Gunicorn ، سوف تحتوي هذه الوحدة على تطبيق القارورة الفعلي في متغير.
افتراضيا:
app.main إذا كان هناك ملف /app/app/main.py main.py أوmain إذا كان هناك ملف /app/main.py على سبيل المثال ، إذا كان ملفك الرئيسي على /app/custom_app/custom_main.py custom_app/custom_main.py ، فيمكنك تعيينه مثل:
docker run -d -p 80:80 -e MODULE_NAME= " custom_app.custom_main " myimageVARIABLE_NAMEالمتغير داخل وحدة بيثون التي تحتوي على تطبيق القارورة.
افتراضيا:
appعلى سبيل المثال ، إذا كان ملف Python الرئيسي الخاص بك يحتوي على شيء مثل:
from flask import Flask
api = Flask ( __name__ )
@ api . route ( "/" )
def hello ():
return "Hello World from Flask" في هذه الحالة ، ستكون api هي المتغير مع "تطبيق Flask". يمكنك ضبطه مثل:
docker run -d -p 80:80 -e VARIABLE_NAME= " api " myimageAPP_MODULEتم نقل السلسلة مع وحدة Python والاسم المتغير إلى Gunicorn.
بشكل افتراضي ، قم بتعيين استنادًا إلى المتغيرات MODULE_NAME و VARIABLE_NAME :
app.main:app أوmain:appيمكنك ضبطه مثل:
docker run -d -p 80:80 -e APP_MODULE= " custom_app.custom_main:api " myimageGUNICORN_CONFالمسار إلى ملف تكوين Python Gunicorn.
افتراضيا:
/app/gunicorn_conf.py إذا كان موجودًا/app/app/gunicorn_conf.py إذا كان موجودًا/gunicorn_conf.py (الافتراضي المتضمن)يمكنك ضبطه مثل:
docker run -d -p 80:80 -e GUNICORN_CONF= " /app/custom_gunicorn_conf.py " myimageWORKERS_PER_COREستتحقق هذه الصورة من عدد نوى وحدة المعالجة المركزية المتوفرة في الخادم الحالي الذي يعمل على تشغيل الحاوية.
سيؤدي ذلك إلى تعيين عدد العمال على عدد نوى وحدة المعالجة المركزية مضروبة في هذه القيمة.
افتراضيا:
2يمكنك ضبطه مثل:
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 3 " myimage إذا استخدمت القيمة 3 في خادم مع 2 نوى وحدة المعالجة المركزية ، فسيقوم بتشغيل 6 عمليات عامل.
يمكنك استخدام قيم النقطة العائمة أيضًا.
لذلك ، على سبيل المثال ، إذا كان لديك خادم كبير (دعنا نقول ، مع 8 نوى وحدة المعالجة المركزية) تشغيل العديد من التطبيقات ، ولديك تطبيق ASGI الذي تعرفه لن يحتاج إلى أداء عالي. وأنت لا تريد أن تضيع موارد الخادم. هل يمكن أن تجعلها تستخدم 0.5 عامل لكل وحدة المعالجة المركزية. على سبيل المثال:
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 0.5 " myimageفي خادم مع 8 نوى وحدة المعالجة المركزية ، فإن هذا سيجعله يبدأ فقط 4 عمليات عامل.
WEB_CONCURRENCYتجاوز التعريف التلقائي لعدد العمال.
افتراضيا:
WORKERS_PER_CORE . لذلك ، في خادم مع 2 النوى ، سيتم تعيينه افتراضيًا على 4 .يمكنك ضبطه مثل:
docker run -d -p 80:80 -e WEB_CONCURRENCY= " 2 " myimageهذا من شأنه أن يجعل الصورة تبدأ من عمليتين للعاملين ، بغض النظر عن عدد مراكز وحدة المعالجة المركزية المتوفرة في الخادم.
HOST"المضيف" الذي يستخدمه Gunicorn ، IP حيث سيستمع Gunicorn للطلبات.
إنه المضيف داخل الحاوية.
لذلك ، على سبيل المثال ، إذا قمت بتعيين هذا المتغير على 127.0.0.1 ، فسيكون متاحًا فقط داخل الحاوية ، وليس في المضيف الذي يديره.
يتم توفيره للاكتمال ، لكن ربما لا ينبغي عليك تغييره.
افتراضيا:
0.0.0.0PORTالمنفذ يجب أن يستمع الحاوية.
إذا كنت تقوم بتشغيل الحاوية في بيئة تقييدية تجبرك على استخدام بعض المنافذ المحددة (مثل 8080 ) ، فيمكنك تعيينها مع هذا المتغير.
افتراضيا:
80يمكنك ضبطه مثل:
docker run -d -p 80:8080 -e PORT= " 8080 " myimageBINDانتقل المضيف الفعلي والميناء إلى Gunicorn.
بشكل افتراضي ، تعيين بناءً على HOST المتغيرات PORT .
لذا ، إذا لم تقم بتغيير أي شيء ، فسيتم تعيينه افتراضيًا على:
0.0.0.0:80يمكنك ضبطه مثل:
docker run -d -p 80:8080 -e BIND= " 0.0.0.0:8080 " myimageLOG_LEVELمستوى السجل لـ Gunicorn.
واحد من:
debuginfowarningerrorcritical افتراضيا ، اضبط على info .
إذا كنت بحاجة إلى الضغط على مزيد من الأداء للتضحية بتسجيل الدخول ، فقم بتعيينه على warning ، على سبيل المثال:
يمكنك ضبطه مثل:
docker run -d -p 80:8080 -e LOG_LEVEL= " warning " myimage يتم إرسال السجلات إلى stderr و stdout للحاوية ، مما يعني أنه يمكنك عرض السجلات مع أمر docker logs -f your_container_name_here .
تتضمن الصورة ملف تكوين Gunicorn Python الافتراضي على /gunicorn_conf.py .
يستخدم متغيرات البيئة المعلنة أعلاه لتعيين جميع التكوينات.
يمكنك تجاوزه بتضمين ملف في:
/app/gunicorn_conf.py/app/app/gunicorn_conf.py/gunicorn_conf.py/app/prestart.sh إذا كنت بحاجة إلى تشغيل أي شيء قبل بدء التطبيق ، فيمكنك إضافة ملف prestart.sh إلى الدليل /app . ستكتشف الصورة وتشغيلها تلقائيًا قبل بدء كل شيء.
على سبيل المثال ، إذا كنت ترغب في إضافة Alembic SQL Migrations (مع SqlalChemy) ، فيمكنك إنشاء ملف ./app/prestart.sh في دليل الكود الخاص بك (الذي سيتم نسخه بواسطة Dockerfile ) مع:
#! /usr/bin/env bash
# Let the DB start
sleep 10 ;
# Run migrations
alembic upgrade head وسوف ينتظر 10 ثوانٍ لإعطاء قاعدة البيانات بعض الوقت للبدء ثم تشغيل هذا الأمر alembic .
إذا كنت بحاجة إلى تشغيل برنامج نصي Python قبل بدء التطبيق ، فيمكنك إنشاء ملف /app/prestart.sh تشغيل البرنامج النصي Python الخاص بك ، مع شيء مثل:
#! /usr/bin/env bash
# Run custom Python script before starting
python /app/my_custom_prestart_script.py باختصار: ربما لا ينبغي عليك استخدام جبال الألب لمشاريع بيثون ، بدلاً من ذلك ، استخدم إصدارات صورة Docker slim .
هل تريد المزيد من التفاصيل؟ متابعة القراءة؟
يعد Alpine أكثر فائدة للغات الأخرى حيث تقوم ببناء ثنائي ثابت في مرحلة صورة Docker واحدة (باستخدام بناء Docker متعدد المراحل) ثم نسخه إلى صورة جبال الألب البسيطة ، ثم تنفيذ ذلك الثنائي فقط. على سبيل المثال ، باستخدام GO.
ولكن بالنسبة إلى Python ، نظرًا لأن جبال الألب لا تستخدم الأدوات القياسية المستخدمة لبناء امتدادات Python ، عند تثبيت الحزم ، في كثير من الحالات ، لن يجد Python ( pip ) حزمة تثبيت قابلة للتثبيت مسبقًا ("عجلة") للبن. وبعد تصحيح الكثير من الأخطاء الغريبة ، ستدرك أنه يتعين عليك تثبيت الكثير من الأدوات الإضافية وبناء الكثير من التبعيات فقط لاستخدام بعض حزم Python الشائعة هذه. ؟
هذا يعني أنه على الرغم من أن صورة جبال الألب الأصلية قد تكون صغيرة ، إلا أنك تنتهي بصورة بحجم مماثل للحجم الذي كنت قد حصلت عليه إذا كنت قد استخدمت للتو صورة بيثون قياسية (استنادًا إلى Debian) ، أو في بعض الحالات أكبر. ؟
وفي جميع هذه الحالات ، سوف يستغرق الأمر وقتًا أطول بكثير للبناء ، واستهلاك المزيد من الموارد ، وبناء تبعيات لفترة أطول ، وكذلك زيادة بصمة الكربون ، حيث تستخدم المزيد من وقت وحدة المعالجة المركزية والطاقة لكل بناء. ؟
إذا كنت تريد صور Python النحيفة ، فيجب عليك بدلاً من ذلك محاولة استخدام الإصدارات slim التي لا تزال تعتمد على Debian ، ولكنها أصغر. ؟
يتم اختبار جميع علامات الصور والتكوينات ومتغيرات البيئة وخيارات التطبيق.
issue-manager.yml . PR #154 بواسطة Tiangolo.latest-changes github. PR #153 بواسطة Tiangolo.latest-changes.yml . PR #141 بواسطة ealjsdev.README.md . PR #137 بواسطة ealjsdev. أبرز هذا الإصدار:
دعم Python 3.9 و 3.8.
إهمال بيثون 3.6 و 2.7.
python3.6-2022-11-25 و python2.7-2022-11-25 .إصدارات ترقية من جميع التبعيات.
تحسينات صغيرة وإصلاحات.
أضف دعمًا لـ Python 3.9 و Python 3.9 Alpine. PR #50 بواسطة Tiangolo.
أضف Python 3.8 مع جبال الألب 3.11. PR #28.
أضف دعمًا لـ Python 3.8. PR #27.
tiangolo/meinheld-gunicorn-flask:python3.7-2019-10-15 . PR #17.أضف دعمًا لـ Python 2.7 (يجب عليك استخدام Python 3.7 أو Python 3.6). PR #11.
تحديث تكوين Travis CI. PR #10 بواسطة cclauss.
/app/prestart.sh . هذا المشروع مرخص بموجب شروط ترخيص معهد ماساتشوستس للتكنولوجيا.
