簡介面向CentOS運(yùn)維與Django開發(fā)者的實(shí)戰(zhàn)教程系統(tǒng)講解如何借助寶塔面板快速完成Django項(xiàng)目部署。教程從安裝寶塔面板、Python項(xiàng)目管理器和Nginx等基礎(chǔ)環(huán)境講起覆蓋項(xiàng)目代碼上傳、Python/Django項(xiàng)目創(chuàng)建、域名映射、Nginx反向代理及靜態(tài)/媒體文件配置等關(guān)鍵步驟并附有重啟與加載配置的完整流程。資源為1個(gè)PDF文件壓縮包大小僅139KB內(nèi)容精煉適合Linux基礎(chǔ)薄弱、希望采用可視化面板管理服務(wù)的初學(xué)者參考。該教程已有2371人學(xué)習(xí)步驟中兼顧常見路徑與端口設(shè)置提醒能幫助讀者避開部署過程中的典型坑點(diǎn)快速搭建可正常訪問且支持靜態(tài)資源的Django站點(diǎn)。1. 一臺 CentOS 上讓 Django 跑起來為什么繞不開寶塔面板在 CentOS 上部署 Django 項(xiàng)目最折磨人的往往不是 Django 本身而是它周圍那一圈基礎(chǔ)設(shè)施Python 版本對不對、Nginx 怎么轉(zhuǎn)發(fā)、uwsgi 日志去哪看、MySQL 的 socket 通不通。每一樣單拎出來都能查半天資料組合在一起就成了新手眼里的黑匣子。寶塔面板把 Nginx、MySQL、Redis 這些服務(wù)的安裝和運(yùn)維收斂成圖形化操作你只需要把精力放在 Django 項(xiàng)目的配置和 uWSGI 的銜接上這條路也是目前個(gè)人站長和小團(tuán)隊(duì)部署 Django 最多人走通的一條線。這套組合適合兩類人一是本地能跑 python manage.py runserver、但第一次面對服務(wù)器的初學(xué)者二是手里同時(shí)維護(hù)多個(gè)站點(diǎn)、不想為每個(gè)環(huán)境重復(fù)編譯 Nginx 和數(shù)據(jù)庫的開發(fā)者。有人會(huì)問 1panel 和寶塔哪個(gè)好我的觀點(diǎn)很直接如果你只是要快速把 Django 項(xiàng)目掛上線選寶塔更省事因?yàn)樗慕坛坛恋碜銐蚨嗖瓤佑涗浺不径寄芩训?。本文從裝系統(tǒng)前的檢查講起一路到用 uWSGI 和 Nginx 把項(xiàng)目真正跑起來最后收在部署完的自檢清單上照著做一遍你就能獲得一臺從外網(wǎng)訪問的 Django 服務(wù)。2. 裝寶塔前先摸清家底CentOS 版本、內(nèi)存下限與軟件源2.1 系統(tǒng)選擇CentOS 7.9 仍是主流先看三行命令的結(jié)果部署 CentOS 服務(wù)器第一步不是下載鏡像而是先確認(rèn)三件事系統(tǒng)版本、內(nèi)存大小、磁盤空間。登錄服務(wù)器后先執(zhí)行下面這組命令cat /etc/redhat-release free -h df -h /www /home /var第一行看系統(tǒng)發(fā)行版第二行看內(nèi)存總量和已用內(nèi)存第三行看磁盤剩余空間。之所以強(qiáng)調(diào)先看這三項(xiàng)是因?yàn)楹罄m(xù)裝寶塔面板時(shí)內(nèi)存和磁盤會(huì)直接決定你是否要加班加點(diǎn)處理環(huán)境問題。手動(dòng)裝系統(tǒng)時(shí)鏡像建議選 CentOS 7.9 的 Minimal 版本帶桌面的版本會(huì)白白吃掉幾百兆內(nèi)存下載 ISO 時(shí)別在官網(wǎng)到處亂找國內(nèi)鏡像站基本都保留了完整版本速度也更快。CentOS 7 已經(jīng)停止官方維護(hù)有個(gè)現(xiàn)實(shí)問題新裝的 7.9 系統(tǒng)默認(rèn) YUM 源可能已經(jīng)失效執(zhí)行 yum install 直接報(bào)錯(cuò)或者拉不到包。這種情況不是錯(cuò)覺是源地址指向了已歸檔的倉庫。換源這一步在裝任何軟件之前做掉否則后面每一步都會(huì)卡殼cd /etc/yum.repos.d/ sed -i s/mirrorlist/#mirrorlist/g CentOS-Base.repo sed -i s|#baseurlhttp://mirror.centos.org|baseurlhttp://vault.centos.org|g CentOS-Base.repo yum clean all yum makecache這段操作把原來的 mirrorlist 注釋掉將鏡像源切到 Vault 歸檔倉庫讓已經(jīng)停止維護(hù)的 CentOS 7 仍能繼續(xù)安裝和更新軟件包。執(zhí)行完 makecache 不報(bào)錯(cuò)說明源已經(jīng)通了。這一步做完不要急著裝東西順手再確認(rèn)一個(gè)容易被忽略的細(xì)節(jié)系統(tǒng)自帶的 python3 版本。CentOS 7.9 默認(rèn)自帶的是 Python 3.6而 Django 4 以上的框架版本要求 Python 3.8 起步這個(gè)版本差異會(huì)在后面裝依賴時(shí)被放大成一道坎。具體怎么解決到第三章我會(huì)展開說。2.2 寶塔面板安裝失敗的內(nèi)幕至少 3700MB 內(nèi)存的本意是什么寶塔面板的安裝腳本對內(nèi)存有硬性檢查低于 3700MB 會(huì)直接拒絕安裝報(bào)錯(cuò)信息大意是“至少需要 3700MB 內(nèi)存才能安裝”。這個(gè)數(shù)字第一次見的人會(huì)覺得莫名其妙其實(shí)它是面板用來保證運(yùn)行時(shí) PHP、MySQL、Nginx 三個(gè)服務(wù)能同時(shí)駐留內(nèi)存的經(jīng)驗(yàn)值。如果你手上是一臺 1G 或 2G 內(nèi)存的輕量服務(wù)器不要硬著頭皮重復(fù)執(zhí)行安裝腳本先補(bǔ)一塊 swap 交換分區(qū)if [ ! -f /swapfile ]; then dd if/dev/zero of/swapfile bs1M count2048 chmod 600 /swapfile mkswap /swapfile swapon /swapfile echo /swapfile swap swap defaults 0 0 /etc/fstab fi free -h這段腳本創(chuàng)建一個(gè) 2GB 的 swapfile賦予 600 權(quán)限防止普通用戶讀取格式化為 swap 分區(qū)并臨時(shí)啟用最后寫入 /etc/fstab 讓重啟后仍然生效。dd 的 bs1M count2048 表示按 1MB 塊大小寫 2048 次總共生成 2GB 文件這個(gè)大小對寶塔安裝足夠?qū)φ竭\(yùn)行則偏緊。swap 是用磁盤換內(nèi)存讀寫速度比物理內(nèi)存慢得多真正跑生產(chǎn)時(shí)建議還是升級內(nèi)存swap 只作為兜底不能指望它讓項(xiàng)目流暢運(yùn)行。安裝面板本身沒有特別多的技巧到官網(wǎng)復(fù)制針對 CentOS 的安裝命令一條 curl 或 wget 命令下載安裝腳本然后 bash 執(zhí)行。注意不要直接在服務(wù)器上亂搜安裝包以官網(wǎng)當(dāng)前提供的腳本為準(zhǔn)。安裝過程持續(xù)幾分鐘期間保持 SSH 連接穩(wěn)定輸出里出現(xiàn)面板地址、賬號和初始密碼后要及時(shí)記下來尤其是那個(gè)安全入口的路徑后綴是一次性的忘了只能去配置文件里翻。2.3 面板初始化和軟件選型Nginx、MySQL 先裝Python 的坑單獨(dú)講第一次登錄寶塔面板會(huì)要求綁定賬號并設(shè)置安全入口。綁定這一步按流程走就行不綁定后面沒法繼續(xù)使用面板功能。進(jìn)入面板首頁后系統(tǒng)會(huì)提示安裝推薦軟件。在這里不要一鍵全裝只選需要的那幾項(xiàng)Nginx 選穩(wěn)定版用來做反向代理和靜態(tài)文件分發(fā)MySQL 選 5.7 或 8.0具體取決于你在本地開發(fā)時(shí)用的哪個(gè)版本跨大版本遷移數(shù)據(jù)容易出現(xiàn)字符集和排序規(guī)則不一致的問題PHP 如果項(xiàng)目用不到就完全跳過它除了增加內(nèi)存占用沒有意義。Python 環(huán)境的坑比較隱蔽。寶塔的“軟件商店”里有個(gè) Python 項(xiàng)目管理器聽起來很省事但它的虛擬環(huán)境和真實(shí)服務(wù)器環(huán)境經(jīng)常有版本錯(cuò)位尤其當(dāng)你需要 Python 3.8 時(shí)面板可能提供的還是 3.6。我一般不會(huì)把希望全部寄托在面板插件上而是直接在服務(wù)器上檢查現(xiàn)有 Python 版本再?zèng)Q定是用 pyenv 裝新版還是直接編譯安裝。這一步先不做留到項(xiàng)目依賴安裝時(shí)再說。到這里CentOS 系統(tǒng)、軟件源、寶塔面板三件事已經(jīng)搞定可以正式進(jìn)入 Django 項(xiàng)目的改造環(huán)節(jié)。3. 上線前的三個(gè)必改項(xiàng)settings、依賴鎖定與數(shù)據(jù)庫切換3.1 settings.py 的四處改動(dòng)從本地能跑到服務(wù)器能跑的差距本地開發(fā)時(shí) Django 項(xiàng)目跑得再歡也不能把代碼原封不動(dòng)丟到服務(wù)器上。本地和服務(wù)器環(huán)境的差異大部分集中在 settings.py 里。一個(gè)最常見的翻車現(xiàn)象是代碼上傳后頁面打開直接報(bào)錯(cuò)瀏覽器提示“DisallowedHost”這就是 ALLOWED_HOSTS 沒配置導(dǎo)致的。部署前需要改動(dòng)的關(guān)鍵配置如下from pathlib import Path import os BASE_DIR Path(__file__).resolve().parent.parent DEBUG False ALLOWED_HOSTS [example.com, www.example.com] SECRET_KEY os.environ.get(DJANGO_SECRET_KEY, 一串足夠長的隨機(jī)字符) DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: django_project, USER: django_user, PASSWORD: 你的數(shù)據(jù)庫密碼, HOST: 127.0.0.1, PORT: 3306, OPTIONS: {charset: utf8mb4}, } } STATIC_ROOT BASE_DIR / staticfiles MEDIA_ROOT BASE_DIR / media STATIC_URL /static/ MEDIA_URL /media/DEBUG 必須設(shè)為 False否則服務(wù)器會(huì)直接把堆棧信息暴露給訪問者這不僅是安全問題還會(huì)讓頁面渲染速度明顯變慢。ALLOWED_HOSTS 填你實(shí)際要使用的域名或服務(wù)器 IP多個(gè)域名用逗號分隔開發(fā)階段臨時(shí)用 [*] 也不是不行但上線前一定要收斂。SECRET_KEY 在本地開發(fā)時(shí)往往直接寫在配置里到了服務(wù)器最好改成從環(huán)境變量讀取避免代碼倉庫泄露導(dǎo)致簽名被偽造。最容易被漏掉的是 STATIC_ROOT 和 MEDIA_ROOT這兩個(gè)路徑?jīng)Q定 collectstatic 把靜態(tài)文件收攏到哪里以及用戶上傳的文件落在哪個(gè)目錄后面配 Nginx 時(shí)alias 路徑要和這兩個(gè)值完全對應(yīng)。3.2 用虛擬環(huán)境鎖定依賴pip freeze 不是萬能的依賴管理的目標(biāo)只有一個(gè)本地能跑的庫服務(wù)器上裝出同一套。很多人習(xí)慣在本地執(zhí)行 pip freeze requirements.txt然后把這個(gè)文件傳到服務(wù)器直接 pip install -r結(jié)果發(fā)現(xiàn)要么裝出一堆無關(guān)包要么因版本沖突當(dāng)場報(bào)錯(cuò)。pip freeze 會(huì)把本地環(huán)境里所有包都導(dǎo)出其中很多是只有開發(fā)才需要的工具這類雜訊會(huì)讓排查變得很困難。我習(xí)慣手動(dòng)維護(hù)一份最小依賴清單只在 requirements.txt 里寫項(xiàng)目真正用到的框架和庫Django4.2.7 mysqlclient2.2.0 uWSGI2.0.23 gunicorn21.2.0固定版本號是必須的Django 4.2 和 Django 5.0 在兼容性上有明顯差異不鎖版本等于把線上環(huán)境交給運(yùn)氣。到了服務(wù)器的項(xiàng)目目錄下創(chuàng)建虛擬環(huán)境并安裝依賴cd /www/wwwroot/django_project python3 -m venv venv source venv/bin/activate pip install --upgrade pip pip install -r requirements.txtpython3 -m venv 是創(chuàng)建虛擬環(huán)境的命令后續(xù)安裝的包都會(huì)落到 venv 目錄下不會(huì)污染系統(tǒng)環(huán)境。source venv/bin/activate 激活環(huán)境后命令行提示符會(huì)帶上 (venv) 前綴這代表當(dāng)前處于虛擬環(huán)境內(nèi)。如果服務(wù)器自帶的 Python 版本低于項(xiàng)目要求比如 Django 5.0 項(xiàng)目配 Python 3.6創(chuàng)建虛擬環(huán)境這步就會(huì)失敗或裝不上依賴這時(shí)先解決 Python 版本問題再回頭繼續(xù)。解決方式是編譯安裝新版 Python下載源碼包、配置 prefix、make install整個(gè)過程約十幾分鐘編譯前要保證系統(tǒng)已安裝 gcc 和 make這一步?jīng)]有捷徑。3.3 數(shù)據(jù)庫從 SQLite 切換到 MySQL先建庫再 migrateDjango 默認(rèn)的 SQLite 適合開發(fā)和測試但到了服務(wù)器上并發(fā)寫入和多進(jìn)程訪問會(huì)成為瓶頸。寶塔面板里切換 MySQL 的操作很簡單進(jìn)入面板的數(shù)據(jù)庫頁面點(diǎn)擊添加數(shù)據(jù)庫填上庫名和用戶名生成一個(gè)隨機(jī)密碼。這里要留意“訪問權(quán)限”這一項(xiàng)選擇“本地服務(wù)器”即可不需要勾選遠(yuǎn)程訪問因?yàn)?Django 和 MySQL 在同一臺機(jī)器上通信走 127.0.0.1 就夠了。數(shù)據(jù)庫建好之后回到服務(wù)器端的項(xiàng)目目錄先安裝驅(qū)動(dòng)再執(zhí)行遷移source /www/wwwroot/django_project/venv/bin/activate pip install mysqlclient python manage.py migratemysqlclient 是 Django 官方文檔推薦的 MySQL 驅(qū)動(dòng)但它依賴系統(tǒng)的 mysql-devel 和 gcc 才能編譯。寶塔環(huán)境里經(jīng)常遇到編譯失敗報(bào)錯(cuò)信息指向缺少頭文件解決方法是先 yum install mysql-devel gcc python3-devel再重新安裝。如果實(shí)在編譯不過退路是改用 PyMySQL在項(xiàng)目目錄的init.py 或 settings.py 里加兩行把 pymysql 偽裝成 mysqldb。這個(gè)方法相對省事但復(fù)雜查詢場景下兼容性不如官方驅(qū)動(dòng)所以編譯這條路能走通就優(yōu)先走通。migrate 成功之后緊接著執(zhí)行 collectstatic把項(xiàng)目依賴的靜態(tài)文件統(tǒng)一收攏到之前配置好的 STATIC_ROOT 目錄python manage.py collectstatic --noinput--noinput 參數(shù)讓命令不再交互式確認(rèn)適合在部署腳本里直接執(zhí)行。執(zhí)行完成后檢查一下 staticfiles 目錄里是否出現(xiàn)了 admin 子目錄這是 Django 后臺管理界面的樣式文件出現(xiàn)即說明收集成功。到這里項(xiàng)目代碼本身已經(jīng)具備了被服務(wù)器承載的條件下一步要解決的是怎么讓它常駐運(yùn)行——這份工作落到 uWSGI 頭上。4. uWSGI 接管 Django進(jìn)程參數(shù)、配置文件與 supervisor 守護(hù)4.1 為什么上線不能用 runserver開發(fā)服務(wù)器的三個(gè)天花板python manage.py runserver 是 Django 自帶的開發(fā)服務(wù)器它天生只為一個(gè)場景設(shè)計(jì)你在本地改代碼它自動(dòng)重載并顯示詳細(xì)報(bào)錯(cuò)。到了生產(chǎn)環(huán)境runserver 有三個(gè)致命問題單進(jìn)程處理請求CPU 多核完全用不上沒有進(jìn)程守護(hù)SSH 斷開后服務(wù)跟著退出性能上限極低稍微有點(diǎn)并發(fā)就會(huì)出現(xiàn)請求排隊(duì)。解決這個(gè)問題的通用做法是用 WSGI 服務(wù)器承載 Django 應(yīng)用常見選擇是 uWSGI 或 gunicorn。uWSGI 和 gunicorn 都符合 WSGI 協(xié)議但 uWSGI 對 Nginx 的 unix socket 支持成熟再加上一個(gè) uWSGI 進(jìn)程可以同時(shí)管理多進(jìn)程和多線程我這邊部署 Django 項(xiàng)目基本都是 uWSGI 優(yōu)先。4.2 最小可運(yùn)行的 uWSGI 配置每個(gè)參數(shù)都對應(yīng)一個(gè)線上問題uWSGI 可以直接用命令行參數(shù)啟動(dòng)但參數(shù)一多就變成災(zāi)難。我習(xí)慣把配置寫進(jìn)一個(gè) ini 文件隨項(xiàng)目一起管理。下面是一個(gè)最小可運(yùn)行的配置放在項(xiàng)目目錄的 deploy/uwsgi.ini 下[uwsgi] chdir /www/wwwroot/django_project module django_project.wsgi:application master true processes 4 threads 2 socket /tmp/django_project.sock chmod-socket 664 vacuum true max-requests 5000 daemonize /var/log/django_project_uwsgi.log pidfile /var/run/django_project.pid逐項(xiàng)說明這幾個(gè)參數(shù)的作用chdir 指定項(xiàng)目根目錄也就是 manage.py 所在的位置uWSGI 啟動(dòng)后會(huì)先切換到這個(gè)目錄保證相對路徑的準(zhǔn)確性。module 指向項(xiàng)目內(nèi) wsgi.py 暴露出的 application 對象這個(gè)對象是 Django 和 WSGI 服務(wù)器之間的橋梁路徑格式是“項(xiàng)目配置包名.wsgi:application”。master 設(shè)為 true 后uWSGI 會(huì)啟動(dòng)一個(gè)主進(jìn)程來管理子進(jìn)程主進(jìn)程負(fù)責(zé)回收異常退出的 worker這是服務(wù)穩(wěn)定性的基礎(chǔ)。processes 和 threads 配合決定并發(fā)模型4 個(gè)進(jìn)程乘 2 個(gè)線程等于 8 個(gè)并發(fā)處理單元對一臺 2 核服務(wù)器來說已經(jīng)是合理配置別再往上加進(jìn)程太多反而會(huì)因?yàn)樯舷挛那袚Q降低吞吐。socket 參數(shù)指定監(jiān)聽的本地 socket 文件uWSGI 與 Nginx 就通過這個(gè)文件通信而不是占用 TCP 端口。chmod-socket 設(shè)成 664是為了讓 Nginx 的 www 用戶能讀寫這個(gè) socket 文件否則后面會(huì)出現(xiàn) 403 權(quán)限錯(cuò)誤。vacuum 在進(jìn)程退出時(shí)自動(dòng)清理 socket 文件避免殘留文件導(dǎo)致下次啟動(dòng)報(bào)“Address already in use”。max-requests 讓每個(gè) worker 處理滿 5000 個(gè)請求后自動(dòng)重啟一次這是對抗內(nèi)存泄漏的土辦法比寫監(jiān)測腳本省心。daemonize 把日志寫入獨(dú)立文件pidfile 記錄主進(jìn)程號這兩個(gè)配合起來方便排查問題和做優(yōu)雅重啟。第一次啟動(dòng)可以不開 daemonize前臺運(yùn)行看輸出確認(rèn)無誤后再以守護(hù)方式正式拉起來cd /www/wwwroot/django_project venv/bin/uwsgi --ini deploy/uwsgi.ini執(zhí)行后觀察日志輸出的最后幾行如果出現(xiàn)“WSGI app 0 (mountpoint) ready”的字樣說明 uWSGI 已經(jīng)成功加載了 Django 應(yīng)用。4.3 用 supervisor 守護(hù) uWSGI進(jìn)程死了能自己爬起來uWSGI 能跑起來不代表能一直跑下去。進(jìn)程被系統(tǒng)殺掉、服務(wù)器重啟、代碼異常導(dǎo)致崩潰這些情況都需要一個(gè)外部機(jī)制把 uWSGI 拉起來。常見做法是 systemd 服務(wù)或 supervisor。寶塔面板的“進(jìn)程守護(hù)管理器”插件也能干這活但插件版本更新慢而且配置方式繞了一圈還是在寫 supervisor 的配置文件。直接用 supervisor 更透明配置如下保存到 /etc/supervisord.d/django_project.ini[program:django_project] command/www/wwwroot/django_project/venv/bin/uwsgi --ini /www/wwwroot/django_project/deploy/uwsgi.ini autostarttrue autorestarttrue redirect_stderrtrue stdout_logfile/var/log/django_project_supervisor.log stopsignalINTcommand 必須寫 uWSGI 的完整路徑因?yàn)?supervisor 啟動(dòng)時(shí)的環(huán)境變量和當(dāng)前 SSH 會(huì)話不同直接寫 uwsgi 可能找不到命令。autostart 讓 supervisor 啟動(dòng)時(shí)就拉起 uWSGIautorestart 在進(jìn)程異常退出后自動(dòng)重新拉起這兩項(xiàng)配合起來相當(dāng)于給服務(wù)上了雙重保險(xiǎn)。redirect_stderr 把 uWSGI 的錯(cuò)誤輸出合并到主日志省得分開看兩個(gè)日志文件。stopsignal 用 INT 信號讓 uWSGI 收到停止指令時(shí)優(yōu)雅退出等當(dāng)前請求處理完再關(guān)閉進(jìn)程而不是立刻殺死。配置寫好后執(zhí)行 supervisorctl update 加載新配置再執(zhí)行 supervisorctl status 檢查狀態(tài)supervisorctl update supervisorctl status django_project看到狀態(tài)為 RUNNING 就是正常。這套進(jìn)程守護(hù)方式不只是 Django 能用以后再部署 agent 服務(wù)、定時(shí)任務(wù)腳本或者其他任何需要常駐的程序都可以照這個(gè)模板套一層 supervisor通用性很強(qiáng)。到這里Django 已經(jīng)被 uWSGI 跑起來了但外網(wǎng)訪問還需要 Nginx 在前面做中轉(zhuǎn)下一章就處理這部分。5. Nginx 反向代理與靜態(tài)文件寶塔站點(diǎn)配置與避坑排查5.1 在寶塔里添加站點(diǎn)并寫入 uwsgi_pass 轉(zhuǎn)發(fā)規(guī)則uWSGI 通過 socket 文件對外提供 Web 服務(wù)但它不適合直接暴露給公網(wǎng)用戶前面還需要一層 Nginx。Nginx 在這里干兩件事把 HTTP 請求轉(zhuǎn)成 uWSGI 協(xié)議發(fā)給 Django以及高效地吐出靜態(tài)文件。寶塔里操作 Nginx 不需要手動(dòng)編輯主配置進(jìn)入“網(wǎng)站”頁面點(diǎn)擊“添加站點(diǎn)”填入你的域名或服務(wù)器 IPPHP 版本選擇純靜態(tài)提交后站點(diǎn)目錄會(huì)自動(dòng)創(chuàng)建配置文件也生成好了。接下來進(jìn)入站點(diǎn)的設(shè)置面板找到配置文件編輯入口在默認(rèn)的 server 塊里加入 Django 的轉(zhuǎn)發(fā)和靜態(tài)文件規(guī)則server { listen 80; server_name example.com; access_log /www/wwwlogs/example.com.log; error_log /www/wwwlogs/example.com.error.log; location /static/ { alias /www/wwwroot/django_project/staticfiles/; } location /media/ { alias /www/wwwroot/django_project/media/; } location / { include uwsgi_params; uwsgi_pass unix:///tmp/django_project.sock; uwsgi_read_timeout 60; uwsgi_send_timeout 60; } }location / 塊是核心include uwsgi_params 把 uWSGI 協(xié)議需要的請求頭參數(shù)導(dǎo)入uwsgi_pass 指定要轉(zhuǎn)發(fā)的 socket 文件地址這里要和 uWSGI 配置文件里的 socket 路徑完全一致。uwsgi_read_timeout 和 uwsgi_send_timeout 設(shè)為 60 秒防止某些處理時(shí)間長的接口觸發(fā)超時(shí)。配置文件保存后執(zhí)行 nginx -t 檢查語法再在面板里重載 Nginx 服務(wù)。此時(shí)訪問你的域名Django 應(yīng)用已經(jīng)攔在 Nginx 后面開始工作了。5.2 靜態(tài)文件的收尾工作collectstatic 與 alias 的對應(yīng)關(guān)系換到生產(chǎn)環(huán)境后Django 不再處理靜態(tài)文件全交給 Nginx。Nginx 收到 /static/ 開頭的請求時(shí)會(huì)直接到 alias 指定的目錄里找文件根本不經(jīng)過 Django。在這條鏈路里最容易出問題的不是 Nginx 配置而是 collectstatic 有沒有執(zhí)行。settings.py 里的 STATIC_ROOT 配置了收集目標(biāo)目錄collectstatic 把 Django 自帶的 admin 靜態(tài)文件和你項(xiàng)目里的 static 目錄文件全部收納進(jìn)這個(gè)文件夾。Nginx 的 alias 路徑必須指向這個(gè)目錄多寫或少寫一層都會(huì)導(dǎo)致 404。media 目錄同理用戶上傳的圖片和附件會(huì)寫進(jìn) MEDIA_ROOTNginx 的 /media/ location 也要指向同樣的位置。檢查一下 staticfiles 目錄權(quán)限是否讓 Nginx 用戶有讀取權(quán)限ls -ld /www/wwwroot/django_project/staticfiles chown -R www:www /www/wwwroot/django_project/staticfiles chown -R www:www /www/wwwroot/django_project/mediawww 用戶是寶塔 Nginx 默認(rèn)的運(yùn)行用戶靜態(tài)文件和媒體目錄都要?dú)w www 所有否則 Nginx 讀取時(shí)觸發(fā)權(quán)限不足頁面上的 CSS 和圖片就會(huì)全部 404。這是部署階段最容易忽略的一步本地開發(fā)時(shí)不用考慮權(quán)限問題上了服務(wù)器就完全不一樣了。5.3 部署后最常見的 5 個(gè)坑現(xiàn)象、原因與解決方法第一個(gè)坑是 502 Bad Gateway?，F(xiàn)象是首頁打得開但所有接口都報(bào) 502。常見原因是 uWSGI 沒有運(yùn)行或者 socket 文件路徑不一致。排查方法是先看 supervisor 狀態(tài)再確認(rèn) /tmp/django_project.sock 是否存在兩條命令就能定位問題。解決方式是對應(yīng)調(diào)整 supervisor 里的啟動(dòng)命令或 Nginx 里的 socket 路徑。第二個(gè)坑是 403 Forbidden。現(xiàn)象是頁面能訪問但提示無權(quán)限查 Nginx 錯(cuò)誤日志能看到 permission denied 相關(guān)記錄。原因是 uWSGI 創(chuàng)建的 socket 文件權(quán)限不夠Nginx 的 www 用戶無法訪問。解決方法是把 uWSGI 配置里的 chmod-socket 設(shè)為 664然后重啟 uWSGI讓 socket 文件重新按新權(quán)限生成。第三個(gè)坑是頁面返回的是源碼而不是渲染后的頁面。現(xiàn)象是瀏覽器顯示一串 HTML 代碼或者提示下載文件。原因是 Nginx 沒有把請求轉(zhuǎn)發(fā)給 uWSGIlocation / 塊里缺了 uwsgi_pass 配置請求被當(dāng)成靜態(tài)文件處理。解決方法是補(bǔ)上轉(zhuǎn)發(fā)規(guī)則確認(rèn) include uwsgi_params 和 uwsgi_pass 都在同一個(gè) location 塊里。第四個(gè)坑是后臺管理頁面全裸奔樣式全丟。現(xiàn)象是 admin 頁面能看到表格但沒有任何 CSS排版徹底塌掉。原因是 admin 的靜態(tài)文件沒有被 collectstatic 收集。解決方法是進(jìn)入虛擬環(huán)境執(zhí)行 collectstatic --noinput然后確認(rèn) staticfiles/admin 目錄下存在 css、js 等子目錄。第五個(gè)坑是改完代碼后線上不生效?，F(xiàn)象是本地改了一行代碼push 到服務(wù)器后頁面沒變化。原因是 uWSGI 默認(rèn)不會(huì)自動(dòng)重載代碼worker 進(jìn)程里跑的還是舊版本。解決方法是執(zhí)行 supervisorctl restart django_project或者發(fā)送 HUP 信號給 uWSGI 主進(jìn)程做溫和重載后者能避免中斷正在進(jìn)行的請求。6. 部署完別急著收工一套可復(fù)用的自檢流程與日志習(xí)慣6.1 五個(gè)命令完成上線初檢網(wǎng)站能打開只是第一步上線之后還要按順序跑一遍自檢。把下面這套檢查固化到自己的部署流程里能省掉很多半夜被叫起來的場景。檢查項(xiàng)、命令和期望結(jié)果對比如下檢查項(xiàng)命令期望結(jié)果頁面響應(yīng)狀態(tài)curl -I http://127.0.0.1/返回 200 OKuWSGI 進(jìn)程狀態(tài)supervisorctl status django_project狀態(tài)為 RUNNINGsocket 文件存在ls -l /tmp/django_project.sock文件存在且權(quán)限 664靜態(tài)文件可訪問curl -I http://127.0.0.1/static/admin/css/base.css返回 200 OKNginx 錯(cuò)誤日志tail -n 50 /www/wwwlogs/example.com.error.log無 traceback 或 permission denied這些命令可以合并成一個(gè)腳本放在項(xiàng)目里每次部署后執(zhí)行一遍省得手動(dòng)敲五遍。6.2 一套日志習(xí)慣和收尾動(dòng)作日志是線上問題排查的唯一線索我一般把日志分成兩個(gè)查看入口Nginx 的 error.log 看外層請求錯(cuò)誤uWSGI 的 daemonize 日志看 Django 內(nèi)部異常。執(zhí)行 tail -f 同時(shí)盯住兩個(gè)文件等用戶復(fù)現(xiàn)問題報(bào)錯(cuò)信息會(huì)直接滾出來。tail -f /www/wwwlogs/example.com.error.log /var/log/django_project_uwsgi.log另外每次發(fā)布前固定執(zhí)行一輪 collectstatic 與 migrate把這兩步寫進(jìn)發(fā)布清單而不是靠大腦記憶。我第一次部署 Django 項(xiàng)目時(shí)就是在 collectstatic 這一步上栽了跟頭admin 樣式全丟排查了很久才反應(yīng)過來是靜態(tài)文件沒收集。后來把這個(gè)動(dòng)作固化成習(xí)慣就再也沒翻過車。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取