uvicorn gunicorn docker
0.8.0
Cette image Docker est désormais obsolète. Il n'est pas nécessaire de l'utiliser, vous pouvez simplement utiliser Uvicorn avec --workers .
En savoir plus à ce sujet ci-dessous.
Dockerfile respectifspython3.11 , latest (dockerfile)python3.10 , (dockerfile)python3.9 , (dockerfile)python3.11-slim (dockerfile)python3.10-slim (dockerfile)python3.9-slim (dockerfile) Ces balises ne sont plus prises en charge ou entretenues, elles sont supprimées du référentiel GitHub, mais les dernières versions poussées pourraient toujours être disponibles dans Docker Hub si quelqu'un les tire:
python3.9-alpine3.14python3.8python3.8-slimpython3.8-alpine3.10python3.7python3.7-alpine3.8python3.6python3.6-alpine3.8Les étiquettes de dernière date pour ces versions sont:
python3.9-alpine3.14-2024-03-11python3.8-2024-11-02python3.8-slim-2024-11-02python3.8-alpine3.10-2024-03-11python3.7-2024-11-02python3.7-alpine3.8-2024-03-11python3.6-2022-11-25python3.6-alpine3.8-2022-11-25 Remarque : il y a des balises pour chaque date de construction. Si vous devez "épingler" la version Docker Image que vous utilisez, vous pouvez sélectionner l'une de ces balises. Par exemple tiangolo/uvicorn-gunicorn:python3.11-2024-11-02 .
Image Docker avec Uvicorn gérée par Gunicorn pour des applications Web haute performance en Python avec des performances automatique.
Github Repo : https://github.com/tiangolo/uvicorn-gunicorn-docker
Docker Hub Image : https://hub.docker.com/r/tiangolo/uvicorn-gunicorn/
Les applications Web Python exécutées avec Uvicorn (en utilisant la spécification "ASGI" pour les applications Web asynchrones Python) ont montré que certaines des meilleures performances, telles que mesurées par des repères tiers.
La performance réalisable est à égalité avec (et dans de nombreux cas supérieure à) go et les cadres Node.js.
Cette image a un mécanisme de réglage automatique inclus pour démarrer un certain nombre de processus de travailleurs en fonction des noyaux CPU disponibles. De cette façon, vous pouvez simplement ajouter votre code et obtenir automatiquement des performances , ce qui est utile dans les déploiements simples .
Vous utilisez probablement des kubernetes ou des outils similaires. Dans ce cas, vous n'avez probablement pas besoin de cette image (ou de toute autre image de base similaire ). Vous feriez probablement mieux de construire une image Docker à partir de zéro, comme expliqué dans les documents pour Fastapi dans les conteneurs - Docker: construire une image Docker pour Fastapi, ce même processus et même idées pourraient être appliqués à d'autres frameworks ASGI.
Si vous avez un groupe de machines avec Kubernetes , Mode Swarm Docker, Nomad ou autre système complexe similaire pour gérer des conteneurs distribués sur plusieurs machines, vous voudrez probablement gérer la réplication au niveau du cluster au lieu d'utiliser un gestionnaire de processus (comme Gunicorn avec des travailleurs Uvicorn) dans chaque conteneur, ce qui est ce que cette image Docker fait.
Dans ces cas (par exemple, à l'aide de Kubernetes), vous voudriez probablement construire une image Docker à partir de zéro , installer vos dépendances et exécuter un seul processus d'uvicorne au lieu de cette image.
Par exemple, votre Dockerfile pourrait ressembler:
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" ]Vous pouvez en savoir plus à ce sujet dans la documentation FastAPI sur: Fastapi dans les conteneurs - Docker comme les mêmes idées s'appliqueraient à d'autres frameworks ASGI.
Si vous voulez vraiment avoir plusieurs travailleurs sur un seul conteneur, Uvicorn prend désormais en charge la gestion des sous-processus, y compris le redémarrage de ceux morts. Il n'est donc pas nécessaire que Gunicorn gére plusieurs travailleurs dans un seul conteneur.
Vous pouvez modifier l'exemple Dockerfile d'en haut, en ajoutant l'option --workers à Uvicorn, comme:
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" ]C'est tout ce dont vous avez besoin. Vous n'avez pas du tout besoin de cette image Docker. ?
Vous pouvez en savoir plus à ce sujet dans les documents Fastapi sur le déploiement avec Docker.
Uvicorn n'avait pas de soutien à la gestion du traitement des travailleurs, y compris le redémarrage des travailleurs morts. Mais maintenant c'est le cas.
Avant cela, Gunicorn pourrait être utilisé comme gestionnaire de processus, dirigeant des travailleurs d'Uvicorn. Cette complexité supplémentaire qui n'est plus nécessaire.
Le reste de ce document est conservé pour des raisons historiques, mais vous n'en avez probablement pas besoin. ?
tiangolo/uvicorn-gunicornCette image définira une configuration raisonnable en fonction du serveur sur lequel il fonctionne (la quantité de cœurs CPU disponibles) sans faire de sacrifices.
Il a des paramètres raisonnables, mais vous pouvez le configurer avec des variables d'environnement ou remplacer les fichiers de configuration.
Il existe également une version mince. Si vous en voulez un, utilisez l'une des balises d'en haut.
Cette image a été créée pour être l'image de base pour:
Mais pourrait être utilisé comme image de base pour exécuter n'importe quelle application Web Python qui utilise la spécification ASGI.
Si vous créez une nouvelle application Web Starlette , vous devez utiliser Tiangolo / Uvicorn-Gunicorn-Starlette .
Si vous créez une nouvelle application Web Fastapi , vous devez utiliser Tiangolo / Uvicorn-Gunicorn-Fastapi à la place.
Remarque : Fastapi est basé sur Starlette et ajoute plusieurs fonctionnalités dessus. Utile pour les API et autres cas: validation des données, conversion des données, documentation avec OpenAPI, injection de dépendance, sécurité / authentification et autres.
Remarque : à moins que vous ne fassiez quelque chose de plus avancé techniquement, vous devriez probablement utiliser Starlette avec Tiangolo / Uvicorn-Gunicorn-Starlette ou Fastapi avec Tiangolo / Uvicorn-Gunicorn-Fastapi .
Vous n'avez pas besoin de cloner le repo GitHub.
Vous pouvez utiliser cette image comme image de base pour d'autres images.
En supposant que vous avez un fichier requirements.txt , vous pouvez avoir un Dockerfile comme celui-ci:
FROM tiangolo/uvicorn-gunicorn:python3.11
COPY ./requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /app Il s'attendra à un fichier sur /app/app/main.py .
Ou autrement un fichier sur /app/main.py .
Et s'attendra à ce qu'il contienne une app variable avec votre application "ASGI".
Ensuite, vous pouvez créer votre image à partir du répertoire qui a votre Dockerfile , par exemple:
docker build -t myimage ./docker run -d --name mycontainer -p 80:80 myimageVous devriez pouvoir le vérifier dans l'URL de votre conteneur Docker, par exemple: http://192.168.99.100/ ou http://127.0.0.1/ (ou équivalent, en utilisant votre hôte Docker).
Vous voudrez probablement également ajouter des dépendances pour votre application et les épingler à une version spécifique, y compris probablement Uvicorn et Gunicorn.
De cette façon, vous pouvez vous assurer que votre application fonctionne toujours comme prévu.
Vous pouvez installer des packages avec des commandes pip dans votre Dockerfile , en utilisant un requirements.txt , ou même en utilisant de la poésie.
Et puis vous pouvez mettre à niveau ces dépendances de manière contrôlée, en exécutant vos tests, en vous assurant que tout fonctionne, mais sans casser votre application de production si une nouvelle version n'est pas compatible.
Voici un petit exemple de l'une des façons d'installer vos dépendances en vous assurant d'avoir une version épinglée pour chaque package.
Supposons que vous ayez un projet géré avec la poésie, vous avez donc vos dépendances de package dans un fichier pyproject.toml . Et peut-être un fichier poetry.lock .
Ensuite, vous pourriez avoir un Dockerfile en utilisant le bâtiment Docker en plusieurs étapes avec:
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: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 /appQui le fera:
./poetry.lock* (se terminant par A * ), il ne se bloquera pas si ce fichier n'est pas encore disponible.Il est important de copier le code d'application après l'installation des dépendances, de cette façon, vous pouvez profiter du cache de Docker. De cette façon, il n'aura pas à tout installer à partir de zéro chaque fois que vous mettez à jour vos fichiers d'application, uniquement lorsque vous ajoutez de nouvelles dépendances.
Cela s'applique également à toute autre manière que vous utilisez pour installer vos dépendances. Si vous utilisez un requirements.txt , copiez-le seul et installez toutes les dépendances en haut du Dockerfile et ajoutez votre code d'application après.
Ce sont les variables d'environnement que vous pouvez définir dans le conteneur pour le configurer et leurs valeurs par défaut:
MODULE_NAMELe "module" (fichier "Python à importer par Gunicorn, ce module contiendrait l'application réelle dans une variable.
Par défaut:
app.main s'il y a un fichier /app/app/main.py oumain s'il y a un fichier /app/main.py Par exemple, si votre fichier principal était sur /app/custom_app/custom_main.py , vous pouvez le définir comme:
docker run -d -p 80:80 -e MODULE_NAME= " custom_app.custom_main " myimageVARIABLE_NAMELa variable à l'intérieur du module Python qui contient l'application ASGI.
Par défaut:
appPar exemple, si votre fichier Python principal a quelque chose comme:
from fastapi import FastAPI
api = FastAPI ()
@ api . get ( "/" )
def read_root ():
return { "message" : "Hello world!" } Dans ce cas, api serait la variable avec "l'application ASGI". Vous pouvez le définir comme:
docker run -d -p 80:80 -e VARIABLE_NAME= " api " myimageAPP_MODULELa chaîne avec le module Python et le nom de variable passaient à Gunicorn.
Par défaut, défini basé sur les variables MODULE_NAME et VARIABLE_NAME :
app.main:app oumain:appVous pouvez le définir comme:
docker run -d -p 80:80 -e APP_MODULE= " custom_app.custom_main:api " myimageGUNICORN_CONFLe chemin vers un fichier de configuration de Python Gunicorn.
Par défaut:
/app/gunicorn_conf.py s'il existe/app/app/gunicorn_conf.py s'il existe/gunicorn_conf.py (la valeur par défaut incluse)Vous pouvez le définir comme:
docker run -d -p 80:80 -e GUNICORN_CONF= " /app/custom_gunicorn_conf.py " myimageVous pouvez utiliser le fichier de configuration à partir de cette image comme point de départ pour le vôtre.
WORKERS_PER_CORECette image vérifiera le nombre de cœurs CPU disponibles dans le serveur actuel exécutant votre conteneur.
Il définira le nombre de travailleurs sur le nombre de cœurs CPU multipliés par cette valeur.
Par défaut:
1Vous pouvez le définir comme:
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 3 " myimage Si vous avez utilisé la valeur 3 dans un serveur avec 2 cœurs CPU, il exécuterait 6 processus de travail.
Vous pouvez également utiliser des valeurs de points flottants.
Ainsi, par exemple, si vous avez un grand serveur (disons, avec 8 cœurs de processeur) exécutant plusieurs applications, et vous avez une application ASGI qui, vous savez, n'aura pas besoin de performances élevées. Et vous ne voulez pas gaspiller les ressources du serveur. Vous pouvez le faire utiliser 0.5 travailleurs par noyau CPU. Par exemple:
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 0.5 " myimageDans un serveur avec 8 cœurs CPU, cela ne ferait démarrer que 4 processus de travail.
Remarque : Par défaut, si WORKERS_PER_CORE est 1 et que le serveur n'a que 1 noyau CPU, au lieu de démarrer 1 travailleur unique, il commencera 2. Ceci pour éviter les mauvaises performances et le blocage des applications (application du serveur) sur de petites machines (machine de serveur / cloud / etc). Cela peut être remplacé à l'aide WEB_CONCURRENCY .
MAX_WORKERSDéfinissez le nombre maximum de travailleurs à utiliser.
Vous pouvez l'utiliser pour permettre à l'image de calculer automatiquement le nombre de travailleurs, mais en vous assurant qu'elle est limitée à un maximum.
Cela peut être utile, par exemple, si chaque travailleur utilise une connexion de base de données et que votre base de données a une limite maximale de connexions ouvertes.
Par défaut, il n'est pas défini, ce qui signifie qu'il est illimité.
Vous pouvez le définir comme:
docker run -d -p 80:80 -e MAX_WORKERS= " 24 " myimageCela rendrait l'image à démarrer au plus 24 travailleurs, indépendamment du nombre de cœurs CPU disponibles dans le serveur.
WEB_CONCURRENCYRemplacez la définition automatique du nombre de travailleurs.
Par défaut:
WORKERS_PER_CORE . Ainsi, dans un serveur avec 2 cœurs, par défaut, il sera défini sur 2 .Vous pouvez le définir comme:
docker run -d -p 80:80 -e WEB_CONCURRENCY= " 2 " myimageCela rendrait l'image à démarrer 2 processus de travail, indépendamment du nombre de cœurs de processeur disponibles dans le serveur.
HOSTL'hôte utilisé par Gunicorn, l'IP où Gunicorn écoutera les demandes.
C'est l'hôte à l'intérieur du conteneur.
Ainsi, par exemple, si vous définissez cette variable sur 127.0.0.1 , elle ne sera disponible que dans le conteneur, pas dans l'hôte qui l'exécute.
Il est prévu pour l'exhaustivité, mais vous ne devriez probablement pas le changer.
Par défaut:
0.0.0.0PORTLe port sur lequel le conteneur doit écouter.
Si vous exécutez votre conteneur dans un environnement restrictif qui vous oblige à utiliser un port spécifique (comme 8080 ), vous pouvez le définir avec cette variable.
Par défaut:
80Vous pouvez le définir comme:
docker run -d -p 80:8080 -e PORT= " 8080 " myimageBINDL'hôte et le port réels sont passés à Gunicorn.
Par défaut, défini basé sur HOST et PORT variables.
Donc, si vous n'avez rien changé, il sera défini par défaut sur:
0.0.0.0:80Vous pouvez le définir comme:
docker run -d -p 80:8080 -e BIND= " 0.0.0.0:8080 " myimageLOG_LEVELLe niveau de journal pour Gunicorn.
Un des:
debuginfowarningerrorcritical Par défaut, défini sur info .
Si vous avez besoin de presser plus de performances sacrifiant la journalisation, définissez-la dans warning , par exemple:
Vous pouvez le définir comme:
docker run -d -p 80:8080 -e LOG_LEVEL= " warning " myimageWORKER_CLASSLa classe à utiliser par Gunicorn pour les travailleurs.
Par défaut, défini sur uvicorn.workers.UvicornWorker .
Le fait qu'il utilise Uvicorn est ce qui permet d'utiliser des applications ASGI comme Fastapi et Starlette, et c'est aussi ce qui fournit les performances maximales.
Vous ne devriez probablement pas le changer.
Mais si, pour une raison quelconque, vous devez utiliser l'ouvrier alternatif d'Uvicorn: uvicorn.workers.UvicornH11Worker vous pouvez le définir avec cette variable d'environnement.
Vous pouvez le définir comme:
docker run -d -p 80:8080 -e WORKER_CLASS= " uvicorn.workers.UvicornH11Worker " myimageTIMEOUTLes travailleurs silencieux pendant plus que ces nombreuses secondes sont tués et redémarrés.
En savoir plus à ce sujet dans les Docs Gunicorn: Timeout.
Par défaut, réglé sur 120 .
Notez que les cadres Uvicorn et ASGI comme Fastapi et Starlette sont asynchronisés, pas synchronisés. Il est donc probablement sûr d'avoir des délais d'attente plus élevés que pour les travailleurs de la synchronisation.
Vous pouvez le définir comme:
docker run -d -p 80:8080 -e TIMEOUT= " 20 " myimageKEEP_ALIVELe nombre de secondes pour attendre les demandes sur une connexion de conservation.
En savoir plus à ce sujet dans les documents Gunicorn: Keepalive.
Par défaut, réglé sur 2 .
Vous pouvez le définir comme:
docker run -d -p 80:8080 -e KEEP_ALIVE= " 20 " myimageGRACEFUL_TIMEOUTLe temps mort pour les travailleurs gracieux redémarre.
En savoir plus à ce sujet dans les Docs Gunicorn: Graceful-Timeout.
Par défaut, réglé sur 120 .
Vous pouvez le définir comme:
docker run -d -p 80:8080 -e GRACEFUL_TIMEOUT= " 20 " myimageACCESS_LOGLe fichier journal d'accès à écrire.
Par défaut "-" , ce qui signifie stdout (imprimer dans les journaux docker).
Si vous souhaitez désactiver ACCESS_LOG , définissez-le sur une valeur vide.
Par exemple, vous pouvez le désactiver avec:
docker run -d -p 80:8080 -e ACCESS_LOG= myimageERROR_LOGLe fichier journal d'erreur à écrire.
Par défaut "-" , ce qui signifie stderr (imprimer dans les journaux docker).
Si vous souhaitez désactiver ERROR_LOG , définissez-le sur une valeur vide.
Par exemple, vous pouvez le désactiver avec:
docker run -d -p 80:8080 -e ERROR_LOG= myimageGUNICORN_CMD_ARGS Tout paramètre de ligne de commande supplémentaire pour Gunicorn peut être passé dans la variable d'environnement GUNICORN_CMD_ARGS .
En savoir plus à ce sujet dans les documents Gunicorn: Paramètres.
Ces paramètres auront la priorité sur les autres variables d'environnement et tout fichier de configuration Gunicorn.
Par exemple, si vous disposez d'un certificat TLS / SSL personnalisé que vous souhaitez utiliser, vous pouvez les copier sur l'image Docker ou les monter dans le conteneur, et définir --keyfile et --certfile à l'emplacement des fichiers, par exemple:
docker run -d -p 80:8080 -e GUNICORN_CMD_ARGS= " --keyfile=/secrets/key.pem --certfile=/secrets/cert.pem " -e PORT=443 myimageRemarque : Au lieu de gérer TLS / SSL vous-même et de le configurer dans le conteneur, il est recommandé d'utiliser un "proxy de terminaison TLS" comme Trafik. Vous pouvez en savoir plus à ce sujet dans la documentation FastAPI sur HTTPS.
PRE_START_PATHLe chemin où trouver le script pré-démarré.
Par défaut, définissez-vous sur /app/prestart.sh .
Vous pouvez le définir comme:
docker run -d -p 80:8080 -e PRE_START_PATH= " /custom/script.sh " myimage L'image comprend un fichier de configuration de python Gunicorn par défaut sur /gunicorn_conf.py .
Il utilise les variables d'environnement déclarées ci-dessus pour définir toutes les configurations.
Vous pouvez le remplacer en incluant un fichier dans:
/app/gunicorn_conf.py/app/app/gunicorn_conf.py/gunicorn_conf.py/app/prestart.sh Si vous devez exécuter quelque chose avant de démarrer l'application, vous pouvez ajouter un fichier prestart.sh au répertoire /app . L'image détectera et l'exécutera automatiquement avant de tout démarrer.
Par exemple, si vous souhaitez ajouter des migrations SQL Alembic (avec SQLALCHEMY), vous pouvez créer un fichier ./app/prestart.sh dans votre répertoire de code (qui sera copié par votre Dockerfile ) avec:
#! /usr/bin/env bash
# Let the DB start
sleep 10 ;
# Run migrations
alembic upgrade head Et il attendrait 10 secondes pour donner à la base de données un peu de temps pour démarrer, puis exécuter cette commande alembic .
Si vous avez besoin d'exécuter un script Python avant de démarrer l'application, vous pouvez faire en sorte que le fichier /app/prestart.sh exécute votre script Python, avec quelque chose comme:
#! /usr/bin/env bash
# Run custom Python script before starting
python /app/my_custom_prestart_script.py Vous pouvez personnaliser l'emplacement du script Prestart avec la variable d'environnement PRE_START_PATH décrit ci-dessus.
Le programme par défaut exécuté est sur /start.sh . Il fait tout ce qui est décrit ci-dessus.
Il y a aussi une version pour le développement avec le montage automatique en direct sur:
/start-reload.shPour le développement, il est utile de pouvoir monter le contenu du code d'application à l'intérieur du conteneur en tant que "volume d'hôte" Docker, pour pouvoir changer le code et le tester en direct, sans avoir à construire l'image à chaque fois.
Dans ce cas, il est également utile d'exécuter le serveur avec le rechargement automatique en direct, afin qu'il remonte automatiquement à chaque changement de code.
Le script supplémentaire /start-reload.sh exécute Uvicorn seul (sans Gunicorn) et en un seul processus.
Il est idéal pour le développement.
Par exemple, au lieu de courir:
docker run -d -p 80:80 myimageVous pourriez courir:
docker run -d -p 80:80 -v $( pwd ) :/app myimage /start-reload.sh-v $(pwd):/app : signifie que le répertoire $(pwd) doit être monté sous forme de volume à l'intérieur du conteneur à /app .$(pwd) : exécute pwd ("Imprimer le répertoire de travail") et le place dans le cadre de la chaîne./start-reload.sh : ajoutant quelque chose (comme /start-reload.sh ) à la fin de la commande, remplace la "commande" par défaut par celle-ci. Dans ce cas, il remplace la valeur par défaut ( /start.sh ) par l'alternative de développement /start-reload.sh . Comme /start-reload.sh ne fonctionne pas avec Gunicorn, aucune des configurations que vous mettez dans un fichier gunicorn_conf.py ne s'applique pas.
Mais ces variables d'environnement fonctionneront de la même manière que celles décrites ci-dessus:
MODULE_NAMEVARIABLE_NAMEAPP_MODULEHOSTPORTLOG_LEVEL En bref: vous ne devriez probablement pas utiliser Alpine pour les projets Python, utilisez plutôt les versions slim Docker Image.
Voulez-vous plus de détails? Continuer la lecture?
Alpine est plus utile pour d'autres langues où vous construisez un binaire statique dans une étape d'image Docker (en utilisant le bâtiment Docker en plusieurs étapes), puis le copiez sur une simple image alpine, puis exécutez simplement ce binaire. Par exemple, en utilisant Go.
Mais pour Python, car Alpine n'utilise pas l'outillage standard utilisé pour construire des extensions de Python, lors de l'installation de packages, dans de nombreux cas, Python ( pip ) ne trouvera pas un package installable précompilé (une "roue") pour Alpine. Et après le débogage de nombreuses erreurs étranges, vous vous rendrez compte que vous devez installer beaucoup d'outils supplémentaires et créer beaucoup de dépendances juste pour utiliser certains de ces packages Python courants. ?
Cela signifie que, bien que l'image alpine d'origine ait pu être petite, vous vous retrouvez avec une image avec une taille comparable à la taille que vous auriez obtenue si vous veniez d'utiliser une image python standard (basée sur Debian), ou dans certains cas encore plus grande. ?
Et dans tous ces cas, il faudra beaucoup plus de temps pour construire, consommer beaucoup plus de ressources, construire des dépendances plus longtemps et augmenter son empreinte carbone, car vous utilisez plus de temps et d'énergie CPU pour chaque construction. ?
Si vous voulez des images Slim Python, vous devriez plutôt essayer d'utiliser les versions slim qui sont toujours basées sur Debian, mais qui sont plus petites. ?
Toutes les balises d'image, les configurations, les variables d'environnement et les options d'application sont testées.
*.pyc avec PYTHONDONTWRITEBYTECODE=1 et assurez-vous que les journaux sont imprimés immédiatement avec PYTHONUNBUFFERED=1 . PR # 192 par @ Estebanx64. EXPOSE pas les ports 80 et 443 par défaut car ils peuvent être personnalisés. PR # 238 par @tiangolo. --workers . PR # 225 par @tiangolo. issue-manager.yml . PR # 237 par @tiangolo.latest-changes . PR # 236 par @tiangolo.latest-changes.yml . PR # 198 par @alejsdev.arm64 (par exemple Mac M1). PR # 195 par @tiangolo. README.md . PR # 197 par @alejsdev. Les points forts de cette version sont:
python3.6-2022-11-25 .slim . PR # 40.WORKER_CLASSTIMEOUTKEEP_ALIVEGRACEFUL_TIMEOUTACCESS_LOGERROR_LOGGUNICORN_CMD_ARGSMAX_WORKERSpip lors de l'installation avec --no-cache-dir . PR # 13 par @ pmav99.PRE_START_PATH ENV VAR. PR # 30.PRE_START_PATH ENV VAR. PR # 12 par @mgfinch.tiangolo/uvicorn-gunicorn:python3.7-2019-10-15 . PR # 15./dev/shm pour améliorer les performances. PR # 9 par @wshayes./start-reload.sh , consultez la documentation mise à jour. PR # 6.WORKERS_PER_CORE par défaut à 1 , car il montre les meilleures performances sur les repères.WEB_CONCURRENCY n'est pas défini, sur un minimum de 2 travailleurs. Il s'agit d'éviter les mauvaises performances et le blocage des applications (application du serveur) sur les petites machines (serveur machine / cloud / etc.). Cela peut être remplacé à l'aide WEB_CONCURRENCY . Cela s'applique par exemple dans le cas où WORKERS_PER_CORE est défini sur 1 (par défaut) et le serveur n'a que 1 noyau CPU. PR # 5./start.sh exécuter indépendamment, la lecture et la génération de variables d'environnement par défaut utilisées. Et supprimer /entrypoint.sh car il ne modifie rien dans le système, ne lit que les variables d'environnement. PR # 4./app/prestart.sh . Ce projet est concédé sous licence de la licence du MIT.
