uvicorn gunicorn fastapi docker
0.8.0
此Docker图像现在已弃用。无需使用它，您可以将Uvicorn与--workers一起使用。
在下面阅读有关它的更多信息。
Dockerfile链接python3.11 ， latest （Dockerfile）python3.10 ， （Dockerfile）python3.9 ， （Dockerfile）python3.11-slim （Dockerfile）python3.10-slim （Dockerfile）python3.9-slim （Dockerfile） 这些标签不再受支持或维护，将它们从GitHub存储库中删除，但是如果有人将其拉动，则可以在Docker Hub中推出的最后一个版本可以使用：
python3.8python3.8-slimpython3.7python3.9-alpine3.14python3.8-alpine3.10python3.7-alpine3.8python3.6python3.6-alpine3.8这些版本的最后日期标签是：
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注意：每个构建日期都有标签。如果您需要“固定”所使用的Docker Image版本，则可以选择其中一个标签。例如tiangolo/uvicorn-gunicorn-fastapi:python3.11-2024-11-02 。
由Gunicorn管理的Docker Image与gunicorn管理Python的高性能Fastapi Web应用程序，并具有性能自动调整。
github repo ：https：//github.com/tiangolo/uvicorn-gunicorn-fastapi-docker
Docker Hub图像：https：//hub.docker.com/r/tiangolo/uvicorn-gunicorn-fastapi/
Fastapi已证明是一个以第三方基准测量的最佳性能之一，这是一个最好的表演之一，这要归功于Starlette并提供了驱动力。
可实现的性能与go and node.js框架相提并论。
该图像具有一个自动调整机制，可以根据可用的CPU内核启动许多工作过程。这样一来，您就可以添加代码并自动获得高性能，这在简单的部署中很有用。
您可能正在使用Kubernetes或类似工具。在这种情况下，您可能不需要此图像（或任何其他类似的基本图像）。如Fastapi在容器中的文档中所解释的那样，您可能会从头开始构建Docker映像- Docker：为Fastapi构建Docker映像。
如果您有一组带有Kubernetes ，Docker Swarm模式，Nomad或其他类似复杂系统的机器，可以在多台机器上管理分布式容器，那么您可能希望在集群级别上处理复制，而不是使用Process Manager （例如每个容器中的uvicorn tockorn tocker tocker tocker table），这就是该docker映像的内容。
在这种情况下（例如使用kubernetes），您可能想从头开始构建一个docker映像，安装依赖项并运行单个Uvicorn进程而不是此图像。
例如，您的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 [ "uvicorn" , "app.main:app" , "--host" , "0.0.0.0" , "--port" , "80" ]您可以在FastAPI文档中了解有关：Fastapi在容器中-Docker中的更多信息。
如果您肯定想在一个容器上有多个工人，Uvicorn现在支持处理子过程，包括重新启动死亡。因此，枪手无需在一个容器中管理多个工人。
您可以从上方修改示例Dockerfile ，将--workers选项添加到Uvicorn，就像：
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" ]这就是您所需要的。您根本不需要此Docker图像。 ？
您可以在Fastapi文档中了解有关与Docker部署的更多信息。
Uvicorn不支持管理工人处理，包括重新启动死去的工人。但是现在确实如此。
在此之前，枪支可以用作流程经理，经营Uvicorn工人。这种不再需要的增加的复杂性。
由于历史原因，该文档的其余部分被保存下来，但您可能不需要它。 ？
tiangolo/uvicorn-gunicorn-fastapi该图像将基于它正在运行的服务器（可用的CPU内核数量）设置明智的配置，而无需牺牲。
它具有明智的默认值，但是您可以使用环境变量进行配置或覆盖配置文件。
也有苗条的版本。如果您想要其中之一，请使用上面的一个标签。
tiangolo/uvicorn-gunicorn此图像（ tiangolo/uvicorn-gunicorn-fastapi ）基于Tiangolo/Uvicorn-Gunicorn 。
该图像实际上是所有工作。
此图像只是安装了FastApi，并在FastApi中具有专门针对的文档。
如果您对自己对Uvicorn，Gunicorn和Asgi的了解充满信心，则可以直接使用该图像。
tiangolo/uvicorn-gunicorn-starlette有一个兄弟姐妹的图像： tiangolo/uvicorn-gunicorn starlette
如果要创建一个新的星际网络应用程序，并且要丢弃FastApi的所有其他功能，则应改用Tiangolo/Uvicorn-Gunicorn Starlette 。
注意：FastAPI基于星条，并在其顶部添加了几个功能。对API和其他情况有用：数据验证，数据转换，带有OpenAPI的文档，依赖注入，安全/身份验证等。
您不需要克隆github储物库。
您可以将此图像用作其他图像的基本图像。
假设您有文件requirements.txt Dockerfile
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它将在/app/app/main.py上期望一个文件。
或以其他方式为/app/main.py 。
并期望它包含带有您的FastAPI应用程序的可变app 。
然后，您可以从具有Dockerfile的目录中构建图像，例如：
docker build -t myimage ./Dockerfile 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程序目录并输入其中。main.py文件 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所在的位置，包含您的app目录）。docker build -t myimage .docker run -d --name mycontainer -p 80:80 myimage现在，您在Docker容器中拥有优化的FastApi服务器。自动调整当前服务器（以及CPU内核的数量）。
您应该能够在Docker容器的URL中检查它，例如：http：//192.168.99.100/items/5?q= somequemequery或http：//127.0.0.0.0.1/items/5?q= someMomequere（或使用您的Dockeker Hots）。
您会看到类似的东西：
{ "item_id" : 5 , "q" : " somequery " }现在，您可以访问http://192.168.99.100/docs或http://127.0.0.1/docs（或使用docker主机）。
您将看到自动交互式API文档（由Swagger UI提供）：
而且，您也可以访问http://192.168.99.100/redoc或http://127.0.0.0.1/redoc（或等价，使用您的Docker Host）。
您将看到替代自动文档（由RETOC提供）：
您可能还想添加应用程序的任何依赖项，并将其固定在特定版本中，可能包括Uvicorn，Gunicorn和Fastapi。
这样，您可以确保您的应用程序始终按预期工作。
您可以使用requirements.txt ，甚至使用诗歌Dockerfile安装带有pip命令的软件包。
然后，您可以以受控的方式升级这些依赖关系，运行测试，确保一切都起作用，但是如果某些新版本不兼容，则不破坏生产应用程序。
这是您可以安装依赖项的方法之一，以确保每个软件包都有固定版本。
假设您有一个诗歌管理的项目，因此，您在文件pyproject.toml中具有包裹依赖关系。可能是文件poetry.lock 。
然后，您可以使用Docker多阶段建筑物拥有一个Dockerfile 。
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 /app那将：
./poetry.lock* （以a *结尾），所以如果该文件尚未可用，它不会崩溃。安装依赖项后复制应用程序代码很重要，这样您就可以利用Docker的缓存。这样，只有在添加新的依赖项时，就不必每次更新应用程序文件时都要从头开始安装所有内容。
这也适用于您用于安装依赖项的任何其他方式。如果您使用requirements.txt ，请单独复制并安装所有依赖项在Dockerfile的顶部，然后在其之后添加您的应用程序代码。
这些是您可以在容器中设置的环境变量以配置它及其默认值：
MODULE_NAMEPython“模块”（文件）将由Gunicorn导入，该模块将在变量中包含实际应用程序。
默认情况下：
app.main如果有文件/app/app/main.py或main如果有文件/app/main.py例如，如果您的主文件位于/app/custom_app/custom_main.py ，则可以将其设置为：
docker run -d -p 80:80 -e MODULE_NAME= " custom_app.custom_main " myimageVARIABLE_NAME包含FastAPI应用程序的Python模块内部的变量。
默认情况下：
app例如，如果您的主Python文件具有类似的内容：
from fastapi import FastAPI
api = FastAPI ()
@ api . get ( "/" )
def read_root ():
return { "Hello" : "World" }在这种情况下， api将是FastAPI应用程序的变量。您可以将其设置为：
docker run -d -p 80:80 -e VARIABLE_NAME= " api " myimageAPP_MODULE带有Python模块和变量名称的字符串传递给Gunicorn。
默认情况下，基于变量MODULE_NAME和VARIABLE_NAME设置：
app.main:app或main:app您可以将其设置为：
docker run -d -p 80:80 -e APP_MODULE= " custom_app.custom_main:api " myimageGUNICORN_CONFGunicorn Python配置文件的路径。
默认情况下：
/app/gunicorn_conf.py如果存在/app/app/gunicorn_conf.py如果存在/gunicorn_conf.py （随附的默认值）您可以将其设置为：
docker run -d -p 80:80 -e GUNICORN_CONF= " /app/custom_gunicorn_conf.py " myimage您可以将基本图像中的配置文件用作您的起点。
WORKERS_PER_CORE此图像将检查当前运行您的容器的当前服务器中有多少个CPU内核。
它将将工人数量设置为乘以该值的CPU内核数。
默认情况下：
1您可以将其设置为：
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 3 " myimage如果您在具有2个CPU内核的服务器中使用了值3 ，则将运行6个工作过程。
您也可以使用浮点值。
因此，例如，如果您有一个运行多个应用程序的大服务器（例如，带有8个CPU内核），并且您知道您知道的FastAPI应用程序不需要高性能。而且您不想浪费服务器资源。您可以每CPU核心使用0.5工人。例如：
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 0.5 " myimage在具有8个CPU内核的服务器中，这将使它仅启动4个工作过程。
注意：默认情况下，如果WORKERS_PER_CORE是1 ，并且服务器只有1个CPU核心，而不是启动1个单个工作，它将启动2个。这是为了避免性能不良，并且在小型机器上（服务器计算机/云/等）上阻止了应用程序（服务器应用程序）。可以使用WEB_CONCURRENCY覆盖这。
MAX_WORKERS设置最大使用的工人数量。
您可以使用它使图像自动计算工人的数量，但要确保其最大限度地限于最大值。
例如，如果每个工人都使用数据库连接，并且您的数据库具有开放连接的最大限制，那么这可能很有用。
默认情况下它不是设置的，这意味着它是无限的。
您可以将其设置为：
docker run -d -p 80:80 -e MAX_WORKERS= " 24 " myimage这将使图像从大多数24名工人开始，而与服务器中有多少CPU可用。
WEB_CONCURRENCY覆盖工人数量的自动定义。
默认情况下：
WORKERS_PER_CORE 。因此，在具有2个内核的服务器中，默认情况下它将设置为2 。您可以将其设置为：
docker run -d -p 80:80 -e WEB_CONCURRENCY= " 2 " myimage这将使图像启动2个工作过程，而与服务器中有多少个CPU内核无关。
HOSTGunicorn使用的“主机”，枪gunicorn将聆听请求的IP。
它是容器内部的主机。
因此，例如，如果将此变量设置为127.0.0.1 ，则只能在容器内而不是在运行它的主机中可用。
它是为了完整性提供的，但您可能不应该更改它。
默认情况下：
0.0.0.0PORT容器应聆听的端口。
如果您要在限制性环境中运行容器，该环境迫使您使用某些特定端口（例如8080 ），则可以使用此变量设置它。
默认情况下：
80您可以将其设置为：
docker run -d -p 80:8080 -e PORT= " 8080 " myimageBIND实际的主机和港口传给了枪支。
默认情况下，基于变量HOST和PORT设置。
因此，如果您没有更改任何内容，则默认情况下将设置为：
0.0.0.0:80您可以将其设置为：
docker run -d -p 80:8080 -e BIND= " 0.0.0.0:8080 " myimageLOG_LEVEL枪支的日志级别。
之一：
debuginfowarningerrorcritical默认情况下，设置为info 。
如果您需要挤压更多的性能牺牲记录，请将其设置为warning ，例如：
您可以将其设置为：
docker run -d -p 80:8080 -e LOG_LEVEL= " warning " myimageWORKER_CLASS枪支将班级用于工人。
默认情况下，设置为uvicorn.workers.UvicornWorker 。
它使用Uvicorn的事实允许使用ASGI框架，例如FastApi，这也是提供最大性能的原因。
您可能不应该更改它。
但是，如果出于某种原因，您需要使用替代的Uvicorn Worker： uvicorn.workers.UvicornH11Worker ，您可以使用此环境变量进行设置。
您可以将其设置为：
docker run -d -p 80:8080 -e WORKER_CLASS= " uvicorn.workers.UvicornH11Worker " myimageTIMEOUT工人在这秒的时间里沉默了很多秒，被杀死并重新开始。
在《枪支文档：超时》中阅读有关它的更多信息。
默认情况下，设置为120 。
请注意，像FastApi这样的Uvicorn和Asgi框架是异步而不是同步的。因此，比同步工人更高的超时可能是安全的。
您可以将其设置为：
docker run -d -p 80:8080 -e TIMEOUT= " 20 " myimageKEEP_ALIVE等待在野生连接上的请求的秒数。
在《枪支文档：keepalive》中阅读更多有关它的信息。
默认情况下，设置为2 。
您可以将其设置为：
docker run -d -p 80:8080 -e KEEP_ALIVE= " 20 " myimageGRACEFUL_TIMEOUT优雅工人的超时重新启动。
在《枪支文档：优雅的超时》中阅读更多有关它的信息。
默认情况下，设置为120 。
您可以将其设置为：
docker run -d -p 80:8080 -e GRACEFUL_TIMEOUT= " 20 " myimageACCESS_LOG要写入的访问日志文件。
默认情况下"-" ，表示stdout（在Docker日志中打印）。
如果要禁用ACCESS_LOG ，请将其设置为空值。
例如，您可以将其禁用：
docker run -d -p 80:8080 -e ACCESS_LOG= myimageERROR_LOG要写入的错误日志文件。
默认情况下"-" ，表示stderr（在Docker日志中打印）。
如果要禁用ERROR_LOG ，请将其设置为空值。
例如，您可以将其禁用：
docker run -d -p 80:8080 -e ERROR_LOG= myimageGUNICORN_CMD_ARGS枪支的任何其他命令行设置都可以在GUNICORN_CMD_ARGS环境变量中传递。
在《枪支文档：设置》中阅读有关它的更多信息。
这些设置将优先于其他环境变量和任何Gunicorn配置文件。
例如，如果您有要使用的自定义TLS/SSL证书，则可以将其复制到Docker映像或将其安装在容器中，然后将--keyfile和--certfile设置为文件位置，例如：
docker run -d -p 80:8080 -e GUNICORN_CMD_ARGS= " --keyfile=/secrets/key.pem --certfile=/secrets/cert.pem " -e PORT=443 myimage注意：代替自己处理TLS/SSL并在容器中配置它，而是建议使用像Traefik这样的“ TLS终止代理”。您可以在有关HTTPS的FastAPI文档中阅读有关它的更多信息。
PRE_START_PATH找到启动脚本的路径。
默认情况下，设置为/app/prestart.sh 。
您可以将其设置为：
docker run -d -p 80:8080 -e PRE_START_PATH= " /custom/script.sh " myimage该图像在/gunicorn_conf.py上包括一个默认的Gunicorn Python配置文件。
它使用上面声明的环境变量来设置所有配置。
您可以通过在：
/app/gunicorn_conf.py/app/app/gunicorn_conf.py/gunicorn_conf.py/app/prestart.sh如果您需要在启动应用程序之前运行任何内容，则可以将文件prestart.sh添加到目录/app 。图像将在开始所有内容之前自动检测并运行它。
例如，如果要添加ALEMBIC SQL迁移（使用SQLalchemy），则可以在代码目录中创建一个./app/prestart.sh文件（由您的Dockerfile复制）中：
#! /usr/bin/env bash
# Let the DB start
sleep 10 ;
# Run migrations
alembic upgrade head它将等待10秒钟才能给数据库一些时间开始，然后运行该alembic命令。
如果您需要在启动应用程序之前运行Python脚本，则可以使/app/prestart.sh文件运行您的python脚本，并带有类似的内容：
#! /usr/bin/env bash
# Run custom Python script before starting
python /app/my_custom_prestart_script.py您可以使用上面描述的环境变量PRE_START_PATH自定义Prestart脚本的位置。
运行的默认程序在/start.sh 。它可以完成上面描述的所有内容。
还有一个用于开发的版本，其中有实时自动加载量：
/start-reload.sh为了开发，能够将应用程序代码的内容安装在容器中的“主机卷”中，能够更改代码和测试其实时，而无需每次构建图像。
在这种情况下，使用Live Auto-Reload运行服务器也很有用，以便在每个代码更改时自动重新启动。
附加的脚本/start-reload.sh仅在一个过程中单独运行UVICORN（没有枪支）。
它是开发的理想选择。
例如，而不是运行：
docker run -d -p 80:80 myimage您可以运行：
docker run -d -p 80:80 -v $( pwd ) :/app myimage /start-reload.sh-v $(pwd):/app ：表示目录$(pwd)应安装为AT /app容器内部的音量。$(pwd) ：运行pwd （“打印工作目录”），并将其作为字符串的一部分。/start-reload.sh ：在命令末尾添加一些东西（例如/start-reload.sh ），用此替换默认的“命令”。在这种情况下，它用开发替代/start-reload.sh代替默认值（ /start.sh ）。 AS /start-reload.sh不使用Gunicorn运行，您将任何配置都放在gunicorn_conf.py文件中。
但是这些环境变量的工作原理与上述相同：
MODULE_NAMEVARIABLE_NAMEAPP_MODULEHOSTPORTLOG_LEVEL简而言之：您可能不应该将高山用于Python项目，而是使用slim Docker Image版本。
您想要更多详细信息吗？继续阅读？
Alpine对于您在一个Docker Image阶段（使用多阶段Docker Building）然后将其复制到简单的Alpine图像，然后执行该二进制文件的其他语言更有用。例如，使用GO。
但是对于Python而言，由于Alpine不使用用于构建Python扩展的标准工具，因此在安装软件包时，在许多情况下，Python（ pip ）找不到Alpine的预编译可安装的软件包（“ Wheel”）。在调试许多奇怪的错误之后，您将意识到，您必须安装许多额外的工具并构建许多依赖关系，以便使用其中一些常见的Python软件包。 ？
这意味着，尽管原始的高山图像可能很小，但您最终会得到一个尺寸的图像，如果您刚刚使用了标准的Python图像（基于Debian），或者在某些情况下更大。 ？
在所有这些情况下，构建需要更长的时间，消耗更多的资源，建立更长的依赖性，并增加其碳足迹，因为您在每个构建中都使用了更多的CPU时间和能量。 ？
如果您想要Slim Python图像，则应尝试使用仍然基于Debian但较小的slim版本。 ？
测试了所有图像标签，配置，环境变量和应用程序选项。
--workers一起使用。 @tiangolo的PR＃303。issue-manager.yml 。 @tiangolo的PR＃343。latest-changes github动作。 @tiangolo的PR＃340。latest-changes.yml 。 PR＃276由@Alejsdev。README.md中的测试徽章。 PR＃275由@Alejsdev。README.md中的测试徽章。 PR＃274 @alejsdev。 此版本的亮点：
python3.6-2022-11-25 。slim版本。 PR＃40。WORKER_CLASSTIMEOUTKEEP_ALIVEGRACEFUL_TIMEOUTACCESS_LOGERROR_LOGGUNICORN_CMD_ARGSMAX_WORKERSPRE_START_PATH env v var的文档。 PR＃33。tiangolo/uvicorn-gunicorn-fastapi:python3.7-2019-10-15 。 PR＃17。/start-reload.sh添加对实时自动填充的支持，请检查更新的文档。 PR＃6在父映像中。WORKERS_PER_CORE设置为默认为1 ，因为它表明在基准上具有最佳性能。WEB_CONCURRENCY时，将默认的Web并发设置为至少2个工人。这是为了避免性能不佳，并阻止了小型机器（服务器机/云/等）上的应用程序（服务器应用程序）。可以使用WEB_CONCURRENCY覆盖这。例如，在设置为1 （默认值）的WORKERS_PER_CORE ，并且服务器仅具有1个CPU核心的情况下，这适用于此。 PR＃6和PR＃5在父映像中。/start.sh独立运行，读取和生成使用的默认环境变量。并删除/entrypoint.sh因为它不会修改系统中的任何内容，因此只读取环境变量。 PR＃4在父映像中。/app/prestart.sh的支持。 该项目是根据MIT许可证的条款获得许可的。
