原創博文地址:django進階04部署上線(nginx,uwsgi,supervisor)
django自身服務ok
python manage.py runserver，驗證可正常訪問
uwsgi安裝和服務驗證
安裝:pip Install uwsgi
測試代碼
1 2 3 4 5 |
def application(env, start_response):
start_response('200 OK', [('Content-Type','text/html')])
return [b"Hello World"]
```
執行下面命令行:
|
uwsgi –plugin python –http :8001 –wsgi-file test.py
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 |
重新訪問 localhost:8001 就可以看到 成功的顯示了 'Hello world' 如果報錯:error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory 解決方式： ``` sudo apt-get install libpcre3 libpcre3-dev # 安裝需要的包 find / -name libpcre.so.3 # 找到libpcre.so.3（一般在根目錄/lib/x86_64-linux-gnu下） 找到 /lib/x86_64-linux-gnu/libpcre.so.3 sudo ln -s /lib/x86_64-linux-gnu/libpcre.so.3 /usr/lib/libpcre.so.1 # 做軟鏈接即可 ``` ## uwsgi對接django配置ini ``` [uwsgi] #使用nginx連接時使用 #socket=127.0.0.1:8080 #正式上線後使用此模式，速度稍有優勢 #直接做web服務器使用 http=127.0.0.1:8080 #聯調階段優先使用http模式，方便定點測試 #項目目錄 chdir=/home/shuan/dailiyfresh #這裏可能需要多次嘗試，如果報錯can't find module **,大概率這裏問題 #項目中wsgi.py文件的目錄，相對於項目目錄 wsgi-file=dailiyfresh/wsgi.py #這裏儘可能使用絕對路徑避免踩坑 # 指定啓動的工作進程數 processes=4 # 指定工作進程中的線程數 threads=2 master=True # 保存啓動之後主進程的pid pidfile=uwsgi.pid # 設置uwsgi後臺運行，用uwsgi.log保存日誌信息 daemonize=uwsgi.log # 設置虛擬環境的路徑 virtualenv=/home/shuan/.virtualenvs/bj18_py3# conda 環境路徑 ``` 啓動：uwsgi --ini uwsgi.ini 停止：uwsgi --stop uwsgi.pid 啓動後訪問8080查看是否啓動成功。 ## uwsgi對接supervisor 安裝supervisor：pip install supervisor 生成初始配置文件：echo_supervisord_conf > /etc/supervisord.conf ``` [program:zqxt] command=/usr/bin/uwsgi(視環境情況 which uwsgi,本例用pip安裝應該是conda環境裏的uwsgi地址) --ini uwsgi_conf.ini #可終端單獨執行此命令，確保正確 directory=/path/to/zqxt#同uwsgi_conf的chdir，項目目錄 startsecs=0 stopwaitsecs=0 autostart=true #測試階段改爲false,讓錯誤暴露出來 autorestart=true #測試階段改爲false,讓錯誤暴露出來 ``` 修改:supervisor_conf |
redirect_stderr = true ; 把 stderr 重定向到 stdout，默認 false
stdout_logfile_maxbytes = 20MB ; stdout 日誌文件大小，默認 50MB
stdout_logfile = /data/log/plantool_stdout.log
stderr_logfile = /data/log/plantool_err.log
1 2 |
修改wsgi_conf.ini |
#daemonize=/var/log/uwsgi8011.log # 守護進程一定要註釋掉(關鍵)
1 2 |
功能測試 |
啓用config配置：supervisord -c /etc/supervisord.conf
supervisorctl status //查看所有進程的狀態
supervisorctl stop es //停止es
supervisorctl start es //啓動es
supervisorctl restart es //重啓es
supervisorctl update //配置文件修改後使用該命令加載新的配置
supervisorctl reload //重新啓動配置中的所有程序
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 |
啓動只是啓動conf配置，需要supervisorctl start 纔是真正啓動（也就是說，使用supervisorctl前必須先執行supervisord）
下面這一段描述問題在於supervisord當做開啓服務的了，其實不是，supervisord之後使用supervisorctl纔是真正開啓服務.
再次啓動，查看 supervisorctl status，狀態爲退出(exited)，可見出了問題，查看錯誤日誌plantool_err.log
thunder lock：search ，沒有效信息，所以這個可能是正常狀態的日誌。
猜--socket導致問題，搜索也沒發現有效信息，可能也是對的。
## nginx對接uwsgi
先確保nginx安裝成功
nginx安裝後：http://localhost,如果顯示nginx歡迎頁，說明nginx默認配置ok
修改nginx配置(大概意思)
```
server {
listen 80 ;
charset utf-8;
client_max_body_size 75M;
location /api { # 後臺api接口
proxy_pass 127.0.0.1:8080;
}
location /media {
alias /path/to/project/media;
}
location /static {
alias /path/to/project/static;
}
location / { # html資源文件
root /path/to/template;
index index.html;
}
}
```
先測試後端接口:127.0.0.1:8080/api/,ok
再測試轉發接口:127.0.0.1:80/api/,是否正確轉發.
最後再測試html,靜態文件(static),媒體文件(media）等.
可能問題：報錯nginx: [emerg] getgrnam("nginx") failed：https://blog.csdn.net/qq_39556759/article/details/78406813
解決方法：
vim /aplication/nginx/conf/nginx.conf
去掉user nobody之前的#號（也就是說啓用user 的配置項）
可能問題：訪問Html,css,js資源文件，報錯，13: Permission denied
前端，templates/index.html，無權限
權限不足的解決方案:
一、由於啓動用戶和nginx工作用戶不一致所致（user配置項配置錯誤）
01，查看nginx的啓動用戶，發現是nobody，而非root啓動的
命令：ps aux | grep "nginx: worker process" | awk'{print $1}'
02，將nginx.config的user改爲和啓動用戶一致，
命令：vi conf/nginx.conf
這一步，根據個人經驗，**應該修改爲"/html/or/templates/目錄擁有者的用戶"和組信息**，比如
當前爲用戶john(/templates/擁有者，負責啓動nginx的人，是否有root權限無所謂),則通過"id john"查看所屬組,比如 work組
則配置:"user john work"，**效果是啓動後的nginx子進程顯示的啓動者是john**（而實際nginx啓動者可能是別人，有root權限的其他人）
這一步可能需要多做嘗試，本人這一步卡了好久，嘗試了很多組合，最後才發現正確配置(主要是網上教程差異很大，拜版本不同所賜，踩坑頗多)
|
user www-data #nginx -t 測試通過,啓動後訪問權限不足
user nobody # nginx -t 測試不通過,
user john # nginx -t 測試不通過,（john無root權限，無法啓動nginx，但是templates目錄擁有者）
user yyyy # nginx -t 測試不通過,（yyyy有root權限，且是nginx服務啓動者）
刪除:user 這一行 # nginx -t 測試通過,啓動後訪問權限不足
user work john # nginx -t 測試不通過,
user work yyyy # nginx -t 測試不通過,
user john work # nginx -t 測試通過,啓動後訪問ok
1 2 3 4 |
二、templates權限問題，**如果nginx沒有web目錄的操作權限，也會出現403錯誤**。 解決辦法：修改web目錄的讀寫權限，或者是把nginx的啓動用戶改成目錄的所屬用戶，重啓Nginx即可解決 |
chmod -R 777 /data
chmod -R 777 /data/www/
1 2 3 4 5 6 7 8 9 10 11 12 13 |
## 驗證無問題後的進一步改進 01，nginx的轉發（到uwsgi），從http轉發模式改爲socket轉發模式（nginx.conf,uwsgi.conf）（對接階段使用http，方便獨立的正確性驗證。正式環境改爲socket模式，保證速度以及減少端口占用。） 02，supervisord.conf配置的autostart和autorestart改爲true。確保進程死機後自動重啓。 03，檢查各路徑配置，是否有私有路徑（別人無法訪問的路徑）,可能導致別人無法啓動項目。 ## 其他注意事項 ### 啓用django後臺管理admin模塊 啓用admin後會發現無法進入登錄界面（部分資源無法加載static/admin/simple-ui/xxxx） 原因：問題admin/下的靜態資源無法訪問。 大部分項目前後端完全分離，所以templates和static一般都是前端組提供，我們想當然就用了，而實際上django_admin模塊內部也包含部分靜態資源，當使用django內置服務器時可以檢索到，但如果部署到線上則必須將admin內靜態文件導出，整合到統一的templates目錄中(讓nginx檢索到)。 解決： |
python manage collectstatic # 自動收集靜態文件到django_setting配置的STATIC_ROOT中
cp STATIC_ROOT templates/static
chmod -R 777 xxx
`
參考
linux下部署Django uwsgi: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory:https://www.cnblogs.com/erhangboke/p/11673156.html
初次使用uwsgi:no python application found, check your startup logs for errors:https://www.cnblogs.com/loveyangaddddd/p/8119720.html
uWSGI出現錯誤：no python application found, check your startup logs for errors:https://blog.csdn.net/weixin_40576010/article/details/89000128
supervisor管理uwsgi：https://www.cnblogs.com/supery007/p/9368242.html
Django 部署(Nginx)：https://code.ziqiangxuetang.com/django/django-nginx-deploy.html
使用supervisor作爲uWSGI的守護進程:luchanghong.lofter.com/post/f04c0_242345
Supervisor使用詳解:https://www.jianshu.com/p/0b9054b33db3
解決Nginx出現403 forbidden (13: Permission denied)報錯的四種方法：https://www.cnblogs.com/williamjie/p/9604594.html
nginx 錯誤集錦：https://www.jianshu.com/p/3de849802a89
Nginx之proxy_pass指令url反斜槓作用：https://blog.csdn.net/sleepIII/article/details/100787652