uvicorn gunicorn fastapi docker
0.8.0
تم إهمال صورة Docker هذه الآن. ليست هناك حاجة لاستخدامه ، يمكنك فقط استخدام UVICORN مع --workers .
اقرأ المزيد عنها أدناه.
Dockerfile ذات الصلةpython3.11 ، latest (Dockerfile)python3.10 ، (Dockerfile)python3.9 ، (Dockerfile)python3.11-slim (Dockerfile)python3.10-slim (Dockerfile)python3.9-slim (Dockerfile) لم تعد هذه العلامات مدعومة أو محافظة عليها ، تتم إزالتها من مستودع GitHub ، ولكن قد تظل الإصدارات الأخيرة التي تم دفعها متوفرة في Docker Hub إذا كان أي شخص يقوم بسحبها:
python3.8python3.8-slimpython3.7python3.9-alpine3.14python3.8-alpine3.10python3.7-alpine3.8python3.6python3.6-alpine3.8علامات التاريخ الأخيرة لهذه الإصدارات هي:
python3.8-2024-11-02python3.8-slim-2024-11-02python3.7-2024-11-02python3.9-alpine3.14-2024-03-11python3.8-alpine3.10-2024-01-29python3.7-alpine3.8-2024-03-11python3.6-2022-11-25python3.6-alpine3.8-2022-11-25 ملاحظة : هناك علامات لكل تاريخ بناء. إذا كنت بحاجة إلى "تثبيت" إصدار صورة Docker الذي تستخدمه ، فيمكنك تحديد إحدى هذه العلامات. مثل tiangolo/uvicorn-gunicorn-fastapi:python3.11-2024-11-02 .
صورة Docker مع Uvicorn التي تديرها Gunicorn لتطبيقات Fastapi عالية الأداء في Python مع الأداء التلقائي.
Github repo : https://github.com/tiangolo/uvicorn-gunicorn-fastapi-docker
Docker Hub Image : https://hub.docker.com/r/tiangolo/uvicorn-gunicorn-fastapi/
لقد أظهر Fastapi إطارًا على شبكة الإنترنت Python مع أحد أفضل العروض ، كما تم قياسه من خلال معايير الطرف الثالث ، وذلك بفضل أن تكون مبنية على Starlette وتشغيلها.
الأداء القابل للتحقيق على قدم المساواة مع (وفي كثير من الحالات متفوقة على) GO و NODE.JS.
تحتوي هذه الصورة على آلية ضبط تلقائي متضمنة لبدء عدد من عمليات العمال بناءً على نوى وحدة المعالجة المركزية المتاحة. وبهذه الطريقة ، يمكنك فقط إضافة الكود الخاص بك والحصول على الأداء العالي تلقائيًا ، وهو أمر مفيد في عمليات النشر البسيطة .
ربما تستخدم kubernetes أو أدوات مماثلة. في هذه الحالة ، ربما لا تحتاج إلى هذه الصورة (أو أي صورة أساسية مماثلة أخرى). من المحتمل أن تكون أفضل حالًا في بناء صورة Docker من نقطة الصفر كما هو موضح في مستندات Fastapi في الحاويات - Docker: إنشاء صورة Docker لـ Fastapi.
إذا كان لديك مجموعة من الآلات التي تحتوي على Kubernetes أو وضع Swarm Docker أو Nomad أو أي نظام معقد مشابه آخر لإدارة الحاويات الموزعة على آلات متعددة ، فربما ترغب في التعامل مع النسخ المتماثل على مستوى الكتلة بدلاً من استخدام مدير العملية (مثل Gunicorn مع عمال Uvicorn) في كل حاوية ، وهذا ما تفعله صورة Docker هذه.
في هذه الحالات (على سبيل المثال ، باستخدام kubernetes) ، ربما ترغب في إنشاء صورة Docker من نقطة الصفر ، وتثبيت تبعياتك ، وتشغيل عملية uvicorn واحدة بدلاً من هذه الصورة.
على سبيل المثال ، يمكن أن يبدو 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 [ "uvicorn" , "app.main:app" , "--host" , "0.0.0.0" , "--port" , "80" ]يمكنك قراءة المزيد حول هذا الموضوع في وثائق Fastapi حول: Fastapi في الحاويات - Docker.
إذا كنت ترغب بالتأكيد في الحصول على العديد من العمال على حاوية واحدة ، فإن Uvicorn تدعم الآن التعامل مع العمليات الفرعية ، بما في ذلك إعادة تشغيل الموتى. لذلك ليست هناك حاجة إلى Gunicorn لإدارة العديد من العمال في حاوية واحدة.
يمكنك تعديل مثال Dockerfile من الأعلى ، وإضافة خيار --workers إلى Uvicorn ، مثل:
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 [ "uvicorn" , "app.main:app" , "--host" , "0.0.0.0" , "--port" , "80" , "--workers" , "4" ]هذا كل ما تحتاجه. أنت لا تحتاج إلى صورة Docker على الإطلاق. ؟
يمكنك قراءة المزيد حول هذا الموضوع في مستندات Fastapi حول النشر مع Docker.
لم يكن لدى Uvicorn دعم لإدارة معالجة العمال بما في ذلك إعادة تشغيل العمال القتلى. ولكن الآن يفعل.
قبل ذلك ، يمكن استخدام Gunicorn كمدير للعمليات ، يدير عمال Uvicorn. هذا التعقيد المضافة لم يعد ضروريًا.
يتم الاحتفاظ بباقي هذه الوثيقة لأسباب تاريخية ، لكن ربما لا تحتاج إليها. ؟
tiangolo/uvicorn-gunicorn-fastapiستقوم هذه الصورة بتعيين تكوين معقول استنادًا إلى الخادم الذي يعمل عليه (كمية نوى وحدة المعالجة المركزية المتاحة) دون تقديم تضحيات.
إنه يحتوي على افتراضات معقولة ، ولكن يمكنك تكوينه مع متغيرات البيئة أو تجاوز ملفات التكوين.
هناك أيضا إصدارات ضئيلة. إذا كنت تريد واحدة من هؤلاء ، استخدم إحدى العلامات من الأعلى.
tiangolo/uvicorn-gunicorn تستند هذه الصورة ( tiangolo/uvicorn-gunicorn-fastapi ) إلى Tiangolo/Uvicorn-Gunicorn .
تلك الصورة هي ما يفعله كل العمل.
تقوم هذه الصورة فقط بتثبيت Fastapi ولديها الوثائق التي تستهدف على وجه التحديد Fastapi.
إذا كنت تشعر بالثقة بشأن معرفتك بـ Uvicorn و Gunicorn و Asgi ، فيمكنك استخدام هذه الصورة مباشرة.
tiangolo/uvicorn-gunicorn-starletteهناك صورة Docker الأخوة: Tiangolo/Uvicorn-Gunicorn-Starlette
إذا كنت تقوم بإنشاء تطبيق ويب Starlette جديد وتريد تجاهل جميع الميزات الإضافية من Fastapi ، فيجب عليك استخدام Tiangolo/Uvicorn-Gunicorn-Starlette بدلاً من ذلك.
ملاحظة : يعتمد Fastapi على Starlette ويضيف عدة ميزات فوقها. مفيد لواجهة برمجة التطبيقات والحالات الأخرى: التحقق من صحة البيانات ، تحويل البيانات ، الوثائق مع OpenAPI ، حقن التبعية ، الأمان/المصادقة وغيرها.
لا تحتاج إلى استنساخ جيثب ريبو.
يمكنك استخدام هذه الصورة كصورة أساسية للصور الأخرى.
على افتراض أن لديك requirements.txt ملف. txt ، يمكن أن يكون لديك Dockerfile مثل هذا:
FROM tiangolo/uvicorn-gunicorn-fastapi:python3.11
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 متغير مع تطبيق Fastapi الخاص بك.
ثم يمكنك بناء صورتك من الدليل الذي يحتوي على Dockerfile ، على سبيل المثال:
docker build -t myimage ./Dockerfile مع: FROM tiangolo/uvicorn-gunicorn-fastapi:python3.11
COPY ./requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /appapp وأدخله.main.py مع: from fastapi import FastAPI
app = FastAPI ()
@ app . get ( "/" )
def read_root ():
return { "Hello" : "World" }
@ app . get ( "/items/{item_id}" )
def read_item ( item_id : int , q : str = None ):
return { "item_id" : item_id , "q" : q } .
├── app
│ └── main.py
└── Dockerfile
Dockerfile الخاص بك ، يحتوي على دليل app الخاص بك).docker build -t myimage .docker run -d --name mycontainer -p 80:80 myimageالآن لديك خادم Fastapi محسّن في حاوية Docker. تم ضبطه تلقائيًا لخادمك الحالي (وعدد نوى وحدة المعالجة المركزية).
يجب أن تكون قادرًا على التحقق من ذلك في عنوان URL لحاوية Docker الخاصة بك ، على سبيل المثال: http://192.168.99.100/items/5؟q=somequery أو http://127.0.0.1/items/5؟q=somequery (أو معادل ، باستخدام مضيف Docker الخاص بك).
سترى شيئًا مثل:
{ "item_id" : 5 , "q" : " somequery " }يمكنك الآن الانتقال إلى http://192.168.99.100/docs أو http://127.0.0.1/docs (أو ما يعادلها ، باستخدام مضيف Docker).
سترى وثائق API التفاعلية التلقائية (المقدمة من Swagger UI):
ويمكنك أيضًا الانتقال إلى http://192.168.99.100/redoc أو http://127.0.0.1/redoc ind.or ، باستخدام مضيف Docker الخاص بك).
سترى الوثائق التلقائية البديلة (المقدمة من REDOC):
من المحتمل أيضًا أن ترغب أيضًا في إضافة أي تبعيات لتطبيقك وتثبيتها لإصدار معين ، على الأرجح بما في ذلك Uvicorn و Gunicorn و Fastapi.
بهذه الطريقة يمكنك التأكد من أن تطبيقك يعمل دائمًا كما هو متوقع.
يمكنك تثبيت الحزم باستخدام أوامر pip في Dockerfile ، أو باستخدام requirements.txt ، أو حتى استخدام الشعر.
وبعد ذلك ، يمكنك ترقية تلك التبعيات بطريقة خاضعة للرقابة ، وتشغيل الاختبارات الخاصة بك ، والتأكد من أن كل شيء يعمل ، ولكن دون كسر تطبيق الإنتاج الخاص بك إذا كان هناك إصدار جديد غير متوافق.
إليك مثال صغير على أحد الطرق التي يمكنك من خلالها تثبيت تبعياتك مع التأكد من أن لديك إصدارًا مثبتًا لكل حزمة.
لنفترض أن لديك مشروعًا يديره الشعر ، لذلك ، لديك تبعيات الحزمة الخاصة بك في ملف pyproject.toml . وربما ملف poetry.lock .
ثم يمكن أن يكون لديك Dockerfile باستخدام مبنى Docker متعدد المراحل مع:
FROM python:3.9 as requirements-stage
WORKDIR /tmp
RUN pip install poetry
COPY ./pyproject.toml ./poetry.lock* /tmp/
RUN poetry export -f requirements.txt --output requirements.txt --without-hashes
FROM tiangolo/uvicorn-gunicorn-fastapi:python3.11
COPY --from=requirements-stage /tmp/requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /appسوف:
* لأنه يستخدم ./poetry.lock*من المهم نسخ رمز التطبيق بعد تثبيت التبعيات ، وبهذه الطريقة يمكنك الاستفادة من ذاكرة التخزين المؤقت لـ Docker. وبهذه الطريقة ، لن تضطر إلى تثبيت كل شيء من نقطة الصفر في كل مرة تقوم فيها بتحديث ملفات التطبيق الخاصة بك ، فقط عند إضافة تبعيات جديدة.
ينطبق هذا أيضًا على أي طريقة أخرى تستخدمها لتثبيت تبعياتك. إذا كنت تستخدم requirements.txt ، انسخها بمفردها وقم بتثبيت جميع التبعيات في الجزء العلوي من Dockerfile ، وأضف رمز التطبيق الخاص بك بعد ذلك.
هذه هي متغيرات البيئة التي يمكنك تعيينها في الحاوية لتكوينها وقيمها الافتراضية:
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المتغير داخل وحدة Python التي تحتوي على تطبيق fastapi.
افتراضيا:
appعلى سبيل المثال ، إذا كان ملف Python الرئيسي الخاص بك يحتوي على شيء مثل:
from fastapi import FastAPI
api = FastAPI ()
@ api . get ( "/" )
def read_root ():
return { "Hello" : "World" } في هذه الحالة ، سيكون api هو المتغير مع تطبيق Fastapi. يمكنك ضبطه مثل:
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 " myimageيمكنك استخدام ملف التكوين من الصورة الأساسية كنقطة انطلاق لك.
WORKERS_PER_COREستتحقق هذه الصورة من عدد نوى وحدة المعالجة المركزية المتوفرة في الخادم الحالي الذي يعمل على تشغيل الحاوية.
سيؤدي ذلك إلى تعيين عدد العمال على عدد نوى وحدة المعالجة المركزية مضروبة في هذه القيمة.
افتراضيا:
1يمكنك ضبطه مثل:
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 3 " myimage إذا استخدمت القيمة 3 في خادم مع 2 نوى وحدة المعالجة المركزية ، فسيقوم بتشغيل 6 عمليات عامل.
يمكنك استخدام قيم النقطة العائمة أيضًا.
لذلك ، على سبيل المثال ، إذا كان لديك خادم كبير (دعنا نقول ، مع 8 نوى وحدة المعالجة المركزية) تشغيل العديد من التطبيقات ، ولديك تطبيق fastapi الذي تعرفه لن يحتاج إلى أداء عالي. وأنت لا تريد أن تضيع موارد الخادم. هل يمكن أن تجعلها تستخدم 0.5 عامل لكل وحدة المعالجة المركزية. على سبيل المثال:
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 0.5 " myimageفي خادم مع 8 نوى وحدة المعالجة المركزية ، فإن هذا سيجعله يبدأ فقط 4 عمليات عامل.
ملاحظة : بشكل افتراضي ، إذا كان WORKERS_PER_CORE هو 1 والخادم يحتوي على جوهر وحدة المعالجة المركزية واحدة فقط ، بدلاً من بدء عمل واحد واحد ، فسيبدأ 2. هذا لتجنب الأداء السيئ وحظر تطبيقات (تطبيق الخادم) على الآلات الصغيرة (جهاز الخادم/السحابة/الخ). يمكن تجاوز هذا باستخدام WEB_CONCURRENCY .
MAX_WORKERSاضبط الحد الأقصى لعدد العمال للاستخدام.
يمكنك استخدامه للسماح للصورة بحساب عدد العمال تلقائيًا ولكن التأكد من أنه يقتصر على الحد الأقصى.
يمكن أن يكون هذا مفيدًا ، على سبيل المثال ، إذا كان كل عامل يستخدم اتصال قاعدة البيانات وكانت قاعدة البيانات الخاصة بك تحتوي على حد أقصى للاتصالات المفتوحة.
بشكل افتراضي ، لم يتم تعيينه ، وهذا يعني أنه غير محدود.
يمكنك ضبطه مثل:
docker run -d -p 80:80 -e MAX_WORKERS= " 24 " myimageهذا من شأنه أن يجعل الصورة تبدأ على الأقل 24 عامل ، بغض النظر عن عدد نوى وحدة المعالجة المركزية المتوفرة في الخادم.
WEB_CONCURRENCYتجاوز التعريف التلقائي لعدد العمال.
افتراضيا:
WORKERS_PER_CORE . لذلك ، في خادم يحتوي على نوى ، سيتم تعيينه افتراضيًا على 2 .يمكنك ضبطه مثل:
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 " myimageWORKER_CLASSالفصل لاستخدامه من قبل Gunicorn للعمال.
افتراضيًا ، تم تعيينه على uvicorn.workers.UvicornWorker .
حقيقة أنه يستخدم Uvicorn هو ما يسمح باستخدام أطر ASGI مثل Fastapi ، وهذا هو أيضًا ما يوفر الحد الأقصى للأداء.
ربما لا ينبغي عليك تغييره.
ولكن إذا كنت بحاجة لسبب ما إلى استخدام عامل Uvicorn البديل: uvicorn.workers.UvicornH11Worker ، يمكنك ضبطه مع متغير البيئة هذا.
يمكنك ضبطه مثل:
docker run -d -p 80:8080 -e WORKER_CLASS= " uvicorn.workers.UvicornH11Worker " myimageTIMEOUTيقتل العمال صامتين لأكثر من هذه الثواني العديدة وإعادة تشغيله.
اقرأ المزيد عن ذلك في مستندات Gunicorn: Timeout.
بشكل افتراضي ، ضبط على 120 .
لاحظ أن أطر Uvicorn و ASGI مثل Fastapi غير متزامنة ، وليس المزامنة. لذلك ربما يكون من الآمن أن يكون لديك مهلة أعلى من العمال المزامنة.
يمكنك ضبطه مثل:
docker run -d -p 80:8080 -e TIMEOUT= " 20 " myimageKEEP_ALIVEعدد الثواني لانتظار الطلبات على اتصال محافظ.
اقرأ المزيد عن ذلك في مستندات Gunicorn: Keepalive.
افتراضيا ، تعيين على 2 .
يمكنك ضبطه مثل:
docker run -d -p 80:8080 -e KEEP_ALIVE= " 20 " myimageGRACEFUL_TIMEOUTمهلة إعادة تشغيل العمال الرشيقة.
اقرأ المزيد حول هذا الموضوع في مستندات Gunicorn: Timeout رشيقة.
بشكل افتراضي ، ضبط على 120 .
يمكنك ضبطه مثل:
docker run -d -p 80:8080 -e GRACEFUL_TIMEOUT= " 20 " myimageACCESS_LOGملف سجل الوصول للكتابة إليه.
بشكل افتراضي "-" ، وهو ما يعني stdout (طباعة في سجلات Docker).
إذا كنت ترغب في تعطيل ACCESS_LOG ، فقم بتعيينه على قيمة فارغة.
على سبيل المثال ، يمكنك تعطيله بـ:
docker run -d -p 80:8080 -e ACCESS_LOG= myimageERROR_LOGملف سجل الخطأ للكتابة إلى.
بشكل افتراضي "-" ، وهو ما يعني STDERR (طباعة في سجلات Docker).
إذا كنت ترغب في تعطيل ERROR_LOG ، فقم بتعيينه على قيمة فارغة.
على سبيل المثال ، يمكنك تعطيله بـ:
docker run -d -p 80:8080 -e ERROR_LOG= myimageGUNICORN_CMD_ARGS يمكن تمرير أي إعدادات سطر أوامر إضافية لـ Gunicorn في متغير بيئة GUNICORN_CMD_ARGS .
اقرأ المزيد عن ذلك في مستندات Gunicorn: الإعدادات.
سيكون لهذه الإعدادات الأسبقية على متغيرات البيئة الأخرى وأي ملف تكوين Gunicorn.
على سبيل المثال ، إذا كان لديك شهادة TLS/SSL مخصصة تريد استخدامها ، فيمكنك نسخها إلى صورة Docker أو تثبيتها في الحاوية ، وتعيين --keyfile و --certfile إلى موقع الملفات ، على سبيل المثال:
docker run -d -p 80:8080 -e GUNICORN_CMD_ARGS= " --keyfile=/secrets/key.pem --certfile=/secrets/cert.pem " -e PORT=443 myimageملاحظة : بدلاً من التعامل مع TLS/SSL بنفسك وتكوينه في الحاوية ، يوصى باستخدام "وكيل إنهاء TLS" مثل Traefik. يمكنك قراءة المزيد حول هذا الموضوع في وثائق Fastapi حول HTTPS.
PRE_START_PATHالمسار حيث للعثور على البرنامج النصي قبل البدء.
افتراضيًا ، تم تعيينه على /app/prestart.sh .
يمكنك ضبطه مثل:
docker run -d -p 80:8080 -e PRE_START_PATH= " /custom/script.sh " myimage تتضمن الصورة ملف تكوين 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 يمكنك تخصيص موقع البرنامج النصي Prestart مع متغير البيئة PRE_START_PATH الموضح أعلاه.
البرنامج الافتراضي الذي يتم تشغيله هو في /start.sh . يفعل كل ما هو موضح أعلاه.
هناك أيضًا نسخة للتطوير مع التحميل التلقائي المباشر على:
/start-reload.shللتنمية ، من المفيد أن تكون قادرًا على تركيب محتويات رمز التطبيق داخل الحاوية كـ Docker "Volume" ، لتكون قادرًا على تغيير الكود واختباره على الهواء مباشرة ، دون الحاجة إلى بناء الصورة في كل مرة.
في هذه الحالة ، من المفيد أيضًا تشغيل الخادم باستخدام التحميل التلقائي المباشر ، بحيث يتم إعادة تشغيله تلقائيًا في كل رمز يتغير.
يدير Script /start-reload.sh Uvicorn بمفرده (بدون Gunicorn) وفي عملية واحدة.
إنه مثالي للتنمية.
على سبيل المثال ، بدلاً من الجري:
docker run -d -p 80:80 myimageيمكنك الجري:
docker run -d -p 80:80 -v $( pwd ) :/app myimage /start-reload.sh-v $(pwd):/app : يعني أن الدليل $(pwd) يجب أن يتم تركيبه كوحدة حرارية داخل الحاوية AT /app .$(pwd) : تشغيل pwd ("Print Working Directory") ويضعه كجزء من السلسلة./start-reload.sh : إضافة شيء (مثل /start-reload.sh ) في نهاية الأمر ، يحل محل "الأمر" الافتراضي مع هذا واحد. في هذه الحالة ، يحل محل الافتراضي ( /start.sh ) ببديل التنمية /start-reload.sh . As /start-reload.sh لا يعمل مع Gunicorn ، أي من التكوينات التي وضعتها في ملف gunicorn_conf.py لن يتم تطبيقه.
لكن متغيرات البيئة هذه ستعمل كما هو موضح أعلاه:
MODULE_NAMEVARIABLE_NAMEAPP_MODULEHOSTPORTLOG_LEVEL باختصار: ربما لا ينبغي عليك استخدام جبال الألب لمشاريع بيثون ، بدلاً من ذلك ، استخدم إصدارات صورة Docker slim .
هل تريد المزيد من التفاصيل؟ متابعة القراءة؟
يعد Alpine أكثر فائدة للغات الأخرى حيث تقوم ببناء ثنائي ثابت في مرحلة صورة Docker واحدة (باستخدام بناء Docker متعدد المراحل) ثم نسخه إلى صورة جبال الألب البسيطة ، ثم تنفيذ ذلك الثنائي فقط. على سبيل المثال ، باستخدام GO.
ولكن بالنسبة إلى Python ، نظرًا لأن جبال الألب لا تستخدم الأدوات القياسية المستخدمة لبناء امتدادات Python ، عند تثبيت الحزم ، في كثير من الحالات ، لن يجد Python ( pip ) حزمة تثبيت قابلة للتثبيت مسبقًا ("عجلة") للبن. وبعد تصحيح الكثير من الأخطاء الغريبة ، ستدرك أنه يتعين عليك تثبيت الكثير من الأدوات الإضافية وبناء الكثير من التبعيات فقط لاستخدام بعض حزم Python الشائعة هذه. ؟
هذا يعني أنه على الرغم من أن صورة جبال الألب الأصلية قد تكون صغيرة ، إلا أنك تنتهي بصورة بحجم مماثل للحجم الذي كنت قد حصلت عليه إذا كنت قد استخدمت للتو صورة بيثون قياسية (استنادًا إلى Debian) ، أو في بعض الحالات أكبر. ؟
وفي جميع هذه الحالات ، سوف يستغرق الأمر وقتًا أطول بكثير للبناء ، واستهلاك المزيد من الموارد ، وبناء تبعيات لفترة أطول ، وكذلك زيادة بصمة الكربون ، حيث تستخدم المزيد من وقت وحدة المعالجة المركزية والطاقة لكل بناء. ؟
إذا كنت تريد صور Python النحيفة ، فيجب عليك بدلاً من ذلك محاولة استخدام الإصدارات slim التي لا تزال تعتمد على Debian ، ولكنها أصغر. ؟
يتم اختبار جميع علامات الصور والتكوينات ومتغيرات البيئة وخيارات التطبيق.
--workers . PR #303 بواسطة Tiangolo.issue-manager.yml . PR #343 بواسطة Tiangolo.latest-changes github. PR #340 بواسطة Tiangolo.latest-changes.yml . PR #276 بواسطة ealjsdev.README.md . PR #275 بواسطة alejsdev.README.md . PR #274 بواسطة ealjsdev. أبرز هذا الإصدار:
python3.6-2022-11-25 .slim . PR #40.WORKER_CLASSTIMEOUTKEEP_ALIVEGRACEFUL_TIMEOUTACCESS_LOGERROR_LOGGUNICORN_CMD_ARGSMAX_WORKERSPRE_START_PATH env var. PR #33.tiangolo/uvicorn-gunicorn-fastapi:python3.7-2019-10-15 . PR #17./start-reload.sh ، تحقق من الوثائق المحدثة. PR #6 في صورة الوالدين.WORKERS_PER_CORE افتراضيًا إلى 1 ، حيث يظهر أن يكون لديه أفضل أداء في المعايير.WEB_CONCURRENCY ، إلى عمالين على الأقل. هذا لتجنب الأداء السيئ وحظر التطبيقات (تطبيق الخادم) على الأجهزة الصغيرة (جهاز الخادم/السحابة/الخ). يمكن تجاوز هذا باستخدام WEB_CONCURRENCY . ينطبق هذا على سبيل المثال في الحالة التي يتم فيها تعيين WORKERS_PER_CORE على 1 (الافتراضي) ولديه خادم واحد فقط من وحدة المعالجة المركزية. PR #6 و PR #5 في صورة الوالدين./start.sh تشغيل بشكل مستقل ، وقراءة وتوليد متغيرات البيئة الافتراضية المستخدمة. وإزالة /entrypoint.sh لأنه لا يعدل أي شيء في النظام ، يقرأ فقط متغيرات البيئة. PR #4 في صورة الوالدين./app/prestart.sh . هذا المشروع مرخص بموجب شروط ترخيص معهد ماساتشوستس للتكنولوجيا.
