meinheld gunicorn flask docker
0.5.0
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許可證的條款獲得許可的。
