大體想法以及背景:javascript
剛開始建立Django項目,能夠經過runserver命令更方便地調試程序,可是若是當一個項目完成了以後,須要部署到真正的環境,就須要考慮其穩定性。
以前在寫畢設的時候,寫過一個自動化運維監控的項目,部署在本身的阿里雲服務器上。那時候沒啥經驗,直接一個(pyhon runserver 0.0.0.0:8888 &)讓項目在後臺本身跑。因此對一些項目掛掉,數據庫鏈接失敗等問題不可以及時定位解決。
因此如今花點時間結合Nginx+Uwsgi部署本身的項目,利用Nginx處理靜態資源請求以及Uwsgi處理後臺的動態請求。php
pip安裝:pip install uwsgicss
源碼包安裝:wget https://files.pythonhosted.org/packages/a2/c9/a2d5737f63cd9df4317a4acc15d1ddf4952e28398601d8d7d706c16381e0/uwsgi-2.0.17.1.tar.gz
(解壓文件,安裝編譯)html
cd /data/wwwroot/DevOps/ (進入Django項目,如下是項目的目錄樹)java
uwsgi --http 0.0.0.0:8888 --file mysite/wsgi.py --static-map=/static=static
參數詳解:--http:啓動項目的IP地址和端口 --file:指定Django項目中wsgi文件,通常建立Django項目自動生成,--static-map:指定靜態資源存放的目錄python
啓動成功!!!nginx
建立uwsgi.ini配置文件數據庫
[uwsgi] chdir=/data/wwwroot/DevOps/ module=mysite.wsgi:application socket=/data/wwwroot/DevOps/uwsgi/uwsgi.sock workers=5 pidfile=/data/wwwroot/DevOps/uwsgi/uwsgi.pid http=192.168.1.1:8888 static-map=/static=/data/wwwroot/DevOps/static uid=root gid=root master=true vacuum=true thunder-lock=true enable-threads=true harakiri=30 post-buffering=4096 daemonize=/data/wwwroot/DevOps/uwsgi/uwsgi.log
uwsgi.ini配置文件參數重點詳解:
vacuum:自動移除unix Socket和pid文件當服務中止的時候;
thunder-lock:序列化接受的內容
enable-threads:啓用線程
harakiri:設置自中斷時間
post-buffering:設置緩衝json
對於安裝Nginx,本節忽略不講,主要是針對安裝玩Nginx,修改配置文件,添加虛擬主機。同時在前文也提到了,nginx對於處理靜態資源能力強,而對於動態請求,nginx將其轉發到uwsgi處理。
添加配置文件到/etc/nginx/conf.d/目錄下後端
server{ listen 80; server_name 192.168.1.1; access_log /data/wwwroot/DevOps/uwsgi/nginx/access.log main; error_log /data/wwwroot/DevOps/uwsgi/nginx/error.log; charset utf-8; gzip_types text/plain application/x-javascript text/css text/javascript application/x-httpd-php application/json text/json image/jpeg image/gif image/png application/octet-stream; location / { include uwsgi_params; uwsgi_connect_timeout 30; uwsgi_pass unix:/data/wwwroot/DevOps/uwsgi/uwsgi.sock; } location /static/{ alias /data/wwwroot/DevOps/static/; index index.html index.htm; } }
重要參數詳解:
gzip_types:支持的壓縮類型
uwsgi_connect_timeout:設置Uwsgi超時時間
uwsgi_pass:指定uwsgi的sock文件處理動態請求
使用(nginx -t)命令檢測nginx配置是否出錯,而後重啓nginx(systemctl restart nginx)
問題解決的方法:
經過查閱資料和整理文檔:
「But uWSGI logs these things for misbehaving clients. A write error would happen if the upstream got disconnected, but the backend process was still attempting to write to the closed socket.」
在配置文件最後添加:
ignore-sigpipe = true ignore-write-errors = true disable-write-exception = true
問題解決方法:
因爲接受uwsgi的應答的事件超時,因此發生504錯誤,經過修改nginx的uwsgi超時鏈接時間就能夠解決此類問題。
uwsgi_send_timeout 600; # 指定向uWSGI傳送請求的超時時間,完成握手後向uWSGI傳送請求的超時時間。 uwsgi_connect_timeout 600; # 指定鏈接到後端uWSGI的超時時間。 uwsgi_read_timeout 600; # 指定接收uWSGI應答的超時時間,完成握手後接收uWSGI應答的超時時間。