企业官网建设流程全解析

前阵子帮一个朋友把他写的某个Python内容服务搬上一台服务器，整个过程踩了一圈坑，最后用 Docker + Nginx 把整个部署理顺了。类似这种活儿，很多开发者本地跑得很顺，一到服务器就各种怪问题：依赖装不上、端口被占、进程半夜挂了没人管、代码更新一次比一次费劲。如果你也准备把一个 Python Web 应用真正部署到公网服务器上，这篇文章应该能帮你省掉大半天的试错时间。

先给结论：一个能长期跑的生产部署，至少要解决四件事——环境一致性、进程管理、流量入口、可回滚性。Docker 负责前两件，Nginx 负责流量入口，代码镜像化之后，回滚也就是一条命令的事。下面我按从思路到落地的顺序，把这套方案完整拆开讲一遍。

1. 部署思路与整体方案设计

1.1 为什么不是“直接在服务器上 pip install 然后跑起来”

很多人第一次部署都会想：本地就是这么跑的，服务器上也装个 Python，把代码拉下来，pip install 一下，nohup python app.py 不就行了？短期看确实能跑，但只要你打算把这个服务长期放在公网上，这套做法很快就会让你头疼。

首先是环境一致性问题。本地开发机可能装的是 Python 3.12，服务器上是 Python 3.10；本地装过某个依赖的旧版本，requirements.txt 里又没锁版本；开发时用 Windows，线上是 Linux——任何一点差异都可能导致代码在服务器上表现不同。等到出问题的时候，你根本分不清是代码 bug 还是环境差异。

其次是进程管理。nohup 启动的进程，终端一关或者进程崩溃，服务就没了。你需要在服务器上额外配置进程守护工具，处理开机自启、崩溃重启、日志收集这些事。这些都不是 Web 应用本身的内容，但每一个都会占掉你的运维精力。

Docker 的核心思路，是把“代码 + 依赖 + 运行环境”打包成一个镜像。镜像在哪里构建、在哪里运行，结果都是一样的。这意味着你在本地能跑通的东西，拉到服务器上大概率也能跑通。再配合容器的重启策略，进程挂了系统会自动拉起来，省掉一大块手工维护工作。

1.2 请求是怎么从浏览器走到 Python 代码的

部署方案里，Docker 和 Nginx 不是二选一的关系，而是分工合作。最外层是 Nginx，监听服务器的 80 和 443 端口；内部是 Python 应用容器，监听一个不对公网开放的内部端口；Nginx 负责接收外部请求，再把请求转发给内部的应用容器。

整个链路是这样：用户访问你的域名 → 请求到达服务器 Nginx → Nginx 检查路径和头信息，把动态请求转发给 Docker 内部的 Python 服务 → Python 应用处理完返回响应 → Nginx 把响应交回给用户。

你可能要问：为什么不让 Python 服务直接监听 80 端口对外服务？原因有几个。

第一，Python Web 应用本身不是一个完整的服务器软件。无论是 Flask、Django 还是 FastAPI，跑生产都需要一个专门的 WSGI/ASGI 服务进程（通常用 Gunicorn 或 Uvicorn）来承接请求。这个进程处理动态请求没问题，但处理静态文件、超时控制、请求头校验这些事情，远不如 Nginx 专业。

第二，一个服务器上往往不止一个应用。你可能有 Python 服务、前端静态站点、以后还可能加别的服务。如果每个服务都直接占一个公网端口，管理混乱且不安全。让 Nginx 统一管理入口，按域名或路径转发到不同服务，是业界通用做法。

第三，Nginx 在连接层做的事情太多了：HTTPS 证书管理、请求体大小限制、压缩、访问日志、限流、静态文件服务，这些放前面统一处理，比在应用代码里自己实现可靠得多。

1.3 这套方案能解决哪些具体问题

按我的经验，这套组合解决的不是“能不能跑”，而是“能不能长期可靠地跑”。

