Ubuntu 22.04上构建Python Web服务生产级部署流水线
1. 项目概述：这不是一次普通装系统，而是一套可复用的Python Web服务交付流水线
“How To Set Up Ubuntu Cloud Servers For Python Web-Applications”——这个标题乍看像一篇基础教程，但在我过去十年运维过37个SaaS产品、亲手部署过2100+台生产级Ubuntu云服务器的经历里，它背后藏着一套被反复验证、持续迭代的最小可行交付范式（MVDP, Minimum Viable Deployment Pattern）。它不是教你怎么敲sudo apt update，而是告诉你：当客户凌晨三点发来一封“线上API崩了，用户在投诉”的邮件时，你能否在12分钟内拉起一台全新、干净、安全、可监控、带完整日志链路的Python Web服务节点？这才是标题真正的分量。
核心关键词——Ubuntu、Python、web-applications、cloud servers、setup——每一个都不是孤立存在。Ubuntu不是随便选的发行版，它是AWS/Azure/GCP官方镜像中默认占比超68%的Linux基座，其LTS版本5年安全更新周期与Python Web应用常见的2–3年生命周期高度咬合；Python不是泛指语言本身，而是特指CPython解释器+现代包管理（pip+venv）+异步运行时（uvicorn/gunicorn）这一黄金三角；web-applications在这里明确排除了静态站点和纯API代理，专指需要进程管理、环境隔离、请求路由、健康检查的真实业务服务，比如Django Admin后台、FastAPI数据接口、Flask报表引擎；cloud servers则意味着我们必须直面无GUI、无物理控制台、SSH是唯一入口、网络策略由VPC/NACL/SG层层管控的现实；而setup，绝非一次性初始化脚本，它必须是幂等、可审计、可回滚、带版本标记、能嵌入CI/CD流水线的声明式配置集合。
我见过太多团队把“setup”做成黑盒Shell脚本：硬编码IP、明文写数据库密码、用pip install -r requirements.txt直接污染系统Python、忽略时区和locale设置、忘记配置ulimit导致高并发下文件句柄耗尽……结果就是每次扩容都要人工救火，每次安全审计都得临时打补丁。这篇内容要拆解的，正是如何把这种“人肉运维”升级为“机器可读、人可理解、业务可信赖”的交付标准。它适合三类人：刚从本地开发切到云上部署的Python工程师，需要快速建立生产意识；中小团队DevOps负责人，正为缺乏标准化部署流程头疼；以及技术决策者，想评估一套Web服务基础设施的长期维护成本。接下来，我会用真实生产环境中的参数、命令、配置片段和踩过的坑，带你走完这条从裸机到高可用服务的完整路径。
2. 整体架构设计与方案选型逻辑：为什么是这套组合，而不是其他？
2.1 为什么锁定Ubuntu 22.04 LTS而非20.04或24.04？
选择Ubuntu 22.04 LTS（Jammy Jellyfish）不是跟风，而是基于三个硬性约束的交叉验证。第一是Python生态兼容性：截至2024年Q2，PyPI上下载量Top 100的包中，92%已正式声明支持Python 3.10+，而22.04默认Python版本为3.10.6，完美匹配Django 4.2+、FastAPI 0.103+、SQLAlchemy 2.0+等主流框架的最低要求。反观20.04默认Python 3.8，已无法安装最新版Pandas（需3.9+）；24.04虽默认3.12，但其系统级依赖如systemd 255、glibc 2.39与部分C扩展模块（如psycopg2-binary 3.1.18前版本）存在ABI不兼容风险，我们实测过在24.04上部署PostgreSQL驱动时出现段错误，回退到22.04后即解决。
第二是云平台支持深度：AWS EC2官方AMI中，22.04 LTS镜像的更新频率为每月一次，包含所有关键CVE补丁，且预装了awscli v2、ec2-instance-connect、cloud-init 23.3+等核心工具；Azure Ubuntu Pro镜像对22.04提供FIPS 140-2合规认证，这对金融类Web应用是刚需；GCP则为22.04提供了专用的GPU驱动优化镜像。而20.04已于2025年4月结束标准支持，仅剩ESM（Extended Security Maintenance）付费通道，这会增加团队安全运维成本。
第三是内核与容器运行时成熟度：22.04搭载Linux Kernel 5.15，原生支持cgroup v2、io_uring、BPF LSM等现代特性，这对后续可能引入的eBPF网络监控或容器安全策略至关重要。我们曾用同一套Docker Compose配置在20.04和22.04上压测，22.04在10K并发连接下内存泄漏率低47%，原因正是Kernel 5.15对memory cgroup的回收算法优化。因此，22.04不是“够用”，而是当前三年内稳定性、安全性、生态适配性三者交集的最大公约数。
2.2 为什么放弃systemd直接托管Python进程，而选用Gunicorn+Uvicorn双层架构？
很多新手会问：既然systemd能管理服务，为何还要加一层Gunicorn？答案藏在进程模型与故障域隔离里。systemd是操作系统级守护进程，它只负责“进程是否存活”，但对Python Web应用的内部状态一无所知。比如一个Django应用因ORM缓存击穿导致数据库连接池耗尽，此时worker进程仍在运行（PID未退出），systemd认为服务“健康”，但实际所有HTTP请求都卡在504 Gateway Timeout。Gunicorn作为应用服务器，内置了worker超时检测（--timeout 120）、内存使用阈值（--max-requests 1000 --max-requests-jitter 100）和优雅重启机制，它能在worker异常时主动杀死并拉起新进程，将故障影响限制在单个worker内。
而Uvicorn的引入，则是为了解决协议栈分层与性能杠杆问题。Gunicorn是同步多进程模型，适合CPU密集型任务；Uvicorn是异步ASGI服务器，基于asyncio和uvloop，专为I/O密集型Web请求优化。我们实测过一个FastAPI接口：纯Gunicorn（4 worker）QPS为3200，Gunicorn+Uvicorn（每个Gunicorn worker内嵌1个Uvicorn实例）QPS跃升至8900，提升178%。这是因为Gunicorn负责负载均衡和进程管理，Uvicorn专注处理HTTP/1.1解析、WebSocket握手、长连接保活等高并发I/O操作，两者分工明确，避免了单进程模型下GIL（全局解释器锁）对异步能力的压制。
提示：不要用Gunicorn直接跑Django/Flask——它们是WSGI应用，Gunicorn原生支持；但FastAPI/Starlette是ASGI应用，必须通过Uvicorn或Daphne等ASGI服务器承载。Gunicorn 21.2+才通过
--worker-class uvicorn.workers.UvicornWorker提供ASGI支持，这是关键版本门槛。
2.3 为什么坚持用venv而非pyenv、conda或系统pip？
Python环境管理是部署中最易被轻视的雷区。pyenv适合开发者本地多版本切换，但其pyenv init生成的shell hook在无交互式shell的systemd服务中根本不会执行；conda虽强大，但其二进制包体积庞大（base环境超1.2GB），且私有仓库同步复杂，不符合云服务器“轻量化、快速克隆”的原则；系统pip（sudo pip install）更是大忌——它会污染/usr/lib/python3.x/site-packages，导致系统工具（如apt、cloud-init）依赖的Python包被意外升级而崩溃，我们曾因此导致一台生产服务器无法执行apt upgrade，最终靠Live CD救援。
venv是Python 3.3+官方标准，其优势在于零外部依赖、路径绝对可控、隔离粒度精准。python3 -m venv /opt/myapp/venv创建的环境，所有包都安装在/opt/myapp/venv目录下，/opt/myapp/venv/bin/python是绝对路径的解释器，/opt/myapp/venv/bin/pip是绝对路径的包管理器。在systemd服务文件中，我们直接指定ExecStart=/opt/myapp/venv/bin/gunicorn ...，彻底规避PATH污染风险。更重要的是，venv环境可被完整打包为tar.gz，通过rsync秒级同步到新节点，这是pyenv/conda无法做到的确定性交付。
2.4 为什么网络配置必须显式声明DNS与NTP，而非依赖DHCP？
云服务器的DHCP租约看似方便，但埋下两大隐患。一是DNS劫持风险：某些公有云厂商的DHCP分配的DNS服务器（如169.254.169.253）会缓存TTL极短的记录，当你的Web应用调用第三方API（如Stripe支付网关）时，若DNS解析返回过期IP，可能导致连接超时。我们曾遇到某次AWS区域DNS故障，导致所有Python服务的requests.get("https://api.stripe.com")批量失败，根源就是未覆盖DHCP DNS。
二是时间漂移引发证书失效：Python的SSL/TLS握手严格校验证书有效期，若服务器时间比UTC快5分钟，而Let's Encrypt证书恰好在此窗口内过期，所有HTTPS请求都会抛出SSLCertVerificationError。云服务器因虚拟化时钟漂移，开机后时间误差可达2–3秒，必须由NTP强制校准。我们在22.04上禁用systemd-timesyncd（其精度仅±200ms），改用chrony并配置pool ntp.ubuntu.com iburst minpoll 4 maxpoll 4，实测时间同步精度达±5ms以内，且chrony在断网后能智能补偿时钟漂移。
3. 核心细节解析与实操要点：从裸机到可运行服务的12个关键动作
3.1 初始化系统：安全加固与基础环境准备
拿到一台全新的Ubuntu 22.04云服务器（假设公网IP为203.0.113.10），SSH登录后的第一件事不是装Python，而是构建可信执行基线。这包括四个不可跳过的步骤：
第一步：强制更新并锁定内核版本
sudo apt update && sudo apt full-upgrade -y sudo apt autoremove -y && sudo apt autoclean # 锁定内核防止自动升级破坏驱动兼容性 sudo apt-mark hold linux-image-5.15.0-107-generic linux-headers-5.15.0-107-genericfull-upgrade比upgrade更激进，会处理包依赖冲突（如旧版openssl被新版替代），这是安全补丁落地的关键。apt-mark hold则防止云平台自动内核升级导致NVIDIA驱动或自定义内核模块失效——我们曾因一次自动升级使GPU加速的TensorFlow服务离线6小时。
第二步：配置非root管理员账户与SSH密钥登录
sudo adduser deploy --gecos "Deploy User,,," --disabled-password sudo usermod -aG sudo deploy sudo mkdir -p /home/deploy/.ssh sudo cp /root/.ssh/authorized_keys /home/deploy/.ssh/ sudo chown -R deploy:deploy /home/deploy/.ssh sudo chmod 700 /home/deploy/.ssh sudo chmod 600 /home/deploy/.ssh/authorized_keys # 禁用root密码登录 sudo sed -i 's/^PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config sudo systemctl restart sshd--gecos参数避免交互式提问，adduser比useradd更安全（自动创建家目录、设置合理umask）。将root的SSH密钥复制给deploy用户，是为了保留紧急访问通道，同时满足“最小权限原则”——日常部署操作用deploy，而非root。
第三步：配置防火墙（UFW）与网络策略
sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow OpenSSH sudo ufw allow from 192.168.1.0/24 to any port 5432 # 允许内网DB访问 sudo ufw allow 8000 # 应用HTTP端口 sudo ufw enableUFW是iptables的前端，default deny incoming是安全基石。注意：永远不要开放22端口给0.0.0.0/0，应限制为公司办公IP段或VPN出口IP。我们曾因开放22端口给全网，遭遇暴力破解攻击，日志显示单日23万次失败登录尝试。
第四步：配置时区、locale与NTP
sudo timedatectl set-timezone Asia/Shanghai sudo locale-gen en_US.UTF-8 zh_CN.UTF-8 sudo update-locale LANG=en_US.UTF-8 sudo apt install chrony -y sudo systemctl enable chrony && sudo systemctl start chrony时区错误会导致日志时间错乱，排查问题时如同雾里看花；locale缺失会使Python的str.encode()在处理中文路径时抛出UnicodeEncodeError；chrony比ntpdate更可靠，因其支持平滑调整时间（slew mode），避免时间跳跃导致应用逻辑异常。
3.2 Python环境构建：venv的正确打开方式与依赖安装
Python环境构建的核心是路径绝对化、依赖显式化、安装静默化。以下是经过2100+次验证的标准化流程：
创建项目目录结构
sudo mkdir -p /opt/myapp/{src,logs,config,venv} sudo chown -R deploy:deploy /opt/myapp sudo chmod 755 /opt/myapp/opt是Linux FHS（文件系统层次结构标准）规定的“第三方应用程序”目录，比/home/deploy更符合生产环境规范；src存代码，logs存日志，config存配置文件（分离于代码），venv存虚拟环境——这种结构让备份、迁移、审计一目了然。
创建并激活venv
sudo -u deploy /usr/bin/python3 -m venv /opt/myapp/venv sudo -u deploy /opt/myapp/venv/bin/pip install --upgrade pip setuptools wheel关键点：sudo -u deploy确保venv所有权为deploy用户，避免后续pip install因权限不足失败；--upgrade确保pip为最新版（22.04默认pip 20.0.2，存在CVE-2021-3572漏洞）；wheel包是必需的，否则安装含C扩展的包（如psycopg2）会触发源码编译，极大拖慢部署速度。
依赖安装的两种模式
模式A：requirements.txt精确锁定（推荐用于生产）
# 将本地开发环境的依赖冻结 pip freeze > requirements.txt # 上传到服务器并安装 sudo -u deploy /opt/myapp/venv/bin/pip install -r /opt/myapp/src/requirements.txt --no-cache-dir--no-cache-dir强制禁用pip缓存，确保每次安装都是纯净的，避免缓存损坏导致安装失败。requirements.txt必须包含--find-links和--trusted-host（若用私有PyPI），例如：
--find-links https://pypi.mycompany.com/simple/ --trusted-host pypi.mycompany.com Django==4.2.12 gunicorn==21.2.0 uvicorn[standard]==0.22.0模式B：动态安装（适用于CI/CD流水线）
sudo -u deploy /opt/myapp/venv/bin/pip install "Django>=4.2,<4.3" "gunicorn>=21.2" "uvicorn[standard]>=0.22"用版本范围而非精确锁定，允许在安全补丁发布时自动获取修复版本，但需配合pip list --outdated定期审计。
注意：永远不要在venv中运行
pip install --user！这会将包安装到/home/deploy/.local，破坏环境隔离性。所有包必须进入/opt/myapp/venv。
3.3 Web服务器配置：Gunicorn+Uvicorn的协同工作流
Gunicorn与Uvicorn的集成不是简单拼接，而是进程树层级与信号传递的精密设计。以下是我们的生产级配置：
Gunicorn配置文件/opt/myapp/config/gunicorn.conf.py
import multiprocessing # 绑定配置 bind = "127.0.0.1:8000" # 只监听本地环回，由Nginx反向代理 bind_address = "127.0.0.1:8000" backlog = 2048 # 进程管理 workers = multiprocessing.cpu_count() * 2 + 1 # 通常4核机器设9个worker worker_class = "uvicorn.workers.UvicornWorker" # 关键：启用Uvicorn Worker worker_connections = 1000 max_requests = 1000 max_requests_jitter = 100 timeout = 120 keepalive = 5 # 安全与日志 user = "deploy" group = "deploy" umask = 0o007 pidfile = "/opt/myapp/logs/gunicorn.pid" accesslog = "/opt/myapp/logs/gunicorn_access.log" errorlog = "/opt/myapp/logs/gunicorn_error.log" loglevel = "info" capture_output = True enable_stdio_inheritance = False # 系统资源 limit_memory_soft = 1073741824 # 1GB limit_memory_hard = 1288490188 # 1.2GBmultiprocessing.cpu_count() * 2 + 1是经验公式：每个CPU核心配2个worker处理I/O等待，+1应对突发请求；limit_memory_*参数是Gunicorn 20.1+新增的cgroup内存限制，当worker内存超限时会被OOM Killer杀死并重启，这是防止内存泄漏拖垮整机的关键防线。
Uvicorn Worker的启动逻辑
Gunicorn加载uvicorn.workers.UvicornWorker时，会调用uvicorn.main:Server类，其内部启动一个asyncio事件循环，并在该循环中运行ASGI应用。这意味着：每个Gunicorn worker是一个独立的Python进程，每个进程内有一个Uvicorn事件循环，该循环可并发处理数千个HTTP请求。这与传统Gunicorn同步worker（每个请求阻塞一个线程）有本质区别。
验证Gunicorn+Uvicorn是否生效
sudo -u deploy /opt/myapp/venv/bin/gunicorn --config /opt/myapp/config/gunicorn.conf.py myapp.asgi:application # 检查进程树 ps auxf | grep gunicorn # 应看到：gunicorn: master [myapp] -> gunicorn: worker [myapp] (x9) -> python3 -m uvicorn...若只看到gunicorn: worker而无uvicorn字样，说明worker_class配置错误或Uvicorn未安装。
3.4 反向代理与HTTPS：Nginx配置的生产级实践
Nginx不仅是反向代理，更是Web应用的第一道防护盾。我们的配置摒弃了网上流传的“万能模板”，聚焦三个核心场景：
基础反向代理配置/etc/nginx/sites-available/myapp
upstream myapp_backend { server 127.0.0.1:8000 fail_timeout=10s max_fails=3; # 若有多台后端，可添加server 10.0.1.10:8000 ... } server { listen 80; server_name myapp.example.com; return 301 https://$server_name$request_uri; # 强制HTTP跳转HTTPS } server { listen 443 ssl http2; server_name myapp.example.com; # SSL证书（使用Let's Encrypt） ssl_certificate /etc/letsencrypt/live/myapp.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/myapp.example.com/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/myapp.example.com/chain.pem; # SSL性能优化 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; # 安全头 add_header X-Frame-Options "DENY" always; add_header X-XSS-Protection "1; mode=block" always; add_header X-Content-Type-Options "nosniff" always; add_header Referrer-Policy "no-referrer-when-downgrade" always; add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';" always; # 静态文件服务（Django collectstatic后） location /static/ { alias /opt/myapp/src/staticfiles/; expires 1y; add_header Cache-Control "public, immutable"; } location /media/ { alias /opt/myapp/src/media/; expires 1y; } # 动态请求转发 location / { proxy_pass http://myapp_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_set_header X-Forwarded-Host $server_name; proxy_set_header X-Forwarded-Port $server_port; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_redirect off; proxy_buffering on; proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k; } }upstream块定义后端集群，fail_timeout和max_fails实现健康检查；ssl_ciphers精简为仅支持现代浏览器（Chrome 70+/Firefox 63+），剔除弱加密套件；Content-Security-Policy是防XSS的终极武器，script-src允许'unsafe-inline'是为兼容Django模板中的内联JS，但生产环境应通过django-csp插件动态生成策略。
Let's Encrypt自动化续期
# 使用certbot-auto（已停用）？不，用snap安装的certbot sudo snap install --classic certbot sudo ln -s /snap/bin/certbot /usr/bin/certbot # 获取证书（需提前配置DNS或HTTP验证） sudo certbot --nginx -d myapp.example.com # 自动续期（certbot会自动添加crontab） sudo certbot renew --dry-runcertbot renew --dry-run必须执行，它模拟续期流程，验证DNS解析、端口连通性、Nginx配置有效性。我们曾因DNS TTL未刷新，导致dry-run成功但真实续期失败，证书过期。
3.5 systemd服务管理：从脚本到工业级服务的跨越
将Python Web应用注册为systemd服务，是告别nohup gunicorn &的标志。我们的服务文件追求可审计、可调试、可回滚：
服务文件/etc/systemd/system/myapp.service
[Unit] Description=MyApp Python Web Application Documentation=https://myapp.example.com/docs After=network.target nginx.service [Service] Type=simple User=deploy Group=deploy WorkingDirectory=/opt/myapp/src EnvironmentFile=/opt/myapp/config/environment.env ExecStart=/opt/myapp/venv/bin/gunicorn --config /opt/myapp/config/gunicorn.conf.py myapp.asgi:application Restart=on-failure RestartSec=10 StartLimitInterval=600 StartLimitBurst=5 KillMode=mixed KillSignal=SIGTERM TimeoutStopSec=30 LimitNOFILE=65536 LimitNPROC=65536 MemoryLimit=2G SyslogIdentifier=myapp [Install] WantedBy=multi-user.targetEnvironmentFile指向/opt/myapp/config/environment.env，内容为：
DJANGO_SETTINGS_MODULE=myapp.settings.production DATABASE_URL=postgres://user:pass@10.0.1.5:5432/myapp REDIS_URL=redis://10.0.1.6:6379/0 SECRET_KEY=your-32-char-secret-key-here关键设计点：
Restart=on-failure：仅在进程非0退出时重启，避免无限崩溃循环；StartLimit*：10分钟内最多启动5次，防止单点故障引发雪崩；KillMode=mixed：发送SIGTERM给主进程，同时向整个cgroup发送SIGKILL，确保Uvicorn事件循环彻底退出；MemoryLimit=2G：cgroup内存硬限制，超限时systemd直接OOM Kill，比应用内内存监控更可靠；SyslogIdentifier：所有日志以myapp标识，journalctl -u myapp -f即可实时追踪。
服务管理命令
sudo systemctl daemon-reload # 修改service文件后必执行 sudo systemctl enable myapp.service # 开机自启 sudo systemctl start myapp.service # 启动 sudo systemctl status myapp.service # 查看状态（含最近10行日志） sudo journalctl -u myapp -n 100 -f # 实时跟踪日志 sudo systemctl restart myapp.service # 平滑重启（先stop再start）systemctl status输出中，Active:状态为active (running)且Main PID:有数字，表示服务已就绪；若为activating (auto-restart)，说明刚启动失败，立即journalctl -u myapp -n 50查错。
4. 实操过程与核心环节实现：一次完整的端到端部署演练
4.1 环境准备与工具链安装（5分钟）
假设你有一台全新的Ubuntu 22.04云服务器（2核4GB内存，50GB SSD），公网IP为203.0.113.10，域名myapp.example.com已解析到该IP。以下是零基础开始的完整操作流，每一步都附带原理说明：
Step 1：SSH登录并更新系统
ssh root@203.0.113.10 # 输入root密码（首次登录后建议立即改密） sudo apt update && sudo apt full-upgrade -y # 此步耗时约2-3分钟，安装内核更新、安全补丁 # 验证：sudo apt list --upgradable 应返回空full-upgrade会处理依赖冲突，例如将旧版openssl升级到3.0.2，这是TLS 1.3支持和心脏出血漏洞修复的基础。
Step 2：创建部署用户并配置SSH
sudo adduser deploy --gecos "Deploy User,,," --disabled-password sudo usermod -aG sudo deploy # 生成SSH密钥对（本地机器执行） ssh-keygen -t ed25519 -C "deploy@myapp" -f ~/.ssh/myapp_deploy # 复制公钥到服务器 ssh-copy-id -i ~/.ssh/myapp_deploy.pub deploy@203.0.113.10 # 测试免密登录 ssh -i ~/.ssh/myapp_deploy deploy@203.0.113.10ed25519算法比RSA更安全、更快；ssh-copy-id自动处理~/.ssh/authorized_keys权限，比手动复制更可靠。
Step 3：安装基础工具链
# 切换到deploy用户 su - deploy # 安装git（拉取代码）、curl（调试）、htop（监控） sudo apt install git curl htop -y # 验证：git --version 应返回2.34+htop比top更直观，可按CPU/MEM排序，实时查看Gunicorn worker内存占用。
4.2 项目代码部署与配置（10分钟）
Step 4：创建项目目录并拉取代码
sudo mkdir -p /opt/myapp/{src,logs,config,venv} sudo chown -R deploy:deploy /opt/myapp cd /opt/myapp/src # 从Git仓库拉取（假设使用GitHub私有库） git clone https://github.com/myorg/myapp.git . # 若用SSH，需先配置deploy用户的SSH key # git clone git@github.com:myorg/myapp.git ./opt/myapp/src是代码根目录，git clone .将代码直接检出到当前目录，避免多一层子目录。
Step 5：配置环境变量与敏感信息
# 创建环境变量文件 cat > /opt/myapp/config/environment.env << 'EOF' DJANGO_SETTINGS_MODULE=myapp.settings.production DATABASE_URL=postgres://myapp_user:myapp_pass@10.0.1.5:5432/myapp_db REDIS_URL=redis://10.0.1.6:6379/0 SECRET_KEY=django-insecure-8vzjxq9w2k7l5m4n1o0p6r3s5t7u9v1x2y3z4 DEBUG=False ALLOWED_HOSTS=myapp.example.com,203.0.113.10 EOF # 设置权限 sudo chmod 600 /opt/myapp/config/environment.env sudo chown deploy:deploy /opt/myapp/config/environment.envSECRET_KEY必须是32位随机字符串，用openssl rand -base64 32生成；ALLOWED_HOSTS必须包含域名和IP，否则Django返回400 Bad Request。
Step 6：安装Python依赖
# 创建venv python3 -m venv /opt/myapp/venv # 升级pip /opt/myapp/venv/bin/pip install --upgrade pip setuptools wheel # 安装依赖（假设requirements.txt已提交到Git） /opt/myapp/venv/bin/pip install -r /opt/myapp/src/requirements.txt --no-cache-dir # 验证：/opt/myapp/venv/bin/python -c "import django; print(django.__version__)"--no-cache-dir防止pip缓存损坏，-c "import django"是快速验证依赖安装成功的最简方法。
4.3 Web服务器与反向代理配置（15分钟）
Step 7：配置Gunicorn
# 创建Gunicorn配置目录 mkdir -p /opt/myapp/config # 编写gunicorn.conf.py（内容见3.3节） cat > /opt/myapp/config/gunicorn.conf.py << 'EOF' # ...（粘贴3.3节的完整配置） EOF # 验证配置语法 /opt/myapp/venv/bin/gunicorn --config /opt/myapp/config/gunicorn.conf.py --check-config myapp.wsgi:application # 应输出"Configuration checked."--check-config是Gunicorn的语法检查开关，避免配置错误导致服务启动失败。
Step 8：安装并配置Nginx
sudo apt install nginx -y # 启用站点 sudo ln -sf /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/ # 测试Nginx配置 sudo nginx -t # 应输出"nginx: configuration file /etc/nginx/nginx.conf test is successful" sudo systemctl restart nginxnginx -t是Nginx的配置验证命令，必须在systemctl restart前执行，否则配置错误会导致Nginx宕机。
Step 9：申请并配置SSL证书
# 安装certbot sudo snap install --classic certbot sudo ln -s /snap/bin/certbot /usr/bin/certbot # 获取证书（需确保域名DNS已生效） sudo certbot --nginx -d myapp.example.com # 此步会自动修改/etc/nginx/sites-available/myapp，添加SSL配置 # 验证HTTPS访问 curl -I https://myapp.example.com # 应返回HTTP/2 200 OKcertbot --nginx会自动编辑Nginx配置，无需手动修改，这是其最大优势。
4.4 systemd服务注册与启动（5分钟）
Step 10：创建并启用systemd服务
# 创建service文件 sudo tee /etc/systemd/system/myapp.service << 'EOF' # ...（粘贴3.5节的完整配置） EOF # 重载systemd配置 sudo systemctl daemon-reload # 启用开机自启 sudo systemctl enable myapp.service # 启动服务 sudo systemctl start myapp.service # 检查状态 sudo systemctl status myapp.servicesystemctl status输出中，Active:应为active (running)，Main PID:后有数字，且journalctl -u myapp -n 10应显示Gunicorn启动日志。
Step 11：验证端到端连通性
# 检查Nginx是否代理到Gunicorn curl -H "Host: myapp.example.com" http://127.0.0.1 # 应返回Django欢迎页或API JSON # 检查HTTPS是否
