meinheld gunicorn flask docker
0.5.0
Dockerfile -Linkspython3.9 , latest (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.9-alpine3.13python3.8python3.8-alpine3.11python3.7python3.7-alpine3.8python3.6python3.6-alpine3.8python2.7Die letzten Datum -Tags für diese Versionen sind:
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 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/meinheld-gunicorn-flask:python3.9-2024-11-02
Docker -Bild mit Meinheld von Gunicorn für Hochleistungs-Webanwendungen im Flask mit Python mit Performance Auto-Tuning verwaltet.
Github Repo : https://github.com/tiangolo/meinheld-gunicorn-flask-docker
Docker Hub Image : https://hub.docker.com/r/tiangolo/meinheld-gunicorn-flask/
Python Flask -Webanwendungen, die mit Meinheld von Gunicorn kontrolliert werden, haben einige der besten Leistungen, die von Flask (*) erreicht werden können.
Wenn Sie eine bereits vorhandene Anwendung in Flask haben oder eine neue erstellen, bietet Ihnen dieses Bild die bestmögliche Leistung (oder in der Nähe).
Dieses Bild enthält einen "automatischen Abtun" -Mechanismus, sodass Sie Ihren Code einfach hinzufügen und automatisch eine gute Leistung erzielen können. Und ohne Opfer zu bringen (wie Protokollierung).
Die aktuelle neueste Version von Meinheld ist vom 17. Mai 2020 1.0.2. Diese Version von Meinheld erfordert eine alte Version von Greenlet ( >=0.4.5,<0.5 ), die nicht mit Python 3.10 und 3.11 kompatibel ist. Deshalb ist die neueste Version von Python, die in diesem Bild unterstützt wird, Python 3.9.
Wenn Sie ein neues Projekt starten, können Sie von einem neueren und schnelleren Rahmen wie Fastapi (basierend auf ASGI anstelle von WSGI wie Flask und Django) und einem Docker-Bild wie Tiangolo/Uvicorn-Gunicorn-Fastapi profitieren.
Es würde Ihnen etwa 200% der Leistung mit Flask erhalten, auch wenn Sie dieses Bild verwenden.
Wenn Sie neue Technologien wie WebSockets verwenden möchten, wäre dies bei einem neueren Framework, der auf ASGI basiert, wie Fastapi . Da der Standard -ASGI so konzipiert wurde, dass sie asynchrone Code wie den für Websockets benötigten Code verarbeiten können.
Meinheld ist ein leistungsstarker WSGI-konformer Webserver.
Sie können mit Gunicorn Meinheld verwalten und mehrere Prozesse davon durchführen.
Flask ist ein Mikroframework für Python, das auf Werkzug, Jinja 2 und guten Absichten basiert.
Dieses Bild wurde als Alternative zu Tiangolo/UWSGI-Nginx-Flask erstellt, was etwa 400% der Leistung dieses Bildes liefert.
Es basiert auf dem generischeren Bild Tiangolo/Meinheld-Gunicorn . Das ist diejenige, die Sie für andere WSGI -Frameworks wie Django verwenden würden.
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/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 Es wird eine Datei mit /app/app/main.py erwarten.
Oder anderweitig eine Datei at /app/main.py .
Und erwartet, dass es eine variable app mit Ihrer "WSGI" -Anwendung enthält.
Anschließend können Sie Ihr Bild aus dem Verzeichnis erstellen, in dem Ihre Dockerfile zB:
docker build -t myimage ./Dies sind die Umgebungsvariablen, die Sie im Container einstellen können, um sie und deren Standardwerte zu konfigurieren:
MODULE_NAMEDas Python "Modul" (Datei), das von Gunicorn importiert werden soll, würde dieses Modul die tatsächliche Kolbenanwendung in einer Variablen enthalten.
Standardmäßig:
app.main , wenn es eine Datei /app/app/main.py gibt odermain , wenn es eine Datei /app/main.py gibt Wenn Ihre Hauptdatei beispielsweise unter /app/custom_app/custom_main.py custom_main.py stattfand, können Sie sie feststellen, wie:
docker run -d -p 80:80 -e MODULE_NAME= " custom_app.custom_main " myimageVARIABLE_NAMEDie Variable innerhalb des Python -Moduls, das die Kolbenanwendung enthält.
Standardmäßig:
appZum Beispiel, wenn Ihre Hauptpython -Datei so etwas wie folgt hat:
from flask import Flask
api = Flask ( __name__ )
@ api . route ( "/" )
def hello ():
return "Hello World from Flask" In diesem Fall wäre api die Variable mit der "Flask -Anwendung". Sie könnten es so einstellen wie:
docker run -d -p 80:80 -e VARIABLE_NAME= " api " myimageAPP_MODULEDie Zeichenfolge mit dem Python -Modul und dem variablen Namen übergeben an Gunicorn.
Standardmäßig festlegen basierend auf den Variablen MODULE_NAME und VARIABLE_NAME :
app.main:app odermain:appSie können es so einstellen wie:
docker run -d -p 80:80 -e APP_MODULE= " custom_app.custom_main:api " myimageGUNICORN_CONFDer Pfad zu einer Gunicorn -Python -Konfigurationsdatei.
Standardmäßig:
/app/gunicorn_conf.py Wenn es existiert/app/app/gunicorn_conf.py Wenn es existiert/gunicorn_conf.py (der enthaltene Standard)Sie können es so einstellen wie:
docker run -d -p 80:80 -e GUNICORN_CONF= " /app/custom_gunicorn_conf.py " myimageWORKERS_PER_COREIn diesem Bild werden überprüft, wie viele CPU -Kerne auf dem aktuellen Server verfügbar sind, der Ihren Container ausführt.
Es wird die Anzahl der Arbeiter auf die Anzahl der CPU -Kerne multipliziert mit diesem Wert festlegen.
Standardmäßig:
2Sie können es so einstellen wie:
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 3 " myimage Wenn Sie den Wert 3 in einem Server mit 2 CPU -Kernen verwenden, werden 6 Arbeitsprozesse ausgeführt.
Sie können auch schwimmende Punktwerte verwenden.
Wenn Sie beispielsweise einen großen Server (sagen wir mit 8 CPU -Kernen), ausführen, werden mehrere Anwendungen ausgeführt, und Sie haben eine ASGI -Anwendung, von der Sie wissen, dass sie keine hohe Leistung benötigt. Und Sie möchten keine Serverressourcen verschwenden. Sie können es dazu bringen, 0.5 Arbeiter pro CPU -Kern zu verwenden. Zum Beispiel:
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 0.5 " myimageIn einem Server mit 8 CPU -Kernen würde dies nur 4 Arbeitsprozesse starten.
WEB_CONCURRENCYÜberschreiben Sie die automatische Definition der Anzahl der Arbeitnehmer.
Standardmäßig:
WORKERS_PER_CORE . In einem Server mit 2 Kernen wird er standardmäßig auf 4 gesetzt.Sie können es so einstellen wie:
docker run -d -p 80:80 -e WEB_CONCURRENCY= " 2 " myimageDadurch würde das Bild 2 Worker -Prozesse starten, unabhängig davon, wie viele CPU -Kerne auf dem Server verfügbar sind.
HOSTDer "Host" von Gunicorn, dem IP, bei dem Gunicorn auf Anfragen zuhört, wird verwendet.
Es ist der Host im Container.
Wenn Sie diese Variable beispielsweise auf 127.0.0.1 festlegen, ist sie nur im Container erhältlich, nicht im Host.
Es wird für die Vollständigkeit bereitgestellt, aber Sie sollten es wahrscheinlich nicht ändern.
Standardmäßig:
0.0.0.0PORTDer Port, den der Container anhören sollte.
Wenn Sie Ihren Container in einer restriktiven Umgebung ausführen, die Sie dazu zwingt, einen bestimmten Port (wie 8080 ) zu verwenden, können Sie ihn mit dieser Variablen festlegen.
Standardmäßig:
80Sie können es so einstellen wie:
docker run -d -p 80:8080 -e PORT= " 8080 " myimageBINDDer eigentliche Gastgeber und der Hafen gingen an Gunicorn.
Standardmäßig setzen Sie basierend auf dem Variablen HOST und PORT .
Wenn Sie also nichts geändert haben, wird es standardmäßig festgelegt auf:
0.0.0.0:80Sie können es so einstellen wie:
docker run -d -p 80:8080 -e BIND= " 0.0.0.0:8080 " myimageLOG_LEVELDas Protokollniveau für Gunicorn.
Einer von:
debuginfowarningerrorcritical Setzen Sie standardmäßig auf info .
Wenn Sie mehr Leistungsopfer der Protokollierung drücken müssen, stellen Sie sie beispielsweise auf warning ein:
Sie können es so einstellen wie:
docker run -d -p 80:8080 -e LOG_LEVEL= " warning " myimage Protokolle werden an die stderr und stdout des Containers gesendet, dh Sie können die Protokolle mit dem Befehl docker logs -f your_container_name_here anzeigen.
Das Bild enthält eine Standard -Gunicorn -Python -Konfigurationsdatei unter /gunicorn_conf.py .
Es verwendet die oben deklarierten Umgebungsvariablen, um alle Konfigurationen festzulegen.
Sie können es überschreiben, indem Sie eine Datei in:
/app/gunicorn_conf.py/app/app/gunicorn_conf.py/gunicorn_conf.py/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 alembische SQL -Migrationen (mit SQLAlchemy) hinzufügen möchten, können Sie in Ihrem Code Dockerfile eine ./app/prestart.sh .
#! /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.
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 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.
issue-manager.yml . PR #154 von @tiangolo.latest-changes GitHub-Aktionen. PR #153 von @tiangolo.latest-changes.yml . PR #141 von @alejsdev.README.md . PR #137 von @alejsdev. Highlights dieser Veröffentlichung:
Unterstützung für Python 3.9 und 3.8.
Abwertung von Python 3.6 und 2.7.
python3.6-2022-11-25 und python2.7-2022-11-25 .Verbesserte Versionen aller Abhängigkeiten.
Kleine Verbesserungen und Korrekturen.
Fügen Sie Unterstützung für Python 3.9 und Python 3.9 Alpine hinzu. PR #50 von @tiangolo.
Fügen Sie Python 3.8 mit Alpine 3.11 hinzu. PR #28.
Fügen Sie Unterstützung für Python 3.8 hinzu. PR #27.
tiangolo/meinheld-gunicorn-flask:python3.7-2019-10-15 PR #17.Fügen Sie Unterstützung für Python 2.7 hinzu (Sie sollten Python 3.7 oder Python 3.6 verwenden). PR #11.
Aktualisieren Sie die Travis CI -Konfiguration. PR #10 von @cclauss.
/app/prestart.sh hinzu. Dieses Projekt ist gemäß den Bedingungen der MIT -Lizenz lizenziert.