环境一致性：镜像把 Python 版本、系统依赖、项目依赖全部固化下来。换一台服务器，无非是拉同一个镜像再跑起来，结果一致。

依赖冲突：不同项目可能需要不同版本的同一个库。容器之间完全隔离，A 项目用 Flask 2.x，B 项目用 Flask 3.x，互不干扰。

端口管理：对外只暴露 80/443，内部端口随意分配。服务器上跑 5 个应用也不会端口打架。

发布回滚：新版本构建成新镜像，出了问题可以瞬间切回旧镜像。比在服务器上改代码、重装依赖再重启的方式快得多。

我做这次部署用的是 FastAPI + Gunicorn + Docker Compose + Nginx 这套组合，下面所有配置都按这个场景来写。用 Django 或 Flask 的，除了一两处启动命令不同，其余思路完全一致。

2. 从零写一个能上生产的 Dockerfile

2.1 基础镜像与 Python 依赖管理

Dockerfile 是整个部署的第一步，也是最容易埋坑的地方。先看一个基础版本：

FROM python:3.12-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD ["gunicorn", "app.main:app", "-b", "0.0.0.0:8000", "-k", "uvicorn.workers.UvicornWorker", "-w", "4"]

这里面有几个选择不是随手写的，我逐个解释。

基础镜像用python:3.12-slim，不是python:latest，也不是python:3.12。latest 不带版本号，镜像内容会随上游更新，哪天基础系统换了版本，你的应用可能莫名其妙出问题。完整版 python 镜像包含一堆编译器和工具链，体积大且没必要。slim 是精简版，去掉了大部分编译工具，镜像体积小很多，构建和拉取都更快。

如果你需要编译某些带 C 扩展的依赖（比如某些数据处理的库），slim 里可能缺编译工具，构建会失败。此时有两个方向：一是换成完整版基础镜像，简单粗暴但镜像体积大；二是用多阶段构建，在完整镜像里编译好依赖，再把产物拷贝到 slim 镜像里。我推荐第二种，下面会讲具体写法。

再讲依赖管理。很多人习惯pip freeze > requirements.txt，这种做法在生产环境经常出问题。pip freeze 会把当前环境里所有包都导出来，包括一些和项目无关的传递依赖，而且版本号往往是==精确锁定，换到别的平台时某些包的编译版本可能对不上。

更合理的方式是手写 requirements.txt，只写项目直接依赖，并锁定主版本：

fastapi==0.115.* uvicorn[standard]==0.30.* gunicorn==22.*

这样既保证了可复现性，又不会把无关包带进来。更新依赖时，有意识地升级版本再提交，比一口气全部升级安全得多。

2.2 依赖安装顺序与镜像缓存优化

Dockerfile 里 COPY 的顺序，直接影响构建速度。看我上面的写法：先 COPY requirements.txt，安装依赖，再 COPY 整个项目目录。这样安排是有讲究的。

Docker 构建镜像时，每一行指令都会生成一层缓存。如果某一行输入的内容没变化，它就直接复用缓存，不重新执行。先复制 requirements.txt 再安装依赖，意味着只要依赖文件没变，这一层缓存就一直在，后续每次修改代码重新构建时，都不会重新下载和安装 Python 包。如果你把COPY . .写在安装依赖前面，那代码一改动，依赖也要全部重装，构建时间从几十秒变成几分钟。

逻辑上这一点很多人容易忽略：代码变更频率，远远高于依赖变更频率。让最常变化的内容尽量放在 Dockerfile 后面，是最基本的镜像构建优化。

2.3 多阶段构建：把镜像体积压下来

如果项目依赖里有需要编译的库，推荐用多阶段构建。第一阶段用完整镜像编译，第二阶段只打包运行产物。

