uwsgi nginx flask 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-flask:python3.7-2019-10-14 。
docker映像带有uwsgi和nginx ，用于在单个容器中运行的Python中的烧瓶Web应用程序。
此Docker映像允许您在Python中创建烧瓶Web应用程序，该应用程序在一个容器中使用UWSGI和NGINX运行。
UWSGI与nginx的组合是部署Python烧结Web应用程序的常见方法。
如果您正在启动一个新项目，则可能需要尝试我创建的Fastapi ，以及我现在花费大部分时间的位置。它也不需要自定义的基本图像，文档中有指令可以构建您自己的Dockerfile 。
github repo ：https：//github.com/tiangolo/uwsgi-nginx-flask-docker
Docker Hub图像：https：//hub.docker.com/r/tiangolo/uwsgi-nginx-flask/
您可能正在使用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.12
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-flask:python3.12
COPY ./requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /app有几个图像标签，但对于新项目，您应该使用最新版本。
此Docker图像基于Tiangolo/Uwsgi-nginx 。该Docker映像已安装在同一容器中的UWSGI和NGINX，并成为此图像的基础。
Dockerfile FROM tiangolo/uwsgi-nginx-flask:python3.12
COPY ./app /appapp程序目录并输入其中main.py文件（应该像这样命名，应该在您的app目录中）： from flask import Flask
app = Flask ( __name__ )
@ app . route ( "/" )
def hello ():
return "Hello World from Flask"
if __name__ == "__main__" :
# Only for debugging while developing
app . run ( host = '0.0.0.0' , debug = True , port = 80 )正如本示例中的那样，主要的应用程序对象应命名为app （在代码中）。
注意：具有main()函数的部分是用于调试目的。要了解更多信息，请阅读下面的高级说明。
.
├── app
│ └── main.py
└── Dockerfile
Dockerfile所在的位置，包含您的app目录）docker build -t myimage .docker run -d --name mycontainer -p 80:80 myimage...并且您在Docker容器中拥有优化的烧瓶服务器。
您应该能够在Docker容器的URL中进行检查，例如：http：//192.168.99.100或http：//127.0.0.1.1
如果您要构建现代前端应用程序（例如Vue，React，Angular），您很可能会将现代版本的JavaScript（ES2015，TypeScript等）汇编为不现代，更兼容的版本。
如果要使用相同的后端（烧瓶）docker容器使用（编译）前端代码，则在编译后，必须将代码复制到容器中。
这意味着您需要在构建计算机上安装所有前端工具（可能是您的计算机，远程服务器等）。
这也意味着您必须以某种方式记住要在构建Docker映像之前立即编译前端代码。
这也可能意味着您必须在git存储库中添加编译的前端代码（希望您已经使用git或学习如何使用git ）。
由于几个原因，将您的编译代码添加到git是一个非常糟糕的主意，其中一些是：
由于这些原因，不建议您从同一后端（烧瓶）docker容器中提供前端代码。
从同一后端（烧瓶）docker容器中提供前端代码的替代方案更好。
您可以使用一个安装了所有前端工具（Node.js等）的Docker容器：
要了解Docker中前端大楼的此过程的细节，您可以阅读：
拥有一个后端（烧瓶）容器和一个前端容器后，您需要为两个容器提供服务。
而且，您可能需要在不同的路径下在同一域下为它们提供服务。例如，路径/api处的后端（烧瓶）应用程序和“ root”路径的前端/ 。
然后，您可以使用Traefik处理。
它还可以使用Let's Encrypt自动为您的应用程序生成HTTPS证书。在非常简单的设置中免费免费。
如果您想使用此替代方案，请检查上面的项目生成器，它们都使用此想法。
在这种情况下，您将拥有3个Docker容器：
您应该能够按照上述“ Quickstart ”部分中的相同说明进行一些次要修改：
app/目录中，而是将其放入目录app/app/中。app/app/目录中的内部添加一个空文件__init__.py 。app/目录中添加一个文件uwsgi.ini （该文件在容器内复制到/app/uwsgi.ini ）。uwsgi.ini文件中，添加： [uwsgi]
module = app.main
callable = app uwsgi.ini的解释如下：
app.main 。因此，在软件包app （ /app/app ）中，获取main模块（ main.py ）。app对象（ app = Flask(__name__) ）。您的文件结构看起来像：
.
├── app
│ ├── app
│ │ ├── __init__.py
│ │ ├── main.py
│ └── uwsgi.ini
└── Dockerfile
...而不是：
.
├── app
│ ├── main.py
└── Dockerfile
如果您在同一容器中使用静态文件，请确保设置STATIC_PATH环境变量，例如，要更改/app/static to /app/app/static的默认值，您可以将此行添加到Dockerfile ：
ENV STATIC_PATH /app/app/static...之后，一切都应该按预期工作。所有其他说明将正常适用。
.
├── app
│ ├── app
│ │ ├── api
│ │ │ ├── api.py
│ │ │ ├── endpoints
│ │ │ │ ├── __init__.py
│ │ │ │ └── user.py
│ │ │ ├── __init__.py
│ │ │ └── utils.py
│ │ ├── core
│ │ │ ├── app_setup.py
│ │ │ ├── database.py
│ │ │ └── __init__.py
│ │ ├── __init__.py
│ │ ├── main.py
│ │ └── models
│ │ ├── __init__.py
│ │ └── user.py
│ └── uwsgi.ini
└── Dockerfile
确保您在导入模块时遵循官方文档：
例如，如果您在app/app/main.py中，并且想在app/app/core/app_setup.py中导入模块。
from . core import app_setup或者
from app . core import app_setupapp/app/api/endpoints/user.py中，并且想从app/app/core/database.py导入users对象。 from ... core . database import users或者
from app . core . database import users 您可以使用环境变量自定义几件事。
index.html注意：此技术被弃用，因为它可以使用现代前端框架创建几个问题。有关详细信息和更好的替代方案，请阅读上面的部分。
将环境变量STATIC_INDEX设置为1 ，您可以在请求/时配置nginx在url /static/index.html中使用该文件。
这将提高速度，因为它不涉及UWSGI或Python。 Nginx将直接提供文件。要了解更多信息，请遵循上面的“ Spas快速入门”部分。
例如，要启用它，您可以将其添加到您的Dockerfile ：
ENV STATIC_INDEX 1默认情况下，图像以2个UWSGI进程运行开始。当服务器经历高负载时，它最多可创建16个UWSGI进程来按需处理。
如果您需要配置这些数字，则可以使用环境变量。
UWSGI进程的起始编号由变量UWSGI_CHEAPER控制，默认设置为2 。
UWSGI进程的最大数量由变量UWSGI_PROCESSES控制，默认设置为16 。
请记住， UWSGI_CHEAPER必须低于UWSGI_PROCESSES 。
因此，例如，如果您需要从4个进程开始并最多成长为64个，则您的Dockerfile可能看起来像：
FROM tiangolo/uwsgi-nginx-flask:python3.12
ENV UWSGI_CHEAPER 4
ENV UWSGI_PROCESSES 64
COPY ./app /app您可以使用环境变量NGINX_MAX_UPLOAD设置自定义最大上传文件大小，默认情况下它的值为0 ，该值允许无限上传的文件大小。这不同于NGINX的默认值1 MB。它是这种方式配置的，因为这是Nginx中没有经验的开发人员期望的最简单的经验。
例如，要使最大上载文件大小为1 MB（NGINX的默认值）在您的Dockerfile中添加一行：
ENV NGINX_MAX_UPLOAD 1m默认情况下，此图像制作的容器将在端口80上侦听。
要更改此行为，请设置LISTEN_PORT环境变量。您可能还需要创建EXPOSE的Docker指令。
您可以在Dockerfile中做到这一点，看起来像：
FROM tiangolo/uwsgi-nginx-flask:python3.12
ENV LISTEN_PORT 8080
EXPOSE 8080
COPY ./app /appuwsgi.ini配置在/app/uwsgi.ini中有一个默认文件，带有特定的配置（在全局uwsgi配置之上）。
它仅包含：
[uwsgi]
module = main
callable = appmodule = main指的是文件main.pycallable = app在变量app中引用Flask “应用程序”。您可以通过自己（包括所有配置）替换该文件来自定义uwsgi 。
例如，要扩展上面的默认一个并启用线程，您可以拥有一个文件：
[uwsgi]
module = main
callable = app
enable-threads = trueuwsgi.ini文件位置您可以使用环境变量UWSGI_INI来覆盖图像应在其中查找app uwsgi.ini文件。
因此，您可以将应用程序的默认目录从/app更改为其他内容，例如/application 。
例如，要使图像使用/application/uwsgi.ini中的文件，您可以将其添加到您的Dockerfile ：
ENV UWSGI_INI /application/uwsgi.ini
COPY ./application /application
WORKDIR /application注意： WORKDIR很重要，否则UWSGI将尝试在/app中运行该应用程序。
注意：您还必须配置static文件路径，请阅读下面。
./static/路径您可以使NginX使用文件使用自定义目录路径，直接使用环境变量STATIC_PATH （而无需涉及UWSGI）。
例如，要使用/app/custom_static/ in app/custom_static中的文件，您可以将其添加到Dockerfile ：
ENV STATIC_PATH /app/custom_static然后，当浏览器要求输入文件时，例如http：//example.com/static/index.html，nginx将使用Path /app/custom_static/index.html custom_static/index.html中的文件直接回答。
注意：您还必须配置烧瓶才能将其用作其static目录。
作为另一个示例，如果您需要将应用程序代码放在其他目录中，则可以配置Nginx从该不同目录中提供这些静态文件。
如果您需要在/application/static/中使用静态文件，则可以将其添加到Dockerfile ：
ENV STATIC_PATH /application/static/static网址您还可以使Nginx在不同的URL中使用静态文件，为此，您可以使用环境变量STATIC_URL 。
例如，如果您想将URL /static更改为/content ，则可以将其添加到您的Dockerfile ：
ENV STATIC_URL /content然后，当浏览器询问文件时，例如http：//example.com/content/index.html，nginx将使用路径/app/static/index.html中的文件直接回答。
/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注意：图像使用source运行脚本，因此，例如，环境变量将持续存在。如果您不了解上一句话，则可能不需要它。
默认情况下，NGINX将启动一个“工作过程”。
如果要设置其他数量的NGINX工作流程，则可以使用环境变量NGINX_WORKER_PROCESSES 。
您可以使用特定的单个数字，例如：
ENV NGINX_WORKER_PROCESSES 2或者，您可以将其设置为关键字auto ，它将尝试自动检测可用的CPU数量，并将其用于工人数量。
例如，使用auto ，您的Dockerfile看起来像：
FROM tiangolo/uwsgi-nginx-flask: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代码具有实际的Blask Web应用程序，并且由UWSGI运行。
图像Tiangolo/UWSGI-NGINX利用已经存在的苗条和优化的Docker映像（根据Docker建议的Debian），并实现了Docker的几种最佳实践。
它使用官方的Python Docker映像，安装UWSGI，最重要的是（最少的修改）添加了官方的Nginx图像。
它通过主管控制所有这些过程。
由此存储库创建的图像（和标签）基于图像tiangolo/uwsgi-nginx 。此图像在其顶部添加了烧瓶和明智的默认值。
如果您按照说明并将根目录/app保留在容器中，并使用名为main.py和名为“应用程序” app程序的文件，则应“仅此功能”。
/app目录中已经有一个uwsgi.ini文件，其UWSGI配置为其“只能工作”。所有其他必需的参数都在图像中的另一个uwsgi.ini文件中，内部/etc/uwsgi/ 。
如果您需要更改主文件名或主瓶对象，则必须提供自己的uwsgi.ini文件。您可以将本仓库中的一个用作模板，首先（而且您只需要更改2条相应的行）。
您可以拥有一个/app/static目录，这些文件将直接由Nginx有效地提供（无需浏览烧瓶代码甚至UWSGI），它已经为您配置了。但是，您可以使用环境变量进一步配置它（上文）。
Substisord会在/app程序中使用uwsgi.ini文件运行UWSGI（包括/etc/uwsgi/uwsgi.ini中的文件）和启动nginx。
有一个经验法则，您应该拥有“每个容器一个过程”。
例如，这有助于在不同的容器中隔离应用程序及其数据库。
但是，如果您想采用“微服务”方法，如果它们都与相同的“服务”相关，则可能需要在一个容器中使用多个进程，并且您可能希望在同一容器中包括烧瓶代码，UWSGI和NGINX（也许与数据库一起运行另一个容器）。
这就是此图像采用的方法。
此图像（和标签）具有一些默认文件，因此，如果您单独运行它（不是作为您自己的项目的基本图像），则会看到默认的“ Hello World” Web应用程序。
使用COPY ./app /app构建Dockerfile时，您将用应用程序代码替换这些默认文件。
主默认文件仅在/app/main.py中。对于带有-index的标签，也包括/app/static/index.html 。
但是这些文件在服务网页中呈现一个“（默认）”文本，以便您可以检查是否看到默认代码或自己的代码超出默认值。
您的应用程序代码应在容器/app目录中，它应该具有一个main.py文件，并且main.py文件应具有flask Object app 。
如果您遵循上面的说明或使用可下载的示例模板之一，则可以。
图像中还有一个/app/uwsgi.ini文件，其中包含UWSGI的默认参数。
可下载的示例包括用于调试目的的同一uwsgi.ini文件的副本。要了解更多信息，请阅读下面的“高级开发说明”。
在开发过程中，您可能需要将代码目录作为Docker容器中的卷。
因此，您每次修改它们时都会（临时）更新文件，而无需再次构建容器。
为此，您可以在docker run和Flag -v内使用命令pwd （打印工作目录）进行卷。
因此，您可以将./app目录映射到容器的/app程序目录。
但是首先，您将完全替换容器中的目录/app （以及所有内容），您将需要在./app目录中使用一个uwsgi.ini文件：
[uwsgi]
module = main
callable = app然后您可以进行Docker卷映射。
注意：可下载示例中包含一个uwsgi.ini文件。
Dockerfile和您的./app目录的目录）./app目录中有一个uwsgi.ini文件docker build -t myimage ../app ）映射到您的容器/app目录： docker run -d --name mycontainer -p 80:80 -v $( pwd ) /app:/app myimage如果您转到Docker容器URL，则应该查看您的应用程序，并且应该能够在./app/static/中修改文件，并通过重新加载在浏览器中看到这些更改。
...但是，由于UWSGI启动了整个Python Flask Web应用程序，因此您将无法编辑Python烧瓶代码并查看所反映的更改。
要（暂时）实时调试Python烧结代码，您可以运行容器覆盖默认命令（启动Substisord，又启动了UWSGI和NGINX的Substisord），并在调试模式下直接使用python直接运行您的应用程序，并使用带有环境变量的flask命令在调试模式下使用。
因此，鉴于上面的所有修改并使您的应用程序直接使用flask运行，最终的Docker命令将是：
docker run -d --name mycontainer -p 80:80 -v $( pwd ) /app:/app -e FLASK_APP=main.py -e FLASK_DEBUG=1 myimage flask run --host=0.0.0.0 --port=80或在包装项目的情况下，您将设置FLASK_APP=main/main.py ：
docker run -d --name mycontainer -p 80:80 -v $( pwd ) /app:/app -e FLASK_APP=main/main.py -e FLASK_DEBUG=1 myimage flask run --host=0.0.0.0 --port=80现在，您可以在本地计算机中编辑烧瓶代码，一旦刷新浏览器，您将看到更改现场。
请记住，您应该仅将其用于调试和开发，对于生产中的部署，您不应该安装卷，并且应该让Substisord启动并让其启动UWSGI和NGINX（默认情况下会发生）。
当您没有包裹时，这些最后步骤可以工作的替代方法，但是仅是带有单个文件（模块）的平坦结构，您的Python烧瓶代码可以包含以下部分：
if __name__ == "__main__" :
# Only for debugging while developing
app . run ( host = '0.0.0.0' , debug = True , port = 80 ) ...您可以使用python main.py运行它。但这只有在您不使用软件包结构并且以后不打算这样做时才有效。在这种特定情况下，如果您不添加上面的代码块，则您的应用只会在另一个端口（5000）而不在调试模式下收听localhost （在容器内部）。
另外，如果您想使用环境变量STATIC_INDEX=1进行相同的实时调试（在要求 /时，请直接使用/app/static/index.html服务/ ）您的nginx不会直接使用它，因为它不会运行它（只有您的python blask应用程序在调试模式下运行）。
from flask import Flask , send_file和
@ app . route ( '/' )
def route_root ():
index_path = os . path . join ( app . static_folder , 'index.html' )
return send_file ( index_path ) ...这确保您的应用程序还需要/时为/app/static/index.html文件服务。或者，如果您使用的是软件包结构，则/app/main/static/index.html文件。
而且，如果您使用的是水疗框架，以允许其处理浏览器中的URL，则您的Python烧瓶代码应具有以下部分：
# Everything not declared before (not a Flask route / API endpoint)...
@ app . route ( '/<path:path>' )
def route_frontend ( path ):
# ...could be a static file needed by the front end that
# doesn't use the `static` path (like in `<script src="bundle.js">`)
file_path = os . path . join ( app . static_folder , path )
if os . path . isfile ( file_path ):
return send_file ( file_path )
# ...or should be handled by the SPA's "router" in front end
else :
index_path = os . path . join ( app . static_folder , 'index.html' )
return send_file ( index_path ) ...这使得烧瓶在root（ / ）URL中请求时发送所有CSS，JavaScript和图像文件，但也确保您的前端Spa处理烧瓶应用程序中未定义的所有其他URL。
这就是在上面的教程中写入的，并包含在可下载的示例中。
如果您按照上述说明进行操作，则很可能在某个时候，您将编写会破坏烧瓶调试服务器的代码，并且会崩溃。
而且，由于运行的唯一过程是您的调试服务器，因此现在停止了，您的容器将停止。
然后，您将不得不在修复代码后再次启动容器，并且不会很容易地看到崩溃的服务器的错误。
因此，在开发过程中，您可以做以下操作（这就是我通常这样做的，尽管我使用Docker撰写，就像示例项目中一样）：
docker run -d --name mycontainer -p 80:80 -v $( pwd ) /app:/app -e FLASK_APP=main.py -e FLASK_DEBUG=1 myimage bash -c " while true ; do sleep 10 ; done "FLASK_APP=main/main.py ： docker run -d --name mycontainer -p 80:80 -v $( pwd ) /app:/app -e FLASK_APP=main/main.py -e FLASK_DEBUG=1 myimage bash -c " while true ; do sleep 10 ; done "docker exec -it mycontainer bash现在，您将在/app目录中的容器内部。
flask run --host=0.0.0.0 --port=80您将看到烧瓶调试服务器的启动，您将看到它如何发送对每个请求的响应，您将在打破代码时会看到错误以及它们如何停止服务器，并且您可以通过再次运行上面的命令来快速重新启动它。
测试了所有图像标签，配置，环境变量和应用程序选项。
issue-manager.yml 。 @tiangolo的PR＃385。latest-changes github动作。 @tiangolo的PR＃360。latest-changes.yml 。 PR＃348由@Alejsdev。README.md中的测试徽章。 PR＃346由@Alejsdev。 此版本的亮点：
python3.6-2022-11-25和python2.7-2022-11-25 。1.17.10 .3.11 .-index sufix tags.-index (use ENV STATIC_INDEX 1 instead).2020-05-04 .tiangolo/uwsgi-nginx-flask:python3.8-2019-10-14 . PR #154./start.sh and /app/prestart.sh functionality to parent image. PR #134.2019-02-02:
uwsgi-nginx and PR #121./app/nginx.conf file that overrides the generated one. PR #51 in the parent image uwsgi-nginx and PR #122.2019-01-01:
2018-12-29:
2018-11-23:
2018-09-22:
2018-06-22:
NGINX_WORKER_CONNECTIONS to set the maximum number of Nginx worker connections and NGINX_WORKER_OPEN_FILES to set the maximum number of open files. Thanks to ronlut in this PR.2018-06-22:
Improvements from parent image:
Make uWSGI require an app to run, instead of going in "full dynamic mode" while there was an error. Supervisord doesn't terminate itself but tries to restart uWSGI and shows the errors. Uses need-app as suggested by luckydonald in this comment.
Correctly handled graceful shutdown of uWSGI and Nginx. Thanks to desaintmartin in this PR.
2018-02-04:
It's now possible to set the number of Nginx worker processes with the environment variable NGINX_WORKER_PROCESSES . Thanks to naktinis in this PR.
2018-01-14:
python2.7-alpine3.7 and python3.6-alpine3.7 .2017-12-10:
/app/prestart.sh script to run arbitrary code before starting the app (for example, Alembic - SQLAlchemy migrations). The documentation for the /app/prestart.sh is in the main README./app is part of the PYTHONPATH environment variable. That allows global imports from several places, easier Alembic integration, etc. 2017-12-08: Now you can configure which port the container should listen on, using the environment variable LISTEN_PORT thanks to tmshn in this PR.
2017-09-10: Updated examples and sample project to work with SPAs even when structuring the app as a package (with subdirectories).
2017-09-02:
flask run commands, that allows running a package application while developing more easily.2017-08-10: Many changes:
python3.6 , python3.6-index , python.3.5 , python3.5-index , python2.7 and python2.7-index . All the other images are deprecated in favor is this ones.latest will point to Python 3.6 and the other tags will be removed.tiangolo/uwsgi-nginx that improved this image too.index.html directly: STATIC_INDEXNGINX_MAX_UPLOADuwsgi.ini file (that allows using a custom directory different than /app ): UWSGI_INI (using the ideas by @bercikr in #5 )../static/ path: STATIC_PATH/static/ URL: STATIC_URLDockerfile with: FROM tiangolo/uwsgi-nginx-flask:python3.6
COPY ./app /appand then customize with environment variables.
This project is licensed under the terms of the Apache license.
