Dieses Docker -Bild ist jetzt veraltet. Es ist nicht erforderlich, es zu verwenden, Sie können nur Uvicorn verwenden --workers .
Lesen Sie unten mehr darüber.
Dockerfile -Linkspython3.11 , latest (Dockerfile)python3.10 , (Dockerfile)python3.9 , (Dockerfile)python3.11-slim (Dockerfile)python3.10-slim (Dockerfile)python3.9-slim (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-slimpython3.7python3.9-alpine3.14python3.8-alpine3.10python3.7-alpine3.8python3.6python3.6-alpine3.8Die letzten Datum -Tags für diese Versionen sind:
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 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/uvicorn-gunicorn-fastapi:python3.11-2024-11-02
Docker -Bild mit Uvicorn von Gunicorn für Hochleistungs- Fastapi- Webanwendungen in Python mit Performance Auto-Tuning.
Github Repo : https://github.com/tiangolo/uvicorn-gunicorn-fastapi-docker
Docker Hub Image : https://hub.docker.com/r/tiangolo/uvicorn-gunicorn-fastapi/
Fastapi hat sich als Python-Web-Framework mit einer der besten Leistungen erwiesen, gemessen anhand von Benchmarks von Drittanbietern, dank von Starlette basiert und angetrieben.
Die erreichbare Leistung entspricht (und in vielen Fällen überlegen) Go -and -Node.js -Frameworks.
Dieses Bild verfügt über einen automatischen Einstellungsmechanismus , um eine Reihe von Arbeitsprozessen basierend auf den verfügbaren CPU-Kernen zu starten. Auf diese Weise können Sie Ihren Code einfach hinzufügen und automatisch eine hohe Leistung erzielen, was bei einfachen Bereitstellungen nützlich ist.
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, wie in den Dokumenten für Fastapi in Containern - Docker: Erstellen Sie ein Docker -Bild für Fastapi.
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 (wie Gunicorn mit Uvicorn -Arbeitern) in jedem Container zu verwenden, was dieses Docker -Bild ist.
In diesen Fällen (z. B. mit Kubernetes) möchten Sie wahrscheinlich ein Docker -Bild von Grund auf erstellen, Ihre Abhängigkeiten installieren und einen einzelnen Uvicorn -Prozess anstelle dieses Bildes ausführen.
Zum Beispiel könnte Ihre Dockerfile so aussehen:
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" ]Weitere Informationen zu dieser Dokumentation in der Fastapi -Dokumentation finden Sie in Containern - Docker.
Wenn Sie auf jeden Fall mehrere Arbeiter in einem einzigen Behälter haben möchten, unterstützt Uvicorn jetzt die Umgang mit Subprozessen, einschließlich der Neustart von Toten. Es ist also nicht erforderlich, dass Gunicorn mehrere Arbeiter in einem einzigen Behälter verwaltet.
Sie können das Beispiel Dockerfile von oben ändern und uvicorn die Option --workers hinzufügen, wie:
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" ]Das ist alles was du brauchst. Sie brauchen dieses Docker -Bild überhaupt nicht. ?
Sie können mehr darüber in den Fastapi -Dokumenten über die Bereitstellung mit Docker lesen.
Uvicorn hatte keine Unterstützung für die Verwaltung der Arbeiterverarbeitung, einschließlich des Neustarts von Arbeitnehmern. Aber jetzt tut es das.
Zuvor kann Gunicorn als Prozessmanager verwendet werden, der Uvicorn -Arbeiter leitet. Diese zusätzliche Komplexität, die nicht mehr notwendig ist.
Der Rest dieses Dokuments wird aus historischen Gründen aufbewahrt, aber Sie brauchen es wahrscheinlich nicht. ?
tiangolo/uvicorn-gunicorn-fastapiDieses Bild setzt eine vernünftige Konfiguration basierend auf dem Server, auf dem es ausgeführt wird (die Anzahl der verfügbaren CPU -Kerne), ohne Opfer zu bringen.
Es verfügt über sinnvolle Standardeinstellungen, aber Sie können es mit Umgebungsvariablen konfigurieren oder die Konfigurationsdateien überschreiben.
Es gibt auch schlanke Versionen. Wenn Sie eines davon wollen, verwenden Sie eines der Tags von oben.
tiangolo/uvicorn-gunicorn Dieses Bild ( tiangolo/uvicorn-gunicorn-fastapi ) basiert auf Tiangolo/Uvicorn-Gunicorn .
Dieses Bild ist das, was tatsächlich die ganze Arbeit macht.
Dieses Bild installiert nur FASTAPI und verfügt über die Dokumentation, die speziell auf Fastapi abzielt.
Wenn Sie sich über Ihr Wissen über Uvicorn, Gunicorn und ASGI zuversichtlich fühlen, können Sie dieses Bild direkt verwenden.
tiangolo/uvicorn-gunicorn-starletteEs gibt ein Geschwister-Docker-Bild: Tiangolo/Uvicorn-Gunicorn-Starlette
Wenn Sie eine neue Starlette- Webanwendung erstellen und alle zusätzlichen Funktionen von Fastapi verwerfen möchten, sollten Sie stattdessen Tiangolo/Uvicorn-Gunicorn-Starlette verwenden.
Hinweis : Fastapi basiert auf Starlette und fügt dazu mehrere Funktionen hinzu. Nützlich für APIs und andere Fälle: Datenvalidierung, Datenumwandlung, Dokumentation mit OpenAPI, Abhängigkeitsinjektion, Sicherheit/Authentifizierung und andere.
Sie müssen das Github -Repo nicht klonen.
Sie können dieses Bild als Basisbild für andere Bilder verwenden.
Angenommen, Sie haben Dockerfile requirements.txt .
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 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 Fastapi -Anwendung enthält.
Anschließend können Sie Ihr Bild aus dem Verzeichnis erstellen, in dem Ihre Dockerfile zB:
docker build -t myimage ./Dockerfile mit: 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 -Verzeichnis und geben Sie es ein.main.py -Datei mit: 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 Ihr app -Verzeichnis enthalten).docker build -t myimage .docker run -d --name mycontainer -p 80:80 myimageJetzt haben Sie einen optimierten Fastapi -Server in einem Docker -Container. Automatisch abgestimmt für Ihren aktuellen Server (und die Anzahl der CPU-Kerne).
Sie sollten in der Lage sein, es in der URL Ihres Docker -Containers zu überprüfen, z.
Sie werden so etwas sehen wie:
{ "item_id" : 5 , "q" : " somequery " }Jetzt können Sie zu http://192.168.99.100/docs oder http://127.0.0.1/docs (oder gleichwertig mit Ihrem Docker -Host) gehen.
Sie sehen die automatische interaktive API -Dokumentation (bereitgestellt von der Swagger UI):
Und Sie können auch zu http://192.168.99.100/redoc oder http://127.0.0.1/redoc(or -Äquivalent mit Ihrem Docker -Host) gehen.
Sie sehen die alternative automatische Dokumentation (bereitgestellt von Redoc):
Sie möchten wahrscheinlich auch Abhängigkeiten für Ihre App hinzufügen und sie in eine bestimmte Version anpassen, einschließlich Uvicorn, Gunicorn und Fastapi.
Auf diese Weise können Sie sicherstellen, dass Ihre App immer wie erwartet funktioniert.
Sie können Pakete mit pip -Befehlen in Ihrer Dockerfile , mithilfe einer requirements.txt oder sogar mit Poesie installieren.
Und dann können Sie diese Abhängigkeiten auf kontrollierte Weise aktualisieren, Ihre Tests ausführen und sicherstellen, dass alles funktioniert, ohne jedoch Ihre Produktionsanwendung zu brechen, wenn eine neue Version nicht kompatibel ist.
Hier ist ein kleines Beispiel für eine der Möglichkeiten, wie Sie Ihre Abhängigkeiten installieren können, um sicherzustellen, dass Sie für jedes Paket eine angehaltene Version haben.
Nehmen wir an, Sie haben ein Projekt mit Gedichten verwaltet. Daher haben Sie Ihre Paketabhängigkeiten in einer Datei pyproject.toml . Und möglicherweise eine Datei poetry.lock .
Dann könnten Sie eine Dockerfile mit einem mehrstufigen Gebäude von Docker mit:
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 /appDas wird:
./poetry.lock* *Es ist wichtig, den App -Code nach der Installation der Abhängigkeiten zu kopieren. Auf diese Weise können Sie den Cache von Docker nutzen. Auf diese Weise muss es nicht jedes Mal, wenn Sie Ihre Anwendungsdateien aktualisieren, alles von Grund auf neu installieren, nur wenn Sie neue Abhängigkeiten hinzufügen.
Dies gilt auch für andere Möglichkeiten, wie Sie Ihre Abhängigkeiten installieren. Dockerfile Sie einen requirements.txt verwenden.
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 Anwendung 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 Fastapi -Anwendung enthält.
Standardmäßig:
appZum Beispiel, wenn Ihre Hauptpython -Datei so etwas wie folgt hat:
from fastapi import FastAPI
api = FastAPI ()
@ api . get ( "/" )
def read_root ():
return { "Hello" : "World" } In diesem Fall wäre api die Variable mit der Fastapi -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 " myimageSie können die Konfigurationsdatei vom Basisbild als Ausgangspunkt für Ihre verwenden.
WORKERS_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:
1Sie 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 haben (sagen wir mit 8 CPU -Kernen), die mehrere Anwendungen ausführen, und Sie eine Fastapi -Anwendung haben, 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.
HINWEIS : Wenn WORKERS_PER_CORE standardmäßig 1 ist und der Server nur 1 CPU -Kern verfügt, startet er anstatt 1 einzelne Arbeiter zu starten. Dies wird 2. Dies dient dazu, schlechte Leistung und Blockierung von Anwendungen (Serveranwendung) auf kleinen Maschinen (Servermaschine/Cloud/usw.) zu vermeiden. Dies kann mit WEB_CONCURRENCY überschrieben werden.
MAX_WORKERSStellen Sie die maximale Anzahl von Arbeitnehmern ein.
Sie können es verwenden, um das Bild die Anzahl der Arbeitnehmer automatisch zu berechnen, aber sicherstellen, dass es auf ein Maximum beschränkt ist.
Dies kann beispielsweise nützlich sein, wenn jeder Arbeiter eine Datenbankverbindung verwendet und Ihre Datenbank eine maximale Grenze für offene Verbindungen hat.
Standardmäßig ist es nicht festgelegt, was bedeutet, dass es unbegrenzt ist.
Sie können es so einstellen wie:
docker run -d -p 80:80 -e MAX_WORKERS= " 24 " myimageDies würde das Bild bei den meisten 24 Arbeitern beginnen, unabhängig davon, wie viele CPU -Kerne auf dem Server verfügbar sind.
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 2 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 " myimageWORKER_CLASSDie Klasse, die von Gunicorn für die Arbeiter verwendet werden soll.
Standardmäßig auf uvicorn.workers.UvicornWorker festgelegt.
Die Tatsache, dass es Uvicorn verwendet, ermöglicht die Verwendung von ASGI -Frameworks wie Fastapi, und das bietet auch die maximale Leistung.
Sie sollten es wahrscheinlich nicht ändern.
Aber wenn Sie aus irgendeinem Grund den alternativen Uvicorn -Arbeiter verwenden müssen: uvicorn.workers.UvicornH11Worker können Sie diese mit dieser Umgebungsvariablen festlegen.
Sie können es so einstellen wie:
docker run -d -p 80:8080 -e WORKER_CLASS= " uvicorn.workers.UvicornH11Worker " myimageTIMEOUTDie Arbeiter schweigen mehr als so viele Sekunden, die getötet und neu gestartet werden.
Lesen Sie mehr darüber in den Gunicorn -Dokumenten: Timeout.
Standardmäßig auf 120 festgelegt.
Beachten Sie, dass Uvicorn- und ASGI -Frameworks wie Fastapi asynchron sind und nicht synchronisiert sind. Es ist also wahrscheinlich sicher, höhere Zeitüberschreitungen zu haben als bei Synchronisierungsarbeitern.
Sie können es so einstellen wie:
docker run -d -p 80:8080 -e TIMEOUT= " 20 " myimageKEEP_ALIVEDie Anzahl der Sekunden, um auf Anfragen auf eine Keep-Alive-Verbindung zu warten.
Lesen Sie mehr darüber im Gunicorn Docs: Keepalive.
Standardmäßig auf 2 festgelegt.
Sie können es so einstellen wie:
docker run -d -p 80:8080 -e KEEP_ALIVE= " 20 " myimageGRACEFUL_TIMEOUTZeitüberschreitung für anmutige Arbeiter neu starten.
Lesen Sie mehr darüber in den Gunicorn-Dokumenten: Anmut.
Standardmäßig auf 120 festgelegt.
Sie können es so einstellen wie:
docker run -d -p 80:8080 -e GRACEFUL_TIMEOUT= " 20 " myimageACCESS_LOGDie zu schreiben zu schreiben.
Standardmäßig "-" , was StDout bedeutet (Druck in den Docker-Protokollen).
Wenn Sie ACCESS_LOG deaktivieren möchten, stellen Sie es auf einen leeren Wert ein.
Zum Beispiel können Sie es mit:
docker run -d -p 80:8080 -e ACCESS_LOG= myimageERROR_LOGDie Fehlerprotokolldatei zu schreiben.
Standardmäßig "-" , was Stderr (Druck in den Docker-Protokollen) bedeutet.
Wenn Sie ERROR_LOG deaktivieren möchten, stellen Sie ihn auf einen leeren Wert ein.
Zum Beispiel können Sie es mit:
docker run -d -p 80:8080 -e ERROR_LOG= myimageGUNICORN_CMD_ARGS Alle zusätzlichen Befehlszeileneinstellungen für Gunicorn können in der Umgebungsvariablen GUNICORN_CMD_ARGS übergeben werden.
Lesen Sie mehr darüber in den Gunicorn -Dokumenten: Einstellungen.
Diese Einstellungen haben Vorrang vor den anderen Umgebungsvariablen und jeder Gunicorn -Konfigurationsdatei.
Wenn Sie beispielsweise ein benutzerdefiniertes TLS/SSL -Zertifikat haben, das Sie verwenden möchten, können Sie diese in das Docker -Bild kopieren oder im Container montieren und festlegen --keyfile und --certfile zum Ort der Dateien, zum Beispiel:
docker run -d -p 80:8080 -e GUNICORN_CMD_ARGS= " --keyfile=/secrets/key.pem --certfile=/secrets/cert.pem " -e PORT=443 myimageHinweis : Anstatt TLS/SSL selbst zu handhaben und es im Container zu konfigurieren, wird empfohlen, einen "TLS -Termination -Proxy" wie Traefik zu verwenden. Sie können mehr darüber in der Fastapi -Dokumentation zu HTTPS erfahren.
PRE_START_PATHDer Pfad, in dem das Skript vor dem Start findet.
Standardmäßig auf /app/prestart.sh festlegen.
Sie können es so einstellen wie:
docker run -d -p 80:8080 -e PRE_START_PATH= " /custom/script.sh " myimage 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 Sie können den Standort des Prestart -Skripts mit der oben beschriebenen Umgebungsvariablen PRE_START_PATH anpassen.
Das Standardprogramm, das ausgeführt wird, ist at /start.sh . Es macht alles oben beschrieben.
Es gibt auch eine Version für die Entwicklung mit Live-Auto-Reload unter:
/start-reload.shFür die Entwicklung ist es nützlich, den Inhalt des Anwendungscode im Container als Docker -Hostvolumen zu montieren, um den Code zu ändern und live zu testen, ohne das Bild jedes Mal erstellen zu müssen.
In diesem Fall ist es auch nützlich, den Server mit Live-Auto-Reload auszuführen, damit er bei jeder Codeänderung automatisch neu gestartet wird.
Das zusätzliche Skript /start-reload.sh führt Uvicorn allein (ohne Gunicorn) und in einem einzigen Prozess aus.
Es ist ideal für die Entwicklung.
Zum Beispiel anstatt zu laufen:
docker run -d -p 80:80 myimageSie könnten rennen:
docker run -d -p 80:80 -v $( pwd ) :/app myimage /start-reload.sh-v $(pwd):/app : bedeutet, dass das Verzeichnis $(pwd) als Volumen innerhalb des Containers AT /app montiert werden sollte.$(pwd) : Läuft pwd ("Print Working Directory") und setzt es als Teil der Zeichenfolge./start-reload.sh : Etwas (wie /start-reload.sh ) am Ende des Befehls hinzufügen, ersetzt den Standard-Befehl "" Befehl "durch diesen. In diesem Fall ersetzt es den Standard ( /start.sh ) durch die Entwicklungsalternative /start-reload.sh . As /start-reload.sh läuft nicht mit Gunicorn, und eine der Konfigurationen, die Sie in einer Datei gunicorn_conf.py einfügen, wird nicht gelten.
Diese Umgebungsvariablen funktionieren jedoch genauso wie oben beschrieben:
MODULE_NAMEVARIABLE_NAMEAPP_MODULEHOSTPORTLOG_LEVEL 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.
--workers . PR #303 von @tiangolo.issue-manager.yml . PR #343 von @tiangolo.latest-changes GitHub-Aktionen. PR #340 von @tiangolo.latest-changes.yml . PR #276 von @alejsdev.README.md . PR #275 von @alejsdev.README.md . PR #274 von @alejsdev. Highlights dieser Veröffentlichung:
python3.6-2022-11-25 .slim Version hinzu. PR #40.WORKER_CLASSTIMEOUTKEEP_ALIVEGRACEFUL_TIMEOUTACCESS_LOGERROR_LOGGUNICORN_CMD_ARGSMAX_WORKERSPRE_START_PATH env var hinzu. PR #33.tiangolo/uvicorn-gunicorn-fastapi:python3.7-2019-10-15 . PR #17./start-reload.sh hinzu, und überprüfen Sie die aktualisierte Dokumentation. PR #6 im übergeordneten Bild.WORKERS_PER_CORE auf 1 , da es zeigt, dass sie die beste Leistung für Benchmarks haben.WEB_CONCURRENCY nicht auf mindestens 2 Arbeiter festgelegt ist. Dies soll schlechte Leistung und Blockierung von Anwendungen (Serveranwendung) auf kleinen Maschinen (Servermaschine/Cloud/etc) vermeiden. Dies kann mit WEB_CONCURRENCY überschrieben werden. Dies gilt beispielsweise in dem Fall, in dem WORKERS_PER_CORE auf 1 (Standard) gesetzt ist und der Server nur 1 CPU -Kern hat. PR #6 und PR #5 im übergeordneten Bild./start.sh unabhängig rennen, lesen und generieren Sie verwendete Standardumgebungsvariablen. Und entfernen /entrypoint.sh , da es im System nichts ändert, liest nur Umgebungsvariablen. PR #4 im übergeordneten Bild./app/prestart.sh hinzu. Dieses Projekt ist gemäß den Bedingungen der MIT -Lizenz lizenziert.