uwsgi nginx docker
2.1.0
Dockerfile链接python3.12 ， latest （Dockerfile）python3.11 ， （Dockerfile）python3.10 ， （Dockerfile）python3.9 ， （Dockerfile） 这些标签不再受支持或维护，将它们从GitHub存储库中删除，但是如果有人将其拉动，则可以在Docker Hub中推出的最后一个版本可以使用：
python3.8python3.8-alpinepython3.7python3.6python2.7这些版本的最后日期标签是：
python3.8-2024-10-28python3.8-alpine-2024-03-11python3.7-2024-10-28python3.6-2022-11-25python2.7-2022-11-25注意：每个构建日期都有标签。如果您需要“固定”所使用的Docker Image版本，则可以选择其中一个标签。例如tiangolo/uwsgi-nginx:python3.12-2024-11-02 。
带有UWSGI和NGINX的Docker映像，用于单个容器中的Python （作为烧瓶）中的Web应用程序。
此Docker映像允许您创建Python Web应用程序，这些应用程序在一个容器中使用UWSGI和NGINX运行。
UWSGI与Nginx的组合是部署Python Web应用程序（例如Blask and Django）的常见方法。它在行业中广泛使用，将为您带来体面的表现。 （*）
该图像的创建是Tiangolo/UWSGI-NGINX-FLASK的基本图像，但可以用作任何其他（基于WSGI）Python Web应用程序（例如Django）的基本图像。
如果您启动了一个新项目，则可能会从基于ASGI而不是WSGI的较新框架中受益（Blask和Django是基于WSGI的）。
您可以使用ASGI框架，例如：
Fastapi或starlette将为您提供约800％（8倍）此图像（ Tiangolo/Uwsgi-nginx ）实现的性能。您可以在这里看到第三方基准。
另外，如果您想使用WebSocket之类的新技术，将使用基于ASGI的较新框架（例如Fastapi或starlette）更容易（并且可能）。由于标准的ASGI被设计为能够像Websocket所需的那样处理异步代码。
如果您需要使用较旧的基于WSGI的框架，例如Blask或Django（而不是基于ASGI的东西），并且需要具有最佳性能，则可以使用替代图像： Tiangolo/Meinheld-Gunicorn 。
Tiangolo/Meinheld-Gunicorn将为您提供大约400％（4倍）此图像的性能。
github repo ：https：//github.com/tiangolo/uwsgi-nginx-docker
Docker Hub图像：https：//hub.docker.com/r/tiangolo/uwsgi-nginx/
您可能正在使用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/uwsgi-nginx:python3.12
COPY ./requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /app
# Your Dockerfile code...默认情况下，它将尝试在/app/uwsgi.ini中找到一个UWSGI配置文件。
uwsgi.ini文件将使它尝试在/app/main.py中运行一个python文件。
如果要构建烧瓶Web应用程序，则应使用Tiangolo/UWSGI-NGINX-FLASK 。
如果您需要使用与/app不同的应用程序使用目录，则可以使用环境变量UWSGI_INI覆盖UWSGI配置文件路径，然后将自定义的uwsgi.ini文件放在此处。
例如，如果您需要将应用程序目录在/application而不是/app中使用，则您的Dockerfile看起来像：
FROM tiangolo/uwsgi-nginx:python3.12
ENV UWSGI_INI /application/uwsgi.ini
COPY ./application /application
WORKDIR /appapplication和您的uwsgi.ini文件./application/uwsgi.ini将包含：
[uwsgi]
wsgi-file =/application/main.py注意：包括WORKDIR选项很重要，否则UWSGI将在/app中启动应用程序。
默认情况下，图像以2个UWSGI进程运行开始。当服务器经历高负载时，它最多可创建16个UWSGI进程来按需处理。
如果您需要配置这些数字，则可以使用环境变量。
UWSGI进程的起始编号由变量UWSGI_CHEAPER控制，默认设置为2 。
UWSGI进程的最大数量由变量UWSGI_PROCESSES控制，默认设置为16 。
请记住， UWSGI_CHEAPER必须低于UWSGI_PROCESSES 。
因此，例如，如果您需要从4个进程开始并最多成长为64个，则您的Dockerfile可能看起来像：
FROM tiangolo/uwsgi-nginx:python3.12
ENV UWSGI_CHEAPER 4
ENV UWSGI_PROCESSES 64
COPY ./app /app在此图像中，NGINX被配置为允许无限的上传文件尺寸。之所以这样做，是因为默认情况下，简单的Python服务器将允许这样做，因此这是开发人员期望的最简单行为。
如果您需要限制NGINX中的最大上传大小，则可以添加环境变量NGINX_MAX_UPLOAD并分配与标准Nginx config client_max_body_size相对应的值。
例如，如果您想将最大上传文件大小设置为1 MB（默认安装中的默认值），则需要将NGINX_MAX_UPLOAD环境变量设置为1m 。然后，图像将负责添加相应的配置文件（这是由entrypoint.sh完成的）。
因此，您的Dockerfile看起来像：
FROM tiangolo/uwsgi-nginx:python3.12
ENV NGINX_MAX_UPLOAD 1m
COPY ./app /app默认情况下，此图像制作的容器将在端口80上侦听。
要更改此行为，请设置LISTEN_PORT环境变量。
您可能还需要创建EXPOSE的Docker指令。
您可以在Dockerfile中做到这一点，看起来像：
FROM tiangolo/uwsgi-nginx:python3.12
ENV LISTEN_PORT 8080
EXPOSE 8080
COPY ./app /app/app/prestart.sh如果您需要在启动应用程序之前运行任何内容，则可以将文件prestart.sh添加到目录/app 。图像将在开始所有内容之前自动检测并运行它。
例如，如果要添加启动上运行的数据库迁移（例如使用ALEMBIC或DJANGO迁移），在启动应用程序之前，您可以在代码目录中创建一个./app/prestart.sh文件（将由Dockerfile复制），并使用：
#! /usr/bin/env bash
# Let the DB start
sleep 10 ;
# Run migrations
alembic upgrade head它将等待10秒钟才能给数据库一些时间开始，然后运行该alembic命令（您可以将其更新以运行Django迁移或任何其他工具）。
如果您需要在启动应用程序之前运行Python脚本，则可以使/app/prestart.sh文件运行您的python脚本，并带有类似的内容：
#! /usr/bin/env bash
# Run custom Python script before starting
python /app/my_custom_prestart_script.py注意：图像使用.要运行脚本（如. /app/prestart.sh ），例如，环境变量将持续存在。如果您不了解上一句话，则可能不需要它。
默认情况下，NGINX将启动一个“工作过程”。
如果要设置其他数量的NGINX工作流程，则可以使用环境变量NGINX_WORKER_PROCESSES 。
您可以使用特定的单个数字，例如：
ENV NGINX_WORKER_PROCESSES 2或者，您可以将其设置为关键字auto ，它将尝试自动检测可用的CPU数量，并将其用于工人数量。
例如，使用auto ，您的Dockerfile看起来像：
FROM tiangolo/uwsgi-nginx:python3.12
ENV NGINX_WORKER_PROCESSES auto
COPY ./app /app默认情况下，NGINX将以每个工作人员的最大限制为1024个连接。
如果要设置其他数字，则可以使用环境变量NGINX_WORKER_CONNECTIONS ，例如：
ENV NGINX_WORKER_CONNECTIONS 2048它不能超过开放文件数量最大数量的当前限制。查看如何在下一部分中配置它。
每个NGINX工作人员的数字连接不能超过开放文件的最大数量的限制。
您可以使用环境变量NGINX_WORKER_OPEN_FILES更改打开文件的限制，例如：
ENV NGINX_WORKER_OPEN_FILES 2048如果您需要进一步配置Nginx，则可以在您的Dockerfile中将*.conf文件添加到/etc/nginx/conf.d/ 。
只需记住/etc/nginx/conf.d/upload.conf默认配置是在启动过程中创建/etc/nginx/conf.d/nginx.conf 。因此，您不应该覆盖它们。您应该使用与nginx.conf或upload.conf不同的东西命名*.conf文件，例如： custom.conf 。
注意：如果您是在自定义NGINX，则可能会从博客或stackoverflow答案中复制配置，请记住，您可能需要使用UWSGI特定的配置，而不是用于其他模块的配置，例如ngx_http_fastcgi_module 。
如果您需要进一步配置NGINX，请完全覆盖默认值，可以将自定义Nginx配置添加到/app/nginx.conf 。
它将被复制到/etc/nginx/nginx.conf ，而不是生成的。
请记住，在这种情况下，此图像不会生成任何NGINX配置，它将仅复制和使用您的配置文件。
这意味着将不使用上述特定于NGINX的所有环境变量。
这也意味着它不会在/etc/nginx/conf.d/*.conf /app/nginx.conf使用文件中的其他配置
include /etc/nginx/conf.d/*.conf;
如果要添加自定义/app/nginx.conf文件，但不知道从哪里开始，则可以使用用于测试的nginx.conf并自定义或进一步修改。
UWSGI与NGINX的组合是部署Python Web应用程序的常见方法。
大致：
NGINX是一家Web服务器，它可以处理HTTP连接，还可以直接，更有效地提供静态文件。
UWSGI是一家应用程序服务器，这就是运行您的Python代码的原因，并且与Nginx进行了对话。
您的Python代码具有实际的Web应用程序，并且由UWSGI运行。
该图像利用已经苗条并优化了现有的Docker图像（根据Docker建议的Debian），并实现了Docker的最佳实践。
它使用官方的Python Docker映像，安装UWSGI，最重要的是，添加了最少的修改，添加了官方的NGINX Image（截至2016-02-14开始）。
它通过主管控制所有这些过程。
有一个经验法则，您应该拥有“每个容器一个过程”。
例如，这有助于在不同的容器中隔离应用程序及其数据库。
但是，如果您想采用“微服务”方法，如果它们都与相同的“服务”相关，则可能需要在一个容器中使用多个进程，并且您可能希望在同一容器中包括烧瓶代码，UWSGI和NGINX（也许与数据库一起运行另一个容器）。
这就是此图像采用的方法。
该图像使用UWSGI文档中的示例在容器/app目录中具有默认示例“ Hello World”应用程序。
您可能想覆盖它或在项目中删除它。
如果您本身运行此图像，而不是作为自己的Dockerfile的基本图像，则它在那里，这样您就可以在没有错误的情况下获得示例应用程序。
简而言之：您可能不应该将高山用于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版本。 ？
测试了所有图像标签，配置，环境变量和应用程序选项。
发行版中宣布更新。
您可以单击右上角的“观看”按钮，然后在有新版本时选择“仅发布”以接收电子邮件通知。
PYTHONDONTWRITEBYTECODE=1创建不必要的*.pyc文件，并确保使用PYTHONUNBUFFERED=1立即打印日志。 @estebanx64的PR＃208。 EXPOSE端口80和443 。 @tiangolo的PR＃227。 issue-manager.yml 。 @tiangolo的PR＃226。latest-changes github动作。 @tiangolo的PR＃214。latest-changes.yml 。 PR＃201由@Alejsdev。README.md中的测试徽章。 @Alejsdev的Pr＃199。 此版本的亮点：
python3.6-2022-11-25和python2.7-2022-11-25 。2.0.20 。 @tiangolo的PR＃127。1.17.10 。 PR＃82。2020-05-04使用标签。2019-10-14：
2019-09-28：
tiangolo/uwsgi-nginx:python3.7-2019-09-28 。 PR＃65。升级Travis。 PR＃60。
/app/prestart.sh脚本的支持以运行任意代码（例如，alembic -sqlalchemy迁移）。 /app/prestart.sh的文档在主要读数中。 PR＃59。2019-05-04：
2019-02-02：
/app/nginx.conf文件，该文件覆盖生成的一个文件。 PR＃51。2018-11-23：Python 2.7，Python 3.6和Python 3.7的新Alpine 3.8图像（Python 3.7暂时禁用）。感谢PR＃45中的Philippfreyer
2018-09-22：基于标准和高山的新Python 3.7版本。感谢Disaintmartin在此公关中。
2018-06-22：您现在可以使用NGINX_WORKER_CONNECTIONS设置Nginx Worker连接的最大数量和NGINX_WORKER_OPEN_FILES来设置开放文件的最大数量。感谢Ronlut在此公关中。
2018-06-22：使UWSGI需要一个应用程序才能运行，而不是在发生错误时处于“完整动态模式”。主管没有终止自身，而是试图重新启动UWSGI并显示错误。 LuckyDonald在此评论中建议使用need-app 。
2018-06-22：正确处理UWSGI和NGINX的优雅关闭。感谢Disaintmartin在此公关中。
2018-02-04：现在可以使用环境变量NGINX_WORKER_PROCESSES设置NGINX工作过程的数量。感谢Naktinis在此公关中。
2018-01-14：现在有两个基于高山的版本python2.7-alpine3.7和python3.6-alpine3.7 。
2017-12-08：现在，您可以使用Environment listial_port在此PR中使用环境变量LISTEN_PORT配置该容器应聆听的哪个端口。
2017-08-09：您可以使用环境变量NGINX_MAX_UPLOAD设置自定义最大上传文件大小，默认情况下它的值为0 ，允许无限的上传文件大小。这不同于NGINX的默认值1 MB。它之所以配置为这种方式，是因为这是最简单的经验，而不是Nginx专家会期望的。
2017-08-09：现在，您可以使用EnvirNoment variable UWSGI_INI将uwsgi.ini目录从/app更改为其他内容。
2017-08-08：有一个新的latest标签映像，只是为了向仍使用latest Python 2.7 Web应用程序的警告显示。截至目前，每个人都应该使用Python 3。
2017-08-08：Substisord现在在SIGTERM上终止UWSGI，因此，如果您运行docker stop或类似的东西，它实际上将停止所有内容，而不是等待Docker的超时杀死容器。
2017-07-31：现在有一个Python 3.6的图像标签，基于Python 3.6的官方图像，这要归功于此PR中的JRD。
2016-10-01：现在您可以从/app/uwsgi.ini中的文件中覆盖默认的uwsgi.ini参数。
2016-08-16：根据Python 3.5的官方图像，现在有一个Python 3.5的图像标签。因此，现在您可以将此图像用于Python 2.7和Python 3.5中的项目。
2016-08-16：根据负载从2到16使用动态许多工作过程。这应该在大多数情况下工作。尤其是当有一些缓慢的响应且需要一些时间才能生成时，这会有所帮助，此更改允许所有其他响应可以快速（在新过程中）保持快速（在新过程中），而不必等待第一个（慢）才能完成。
另外，它现在在/etc/uwsgi/下使用一个基本的uwsgi.ini文件，并在大多数常规配置中使用，因此， uwsgi.ini inside /app （您可能需要修改的一个）现在更简单。
2016-04-05：现在将NGINX和UWSGI日志重定向到Stdout，允许使用docker logs 。
该项目是根据Apache许可证的条款获得许可的。
