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許可證的條款獲得許可的。
