Dockerfile链接python3.9 , latest (Dockerfile) 这些标签不再受支持或维护,将它们从GitHub存储库中删除,但是如果有人将其拉动,则可以在Docker Hub中推出的最后一个版本可以使用:
python3.9-alpine3.13python3.8python3.8-alpine3.11python3.7python3.7-alpine3.8python3.6python3.6-alpine3.8python2.7这些版本的最后日期标签是:
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注意:每个构建日期都有标签。如果您需要“固定”所使用的Docker Image版本,则可以选择其中一个标签。例如tiangolo/meinheld-gunicorn-flask:python3.9-2024-11-02 。
使用Python使用Python进行性能自动调整,由Gunicorn管理的Docker Image与Meinheld进行了高性能的Web应用程序。
github repo :https://github.com/tiangolo/meinheld-gunicorn-flask-docker
Docker Hub图像:https://hub.docker.com/r/tiangolo/meinheld-gunicorn-flask/
由Gunicorn控制的Meinheld运行的Python Flask Web应用程序具有烧瓶(*)可实现的最佳性能。
如果您已经在烧瓶中已经存在一个应用程序或正在建造新的应用程序,则此图像将为您提供最佳性能(或接近它)。
此图像具有“自动调节”机制,因此您可以添加代码并自动获得良好的性能。并且没有做出牺牲(例如记录)。
从2020年5月17日起,最新版本的Meinheld发行的最新版本为1.0.2。此版本的Meinheld需要Greenlet的旧版本( >=0.4.5,<0.5 ),与Python 3.10和3.11不兼容。这就是为什么此图像中支持的最新版本的Python是Python 3.9。
如果您要启动一个新项目,则可能会从诸如Fastapi (基于ASGI而不是WSGI)之类的新框架中受益,而不是WSGI,例如Blask和Django),以及像Tiangolo/Uvicorn-Gunicorn-Gunicorn-fastapi这样的Docker Image。
即使使用此图像,它也会为您提供大约200%的烧瓶性能。
另外,如果您想使用WebSocket等新技术,则基于ASGI(例如Fastapi)的较新框架会更容易。由于标准的ASGI被设计为能够像Websocket所需的那样处理异步代码。
Meinheld是一家高性能的WSGI兼容Web服务器。
您可以使用Gunicorn来管理Meinheld并运行多个过程。
烧瓶是基于Werkzeug,Jinja 2和良好意图的Python的小框架。
该图像的创建是Tiangolo/UWSGI-NGINX-FLASK的替代方法,可提供该图像的性能约400%。
它基于更通用的图像Tiangolo/Meinheld-Gunicorn 。那就是您将用于其他WSGI框架(例如Django)的一个。
您可能正在使用Kubernetes或类似工具。在这种情况下,您可能不需要此图像(或任何其他类似的基本图像)。您可能最好从头开始构建Docker映像。
如果您的机器群带有Kubernetes ,Docker swarm模式,Nomad或其他类似的复杂系统来管理多个机器上的分布式容器,那么您可能需要在群集级别上处理复制,而不是在每个启动多个工作过程的容器中使用一个流程管理器,这就是This Docker Image所做的。
在这种情况下(例如使用Kubernetes),您可能想从头开始构建一个docker映像,安装依赖项并运行一个进程而不是此图像。
例如,使用Gunicorn您可以使用一个文件app/gunicorn_conf.py 。
# Gunicorn config variables
loglevel = "info"
errorlog = "-" # stderr
accesslog = "-" # stdout
worker_tmp_dir = "/dev/shm"
graceful_timeout = 120
timeout = 120
keepalive = 5
threads = 3然后,您可以使用一个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 [ "gunicorn" , "--conf" , "app/gunicorn_conf.py" , "--bind" , "0.0.0.0:80" , "app.main:app" ]您可以在FastAPI文档中阅读有关这些想法的更多信息:容器中的FastApi- docker,因为相同的想法将适用于容器中的其他Web应用程序。
如果您的应用程序足够简单,以至于您不需要(至少还没有),您可以在容器中运行多个工作流程,以微调过程的数量过多,并且您只能使用自动默认值,并且您正在在单个服务器上运行它,而不是群集。
您可以将带Docker组成的单个服务器部署到单个服务器(而不是群集),因此在保留共享网络和负载平衡的同时,您将没有一种简单的方法来管理容器复制(使用Docker组合)。
然后,您可能需要一个带有一个流程管理器的单个容器,就像此Docker映像一样,在内部启动了几个工作过程。
您还可能有其他原因可以使拥有一个具有多个进程的单个容器,而不是在每个过程中都有一个具有单个过程的容器。
例如(取决于您的设置),您可以在同一容器中拥有一些工具,例如普罗米修斯出口商,该工具应该可以访问每个请求。
在这种情况下,如果您有多个容器,默认情况下,Prometheus来读取指标,则每次都会获得一个容器(对于处理该请求的容器),而不是为所有复制的容器获得累积的指标。
然后,在这种情况下,拥有一个具有多个进程的容器,以及在同一容器上为所有内部流程收集Prometheus指标并将这些指标公开在该单个容器上的同一容器,这可能更简单。
在FastAPI文档中阅读有关:Fastapi在容器中 - Docker中的更多信息,因为相同的概念适用于容器中的其他Web应用程序。
您不必克隆此回购。
您可以将此图像用作其他图像的基本图像。
假设您有文件requirements.txt Dockerfile
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它将在/app/app/main.py上期望一个文件。
或以其他方式为/app/main.py 。
并期望它包含带有“ WSGI”应用程序的可变app 。
然后,您可以从具有Dockerfile的目录中构建图像,例如:
docker build -t myimage ./这些是您可以在容器中设置的环境变量以配置它及其默认值:
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包含烧瓶应用程序的Python模块内部的变量。
默认情况下:
app例如,如果您的主Python文件具有类似的内容:
from flask import Flask
api = Flask ( __name__ )
@ api . route ( "/" )
def hello ():
return "Hello World from Flask"在这种情况下, api将是“烧瓶应用程序”的变量。您可以将其设置为:
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 " myimageWORKERS_PER_CORE此图像将检查当前运行您的容器的当前服务器中有多少个CPU内核。
它将将工人数量设置为乘以该值的CPU内核数。
默认情况下:
2您可以将其设置为:
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 3 " myimage如果您在具有2个CPU内核的服务器中使用了值3 ,则将运行6个工作过程。
您也可以使用浮点值。
因此,例如,如果您有一个运行多个应用程序的大服务器(假设8个CPU内核),并且您知道您知道的ASGI应用程序不需要高性能。而且您不想浪费服务器资源。您可以每CPU核心使用0.5工人。例如:
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 0.5 " myimage在具有8个CPU内核的服务器中,这将使它仅启动4个工作过程。
WEB_CONCURRENCY覆盖工人数量的自动定义。
默认情况下:
WORKERS_PER_CORE 。因此,在具有2个内核的服务器中,默认情况下它将设置为4 。您可以将其设置为:
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 " myimage日志发送到容器的stderr和stdout ,这意味着您可以使用docker logs -f your_container_name_here命令查看日志。
该图像在/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简而言之:您可能不应该将高山用于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版本。 ?
测试了所有图像标签,配置,环境变量和应用程序选项。
issue-manager.yml 。 @tiangolo的PR#154。latest-changes github动作。 @tiangolo的PR#153。latest-changes.yml 。 PR#141由@Alejsdev。README.md中的测试徽章。 PR#137由@Alejsdev。 此版本的亮点:
支持Python 3.9和3.8。
Python 3.6和2.7的贬值。
python3.6-2022-11-25和python2.7-2022-11-25 。所有依赖项的升级版本。
小改进和修复。
增加对Python 3.9和Python 3.9高山的支持。 @tiangolo的PR#50。
与Alpine 3.11一起添加Python 3.8。 PR#28。
增加对Python 3.8的支持。 PR#27。
tiangolo/meinheld-gunicorn-flask:python3.7-2019-10-15 。 PR#17。添加对Python 2.7的支持(您应该使用Python 3.7或Python 3.6)。 PR#11。
更新Travis CI配置。 PR#10由@cclauss。
/app/prestart.sh的支持。 该项目是根据MIT许可证的条款获得许可的。