摘要:默認情況下,它是。它也是一個安全度量,所以調整為你的應用需要,而不是最大輸出。在運行的時候會把中的靜態文件拷貝到這個目錄中達到從開發環境到生產環節過程中移植靜態文件的作用。
本文由云+社區發表本文主要講述了如何一步步在生產環境上部署django和vue,操作系統默認為centos
說明:后文中出現的以下字符串均表示具體的路徑或者名稱,含義如下:
DJANGO_DIR----表示django的工程根目錄
DJANGO_NAME----表示django的工程名稱
VUE_HTML_DIR----表示vue編譯好的index.html路徑
VUE_STATIC_DIR----表示vue編譯好的靜態文件夾static的路徑
整體框架一個常用的web框架圖如下圖所示
框架選用.jpg
我們使用nginx + uwsgi來驅動django,因為uwsgi性能非常高
720333-20170312154455592-1425120615.png
一、安裝和配置nginx 安裝使用yum安裝即可
yum -y install nginx
啟動
service nginx start
此時到瀏覽器輸入對應的ip地址,出現下面頁面即表示安裝成功
1324702136-57fb16aa00d21_articlex.png
修改配置文件nginx可以新建一個配置,放在項目目錄,暫時不修改nginx的默認配置,端口號可以換一個,然后在/etc/nginx/conf.d/內新建一個軟鏈接指向該配置文件,這樣nginx在讀取配置時會將該配置一起讀進去。這樣,訪問端口號8080的請求便會指向我們自己的這個配置。
server { listen 8080; server_name 132.232.50.225; root /data/; charset utf-8; access_log /data/access_narwhals.log; error_log /data/error_narwhals.log; client_max_body_size 75M; location / { uwsgi_pass 127.0.0.1:9090; include /etc/nginx/uwsgi_params; } location ^~ /admin/ { uwsgi_pass 127.0.0.1:9090; include /etc/nginx/uwsgi_params; } }
該配置中uwsgi_pass要指向uwsgi綁定的接口。(我們先假設uwsgi配置的是9090端口)
二、安裝和配置uwsgi 安裝使用yum或者pip均可安裝
yum install uwsgi # 或者 pip install uwsgi
不過這里需要注意,如果運行uwsgi出現下面錯誤
uwsgi: option "--http" is ambiguous; possibilities: "--http-socket" "--https-socket-modifier2" "--https-socket-modifier1" "--https-socket" "--http11-socket" "--http-socket-modifier2" "--http-socket-modifier1" getopt_long() error
主要是用yum安裝的uwsgi,缺少python的plugin,可以安裝對應的插件
yum install uwsgi-plugin-python plugins = python (加在ini配置文件中)配置
uwsgi可以使用命令行啟動,也可以使用配置文件來啟動,推薦使用配置文件來啟動守護進程,配置文件內容如下
[uwsgi] socket = 127.0.0.1:9090 stats = 127.0.0.1:9293 workers = 4 # 項目根目錄 chdir = DJANGO_DIR touch-reload = DJANGO_DIR py-auto-reload = 1 # 在項目跟目錄和項目同名的文件夾里面的一個文件 module= DJANGO_NAME.wsgi pidfile = /var/run/inner_manager.pid daemonize = /data/uwsgi9090.log # If you plan to receive big requests with lots of headers you can increase this value up to 64k (65535). buffer-size=65535
這里以socket形式運行uwsgi,綁定了本地的9090端口,也就是上文nginx配置中uwsgi_pass指定的端口。
大概解釋下幾個配置的含義:
chdir----應用加載前chdir到指定目錄,一般設置為django的工程根目錄
touch-reload----如果修改/碰了指定的文件,那么重載uWSGI
module----加載一個WSGI模塊的路徑,如果django的話就指向對應的wsgi文件模塊
buffer-size----設置請求的最大大小 (排除request-body),這一般映射到請求頭的大小。默認情況下,它是4k。如果你接收到了一個更大的請求 (例如,帶有大cookies或者查詢字符串),那么你也許需要增加它。它也是一個安全度量,所以調整為你的應用需要,而不是最大輸出。該值如果太小會報錯
具體參數含義可以到官方文檔查找
然后使用命令啟動uwsgi進程,其中uwsgi.ini為上面內容的配置文件
uwsgi -i uwsgi.ini
可以看下日志文件有沒有報錯,或者看下ps -ef|grep uwsgi進程有沒有跑起來。一定要確保進程正常run起來才行
至此,DJANGO已經通過nginx+uwsgi可以訪問了
三、配置訪問vue其實這里訪問編譯好的vue靜態文件有很多方式,本文主要講述通過nginx直接訪問和通過django路由訪問
通過django路由訪問其實我們也可以直接通過http://ip:8080/ 來經由django的路由來訪問vue的頁面。當然要做到這樣要確保以下配置的正確
找到DJANGO_DIR根目錄下DJANGO_NAME同名文件夾下urls.py,使用通用視圖創建最簡單的模板控制器,增加一行路由
url(r"^$", TemplateView.as_view(template_name="index.html")),
這樣訪問http://ip:8080/時會直接返回 index.html。
上一步使用了Django的模板系統,所以需要配置一下模板使Django知道從哪里找到index.html。在project目錄的settings.py下:
TEMPLATES = [ { "BACKEND": "django.template.backends.django.DjangoTemplates", "DIRS": [VUE_HTML_DIR], "APP_DIRS": True, "OPTIONS": { "context_processors": [ "django.template.context_processors.debug", "django.template.context_processors.request", "django.contrib.auth.context_processors.auth", "django.contrib.messages.context_processors.messages", ], }, }, ]
按照上述配置完成后,結合前面配置好的nginx和uwsgi,你已經可以通過http://ip:8080/ 來訪問到對應的vue編譯好的VUE_HTML_DIR目錄下的index.html了,但是這時候你可能會有其他困擾,比如找不到css樣式文件的問,這經常是靜態配置有誤導致找不到靜態文件的問題。
Django通過django.contrib.staticfiles來管理靜態文件,首先確保django.contrib.staticfiles已經添加到INSTALLED_APPS。
然后可以在DJANGO的配置文件settings.py中增加以下幾個配置:
STATIC_URL = "/static/" STATIC_ROOT = os.path.join(BASE_DIR, "static") # Add for vuejs STATICFILES_DIRS = [ VUE_STATIC_DIR, # other static folders ]
STATIC_URL對外提供WEB訪問時static的URL地址
STATIC_ROOT設置絕對路徑, 用來保存收集到的靜態文件,服務器最終也將從該路徑中獲取文件進行轉發。在collectstatic運行的時候會把STATICFILES_DIRS中的靜態文件拷貝到這個目錄中,達到從開發環境到生產環節過程中移植靜態文件的作用。
STATICFILES_DIRS用來配置一些開發環境下生成的靜態文件的地址,即編譯好的VUE_STATIC_DIR
在url.py中添加路由
url(r"^static/(?P.*)$", static.serve, {"document_root": settings.STATIC_ROOT}, name="static"),
配置好以上配置后,編譯好的靜態文件還在VUE_STATIC_DIR目錄下,我們最終要執行下面命令才能把STATICFILES_DIRS中的靜態文件拷貝到STATIC_ROOT這個目錄中,也就是最終生產環境指定的static的存放目錄
python manage.py collectstatic
那么為什么不直接手動把構建好的VUE_STATIC_DIR中的文件拷過來呢,因為Django自帶的App:admin 也有一些靜態文件(css,js等),它會一并collect過來,畢竟nginx只認項目跟目錄的靜態文件,它不知道django把它自己的需求文件放到哪了
這樣你訪問django的admin網址http://ip:8080/admin 時,也不會出現找不到css的問題了
當然這種方式其實是通過django的路由來訪問靜態文件的,一般的,生產環境不會通過django來轉發靜態文件,而是通過其他服務器進行轉發,比如nginx,apache等,所以這里我們需要再配置下nginx的配置文件,在8080的server中增加如下路徑的配置
location /static/ { expires 30d; autoindex on; add_header Cache-Control private; alias VUE_STATIC_DIR; access_log off; }
這樣訪問靜態文件便會直接通過nginx來訪問了,不用擔心靜態文件訪問導致Django的處理速度變慢了。
通過nginx直接訪問如果你想直接通過nginx訪問對應的前端vue文件,可以重新配置一個server來訪問對應的html文件,比如上面已經使用了8080端口,我們可以用默認的80端口來配置個server,其中root可以指向存放index.html文件的路徑,/static/路徑下的root路徑可以指向html對應的存放css和js的static文件夾,如果static就在index.html路徑下,不指認也可以。直接修改/etc/nginx.conf即可,里面已經有配置好的80端口的server
配置如下所示
server { listen 80 default_server; listen [::]:80 default_server; server_name _; root VUE_HTML_DIR; # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location / { } location /static/ { root VUE_STATIC_DIR; access_log off; } error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } }
這樣我們可以通過http://ip:80/ 來訪問vue編譯好的頁面,使用http://ip:8080/ 訪問django配置的cgi請求
四、通過supervisor管理進程上面我們已經用到了uwsgi,后面可能還會用到redis、celery,都需要開啟守護進程,其中celery自身還不支持守護進程。那么如何管理這么多進程呢,這時候可以考慮下supervisor
安裝使用pip安裝即可
pip install supervisor配置
我們可以配置redis,celery,uwsgi進去,比如向下面一樣
[program:redis] ;指定運行目錄 directory=%(here)s/ ;執行命令(redis-server redis配置文件路徑) command=redis-server /etc/redis.conf ;啟動設置 numprocs=1 ;進程數 autostart=true ;當supervisor啟動時,程序將會自動啟動 autorestart=true ;自動重啟 ;停止信號 stopsignal=INT [program:celery.worker.default] ;指定運行目錄 directory=%(here)s/ ;運行目錄下執行命令 command=celery -A DjangoProject worker --loglevel info --logfile log/celery_worker.log -Q default -n %%h-%(program_name)s-%(process_num)02d process_name=%(process_num)02d ;啟動設置 numprocs=2 ;進程數 autostart=true ;當supervisor啟動時,程序將會自動啟動 autorestart=true ;自動重啟 ;停止信號,默認TERM ;中斷:INT (類似于Ctrl+C)(kill -INT pid),退出后會將寫文件或日志(推薦) ;終止:TERM (kill -TERM pid) ;掛起:HUP (kill -HUP pid),注意與Ctrl+Z/kill -stop pid不同 ;從容停止:QUIT (kill -QUIT pid) stopsignal=INT [program:uwsgi] ;指定運行目錄 directory=%(here)s/ ;運行目錄下執行命令 command=uwsgi -i conf/uwsgi/uwsgi9090.ini ;啟動設置 numprocs=1 ;進程數 autostart=true ;當supervisor啟動時,程序將會自動啟動 autorestart=true ;自動重啟 ;停止信號,默認TERM ;中斷:INT (類似于Ctrl+C)(kill -INT pid),退出后會將寫文件或日志(推薦) ;終止:TERM (kill -TERM pid) ;掛起:HUP (kill -HUP pid),注意與Ctrl+Z/kill -stop pid不同 ;從容停止:QUIT (kill -QUIT pid) stopsignal=INT使用
啟動supervisor輸入如下命令,使用具體的配置文件執行:
supervisord -c supervisord.conf
關閉supervisord需要通過supervisor的控制器:
supervisorctl -c supervisord.conf shutdown
重啟supervisord也是通過supervisor的控制器:
supervisorctl -c supervisord.conf reload一些特殊的變量
%(here)s 配置文件所在路徑 (program_name)s program的名字 %(process_num)02d 多進程時的進程號
注意:command中如果含有%,需要進行轉義%%
多進程時如果不指定process_name會遇到如下錯誤
Error: Format string "celery -A INTProject worker --loglevel info --logfile log/celery_worker.log -Q diff_task,caller_task -n %h" for "program:celery.worker.mac.command" is badly formatted: incomplete format in section "program:celery.worker.mac" (file: "supervisord.conf")中間可能遇到的坑 *8107 recv() failed (104: Connection reset by peer) while reading response header from upstream, client 錯誤
使用django+uwsgi+nginx,發現如下報錯
2018/10/08 14:34:33 [error] 12283#0: *8107 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 9.19.161.66, server: 132.232.50.225, request: "GET /auth/info?token=ZXlKaGJHY2lPaUprWldaaGRXeDBJaXdpZEhsd0lqb2lTbGRRSW4wOjFnOVA3aDp0bVZYcmg3XzJPR3RXSHJrbXFLRVdCZEpUdXc_ZXlKMWMyVnlibUZ0WlNJNkltVjBhR0Z1Wm1GdUlpd2lhV0YwSWpveE5UTTRPVGd3TkRjekxqZzVNekk1TVgwOjFnOVA3aDpMVXRHZkFiQkhrRTNaenFnS3NuS1RvOHBOMGM_3bdf34e6de16096f9982015a2382d3c8 HTTP/1.1", upstream: "uwsgi://127.0.0.1:9090", host: "int.oa.com", referrer: "http://int.oa.com/"
I finally found a reference to fastcgi and a 502 bad gateway error (https://support.plesk.com/hc/...). That lead me to look for a buffer size limit in the uwsgi configuration which exists as buffer-size. The default value is 4096. From the documentation, it says: If you plan to receive big requests with lots of headers you can increase this value up to 64k (65535).
意思是uwsgi中有一項配置是buffer-size,表明收到的最大請求size,默認是4096,可以將其改成65535
buffer-size=65535
此文已由作者授權騰訊云+社區發布
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/72654.html
摘要:默認情況下,它是。它也是一個安全度量,所以調整為你的應用需要,而不是最大輸出。在運行的時候會把中的靜態文件拷貝到這個目錄中達到從開發環境到生產環節過程中移植靜態文件的作用。 本文由云+社區發表本文主要講述了如何一步步在生產環境上部署django和vue,操作系統默認為centos 說明:后文中出現的以下字符串均表示具體的路徑或者名稱,含義如下: DJANGO_DIR----表示dj...
摘要:而大多數數據科學研究的場景下,更快的速度也意味著更早地發現問題和完成檢驗假設的閉環。通常,數據科學被認為研究成果立即應用到生產環境都是比較緩慢的一個過程。 showImg(https://segmentfault.com/img/remote/1460000005771293); 概述 在數據科學研究中,快速驗證想法是非常關鍵的一環,而如何快速開發出數據產品則可以有效推動整個數據科學項...
摘要:而大多數數據科學研究的場景下,更快的速度也意味著更早地發現問題和完成檢驗假設的閉環。通常,數據科學被認為研究成果立即應用到生產環境都是比較緩慢的一個過程。 showImg(https://segmentfault.com/img/remote/1460000005771293); 概述 在數據科學研究中,快速驗證想法是非常關鍵的一環,而如何快速開發出數據產品則可以有效推動整個數據科學項...
摘要:前端一種新一代高性能全棧開發實踐背景本項目將使用配合最簡單的邏輯來展示一個基于的全新一代高性能全棧開發實踐的為什么是對于為何不是等著名框架,或許可能很多人會產生疑惑,本身和非常的相似,而它的出現,不僅是大大改進過去時代性能低下通病,外加配 SanicCRUD-vue Sanic + 前端MVVM 一種新一代Python高性能全棧開發實踐showImg(https://segmentfa...
摘要:前端一種新一代高性能全棧開發實踐背景本項目將使用配合最簡單的邏輯來展示一個基于的全新一代高性能全棧開發實踐的為什么是對于為何不是等著名框架,或許可能很多人會產生疑惑,本身和非常的相似,而它的出現,不僅是大大改進過去時代性能低下通病,外加配 SanicCRUD-vue Sanic + 前端MVVM 一種新一代Python高性能全棧開發實踐showImg(https://segmentfa...
閱讀 1669·2021-11-19 09:40
閱讀 2924·2021-09-24 10:27
閱讀 3215·2021-09-02 15:15
閱讀 1876·2019-08-30 15:54
閱讀 1202·2019-08-30 15:54
閱讀 1369·2019-08-30 13:12
閱讀 626·2019-08-28 18:05
閱讀 2794·2019-08-27 10:53