摘要項目寫完了聯(lián)調也通過了但代碼還在服務器上裸跑今天這篇手把手帶你把商城從開發(fā)環(huán)境打包部署到生產服務器上。Docker 容器化、Nginx 反向代理、Gunicorn 高性能應用服務器、HTTPS 證書配置、域名備案流程一套完整上線流程全走完。三個核心配置文件Dockerfile、docker-compose.yml、nginx.conf全部完整可用帶詳細注釋。最后再教你用 AI 寫部署腳本和排錯指南省下大量踩坑時間。開發(fā)完了用戶還看不到前 18 天我們把商城從 0 搭到了聯(lián)調完畢。Django 的 API 寫好了DRF 的接口通了MySQL 8.0 數據跑起來了Redis 緩存也配上了uni-app 前端也對接完了。但是——你的項目現(xiàn)在是什么狀態(tài)大概率是這樣在服務器上跑著python manage.py runserver 0.0.0.0:8000裸奔著。這就好比你開了一家店招牌沒掛、門沒裝、燈沒亮客人從門口路過都不知道這是不是正經營業(yè)。runserver是開發(fā)用的調試服務器單線程、不安全、不支持并發(fā)。性能不存在的。安全更不存在。那怎么讓你的商城真正跑起來讓用戶通過域名 HTTPS 安全地訪問到今天的主角來了Docker Nginx Gunicorn三件套。這三樣東西在生產環(huán)境部署 Django 項目里是標配學會了這個以后部署任何 Python Web 項目都是同一套流程。三個家伙各管什么動手之前先搞清楚每個角色負責什么這樣后面看配置才不會一頭霧水。Gunicorn —— 干活的工人Django 自帶的runserver是單線程的來了 100 個請求就排隊等著慢得要死。Gunicorn 是一個 WSGI HTTP Server它能起多個 worker 進程真正處理并發(fā)請求。你可以把它理解成一個車間里的多個工人同時處理多個訂單。Nginx —— 門面擔當Nginx 是整個架構的入口它干三件事反向代理把用戶的請求根據規(guī)則轉發(fā)給后面的 Gunicorn靜態(tài)文件服務CSS、JS、圖片這些靜態(tài)資源直接由 Nginx 返回不需要經過 Django性能提升巨大HTTPS 終端SSL 證書的加解密都在 Nginx 層完成后面用 HTTP 通信就行Nginx 處理靜態(tài)文件的能力非常強單機輕松應對上萬并發(fā)。讓 Django 去處理圖片請求那簡直是大材小用。Docker —— 一鍵搬家Docker 把你的整個運行環(huán)境打包成一個鏡像Python 版本、系統(tǒng)依賴、代碼、配置文件全在一起。換服務器拉鏡像docker compose up -d30 秒搞定。不用再手動裝 Python、裝依賴、配環(huán)境變量了。而且環(huán)境一致性有保障——開發(fā)、測試、生產用的都是同一個鏡像不會出現(xiàn)在我電腦上能跑的經典問題。一句話總結Nginx 負責接客和分流 → Gunicorn 負責實際干活 → Docker 負責打包整個環(huán)境。動手實戰(zhàn)從零到上線第一步編寫 DockerfileDockerfile 就是打包說明書告訴 Docker 怎么一步步構建你的運行鏡像。用多階段構建來減小最終鏡像體積# 第一階段構建依賴 FROM python:3.11-slim AS builder WORKDIR /app # 安裝系統(tǒng)依賴編譯 MySQL 客戶端等需要 RUN apt-get update apt-get install -y \ gcc \ default-libmysqlclient-dev \ pkg-config \ rm -rf /var/lib/apt/lists/* # 先復制依賴文件利用 Docker 緩存層 COPY requirements.txt . RUN pip install --no-cache-dir --prefix/install -r requirements.txt # 第二階段運行鏡像 FROM python:3.11-slim WORKDIR /app RUN apt-get update apt-get install -y curl rm -rf /var/lib/apt/lists/* # 從構建階段拷貝安裝好的 Python 包運行時不需要 gcc 這些編譯工具 COPY --frombuilder /install /usr/local COPY . . # 收集靜態(tài)文件生產模式需要 RUN python manage.py collectstatic --noinput EXPOSE 8000 # 啟動命令4 個 worker綁定 0.0.0.0:8000日志輸出到 stdoutdocker logs 可見 CMD [gunicorn, shop.wsgi:application, \ --bind, 0.0.0.0:8000, \ --workers, 4, \ --threads, 2, \ --timeout, 120, \ --access-logfile, -, \ --error-logfile, -]幾個關鍵點多階段構建第一階段裝編譯工具gcc 這些第二階段只拷貝裝好的包。最終鏡像里沒有編譯工具體積能從 1GB 降到 300MB 左右依賴緩存先 COPY requirements.txt再 COPY 代碼。改了業(yè)務代碼不會觸發(fā)重新裝依賴構建速度快workers 數量經驗公式是2 * CPU核心數 14 核機器就配 4-5 個 worker。太多反而會因上下文切換變慢第二步編寫 docker-compose.yml光有 Dockerfile 還不夠。項目不只有 Django還有 MySQL、Redis 這些服務。docker-compose.yml是編排清單定義所有服務和它們之間的關系一鍵啟動version:3.8services:# MySQL 數據庫 mysql:image:mysql:8.0restart:alwaysenvironment:MYSQL_ROOT_PASSWORD:${MYSQL_ROOT_PASSWORD}MYSQL_DATABASE:shop_mallTZ:Asia/Shanghaiports:-127.0.0.1:3306:3306# 只監(jiān)聽本地不暴露到公網volumes:-mysql_data:/var/lib/mysql# 數據持久化command:---character-set-serverutf8mb4---default-authentication-pluginmysql_native_passwordhealthcheck:# 健康檢查MySQL ready 前應用不啟動test:[CMD,mysqladmin,ping,-h,localhost]interval:10stimeout:5sretries:5# Redis 緩存 redis:image:redis:7-alpinerestart:alwaysports:-127.0.0.1:6379:6379volumes:-redis_data:/datacommand:redis-server--appendonly yes--requirepass ${REDIS_PASSWORD}healthcheck:test:[CMD,redis-cli,-a,${REDIS_PASSWORD},ping]interval:10stimeout:5sretries:5# Django 應用 web:build:context:.dockerfile:Dockerfilerestart:alwaysports:-127.0.0.1:8000:8000# 只監(jiān)聽本地由 Nginx 轉發(fā)volumes:-static_files:/app/static# 靜態(tài)文件共享給 Nginx-media_files:/app/media# 用戶上傳文件env_file:-.env# 環(huán)境變量文件敏感配置不硬編碼environment:-DJANGO_SETTINGS_MODULEshop.settings.prod-DATABASE_HOSTmysql# 指向 compose 內的 mysql 服務-REDIS_HOSTredisdepends_on:mysql:condition:service_healthy# 數據庫就緒后才啟動應用redis:condition:service_healthy# Nginx 反向代理 nginx:image:nginx:1.25-alpinerestart:alwaysports:-80:80-443:443volumes:-./nginx/nginx.conf:/etc/nginx/conf.d/default.conf:ro-./nginx/ssl:/etc/nginx/ssl:ro# SSL 證書目錄-static_files:/usr/share/nginx/html/static:ro-media_files:/usr/share/nginx/html/media:rodepends_on:-webvolumes:mysql_data:# 命名卷容器刪了重建數據不丟redis_data:static_files:media_files:設計講究網絡隔離MySQL 和 Redis 都綁定127.0.0.1外網掃描根本掃不到這兩個端口。只有容器之間能通信安全性拉滿健康檢查MySQL/Redis 配了 healthcheckweb 的depends_on配condition: service_healthy確保數據庫完全就緒后應用才啟動——不再踩應用啟動但數據庫還沒 ready的坑環(huán)境變量外置密碼放.env文件不硬編碼在 yml 里數據持久化命名卷保證容器重建數據不丟第三步配置 NginxNginx 配置放在nginx/nginx.conf核心塊# 上游 Gunicorn 服務擴容時加 server web2:8000 即可Nginx 自動輪詢 upstream shop_backend { server web:8000; } # HTTP → HTTPS 強制跳轉 server { listen 80; server_name your-domain.com; # Lets Encrypt 驗證路徑 location /.well-known/acme-challenge/ { root /var/www/certbot; } # 其余所有請求跳轉到 HTTPS location / { return 301 https://$host$request_uri; } } # HTTPS 主配置 server { listen 443 ssl http2; server_name your-domain.com; ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; # 安全頭 add_header Strict-Transport-Security max-age31536000; includeSubDomains always; add_header X-Content-Type-Options nosniff always; add_header X-Frame-Options SAMEORIGIN always; client_max_body_size 20M; # 允許上傳最大 20M圖片、頭像等 # Gzip 壓縮 gzip on; gzip_types text/plain text/css application/json application/javascript; gzip_min_length 1000; # ---------- 靜態(tài)文件Nginx 直接返回不經過 Django---------- location /static/ { alias /usr/share/nginx/html/static/; expires 30d; # 緩存 30 天 add_header Cache-Control public, immutable; access_log off; } # ---------- 用戶上傳的媒體文件 ---------- location /media/ { alias /usr/share/nginx/html/media/; expires 7d; } # ---------- API 請求反向代理到 Gunicorn ---------- location /api/ { proxy_pass http://shop_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_connect_timeout 60s; proxy_read_timeout 120s; } # ---------- 健康檢查端點 ---------- location /health/ { proxy_pass http://shop_backend; access_log off; } }核心設計upstream 塊定義后端服務地址擴展時加server web2:8000就行Nginx 自動輪詢HTTP 跳 HTTPS所有 80 端口請求 301 重定向到 443確保用戶始終走加密通道靜態(tài)文件分離/static/、/media/由 Nginx 直接返回不經過 Django。原來 Django 處理一個靜態(tài)文件要 50msNginx 只要 2ms安全頭HSTS 強制瀏覽器只用 HTTPS、X-Frame-Options 防點擊劫持、X-Content-Type-Options 防 MIME 嗅探第四步準備環(huán)境變量文件項目根目錄創(chuàng)建.env管理所有敏感配置# .env - 生產環(huán)境變量千萬別提交到 GitDJANGO_SETTINGS_MODULEshop.settings.prodSECRET_KEY你的django-secret-keyDEBUGFalseALLOWED_HOSTSyour-domain.com,www.your-domain.comMYSQL_ROOT_PASSWORDxxxMYSQL_PASSWORDxxxREDIS_PASSWORDxxx記得在.gitignore里加上.env密碼泄露到 GitHub 上可不是鬧著玩的。第五步申請 SSL 證書推薦用Let’s Encrypt的免費證書certbot申請90 天自動續(xù)期# 1. 安裝 certbotaptupdateaptinstall-ycertbot# 2. 臨時停 Nginx釋放 80 端口給 certbot 驗證dockercompose stop nginx# 3. 申請證書standalone 模式certbot certonly--standalone-dyour-domain.com-dwww.your-domain.com# 4. 把證書拷到項目目錄cp/etc/letsencrypt/live/your-domain.com/{fullchain.pem,privkey.pem}./nginx/ssl/# 5. 啟動所有服務dockercompose up-d# 6. 驗證自動續(xù)期certbot renew --dry-run證書 90 天到期certbot 會自動加定時任務續(xù)期。只要 80 端口不長期關閉續(xù)期全自動。第六步域名 SSL 備案域名這塊新手容易懵完整流程捋一遍買域名阿里云、騰訊云、Cloudflare 都行。.com大概 50-70 元/年.cn更便宜DNS 解析在域名管理后臺添加 A 記錄把域名指向服務器公網 IPICP 備案國內服務器必須備案不備案 80/443 端口會被云廠商封掉在服務器所在云廠商后臺提交一般審核 7-20 個工作日準備身份證正反面、域名證書、網站負責人核驗照片、真實性承諾書公安備案ICP 備案通過后 30 天內去全國公安互聯(lián)網站安全管理服務平臺再備案一次小貼士趕時間可先用香港或海外服務器不需要備案但國內用戶訪問延遲會高 50-100ms正式運營的項目老老實實備案不然后面麻煩更多第七步上線檢查清單部署完別急著收工按清單逐條檢查? docker compose ps → 所有服務 running ? 瀏覽器訪問 https://your-domain.com → 頁面正常 ? /admin/ 后臺 → 能正常登錄 ? curl https://your-domain.com/api/ → 返回正常 JSON ? 靜態(tài)文件 → CSS/JS/圖片正常F12 看 Network ? 圖片上傳 → 功能正常圖片能顯示 ? HTTPS 證書 → 瀏覽器地址欄有綠色鎖 ? HTTP 跳轉 → 輸入 http:// 自動跳 https:// ? 數據持久化 → docker compose restart數據還在 ? .env 文件 → 確認沒提交到 Git ? 日志查看 → docker compose logs -f web 能看到實時日志部署順序與踩坑經驗第一次上線部署順序很重要。別一上來就docker compose up按這個順序來1. 服務器基礎配置防火墻、SSH 密鑰登錄、系統(tǒng)更新 2. 安裝 Docker Docker Compose 3. git clone 拉代碼 4. 配置 .env 環(huán)境變量 5. docker compose build 構建鏡像 6. 先啟動數據庫和緩存docker compose up -d mysql redis 7. 健康檢查通過后執(zhí)行遷移docker compose exec web python manage.py migrate 8. 創(chuàng)建管理員docker compose exec web python manage.py createsuperuser 9. 收集靜態(tài)文件docker compose exec web python manage.py collectstatic --noinput 10. 申請 SSL 證書 11. 啟動全部服務docker compose up -d 12. 逐項檢查上線清單常見踩坑坑 1應用啟動后數據庫連接失敗應用啟動太快MySQL 還沒初始化好。compose 里配了 healthcheck condition: service_healthy基本可以避免。還有問題就在應用啟動腳本加個重試邏輯?？?2靜態(tài)文件 404兩種可能忘了執(zhí)行collectstatic或 Nginx 的 alias 路徑和卷映射對不上。進容器ls /app/static/看有沒有文件再檢查 nginx.conf 里 alias 的路徑?？?3HTTPS 證書無效或不受信任可能是域名解析沒生效DNS 緩存最長等 48 小時或證書路徑寫錯。用openssl s_client -connect your-domain.com:443查看實際返回的證書?？?4Gunicorn worker 頻繁重啟先docker stats看內存夠不夠。2G 內存跑 4 個 worker 可能不夠減到 2 個。再檢查 timeout——有些接口執(zhí)行超過 120 秒需要調大。AI 加速讓 AI 幫你寫部署腳本和排錯部署和運維的活AI 特別擅長。三個實操場景親測好用。場景 1生成一鍵部署腳本“我有一個 Django 4.2 項目目錄結構如下[貼 tree 輸出]。服務器是 Ubuntu 22.04已裝 Docker 24.0。請生成一個一鍵部署 shell 腳本包含環(huán)境檢查、代碼拉取、鏡像構建、數據庫遷移、靜態(tài)文件收集、SSL 證書申請、服務啟動。要求有錯誤處理、彩色日志輸出、每一步都有提示?！睅追昼娚梢粋€完整 bash 腳本比手寫調試快太多。場景 2排查線上問題“我的 Django Docker 部署后訪問 API 返回 502 Bad Gateway。Nginx 錯誤日志[貼日志]。docker compose ps 輸出[貼輸出]。容器內 gunicorn 日志[貼日志]。請分析原因并給出修復方案。”AI 能快速定位根因——可能是 worker 全掛、端口映射錯誤、內存不足被 OOM kill。場景 3生成監(jiān)控告警腳本“幫我寫一個 Docker 健康監(jiān)控腳本。每 5 分鐘檢查所有容器狀態(tài)如果 web 容器異常則自動重啟。連續(xù)重啟 3 次仍失敗就發(fā)告警郵件。用 bash 編寫日志記錄到 /var/log/shop-monitor.log?！边@種運維腳本手寫要半小時AI 幾分鐘搞定質量還高。學完來練練手日志管理配置 Nginx 的 access_log / error_log 輸出到獨立目錄用logrotate做日志輪轉防止磁盤撐爆可視化監(jiān)控部署 Portainer 做 Docker 可視化管理部署 Watchtower 實現(xiàn)鏡像自動更新負載均衡修改 docker-compose 啟動 2 個 web 實例配置 Nginx upstream 的輪詢和權重策略自動備份寫定時腳本每天凌晨mysqldump備份數據庫上傳到遠程 OSS 存儲Docker 官方文檔docs.docker.comGunicorn 部署 Django 官方指南docs.djangoproject.comLet’s Encrypt。本系列為梅雅達編程筆記原創(chuàng)首發(fā)于 CSDN。有問題評論區(qū)見