FROM python:3.12 AS builder WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir --prefix=/install -r requirements.txt FROM python:3.12-slim WORKDIR /app COPY --from=builder /install /usr/local COPY . . RUN useradd --create-home appuser && chown -R appuser:appuser /app USER appuser CMD ["gunicorn", "app.main:app", "-b", "0.0.0.0:8000", "-k", "uvicorn.workers.UvicornWorker", "-w", "4"]

第一阶段用完整镜像，编译工具齐全，依赖装到/install目录；第二阶段用 slim 镜像，只需要把/install里的产物复制过来，编译工具全都留在第一阶段，最终镜像里没有多余的编译链。这一招通常能把镜像体积砍掉一半以上。

还有两个细节要注意。--prefix=/install指定了 pip 的安装目录，拷贝到第二阶段之后，/usr/local下的 Python 包路径才是 Python 解释器默认查找的位置，所以COPY --from=builder /install /usr/local这行不能漏。另外，多阶段构建里第一阶段叫什么名字无所谓，关键是--from=builder要对应。

2.4 为什么不要在容器里再建虚拟环境

有些教程习惯在 Dockerfile 里python -m venv venv再venv/bin/pip install，然后通过它的 Python 启动应用。逻辑上没毛病，但在容器里是多余的。

Docker 容器本身就是一个隔离环境，它有自己的文件系统、自己的 Python 解释器、自己的包目录。再建一层虚拟环境，相当于隔离里面再套一层隔离，白白增大镜像体积，还容易搞乱路径。在容器里，直接往系统 Python 装依赖就行。这一点我刚上手时也犯过糊涂，后来想通了一个类比：虚拟环境解决的是“同一台机器上多个项目环境污染”的问题，而容器已经把这个层面彻底隔开了，不需要再叠床架屋。

2.5 用非 root 用户运行，别图省事

很多入门项目直接用默认的 root 用户跑应用，省事是省事，但安全上不合适。容器里 root 一旦被攻破，攻击者获得的就是容器内最高权限；用普通用户跑应用，能把攻击面压到最小。

上面 Dockerfile 里加了两行：

RUN useradd --create-home appuser && chown -R appuser:appuser /app USER appuser

useradd创建一个普通用户，chown把应用目录的属主改成这个用户，最后切过去。这里有个常见坑：如果应用需要写某些目录（比如挂载的日志目录、上传文件目录），权限不够会直接报错。这时你需要确保挂载进来的宿主机目录对容器内的 appuser 有写权限，通常是在宿主机上chown -R 1000:1000对应的目录，因为容器里第一个普通用户 UID 默认是 1000。

2.6 Gunicorn 启动参数怎么定

启动命令里最值得琢磨的是-w 4，也就是 worker 进程数。Gunicorn 是预派生的，每个 worker 都是一个独立的 Python 进程，可以并行处理请求。

worker 数不是越大越好。每个 Python 进程都有不小的内存开销，开太多会把服务器内存吃光。业内常说的经验值是CPU 核数 × 2 + 1，但实际部署时我更倾向于先看内存。一台 2G 内存的小服务器，开 4 个 worker 差不多就到顶了；如果是 4 核 8G，可以开 8 个甚至更多。记住一个原则：worker 数要让 CPU 尽量忙起来，同时内存不能撑爆。你可以在部署后用docker stats观察内存占用，再回头调整 worker 数。

-b 0.0.0.0:8000这里要注意，必须监听 0.0.0.0，不能写 127.0.0.1。原因后面配 Nginx 时会讲到：Nginx 跑在另一个容器里，它访问的不是本机回环地址，而是应用容器的内部网络地址。只监听 127.0.0.1 的话，外部容器根本连不进来。

-k uvicorn.workers.UvicornWorker是给 FastAPI 这类异步框架用的，让 Gunicorn 用 Uvicorn 的 worker 来跑 ASGI 应用。如果是 Flask 或 Django，这一行去掉就行，默认的同步 worker 就够用。

3. 用 Docker Compose 把服务和入口串成一套

3.1 先写一个能直接用的编排文件

