uwsgi nginx docker
2.1.0
Dockerfile -Linkspython3.12 , latest (Dockerfile)python3.11 , (Dockerfile)python3.10 , (Dockerfile)python3.9 , (Dockerfile) Diese Tags werden nicht mehr unterstützt oder aufrechterhalten, sie werden aus dem Github -Repository entfernt, aber die letzten Versionen sind möglicherweise noch in Docker Hub verfügbar, wenn jemand sie gezogen hat:
python3.8python3.8-alpinepython3.7python3.6python2.7Die letzten Datum -Tags für diese Versionen sind:
python3.8-2024-10-28python3.8-alpine-2024-03-11python3.7-2024-10-28python3.6-2022-11-25python2.7-2022-11-25 Hinweis : Es gibt Tags für jedes Build -Datum. Wenn Sie die von Ihnen verwendete Docker -Bildversion "Pin" "pin" müssen, können Sie eines dieser Tags auswählen. tiangolo/uwsgi-nginx:python3.12-2024-11-02
Docker -Bild mit UWSGI und NGINX für Webanwendungen in Python (als Flasche ) in einem einzigen Container.
Mit diesem Docker -Bild können Sie Python -Webanwendungen erstellen, die mit UWSGI und NGINX in einem einzigen Container ausgeführt werden.
Die Kombination von UWSGI mit Nginx ist eine häufige Möglichkeit, Python -Webanwendungen wie Flask und Django bereitzustellen. Es ist in der Branche weit verbreitet und würde Ihnen eine anständige Leistung bieten. (*)
Dieses Bild wurde als Grundbild für Tiangolo/UWSGI-Nginx-Flask erstellt, könnte jedoch als Basisbild für jede andere (WSGI-basierte) Python-Webanwendung wie Django verwendet werden.
Wenn Sie ein neues Projekt starten, können Sie von einem neueren und schnelleren Rahmen profitieren, das auf ASGI anstelle von WSGI basiert (Flask und Django sind WSGI-basiert).
Sie könnten ein ASGI -Framework verwenden wie:
Fastapi oder Starlette würde Ihnen die Leistung von diesem Bild ( Tiangolo/UWSGI-Nginx ) zu etwa 800% (8x) erhalten. Sie können die Benchmarks von Drittanbietern hier sehen.
Wenn Sie neue Technologien wie WebSockets verwenden möchten, wäre dies mit einem neueren Rahmen, der auf ASGI basiert, wie Fastapi oder Starlette, einfacher (und möglich ). Da der Standard -ASGI so konzipiert wurde, dass sie asynchrone Code wie den für Websockets benötigten Code verarbeiten können.
Wenn Sie ein älteres WSGI-basiertes Framework wie Flask oder Django (anstelle von etwas, das auf ASGI basiert) verwenden müssen und Sie die bestmögliche Leistung haben müssen, können Sie das alternative Bild verwenden: Tiangolo/Meinheld-Gunicorn .
Tiangolo/Meinheld-Gunicorn gibt Ihnen etwa 400% (4x) die Leistung dieses Bildes.
Github Repo : https://github.com/tiangolo/uwsgi-nginx-docker
Docker Hub Image : https://hub.docker.com/r/tiangolo/uwsgi-nginx/
Sie verwenden wahrscheinlich Kubernetes oder ähnliche Tools. In diesem Fall benötigen Sie dieses Bild (oder ein anderes ähnliches Basisbild ) wahrscheinlich nicht . Sie sind wahrscheinlich besser dran, ein Docker -Bild von Grund auf neu zu erstellen .
Wenn Sie über eine Gruppe von Maschinen mit Kubernetes , Docker Swarm -Modus, NOMAD oder einem ähnlichen komplexen System verfügen, um verteilte Container auf mehreren Maschinen zu verwalten, möchten Sie wahrscheinlich die Replikation auf Clusterebene verarbeiten, anstatt einen Prozessmanager in jedem Container zu verwenden, der mehrere Arbeiterprozesse startet, was dieses Docker -Bild ist.
In diesen Fällen (z. B. mit Kubernetes) möchten Sie wahrscheinlich ein Docker -Bild von Grund auf neu erstellen, Ihre Abhängigkeiten installieren und einen einzelnen Prozess anstelle dieses Bildes ausführen.
Mit Gunicorn können Sie beispielsweise eine Datei app/gunicorn_conf.py mit:
# Gunicorn config variables
loglevel = "info"
errorlog = "-" # stderr
accesslog = "-" # stdout
worker_tmp_dir = "/dev/shm"
graceful_timeout = 120
timeout = 120
keepalive = 5
threads = 3 Und dann könnten Sie eine Dockerfile haben mit:
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" ]Weitere Informationen zu diesen Ideen finden Sie in der Fastapi -Dokumentation zu: Fastapi in Containern - Docker wie die gleichen Ideen würden für andere Webanwendungen in Containern gelten.
Sie möchten, dass ein Prozessmanager mehrere Arbeiterprozesse im Container ausführt, wenn Ihre Anwendung einfach genug ist, dass Sie (zumindest noch nicht) die Anzahl der Prozesse zu stark abschneiden, und Sie können nur einen automatisierten Standard verwenden, und Sie führen ihn auf einem einzelnen Server aus, nicht auf einem Cluster.
Sie könnten mit Docker Compose auf einem einzelnen Server (kein Cluster) bereitgestellt werden, sodass Sie keine einfache Möglichkeit haben, die Replikation von Containern (mit Docker Compose) zu verwalten, während Sie das gemeinsame Netzwerk und das Lastausgleich erhalten haben.
Dann möchten Sie einen einzelnen Container mit einem Prozessmanager, der mehrere Arbeitsprozesse startet, wie dieses Docker -Image.
Sie können auch andere Gründe haben, die es einfacher machen würden, einen einzelnen Container mit mehreren Prozessen zu haben, anstatt mehrere Container mit einem einzelnen Prozess in jedem von ihnen zu haben.
Zum Beispiel (abhängig von Ihrem Setup) können Sie ein Tool wie einen Prometheus -Exporteur im selben Container haben, der Zugriff auf jede der kommenden Anforderungen haben sollte.
In diesem Fall, wenn Sie standardmäßig mehrere Container hätten, wenn Prometheus die Metriken las , würde jedes Mal die für einen einzelnen Container (für den Container, der diese bestimmte Anfrage bearbeitet), anstatt die akkumulierten Metriken für alle replizierten Container zu erhalten.
In diesem Fall könnte es dann einfacher sein, einen Container mit mehreren Prozessen und ein lokales Tool (z. B. ein Prometheus -Exporteur) auf demselben Container zu sammeln, das Prometheus -Metriken für alle internen Prozesse sammelt und diese Metriken auf diesem einzelnen Container freigibt.
Lesen Sie mehr darüber in der Fastapi -Dokumentation über: Fastapi in Containern - Docker, wie dieselben Konzepte für andere Webanwendungen in Containern gelten.
Sie müssen dieses Repo nicht klonen.
Sie können dieses Bild als Basisbild für andere Bilder verwenden.
Angenommen, Sie haben Dockerfile requirements.txt .
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... Standardmäßig wird versucht, eine UWSGI -Konfigurationsdatei in /app/uwsgi.ini zu finden.
Diese uwsgi.ini -Datei lässt sie versuchen, eine Python -Datei in /app/main.py auszuführen.
Wenn Sie eine Flask- Webanwendung erstellen, sollten Sie stattdessen Tiangolo/UWSGI-Nginx-Flask verwenden.
Wenn Sie ein Verzeichnis für Ihre App verwenden müssen, anders als /app , können Sie den UWSGI -Konfigurationsdateipfad mit einer Umgebungsvariablen UWSGI_INI überschreiben und Ihre benutzerdefinierte uwsgi.ini -Datei dort einsetzen.
Wenn Sie beispielsweise Ihr Anwendungsverzeichnis in /application anstelle von /app haben mussten, würde Ihre Dockerfile so aussehen:
FROM tiangolo/uwsgi-nginx:python3.12
ENV UWSGI_INI /application/uwsgi.ini
COPY ./application /application
WORKDIR /appapplication Und Ihre uwsgi.ini -Datei in ./application/uwsgi.ini würde enthalten:
[uwsgi]
wsgi-file =/application/main.py HINWEIS : Es ist wichtig, die Option WORKDIR einzuschließen, andernfalls startet UWSGI die Anwendung in /app .
Standardmäßig beginnt das Bild mit 2 UWSGI -Prozessen. Wenn der Server eine hohe Last hat, werden bis zu 16 UWSGI -Prozesse erstellt, um sie bei Bedarf zu bewältigen.
Wenn Sie diese Zahlen konfigurieren müssen, können Sie Umgebungsvariablen verwenden.
Die Startnummer der UWSGI -Prozesse wird standardmäßig von der variablen UWSGI_CHEAPER auf 2 gesteuert.
Die maximale Anzahl von UWSGI -Prozessen wird standardmäßig durch die variable UWSGI_PROCESSES auf 16 gesteuert.
Denken Sie daran, dass UWSGI_CHEAPER niedriger sein muss als UWSGI_PROCESSES .
Wenn Sie beispielsweise mit 4 Prozessen beginnen und maximal 64 wachsen müssen, könnte Ihre Dockerfile wie:
FROM tiangolo/uwsgi-nginx:python3.12
ENV UWSGI_CHEAPER 4
ENV UWSGI_PROCESSES 64
COPY ./app /appIn diesem Bild ist NGINX so konfiguriert, dass unbegrenzte Upload -Dateigrößen zu ermöglichen. Dies geschieht, da ein einfacher Python -Server dies standardmäßig zulassen würde. Dies ist also das einfachste Verhalten, das ein Entwickler erwarten würde.
Wenn Sie die maximale Uploadgröße in Nginx einschränken müssen, können Sie eine Umgebungsvariable NGINX_MAX_UPLOAD hinzufügen und einen Wert zuweisen, der dem Standard -Nginx client_max_body_size entspricht.
Wenn Sie beispielsweise die maximale Hochladendateigröße auf 1 MB festlegen möchten (die Standardeinstellung in einer normalen Nginx -Installation), müssten Sie die Umgebungsvariable NGINX_MAX_UPLOAD auf den Wert 1m festlegen. Anschließend wird das Bild das Hinzufügen der entsprechenden Konfigurationsdatei (dies erfolgt durch den entrypoint.sh ).
Ihre Dockerfile würde also ungefähr so aussehen wie:
FROM tiangolo/uwsgi-nginx:python3.12
ENV NGINX_MAX_UPLOAD 1m
COPY ./app /appStandardmäßig hört der Container aus diesem Bild auf Port 80 an.
Um dieses Verhalten zu ändern, legen Sie die Umgebungsvariable LISTEN_PORT fest.
Möglicherweise müssen Sie auch den EXPOSE Docker -Anweisungen erstellen.
Sie können das in Ihrer Dockerfile tun, es würde ungefähr so aussehen wie:
FROM tiangolo/uwsgi-nginx:python3.12
ENV LISTEN_PORT 8080
EXPOSE 8080
COPY ./app /app/app/prestart.sh Wenn Sie vor dem Starten der App etwas ausführen müssen, können Sie dem Verzeichnis /app eine Datei prestart.sh hinzufügen. Das Bild erkennt und führt es automatisch aus, bevor Sie alles starten.
Wenn Sie beispielsweise Datenbankmigrationen hinzufügen möchten, die beim Start (z. B. mit alembischen oder Django -Migrationen) ausgeführt werden, können Sie vor dem Starten der App eine ./app/prestart.sh -Datei in Ihrem Code -Verzeichnis (die von Ihrem Dockerfile kopiert werden) mit:
#! /usr/bin/env bash
# Let the DB start
sleep 10 ;
# Run migrations
alembic upgrade head Und es würde 10 Sekunden warten, um der Datenbank einige Zeit zum Starten zu geben und diesen alembic Befehl auszuführen (Sie können diese aktualisieren, um Django -Migrationen oder ein anderes Tool auszuführen, das Sie benötigen).
Wenn Sie vor dem Starten der App ein Python -Skript ausführen müssen, können Sie die Datei /app/prestart.sh Ihr Python -Skript mit so etwas wie folgt ausführen:
#! /usr/bin/env bash
# Run custom Python script before starting
python /app/my_custom_prestart_script.py Hinweis : Das Bild verwendet . Um das Skript auszuführen (wie in . /app/prestart.sh ), würden beispielsweise Umgebungsvariablen bestehen. Wenn Sie den vorherigen Satz nicht verstehen, brauchen Sie ihn wahrscheinlich nicht.
Standardmäßig startet Nginx einen "Arbeiterprozess".
Wenn Sie eine andere Anzahl von Nginx -Worker -Prozessen festlegen möchten, können Sie die Umgebungsvariable NGINX_WORKER_PROCESSES verwenden.
Sie können eine bestimmte Einzelnummer verwenden, z. B.:
ENV NGINX_WORKER_PROCESSES 2 Oder Sie können es auf das Keyword auto einstellen und es wird versuchen, die Anzahl der verfügbaren CPUs zu autodieren und diese für die Anzahl der Arbeitnehmer zu verwenden.
Zum Beispiel könnte Ihre Dockerfile mit automatischer Weise wie bei der Verwendung von auto aussehen:
FROM tiangolo/uwsgi-nginx:python3.12
ENV NGINX_WORKER_PROCESSES auto
COPY ./app /appStandardmäßig beginnt Nginx mit einer maximalen Grenze von 1024 Verbindungen pro Arbeiter.
Wenn Sie eine andere Nummer festlegen möchten, können Sie die Umgebungsvariable NGINX_WORKER_CONNECTIONS verwenden, z. B.:
ENV NGINX_WORKER_CONNECTIONS 2048Es kann die aktuelle Grenze für die maximale Anzahl geöffneter Dateien nicht überschreiten. Sehen Sie, wie Sie es im nächsten Abschnitt konfigurieren.
Die Zahlenverbindungen pro NGINX -Arbeiter können die Grenze für die maximale Anzahl geöffneter Dateien nicht überschreiten.
Sie können die Grenze von geöffneten Dateien mit der Umgebungsvariablen NGINX_WORKER_OPEN_FILES ändern, z. B.:
ENV NGINX_WORKER_OPEN_FILES 2048 Wenn Sie Nginx weiter konfigurieren müssen, können Sie in Ihrem Dockerfile *.conf -Dateien zu /etc/nginx/conf.d/ hinzufügen.
Denken Sie nur daran, dass die Standardkonfigurationen während des Starts in einer Datei unter /etc/nginx/conf.d/nginx.conf und /etc/nginx/conf.d/upload.conf erstellt werden. Sie sollten sie also nicht überschreiben. Sie sollten Ihre *.conf -Datei mit etwas anderem als nginx.conf oder upload.conf benennen, z. B. custom.conf .
Hinweis : Wenn Sie Nginx anpassen, können Sie möglicherweise Konfigurationen aus einem Blog oder einer Stackoverflow -Antwort kopieren, denken Sie daran, dass Sie wahrscheinlich die für UWSGI spezifischen Konfigurationen verwenden müssen, anstatt diejenigen für andere Module, wie zum Beispiel ngx_http_fastcgi_module .
Wenn Sie Nginx noch weiter konfigurieren müssen und die Standardeinstellungen vollständig überschreiben müssen, können Sie eine benutzerdefinierte Nginx -Konfiguration zu /app/nginx.conf hinzufügen.
Es wird in /etc/nginx/nginx.conf kopiert und anstelle des erzeugten verwendet.
Beachten Sie, dass dieses Bild in diesem Fall keine der Nginx -Konfigurationen generiert, sondern Ihre Konfigurationsdatei nur kopiert und verwendet.
Dies bedeutet, dass alle oben beschriebenen Umgebungsvariablen, die spezifisch für Nginx sind, nicht verwendet werden.
Dies bedeutet auch, dass keine zusätzlichen Konfigurationen von Dateien in /etc/nginx/conf.d/*.conf verwendet werden, es sei denn, Sie haben explizit einen Abschnitt in Ihrem benutzerdefinierten Datei /app/nginx.conf mit:
include /etc/nginx/conf.d/*.conf;
Wenn Sie eine benutzerdefinierte Datei /app/nginx.conf hinzufügen möchten, aber nicht wissen, wohin Sie beginnen sollen, können Sie die für die Tests verwendete nginx.conf verwenden und anpassen oder weiter ändern.
Die Kombination von UWSGI mit NGINX ist eine häufige Möglichkeit, Python -Webanwendungen bereitzustellen.
Rund:
Nginx ist ein Webserver, er kümmert sich um die HTTP -Verbindungen und kann auch statische Dateien direkt und effizienter bereitstellen.
UWSGI ist ein Anwendungsserver, das führt Ihren Python -Code aus und spricht mit Nginx.
Ihr Python -Code hat die eigentliche Webanwendung und wird von UWSGI ausgeführt.
Dieses Bild nutzt bereits schlanke und optimierte vorhandene Docker -Bilder (basierend auf Debian, wie von Docker empfohlen) und implementiert Docker Best Practices.
Es verwendet das offizielle Python-Docker-Bild, installiert UWSGI und fügt darüber hinaus das offizielle NGINX-Image (ab 2016-02-14) mit der geringsten Änderungen hinzu.
Und es kontrolliert all diese Prozesse mit Supervisford.
Es gibt die Faustregel, dass Sie "einen Prozess pro Container" haben sollten.
Dies hilft beispielsweise, eine App und ihre Datenbank in verschiedenen Containern zu isolieren.
Wenn Sie jedoch einen "Micro-Services" -Ansatz haben möchten, möchten Sie möglicherweise mehr als einen Prozess in einem Container haben, wenn sie alle mit demselben "Service" zusammenhängen, und Sie möchten möglicherweise Ihren Flask-Code, UWSGI und NGINX in denselben Container (und führen Sie möglicherweise einen anderen Container mit Ihrer Datenbank aus).
Das ist der Ansatz in diesem Bild.
Dieses Bild hat eine Standard -Beispiel -"-App" Hello World "im Verzeichnis des Containers /app unter Verwendung des Beispiels in der UWSGI -Dokumentation.
Sie möchten es wahrscheinlich überschreiben oder in Ihrem Projekt löschen.
Für den Fall, dass Sie dieses Bild selbst und nicht als Basisbild für Ihre eigene Dockerfile ausführen, erhalten Sie eine Beispiel -App ohne Fehler.
Kurz gesagt: Sie sollten wahrscheinlich nicht Alpine für Python -Projekte verwenden, sondern die slim Docker -Bildversionen verwenden.
Möchten Sie weitere Details? Lesen Sie weiter?
Alpine ist nützlicher für andere Sprachen, in denen Sie in einer Docker-Bildphase eine statische Binärdatum erstellen (unter Verwendung eines mehrstufigen Docker-Gebäudes) und dann in ein einfaches Alpine-Bild kopieren und diese Binärdatum einfach ausführen. Zum Beispiel verwenden Sie GO.
Für Python, da Alpine nicht die Standardwerkzeuge zum Erstellen von Python -Erweiterungen verwendet, wird bei der Installation von Paketen in vielen Fällen Python ( pip ) kein vorkompiliertes installierbares Paket (ein "Rad") für Alpine gefunden. Und nachdem Sie viele seltsame Fehler debuggen haben, müssen Sie feststellen, dass Sie eine Menge zusätzlicher Werkzeuge installieren und viele Abhängigkeiten erstellen müssen, um einige dieser gängigen Python -Pakete zu verwenden. ?
Dies bedeutet, dass Sie, obwohl das ursprüngliche alpine Bild klein gewesen ist, ein A -Bild mit einer Größe mit der Größe, die Sie erhalten hätten, vergleichbar waren, wenn Sie gerade ein Standard -Python -Bild (basierend auf Debian) oder in einigen Fällen noch größer verwendet hätten. ?
Und in all diesen Fällen wird es viel länger dauern, wenn man viel mehr Ressourcen verbraucht, Abhängigkeiten länger aufbaut und den CO2 -Fußabdruck erhöht, da Sie für jeden Build mehr CPU -Zeit und -senergie nutzen. ?
Wenn Sie schlanke Python -Bilder möchten, sollten Sie stattdessen versuchen, die slim Versionen zu verwenden, die immer noch auf Debian basieren, aber kleiner sind. ?
Alle Bild -Tags, Konfigurationen, Umgebungsvariablen und Anwendungsoptionen werden getestet.
Updates werden in den Veröffentlichungen bekannt gegeben.
Sie können oben rechts auf die Schaltfläche "Watch" klicken und "Releases nur" auswählen, um eine E -Mail -Benachrichtigung zu erhalten, wenn eine neue Version vorliegt.
*.pyc -Dateien mit PYTHONDONTWRITEBYTECODE=1 zu erstellen und stellen Sie sicher, dass Protokolle sofort mit PYTHONUNBUFFERED=1 gedruckt werden. PR #208 von @estebanx64. EXPOSE Sie die Ports 80 und 443 standardmäßig nicht, da sie angepasst werden können. PR #227 von @tiangolo. issue-manager.yml . PR #226 von @tiangolo.latest-changes GitHub-Aktionen. PR #214 von @tiangolo.latest-changes.yml . PR #201 von @alejsdev.README.md . PR #199 von @alejsdev. Highlights dieser Veröffentlichung:
python3.6-2022-11-25 und python2.7-2022-11-25 .2.0.20 ein. PR #127 von @tiangolo.1.17.10 basiert auf dem neuesten Debian, Buster. PR #82.2020-05-04 verwenden.2019-10-14:
2019-09-28:
tiangolo/uwsgi-nginx:python3.7-2019-09-28 . PR #65.Aktualisieren Sie Travis. PR #60.
/app/prestart.sh -Skript zum Ausführen von beliebiger Code vor dem Starten der App (z. B. Alembic - Sqlalchemy -Migrationen). Die Dokumentation für /app/prestart.sh befindet sich im Hauptread. PR #59.2019-05-04:
2019-02-02:
/app/nginx.conf -Datei, in der die generierte überschreibt. PR #51.2018-11-23: Neue Alpine 3.8 Bilder für Python 2.7, Python 3.6 und Python 3.7 (Python 3.7 vorübergehend deaktiviert). Vielen Dank an Philippfreyer in PR #45
2018-09-22: Neue Python 3.7-Versionen, Standard- und Alpinbasis. Vielen Dank an Desaintmartin in dieser PR.
2018-06-22: Sie können jetzt NGINX_WORKER_CONNECTIONS verwenden, um die maximale Anzahl von Nginx-Worker-Verbindungen und NGINX_WORKER_OPEN_FILES festzulegen, um die maximale Anzahl der geöffneten Dateien festzulegen. Vielen Dank an Ronlut in dieser PR.
2018-06-22: Machen Sie, dass UWSGI eine App ausführen muss, anstatt in "vollem dynamischem Modus" zu gehen, während ein Fehler vorliegt. Supervisford endet nicht selbst, sondern versucht, UWSGI neu zu starten, und zeigt die Fehler an. Verwendet need-app , wie von LuckyDonald in diesem Kommentar vorgeschlagen.
2018-06-22: Richtig behandelt die anmutige Abschaltung von UWSGI und Nginx. Vielen Dank an Desaintmartin in dieser PR.
2018-02-04: Es ist nun möglich, die Anzahl der Nginx-Arbeitsprozesse mit den Umgebungsvariablen NGINX_WORKER_PROCESSES festzulegen. Vielen Dank an Naktinis in dieser PR.
2018-01-14: Inzwischen gibt es zwei Alpinversionen, python2.7-alpine3.7 und python3.6-alpine3.7 .
2017-12-08: Jetzt können Sie konfigurieren, welchen Port der Container dank TMSHN in dieser PR mit der LISTEN_PORT sollte.
2017-08-09: Sie können eine 0 maximale Upload-Dateigröße mit einer Umgebungsvariablen NGINX_MAX_UPLOAD festlegen. Dies unterscheidet sich vom Standardwert von Nginx von 1 MB. Es ist auf diese Weise konfiguriert, da dies die einfachste Erfahrung ist, die ein Entwickler, der kein Experte für NGINX ist, erwarten würde.
2017-08-09: Jetzt können Sie überschreiben, wo Sie nach der Datei uwsgi.ini suchen und damit das Standardverzeichnis von /app in etwas anderes ändern können, wobei die Umwelt variable UWSGI_INI verwendet wird.
2017-08-08: Es gibt ein neues latest Tag-Image, nur um eine Warnung für diejenigen zu zeigen, die noch latest für Python 2.7-Webanwendungen verwenden. Ab sofort sollte jeder Python 3 verwenden.
2017-08-08: Supervisford beendet UWSGI jetzt auf SIGTERM . Wenn Sie also docker stop oder ähnliches ausführen, wird es tatsächlich alles stoppen, anstatt auf Dockers Zeitüberschreitung zu warten, um den Container zu töten.
2017-07-31: Es gibt jetzt ein Bild-Tag für Python 3.6, basierend auf dem offiziellen Bild für Python 3.6 dank JRD in dieser PR.
2016-10-01: Jetzt können Sie die Standard uwsgi.ini -Parameter aus der Datei in /app/uwsgi.ini überschreiben.
2016-08-16: Es gibt jetzt ein Bild-Tag für Python 3.5, basierend auf dem offiziellen Bild für Python 3.5. Jetzt können Sie dieses Bild für Ihre Projekte in Python 2.7 und Python 3.5 verwenden.
2016-08-16: Verwenden Sie dynamisch eine Reihe von Arbeitsprozessen für UWSGI, je nach Last von 2 bis 16. Dies sollte in den meisten Fällen funktionieren. Dies hilft besonders, wenn es einige Antworten gibt, die langsam sind und etwas Zeit in Anspruch nehmen, um zu generieren. Diese Änderung ermöglicht es allen anderen Antworten, schnell (in einem neuen Prozess) zu bleiben, ohne auf das erste (langsame) fertig zu werden.
Außerdem verwendet es jetzt eine Basis uwsgi.ini -Datei unter /etc/uwsgi/ mit den meisten allgemeinen Konfigurationen. Daher ist die uwsgi.ini in /app (die, die Sie ändern könnten) jetzt viel einfacher.
2016-04-05: Nginx- und UWSGI-Protokolle werden jetzt in STDOut umgeleitet, sodass docker logs verwendet werden können.
Dieses Projekt ist unter den Bestimmungen der Apache -Lizenz lizenziert.
