2. flask**如何部署
3. 基於docker的flask**部署
flask+gunicorn+nginx是最常用的flask部署方案，大家深究過為何用這樣的搭配麼？
flask 是乙個web框架，而非web server，直接用flask拉起的web服務僅限於開發環境使用，生產環境不夠穩定，也無法承受大量請求的併發，在生茶環境下需要使用伺服器軟體來處理各種請求，如gunicorn、 nginx或apache，而gunicorn+nginx的搭配，好處多多，一方面基於nginx**gunicorn服務，在生產環境下能補充gunicorn服務在某些情況下的不足，另一方面，如果做乙個web**，除了服務外，還有很多靜態檔案需要被託管，這是nginx的強項，也是gunicorn不適合做的事情。所以，基於flask開發的**，部署時用gunicorn和nginx，是乙個很好的選擇。
1、為什麼需要nginx**gunicorn服務？
nginx功能強大，使用nginx有諸多好處，但用nginx**gunicorn服務，重點是解決「慢客戶端行為」給伺服器帶來的效能降低問題；另外，在網際網路上部署http服務時，還要考慮的「快客戶端響應」、ssl處理和高併發等問題，而這些問題在nginx上一併能搞定，所以在gunicorn服務之上加一層nginx反向**，是個一舉多得的部署方案。
2、為什麼會有「慢客戶端行為」帶來的服務效能降低問題？
伺服器和客戶端的通訊，我們簡略的分為三個部分：request，request handling，和response，即客戶端向伺服器發起請求，伺服器端響應並處理請求，和將請求結果返回客戶端，這三個過程。
通常，request handling這部分即服務端的計算，拼的是伺服器的效能，處理是比較高效和穩定的，而request和response部分，影響因素比較多，如果這三個過程放到同乙個程序中同步處理，如果request和response部分耗時比較多，會使計算資源被佔據並無法及時釋放，導致計算資源無法有效利用，降低伺服器的處理能力。
上述「慢客戶端行為」，指的就是request（或response）部分耗時比較多的情況，gunicorn恰好會把上面三個過程放到同乙個程序中，當出現「慢客戶端行為」時，效率很低：
gunicorn 是乙個pre-forking的軟體，這類軟體對低延遲的通訊，如負載均衡或服務間的互相通訊，是非常有效的。但pre-forking系統的不足是，每個通訊都會獨佔乙個程序，當向伺服器發出的請求多於伺服器可用的程序時，由於伺服器端沒有更多程序響應新的請求，其響應效率會降低。
對於web**或服務而言，由於request和response延時是不可控的，我們需要在考慮處理高延遲客戶端請求的情況。這些請求會佔據伺服器端的程序。當慢客戶端直接與服務通訊時，由於慢客戶端請求會佔據程序，可用於處理新請求的程序就會減少，如果有很多慢客戶端請求把所有程序都佔據後，新的請求只能等待有程序被釋放掉後，得到響應。另外，如果應用希望有更高的併發，伺服器與客戶端的通訊要更高效，非同步的通訊會比同步的通訊更有效。
nginx這類非同步的伺服器軟體擅長用很少的記憶體和cpu開銷來處理大量的請求。由於他們擅長於同時處理大量客戶端請求，所以慢客戶端請求對他們影響不大。就nginx而言，現在一般的伺服器硬體條件下，同時處理上萬個請求都不在話下。
所以把nginx擋在pre-forking服務前面處理請求是一種很好的選擇。nginx能夠非同步、高併發的響應客戶端request（慢客戶端請求對nginx影響不大），nginx一旦接收到的請求後立刻轉給gunicorn服務處理，處理結果再由nginx以response的形式發回給客戶端。這樣，整個服務端和客戶端的通訊，就由原來僅通過gunicorn的同步通訊，變成了基於nginx和gunicorn的非同步通訊，通訊效率和併發能力得到大大提公升。
用乙個伺服器軟體（如gunicorn）把flask寫好的應用拉起來
用nginx給上一步拉起的應用做乙個反向**
**涉及到的靜態檔案，用nginx做檔案託管
常見的伺服器軟體是gunicorn和uwsgi，由於gunicorn配置使用簡單，效率也不錯，gunicorn拉起flask**的配置極為簡單，所以通常用gunicorn來部署flask**是最常見的部署方案。（另，gevin個人還有乙個喜歡gunicorn的原因是，gunicorn是純python寫的，直接pip安裝即可，而uwsgi還要系統裝額外的依賴，這在與docker配合使用時，gunicorn的簡單性尤為突出）
對於靜態檔案的託管，由於在開發階段通常會基於flask框架做靜態檔案託管的實現，所以當用gunicorn拉起flask**時，**已經實現了基於gunicorn的檔案託管功能，所以配置nginx的靜態檔案託管url時，可以直接配置成與基於gunicorn託管一致的檔案路徑，這樣能簡化開發和部署的邏輯，而且由於nginx比gunicorn更靠外一層，客戶端請求靜態檔案時，nginx就直接返回response了，不用擔心會請求到gunicorn中去影響伺服器效率。
gunicorn安裝：
pip install gunicornserver
location /media
location /static
}
location /location /media
location /static
docker具有一次部署，到處執行的好處，把上述傳統部署的方法，封裝到docker image中，然後配合docker compose編排服務，在實踐中更方便。
# maintainer gevin
# docker-version 18.03.0-ce, build 0520e24
from python:3.6.5-alpine3.7
label maintainer=
mkdir -p /var/log/gunicorn
run pip install --no-cache-dir gunicorn && \
env port 8000
expose 8000 5000
cmd [
]
nginx上主要做反向**和靜態檔案託管，和上面的配置檔案一致，如：
server
location /media
location /static
}
octblog的docker-compose編排檔案如下：
version: '3'
services:
blog:
# restart: always
image: gevin/octblog:0.4.1
volumes:
env_file: .env
networks:
- webnet
mongo:
# restart: always
image: mongo:3.2
volumes:
- /users/gevin/projects/data/mongodb:/data/db
networks:
- webnet
blog-proxy:
# restart: always
image: nginx:stable-alpine
ports:
- "8080:80"
volumes:
- ./default.conf:/etc/nginx/conf.d/default.conf
- blog-static:/usr/share/nginx/html/static:ro
- blog-static:/usr/share/nginx/html/media:ro
networks:
- webnet
volumes:
blog-static:
networks:
webnet:
用乙個python wsgi http server來部署**，如:
green unicorn
uwsgi
mod_wsgi
cherrypy
用nginx做反向**
做好靜態檔案的託管
gunicorn 部署 flask 應用
一般比較習慣使用uwsgi進行部署django，flask應用。但，有時受許可權限制，無法安裝uwsgi，所以就使用gunicorn進行部署。之前使用python3的使用，發現 supervisor是不支援。所以就不打算用supervisor了。純粹介紹gunicorn 簡單部署方法，完整流程。環境...
Docker 部署 Flask 應用實踐
開啟docker 在專案目錄下編寫 dockerfile 檔案，以下是我專案中dockerfile檔案，並對每一行進行解讀 from python 3.6 專案的基礎映象為 python3.6 expose 8080 docker的指定出口埠為8080 run mkdir project name ...
Docker部署Flask應用的實現步驟
一 目的 本地寫好乙個flask應用，用docker封裝，上傳至自己的伺服器，完成部署。流程圖 二 實驗環境 本地 windows10 1909 伺服器 阿里雲centos系統 三 所需軟體 1.dockerdesktop 2.pycharm 2020.3.3 四 步驟 1.本地完成flask應用的...