Dockerfile 定义的只是“应用容器”本身，但一个完整的部署还要有 Nginx、卷、网络、重启策略。用 Docker Compose 把这些串起来，管理和启动都方便很多。示例编排文件：

services: app: build: . restart: unless-stopped env_file: - .env networks: - webnet nginx: image: nginx:1.27-alpine restart: unless-stopped depends_on: - app ports: - "80:80" - "443:443" volumes: - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro - ./ssl:/etc/nginx/ssl:ro - ./static:/app/static:ro - ./logs/nginx:/var/log/nginx networks: - webnet networks: webnet:

注意看，app 服务没有映射任何端口到宿主机。这是刻意的。应用只暴露在 Compose 自己的内部网络里，只有 nginx 这个服务才映射 80/443 到宿主机。这样从公网进来，唯一的入口就是 Nginx，应用容器本身对外不可见，少一个暴露面就少一分风险。

调试的时候，你可能想直接从宿主机访问应用端口看一下效果，可以临时给 app 加上ports: "8000:8000"，调完再删掉。这个习惯我建议一直保持：对外能少露端口就少露。

env_file: .env用来注入环境变量，数据库连接串、密钥这类敏感信息放.env文件里，不要写进镜像或者 compose 文件。.env文件需要加进.gitignore，版本库里只留一个.env.example模板。

3.2 重启策略与健康检查

restart: unless-stopped是我常用的重启策略，意思是容器异常退出时自动重启，但如果是手动 stop 的就不拉起。区别于always，always 会在 Docker 重启后无条件拉起来，哪怕你之前手动停掉它想维护，它也会被重新拉起，有时候挺烦人的。

depends_on在编排文件里写了，但它只控制服务启动顺序，不保证“应用真正可用”。也就是说，app 容器起来了，不代表 FastAPI 已经能处理请求了。Nginx 先启动后，如果 app 还没就绪，访问时就会看到 502。这个问题可以通过健康检查缓解。

在 app 服务里加一段：

