uwsgi nginx docker
2.1.0
Dockerfile ذات الصلةpython3.12 ، latest (Dockerfile)python3.11 ، (Dockerfile)python3.10 ، (Dockerfile)python3.9 ، (Dockerfile) لم تعد هذه العلامات مدعومة أو محافظة عليها ، تتم إزالتها من مستودع GitHub ، ولكن قد تظل الإصدارات الأخيرة التي تم دفعها متوفرة في Docker Hub إذا كان أي شخص يقوم بسحبها:
python3.8python3.8-alpinepython3.7python3.6python2.7علامات التاريخ الأخيرة لهذه الإصدارات هي:
python3.8-2024-10-28python3.8-alpine-2024-03-11python3.7-2024-10-28python3.6-2022-11-25python2.7-2022-11-25 ملاحظة : هناك علامات لكل تاريخ بناء. إذا كنت بحاجة إلى "تثبيت" إصدار صورة Docker الذي تستخدمه ، فيمكنك تحديد إحدى هذه العلامات. مثل tiangolo/uwsgi-nginx:python3.12-2024-11-02 .
صورة Docker مع UWSGI و NGINX لتطبيقات الويب في Python ( كقارورة ) في حاوية واحدة.
تتيح لك صورة Docker إنشاء تطبيقات الويب Python التي تعمل مع UWSGI و NGINX في حاوية واحدة.
مزيج من UWSGI مع Nginx هو وسيلة شائعة لنشر تطبيقات الويب Python مثل Flask و Django. يستخدم على نطاق واسع في الصناعة وسيمنحك أداءً لائقًا. (*)
تم إنشاء هذه الصورة لتكون الصورة الأساسية لتيانغولو/UWSGI-NGINX-FLASK ولكن يمكن استخدامها كصورة أساسية لأي تطبيق Python (المستند إلى WSGI) ، مثل Django.
إذا كنت تبدأ مشروعًا جديدًا ، فقد تستفيد من إطار عمل أحدث وأسرع يعتمد على ASGI بدلاً من WSGI (قارورة وجانغو تعتمد على WSGI).
يمكنك استخدام إطار ASGI مثل:
سوف يمنحك Fastapi ، أو Starlette ، حوالي 800 ٪ (8x) الأداء الذي يمكن تحقيقه مع هذه الصورة ( Tiangolo/UWSGI-NGINX ). يمكنك رؤية معايير الطرف الثالث هنا.
أيضًا ، إذا كنت ترغب في استخدام تقنيات جديدة مثل WebSockets ، فسيكون ذلك أسهل ( ممكنًا ) مع إطار أحدث يعتمد على ASGI ، مثل Fastapi أو Starlette. نظرًا لأن ASGI القياسي تم تصميمه ليكون قادرًا على التعامل مع التعليمات البرمجية غير المتزامنة مثل الرمز المطلوب لـ WebSockets.
إذا كنت بحاجة إلى استخدام إطار عمل أقدم قائم على WSGI مثل Flask أو Django (بدلاً من شيء يعتمد على ASGI) وتحتاج إلى الحصول على أفضل أداء ممكن ، يمكنك استخدام الصورة البديلة: Tiangolo/Meinheld-Gunicorn .
سيمنحك Tiangolo/Meinheld-Gunicorn حوالي 400 ٪ (4x) أداء هذه الصورة.
github repo : https://github.com/tiangolo/uwsgi-nginx-docker
Docker Hub Image : https://hub.docker.com/r/tiangolo/uwsgi-nginx/
ربما تستخدم 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/uwsgi-nginx:python3.12
COPY ./requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /app
# Your Dockerfile code... بشكل افتراضي ، سيحاول العثور على ملف تكوين UWSGI في /app/uwsgi.ini .
هذا ملف uwsgi.ini سيجعله يحاول تشغيل ملف python في /app/main.py .
إذا كنت تقوم ببناء تطبيق Flask Web ، فيجب عليك استخدام Tiangolo/UWSGI-NGINX-Flask بدلاً من ذلك.
إذا كنت بحاجة إلى استخدام دليل لتطبيقك مختلف عن /app ، فيمكنك تجاوز مسار ملف تكوين UWSGI مع متغير البيئة UWSGI_INI ، ووضع ملف uwsgi.ini المخصص هناك.
على سبيل المثال ، إذا كنت بحاجة إلى الحصول على دليل التطبيق في /application بدلاً من /app ، فإن Dockerfile ستبدو:
FROM tiangolo/uwsgi-nginx:python3.12
ENV UWSGI_INI /application/uwsgi.ini
COPY ./application /application
WORKDIR /appapplication وملف uwsgi.ini الخاص بك في ./application/uwsgi.ini سيحتوي على:
[uwsgi]
wsgi-file =/application/main.py ملاحظة : من المهم تضمين خيار WORKDIR ، وإلا فإن UWSGI سيبدأ التطبيق في /app .
بشكل افتراضي ، تبدأ الصورة بعملية UWSGI تعملان. عندما يعاني الخادم من حمولة عالية ، فإنه يخلق ما يصل إلى 16 عملية UWSGI للتعامل معها عند الطلب.
إذا كنت بحاجة إلى تكوين هذه الأرقام ، فيمكنك استخدام متغيرات البيئة.
يتم التحكم في عدد بداية عمليات UWSGI بواسطة المتغير UWSGI_CHEAPER ، بشكل افتراضي تم تعيينه على 2 .
يتم التحكم في الحد الأقصى لعدد عمليات UWSGI بواسطة متغير UWSGI_PROCESSES ، بشكل افتراضي تم تعيينه على 16 .
ضع في اعتبارك أن UWSGI_CHEAPER يجب أن يكون أقل من UWSGI_PROCESSES .
لذلك ، على سبيل المثال ، إذا كنت بحاجة إلى البدء بـ 4 عمليات وتنمو إلى 64 عامًا كحد أقصى ، فقد يبدو Dockerfile الخاص بك:
FROM tiangolo/uwsgi-nginx:python3.12
ENV UWSGI_CHEAPER 4
ENV UWSGI_PROCESSES 64
COPY ./app /appفي هذه الصورة ، تم تكوين NGINX للسماح بأحجام ملفات التحميل غير المحدودة. يتم ذلك لأنه بشكل افتراضي سيسمح خادم Python البسيط بذلك ، وهذا هو أبسط سلوك يتوقعه مطور.
إذا كنت بحاجة إلى تقييد الحد الأقصى لحجم التحميل في NGINX ، فيمكنك إضافة متغير البيئة NGINX_MAX_UPLOAD وتعيين قيمة تتوافق مع NGINX Config client_max_body_size .
على سبيل المثال ، إذا كنت ترغب في تعيين الحد الأقصى لحجم ملف التحميل على 1 ميغابايت (الافتراضي في تثبيت NGINX العادي) ، فستحتاج إلى تعيين متغير بيئة NGINX_MAX_UPLOAD إلى القيمة 1m . بعد ذلك ، ستهتم الصورة بإضافة ملف التكوين المقابل (يتم ذلك بواسطة entrypoint.sh ).
لذا ، فإن Dockerfile الخاص بك سيبدو مثل:
FROM tiangolo/uwsgi-nginx:python3.12
ENV NGINX_MAX_UPLOAD 1m
COPY ./app /appبشكل افتراضي ، ستستمع الحاوية المصنوعة من هذه الصورة على المنفذ 80.
لتغيير هذا السلوك ، قم بتعيين متغير بيئة LISTEN_PORT .
قد تحتاج أيضًا إلى إنشاء تعليمات Docker EXPOSE ذات الصلة.
يمكنك القيام بذلك في Dockerfile ، سيبدو شيئًا مثل:
FROM tiangolo/uwsgi-nginx:python3.12
ENV LISTEN_PORT 8080
EXPOSE 8080
COPY ./app /app/app/prestart.sh إذا كنت بحاجة إلى تشغيل أي شيء قبل بدء التطبيق ، فيمكنك إضافة ملف prestart.sh إلى الدليل /app . ستكتشف الصورة وتشغيلها تلقائيًا قبل بدء كل شيء.
على سبيل المثال ، إذا كنت ترغب في إضافة ترحيل قاعدة بيانات يتم تشغيله عند بدء التشغيل (على سبيل المثال مع Alembic ، أو Django Migrations) ، قبل بدء التطبيق ، يمكنك إنشاء ملف ./app/prestart.sh في دليل الرمز الخاص بك (سيتم نسخه بواسطة Dockerfile ) مع:
#! /usr/bin/env bash
# Let the DB start
sleep 10 ;
# Run migrations
alembic upgrade head وسوف ينتظر 10 ثوانٍ لإعطاء قاعدة البيانات بعض الوقت للبدء ثم تشغيل هذا الأمر alembic (يمكنك تحديث ذلك لتشغيل عمليات ترحيل Django أو أي أداة أخرى تحتاجها).
إذا كنت بحاجة إلى تشغيل برنامج نصي Python قبل بدء التطبيق ، فيمكنك إنشاء ملف /app/prestart.sh تشغيل البرنامج النصي Python الخاص بك ، مع شيء مثل:
#! /usr/bin/env bash
# Run custom Python script before starting
python /app/my_custom_prestart_script.py ملاحظة : تستخدم الصورة . لتشغيل البرنامج النصي (كما في . /app/prestart.sh ) ، لذلك على سبيل المثال ، ستستمر متغيرات البيئة. إذا كنت لا تفهم الجملة السابقة ، فربما لا تحتاجها.
بشكل افتراضي ، ستبدأ Nginx "عملية العمال".
إذا كنت ترغب في تعيين عدد مختلف من عمليات عامل NGINX ، فيمكنك استخدام متغير البيئة NGINX_WORKER_PROCESSES .
يمكنك استخدام رقم واحد معين ، على سبيل المثال:
ENV NGINX_WORKER_PROCESSES 2 أو يمكنك تعيينه على الكلمة الرئيسية auto وسيحاول توسيع عدد وحدات المعالجة المركزية المتوفرة واستخدام ذلك لعدد العمال.
على سبيل المثال ، باستخدام auto ، يمكن أن يبدو Dockerfile الخاص بك:
FROM tiangolo/uwsgi-nginx:python3.12
ENV NGINX_WORKER_PROCESSES auto
COPY ./app /appبشكل افتراضي ، سيبدأ Nginx بحد أقصى 1024 اتصالات لكل عامل.
إذا كنت ترغب في تعيين رقم مختلف ، يمكنك استخدام متغير البيئة NGINX_WORKER_CONNECTIONS ، على سبيل المثال:
ENV NGINX_WORKER_CONNECTIONS 2048لا يمكن أن يتجاوز الحد الحالي لأقصى عدد من الملفات المفتوحة. تعرف على كيفية تكوينه في القسم التالي.
لا يمكن أن تتجاوز اتصالات الأرقام لكل عامل NGINX الحد الأقصى لعدد الملفات المفتوحة.
يمكنك تغيير حد الملفات المفتوحة مع البيئة المتغير NGINX_WORKER_OPEN_FILES ، على سبيل المثال:
ENV NGINX_WORKER_OPEN_FILES 2048 إذا كنت بحاجة إلى تكوين Nginx بشكل أكبر ، فيمكنك إضافة ملفات *.conf إلى /etc/nginx/conf.d/ في Dockerfile .
فقط ضع في اعتبارك أن التكوينات الافتراضية يتم إنشاؤها أثناء بدء التشغيل في ملف على /etc/nginx/conf.d/nginx.conf و /etc/nginx/conf.d/upload.conf . لذلك يجب ألا تكتبهم. يجب عليك تسمية ملف *.conf بشيء مختلف عن nginx.conf أو upload.conf ، على سبيل المثال: custom.conf .
ملاحظة : إذا كنت تقوم بتخصيص NGINX ، فربما تقوم بنسخ التكوينات من مدونة أو إجابة Stackoverflow ، فكل في الاعتبار أنك قد تحتاج إلى استخدام التكوينات الخاصة بـ UWSGI ، بدلاً من تلك الخاصة بالوحدات النمطية الأخرى ، مثل ngx_http_fastcgi_module .
إذا كنت بحاجة إلى تكوين NGINX بشكل أكبر ، مما يؤدي إلى تجاوز الإعدادات الافتراضية تمامًا ، فيمكنك إضافة تكوين NGINX مخصص إلى /app/nginx.conf .
سيتم نسخه إلى /etc/nginx/nginx.conf واستخدامه بدلاً من واحد تم إنشاؤه.
ضع في اعتبارك أنه في هذه الحالة ، لن تنشئ هذه الصورة أيًا من تكوينات Nginx ، فهي ستقوم فقط بنسخ ملف التكوين الخاص بك واستخدامه.
هذا يعني أنه لن يتم استخدام جميع متغيرات البيئة الموضحة أعلاه والتي هي خاصة بـ Nginx.
/app/nginx.conf يعني أيضًا أنه لن يستخدم تكوينات إضافية من الملفات في /etc/nginx/conf.d/*.conf .
include /etc/nginx/conf.d/*.conf;
إذا كنت ترغب في إضافة ملف custom /app/nginx.conf ولكن لا تعرف من أين تبدأ ، فيمكنك استخدام nginx.conf المستخدمة في الاختبارات وتخصيصه أو تعديله بشكل أكبر.
مزيج من UWSGI مع Nginx هو وسيلة شائعة لنشر تطبيقات الويب Python.
تقريبا:
Nginx هو خادم ويب ، ويهتم باتصالات HTTP ويمكن أيضًا تقديم ملفات ثابتة بشكل مباشر وأكثر كفاءة.
UWSGI هو خادم تطبيق ، وهذا ما يدير رمز Python الخاص بك ويتحدث مع Nginx.
يحتوي رمز Python الخاص بك على تطبيق الويب الفعلي ، ويتم تشغيله بواسطة UWSGI.
تستفيد هذه الصورة من صور Docker النحيفة والمحسّنة بالفعل (استنادًا إلى Debian كما أوصت بها Docker) وتنفيذ أفضل الممارسات Docker.
يستخدم صورة Python Docker الرسمية ، ويقوم بتثبيت UWSGI وعلاوة على ذلك ، مع أقل قدر من التعديلات ، يضيف صورة Nginx الرسمية (اعتبارًا من 2016-02-14).
ويتحكم في كل هذه العمليات مع Supervisord.
هناك قاعدة من الإبهام التي يجب أن يكون لديك "عملية واحدة لكل حاوية".
يساعد ذلك ، على سبيل المثال ، على عزل التطبيق وقاعدة البيانات الخاصة به في حاويات مختلفة.
ولكن إذا كنت ترغب في الحصول على نهج "الخدمات الصغيرة" ، فقد ترغب في الحصول على أكثر من عملية في حاوية واحدة إذا كانت جميعها مرتبطة بنفس "الخدمة" ، وقد ترغب في تضمين رمز القارورة الخاص بك و UWSGI و NGINX في نفس الحاوية (وربما تشغيل حاوية أخرى مع قاعدة البيانات الخاصة بك).
هذا هو النهج الذي اتخذ في هذه الصورة.
تحتوي هذه الصورة على تطبيق افتراضي "Hello World" في دليل الحاوية /app باستخدام المثال في وثائق UWSGI.
ربما تريد تجاوزه أو حذفه في مشروعك.
إنه موجود في حالة تشغيل هذه الصورة بمفرده وليس كصورة أساسية لـ Dockerfile الخاصة بك ، بحيث تحصل على نموذج تطبيق بدون أخطاء.
باختصار: ربما لا ينبغي عليك استخدام جبال الألب لمشاريع بيثون ، بدلاً من ذلك ، استخدم إصدارات صورة Docker slim .
هل تريد المزيد من التفاصيل؟ متابعة القراءة؟
يعد Alpine أكثر فائدة للغات الأخرى حيث تقوم ببناء ثنائي ثابت في مرحلة صورة Docker واحدة (باستخدام بناء Docker متعدد المراحل) ثم نسخه إلى صورة جبال الألب البسيطة ، ثم تنفيذ ذلك الثنائي فقط. على سبيل المثال ، باستخدام GO.
ولكن بالنسبة إلى Python ، نظرًا لأن جبال الألب لا تستخدم الأدوات القياسية المستخدمة لبناء امتدادات Python ، عند تثبيت الحزم ، في كثير من الحالات ، لن يجد Python ( pip ) حزمة تثبيت قابلة للتثبيت مسبقًا ("عجلة") للبن. وبعد تصحيح الكثير من الأخطاء الغريبة ، ستدرك أنه يتعين عليك تثبيت الكثير من الأدوات الإضافية وبناء الكثير من التبعيات فقط لاستخدام بعض حزم Python الشائعة هذه. ؟
هذا يعني أنه على الرغم من أن صورة جبال الألب الأصلية قد تكون صغيرة ، إلا أنك تنتهي بصورة بحجم مماثل للحجم الذي كنت قد حصلت عليه إذا كنت قد استخدمت للتو صورة بيثون قياسية (استنادًا إلى Debian) ، أو في بعض الحالات أكبر. ؟
وفي جميع هذه الحالات ، سوف يستغرق الأمر وقتًا أطول بكثير للبناء ، واستهلاك المزيد من الموارد ، وبناء تبعيات لفترة أطول ، وكذلك زيادة بصمة الكربون ، حيث تستخدم المزيد من وقت وحدة المعالجة المركزية والطاقة لكل بناء. ؟
إذا كنت تريد صور Python النحيفة ، فيجب عليك بدلاً من ذلك محاولة استخدام الإصدارات slim التي لا تزال تعتمد على Debian ، ولكنها أصغر. ؟
يتم اختبار جميع علامات الصور والتكوينات ومتغيرات البيئة وخيارات التطبيق.
يتم الإعلان عن التحديثات في الإصدارات.
يمكنك النقر فوق الزر "مشاهدة" في الجزء العلوي الأيمن واختيار "الإصدارات فقط" لتلقي إشعار البريد الإلكتروني عندما يكون هناك إصدار جديد.
*.pyc غير ضرورية مع PYTHONDONTWRITEBYTECODE=1 وتأكد من طباعة السجلات على الفور باستخدام PYTHONUNBUFFERED=1 . PR #208 بواسطة @estebanx64. EXPOSE المنافذ 80 و 443 بشكل افتراضي حيث يمكن تخصيصها. PR #227 بواسطة Tiangolo. issue-manager.yml . PR #226 بواسطة Tiangolo.latest-changes github. PR #214 بواسطة Tiangolo.latest-changes.yml . PR #201 بواسطة ealjsdev.README.md . PR #199 بواسطة ealjsdev. أبرز هذا الإصدار:
python3.6-2022-11-25 و python2.7-2022-11-25 .2.0.20 . PR #127 بواسطة Tiangolo.1.17.10 ، استنادًا إلى أحدث دبيان ، باستر. PR #82.2020-05-04 .2019-10-14:
2019-09-28:
tiangolo/uwsgi-nginx:python3.7-2019-09-28 . PR #65.ترقية ترافيس. PR #60.
/app/prestart.sh البرنامج النصي لتشغيل رمز تعسفي قبل بدء التطبيق (على سبيل المثال ، Alembic - Sqlalchemy Migrations). الوثائق الخاصة بـ /app/prestart.sh موجودة في readme الرئيسية. PR #59.2019-05-04:
2019-02-02:
/app/nginx.conf تمامًا يتجاوز الفصل الذي تم إنشاؤه. PR #51.2018-11-23: New Alpine 3.8 Images لـ Python 2.7 و Python 3.6 و Python 3.7 (Python 3.7 معطل مؤقتًا). بفضل Philippfreyer في PR #45
2018-09-22: إصدارات Python 3.7 الجديدة ، القياسية والجبال القائمة. بفضل Desaintmartin في هذا العلاقات العامة.
2018-06-22: يمكنك الآن استخدام NGINX_WORKER_CONNECTIONS لتعيين الحد الأقصى لعدد اتصالات عامل NGINX و NGINX_WORKER_OPEN_FILES لتعيين الحد الأقصى لعدد الملفات المفتوحة. بفضل رونلوت في هذا العلاقات العامة.
2018-06-22: اجعل UWSGI تتطلب تشغيل تطبيق ، بدلاً من الذهاب في "الوضع الديناميكي الكامل" في حين كان هناك خطأ. Supervisord لا ينهي نفسه ولكنه يحاول إعادة تشغيل UWSGI ويظهر الأخطاء. يستخدم need-app كما اقترح LuckyDonald في هذا التعليق.
2018-06-22: تم التعامل معها بشكل صحيح عن إغلاق UWSGI و NGINX. بفضل Desaintmartin في هذا العلاقات العامة.
2018-02-04: من الممكن الآن تعيين عدد عمليات العمال NGINX مع متغير البيئة NGINX_WORKER_PROCESSES . بفضل naktinis في هذا العلاقات العامة.
2018-01-14: يوجد الآن نسختان قائمان على جبال الألب ، python2.7-alpine3.7 و python3.6-alpine3.7 .
2017-12-08: يمكنك الآن تكوين المنفذ الذي يجب على الحاوية الاستماع إليه ، باستخدام متغير البيئة LISTEN_PORT بفضل TMSHN في هذا العلاقات العامة.
2017-08-09: يمكنك تعيين حجم ملف التحميل القصوى المخصص باستخدام متغير البيئة NGINX_MAX_UPLOAD ، افتراضيًا له قيمة 0 ، تتيح أحجام ملفات التحميل غير المحدودة. هذا يختلف عن القيمة الافتراضية لـ Nginx البالغة 1 ميغابايت. تم تكوينه بهذه الطريقة لأن هذه هي أبسط تجربة مطور غير خبير في Nginx يتوقعه.
2017-08-09: يمكنك الآن تجاوز مكان البحث عن ملف uwsgi.ini ، ومع ذلك ، قم بتغيير الدليل الافتراضي من /app إلى شيء آخر ، باستخدام envirnoment UWSGI_INI .
2017-08-08: هناك أحدث صورة لعلامة latest ، فقط لإظهار تحذير لأولئك الذين ما زالوا يستخدمون latest لتطبيقات الويب Python 2.7. اعتبارا من الآن ، يجب أن يستخدم الجميع بيثون 3.
2017-08-08: ينهي Supervisord الآن UWSGI على SIGTERM ، لذلك إذا قمت بتشغيل docker stop أو شيء مشابه ، فسيتوقف عن كل شيء بالفعل ، بدلاً من انتظار مهلة Docker لقتل الحاوية.
2017-07-31: هناك الآن علامة صورة لـ Python 3.6 ، استنادًا إلى الصورة الرسمية لـ Python 3.6 بفضل JRD في هذا العلاقات العامة.
2016-10-01: يمكنك الآن تجاوز معلمات uwsgi.ini الافتراضية من الملف في /app/uwsgi.ini .
2016-08-16: هناك الآن علامة صورة لـ Python 3.5 ، استنادًا إلى الصورة الرسمية لـ Python 3.5. حتى الآن يمكنك استخدام هذه الصورة لمشاريعك في Python 2.7 و Python 3.5.
2016-08-16: استخدم ديناميكية عدد من عمليات العمال لـ UWSGI ، من 2 إلى 16 اعتمادًا على الحمل. هذا يجب أن يعمل في معظم الحالات. يساعد هذا خاصةً عندما يكون هناك بعض الردود البطيئة وتستغرق توليد بعض الوقت ، ويسمح هذا التغيير بجميع الردود الأخرى للحفاظ على السرعة (في عملية جديدة) دون الحاجة إلى الانتظار حتى الانتهاء من الأول (البطيء).
أيضًا ، يستخدم الآن ملف uwsgi.ini الأساسي تحت /etc/uwsgi/ مع معظم التكوينات العامة ، لذلك ، أصبح uwsgi.ini insep /app (التطبيق الذي قد تحتاجه إلى تعديله) أبسط بكثير.
2016-04-05: تم الآن إعادة توجيه سجلات NGINX و UWSGI إلى stdout ، مما يسمح باستخدام docker logs .
هذا المشروع مرخص بموجب شروط ترخيص Apache.
