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標籤。-index的標籤（而不是使用ENV STATIC_INDEX 1 ）。2020-05-04使用標籤。tiangolo/uwsgi-nginx-flask:python3.8-2019-10-14 。 PR＃154。/start.sh和/app/prestart.sh功能到父映像。 PR＃134。2019-02-02：
uwsgi-nginx和pr＃121中。/app/nginx.conf文件，該文件覆蓋生成的一個文件。 PR＃51在parent圖像uwsgi-nginx和pr＃122中。2019-01-01：
2018-12-29：
2018-11-23：
2018-09-22：
2018-06-22：
NGINX_WORKER_CONNECTIONS設置Nginx Worker連接的最大數量和NGINX_WORKER_OPEN_FILES來設置最大數量的打開文件。感謝Ronlut在此公關中。2018-06-22：
父母圖像的改進：
使UWSGI需要一個應用程序才能運行，而不是在出現錯誤時處於“完整動態模式”。主管沒有終止自身，而是試圖重新啟動UWSGI並顯示錯誤。 LuckyDonald在此評論中建議使用need-app 。
正確處理UWSGI和NGINX的優美關閉。感謝Disaintmartin在此公關中。
2018-02-04：
現在可以使用環境變量NGINX_WORKER_PROCESSES設置NGINX工作過程的數量。感謝Naktinis在此公關中。
2018-01-14：
python2.7-alpine3.7和python3.6-alpine3.7 。2017-12-10：
/app/prestart.sh腳本的支持以運行任意代碼（例如，alembic -sqlalchemy遷移）。 /app/prestart.sh的文檔在主要讀數中。/app是PYTHONPATH環境變量的一部分。這允許從幾個地方進口全球進口，更容易的Alembic集成等。 2017-12-08：現在，您可以使用Environment listial_port在此PR中使用環境變量LISTEN_PORT配置該容器應聆聽的哪個端口。
2017-09-10：更新的示例和示例項目，即使將應用程序作為包裝（使用子目錄）構造時，也可以與SPA合作。
2017-09-02：
flask run命令”，該命令允許在更容易開發的同時運行軟件包應用程序。2017-08-10：許多變化：
python3.6 ， python3.6-index ， python.3.5 ， python3.5-index ， python2.7和python2.7-index 。所有其他圖像都被貶低了這一點。latest標籤將指向Python 3.6，其他標籤將被刪除。tiangolo/uwsgi-nginx也有幾種改進，這也改進了此圖像。index.html ： STATIC_INDEXNGINX_MAX_UPLOADuwsgi.ini文件（允許使用與/app不同的自定義目錄）： UWSGI_INI （使用@bercikr的想法在＃5中使用）。./static/路徑： STATIC_PATH/static/ URL： STATIC_URLDockerfile FROM tiangolo/uwsgi-nginx-flask:python3.6
COPY ./app /app然後使用環境變量自定義。
該項目是根據Apache許可證的條款獲得許可的。