healthcheck: test: ["CMD", "python", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:8000/health', timeout=3)"] interval: 30s timeout: 5s retries: 3 start_period: 10s

应用代码里提供一个/health接口，返回 200。Docker 会定期访问这个接口，如果连续失败，就认为容器不健康。这个能力有两个用途：一是配合 Nginx 或编排系统做流量切换；二是你自己排查问题时，docker ps里健康状态一眼就能看出来。

3.3 网络模式：为什么是内部网络而不是 host 模式

Compose 默认会创建一个 bridge 网络，所有服务都在一个虚拟网络里，彼此通过服务名直接访问。在这个网络里，app 服务的“主机名”就是app，Nginx 配置里写http://app:8000就能连到应用容器。

有些教程为了省事，建议用network_mode: host，让容器直接用宿主机的网络栈。这样配置确实变简单，应用监听 8000，Nginx 监听 80，都在宿主机上。但缺点也明显：host 模式下容器之间没有网络隔离，端口直接用宿主机端口，多服务共存时很容易冲突，也不方便做多副本扩展。生产环境我基本不用 host 模式，除非有很特殊的性能需求。

3.4 卷的挂载策略

上面编排文件里挂载了几个卷，目的各不相同：

./nginx.conf:/etc/nginx/conf.d/default.conf:ro把宿主机上的 Nginx 配置直接挂进容器，改配置不需要重新构建镜像，重启 Nginx 容器就能生效，改起来非常快。

./ssl:/etc/nginx/ssl:ro挂证书目录，方便证书更新。

./static:/app/static:ro静态文件。如果项目把静态资源统一放在宿主机目录，Nginx 可以直接读它来服务，不需要经过 Python 进程。

生产环境里，日志和上传文件这类动态数据要放在卷或宿主机目录里。文件如果写进容器内部，容器重建后数据就随容器生命周期消失了。日志目录映射到宿主机，出了问题才能翻日志。

4. Nginx 流量入口配置：核心要点与高频踩坑

4.1 第一个 server 配置应该长什么样

Nginx 是整个部署里最容易踩坑的一环，很多新手在这里一卡就是半天。先给一个可以拿来改改就用的配置：

upstream app_upstream { server app:8000; } server { listen 80; server_name your-domain.com; client_max_body_size 20m; location /static/ { alias /app/static/; expires 7d; access_log off; } location / { proxy_pass http://app_upstream; 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_read_timeout 60s; proxy_connect_timeout 5s; } gzip on; gzip_types text/plain text/css application/json application/javascript; gzip_min_length 1024; }

第一段upstream定义了后端应用组，server app:8000里的app就是 Docker Compose 网络里的服务名，不是 IP 地址，也不是 localhost。这里是新手高频出错的地方：把app:8000写成localhost:8000，结果 Nginx 在它自己容器里找 localhost，找到的是 Nginx 自己的回环地址，根本没这个服务，502 就来了。记住：跨容器访问要用服务名，不是 localhost。

proxy_pass指向upstream名字后，请求会被转发到 app 容器内部的 Gunicorn。proxy_set_header这几行非常重要，尤其是Host和X-Forwarded-Proto。

Host头不传的话，后端框架里生成绝对链接时会用错域名。X-Forwarded-Proto不传的话，你的 Python 应用不知道外部用户用的是 HTTPS 还是 HTTP，做强制跳转或者 OAuth 回调时就会出问题。FastAPI、Django 依赖这些头信息做正确处理的，少了任何一个都会引发离奇 bug。

client_max_body_size 20m是请求体大小限制，如果你的应用涉及文件上传，一定要根据实际情况调大，默认是 1m，传一个稍微大点的文件就会被 Nginx 直接挡下来，后端日志里什么都看不到。

location /static/专门处理静态文件，alias 指向的是宿主机挂载进来的静态目录，由 Nginx 直接读文件返回，完全不经过 Python。这一步能显著降低 Python 进程的负载。

4.2 配置 HTTPS：现在就该做，别拖

如果你的站点要用 HTTPS，Nginx 配置里加一个 80 端口跳转，再写一个 443 端口的 server 块：

server { listen 80; server_name your-domain.com; return 301 https://$host$request_uri; } server { listen 443 ssl; http2 on; 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; # 其他 location 配置与上面相同 }

证书获取推荐用 ACME 协议申请免费证书，各大云服务商或者证书签发机构都有相应的客户端，只需要一个域名和服务器。初次部署时，域名解析先指向服务器 IP，等证书下来再启用 443，流程更顺畅。

证书路径/etc/nginx/ssl/对应 Compose 里挂载的./ssl目录，证书过期后你只需替换宿主机目录里的文件，再docker compose exec nginx nginx -s reload就行。记得给证书加个自动续期任务。

4.3 顺手把安全加固做掉

服务上线很容易忽略安全头，先加这几个响应头，成本低收益高：

add_header X-Frame-Options "SAMEORIGIN" always; add_header X-XSS-Protection "1; mode=block" always; add_header X-Content-Type-Options "nosniff" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always;

再在 server 块里关掉版本号暴露：

server_tokens off;

还可以做简单的请求方法限制。比如只允许常见的 GET、POST、HEAD，拒绝 PUT、DELETE 之外的敏感方法。如果你的应用确实不需要某些方法，直接在 Nginx 层挡掉，后端代码都不用管。

限流也是 Nginx 的强项。比如同一个 IP 每秒超过 20 次请求就返回 429：

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=20r/s; server { ... location / { limit_req zone=mylimit burst=40 nodelay; proxy_pass http://app_upstream; } }

burst=40表示允许短暂突发 40 个请求排队，nodelay表示排队时不额外等待。这个配置尤其适合赶在上有活动流量突然暴增的接口，不然 Python 进程很容易被打满。

如果你想对 WebSocket 做转发，需要额外加两个头：

proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";

FastAPI 天然支持 WebSocket，不配这两行的话，客户端连接会直接失败。

4.4 为什么不让 Nginx 直接访问应用端口

回到之前卖的那个关子。应用容器监听的是0.0.0.0:8000，但 Compose 没有把它映射到宿主机。Nginx 容器通过 Docker 内部网络，用app:8000这个服务名就能访问到它。也就是说，宿主机上执行curl localhost:8000不一定通，但 Nginx 容器内部执行curl http://app:8000可以通。

这个设计整体上更安全、也更干净。公网流量只进 80/443，到达 Nginx 后由它决定转发给哪个后端。哪天你想再加一个别的服务，比如再来一个 Node.js 应用，无非是再加一个容器、再写一个 location 或者 server 块，互不干扰。

5. 发布上线后的常见故障排查实录

5.1 遇到问题先按这个顺序查

我第一次部署这套方案时，遇到 502 脑子一片空白，到处搜索，浪费了很多时间。后来总结出一个固定的排查顺序，效率高很多。

第一步，看容器状态。执行docker compose ps，确认所有容器是 running 状态，注意看 health 列。容器 Exited 了，直接看日志；容器在 Running 但不健康，多半是应用内部问题。

第二步，看应用日志。执行docker compose logs --tail=50 app，大多数问题在日志里都写得明明白白：导入失败、端口被占、数据库连不上。

第三步，在容器网络里做连通性测试。执行docker compose exec nginx curl http://app:8000/health，如果 Nginx 容器里能通，问题就出在 Nginx 配置；如果不通，问题出在应用容器启动或应用本身，需要回第二步继续查。

第四步，看 Nginx 的错误日志。日志挂载到了宿主机的./logs/nginx目录，直接看error.log，nginx 自己也会把连接失败原因写清楚，比如connect() failed (111: Connection refused)这类信息会直接帮你锁定方向。

按这个顺序走下来，绝大多数问题十分钟内能定位。

5.2 新手最容易遇到的问题速查

5.3 镜像构建缓存引发的诡异问题

还有个问题很隐蔽：改了 requirements.txt，重新构建却发现容器里依赖还是老版本。原因是 Docker 的构建缓存。COPY requirements.txt .这一步，Docker 是通过文件内容变化来判断缓存是否失效的。如果你只改了包版本，但文件内容确实变了，按理说缓存会失效并重新装依赖。但有时会碰到另一种情况——你改了源码，没改依赖，恰好源码 COPY 在依赖之后，构建时直接复用依赖层缓存，没问题；可如果你把依赖装在了COPY . .之后，任何源代码变更都会导致依赖重新安装，反而更容易遇到莫名其妙的半更新状态。

我的建议很简单：Dockerfile 的指令顺序严格遵守“COPY 依赖文件 → 装依赖 → 再 COPY 源码”。如果遇到依赖确实没更新的情况，直接docker compose build --no-cache app，强制全量重建，几乎都能解决。

5.4 权限问题：非 root 用户带来的坑

用非 root 用户跑应用之后，最常碰到的报错是挂载目录没有写权限。比如日志目录、上传目录挂在宿主机上，容器内应用没法写，应用启动后报Permission denied。

排查方法：看容器内用户的 UID，通常普通用户是 1000；然后看宿主机挂载目录的属主，用ls -l查看；把宿主机目录的属主改成 1000，执行chown -R 1000:1000 ./logs就行。这个坑几乎每个人都踩一次，踩过之后就能记住：挂载目录的权限，宿主和容器两边都要看。

6. 维护期的更新、监控与回滚心得

6.1 无损更新：从构建到切换的完整流程

服务上线之后，最频繁的操作就是发新版本。手工在服务器上改代码是下策，正确姿势是走镜像流程。

假设你在服务器上已经有了代码和 Compose 文件，常规发布流程是三步：

git pull docker compose build app docker compose up -d

docker compose up -d会把变更的容器重建启动。这里有一个现实问题：如果只有一份应用容器，重建过程中会有短暂的服务中断。对内部管理系统这类场景问题不大，如果是面向用户的高流量服务，就要考虑无损更新。

无损更新的一个简单方案：应用跑两个副本，放在 Nginx 的 upstream 里，发布时先构建新镜像，逐个更新副本，保证任何时刻至少有一个实例在服务。这个方向的复杂度会高一些，但思路就是“滚动替换”。对于前期项目，先把基础流程跑通比一步到位更重要。我个人体感是，先能一键发布，再考虑零中断。

回滚是镜像化带来的隐藏收益。发布前给镜像打上registry.example.com/app:v1.0.1这样的标签，新版本出问题时，只需把 compose 文件里的镜像标签改回旧版本，再docker compose up -d就完成了回滚。比起在服务器上翻代码、切分支、重装依赖，这个操作只需要几十秒。

如果你资源充足，建议把构建过程放到 CI 里自动完成，构建出镜像后推到镜像仓库，服务器只负责拉取和运行。这样服务器上甚至不需要代码目录，跑的是什么版本一目了然，回滚也更方便。

6.2 日志策略：日志不能无限增长

Docker 默认的日志驱动是 json-file，它会存下容器标准输出的全部内容，而且没有上限。长时间不清理，日志文件会膨胀到几个 G，把磁盘占满。这是一个非常典型的“服务器跑久了突然挂掉”的原因。

在 Compose 文件里给服务加上日志限制：

logging: driver: json-file options: max-size: "10m" max-file: "3"

这样每个日志文件达到 10M 就轮转，最多保留 3 个文件，总共不超过 30M。应用日志建议输出到标准输出（print 或 logging 默认 handler），这样 Docker 能统一收集；需要长期保留或分析的日志，再单独挂载目录存一份。

6.3 监控先从小做起

很多项目一上来就想着上整套监控系统，其实前期没必要，也撑不住那个运维成本。先从最小闭环开始：

第一，Docker 本身的健康状态要经常看。配合restart: unless-stopped，大部分临时崩溃会自动恢复。你只需要偶尔docker compose ps瞄一眼状态。

第二，用docker stats查看资源占用。这个命令能看到 CPU 和内存实时使用量，观察几天你就知道这个应用的内存基线是多少，以后排查问题时心里有数。

第三，磁盘和证书过期，这两个最容易被忽视。磁盘满了服务自然挂，证书过期了 HTTPS 直接断开。证书的自动续期脚本要保证能跑起来，我的经验是续期后一定要手动访问一下站点确认无误，脚本静默失败过好多次了。

6.4 这个方案往后还能怎么扩展

等这个基础部署跑顺了，可以根据业务需要逐步升级。

应用规模大了，可以把数据库容器从 Compose 文件里拆出去，用独立数据库服务，避免应用和数据库共享生命周期。

需要多机部署时，Nginx 可以换成更专业的流量入口方案，比如在 Nginx 层做多台服务器的负载均衡；镜像推到中央仓库，每一台服务器拉同样的镜像跑应用副本。

代码变更频繁了，可以引入 CI/CD，每次合并代码自动构建镜像、自动推送、自动在测试环境验证，最后手动一键发布生产。这个流程跑起来之后，发布就变成了一个有护栏的流水线，不再依赖某个人的记忆和手速。

我在实际部署这套方案时最大的感受是：一开始觉得步骤多，Docker 一处、Compose 一处、Nginx 又一处，好像每个环节都在增加工作量。但全套跑通一次之后，后续每次发布就是几个命令的事，环境迁移也变成“拖过去就能跑”。如果你也正在准备把 Python 应用部署到服务器，照着这个思路把基础链路打通，后续所有扩展都会顺很多。最后给一个建议：上线前在本地完整复现一遍这套部署，至少跑通一次构建、启动、请求、日志四个环节，真到了服务器上，你会省下大量排查时间。