韩国cn2服务器部署Docker Compose应用时，端口映射和数据卷要先规划

上线前先把这四件事定下来

应用刚从本地迁到韩国cn2服务器时，最容易出问题的通常不是 docker compose up -d 这一步，而是前面的规划：哪些端口要对外、哪些只在容器内部通信、数据库和上传文件放哪里、以及服务起来的顺序是否依赖数据库就绪。只要这些内容先理顺，后面部署会轻很多。

对单机 Compose 来说，最重要的判断是：它负责编排和启动，不负责自动高可用。所以在韩国cn2服务器上部署时，端口映射、数据卷持久化、密钥管理和日志策略都要先设计好，不能等服务跑起来再补。

检查项	上线前要确认什么	为什么重要
端口映射	哪些端口对公网开放，哪些只本机可访问	避免冲突和误暴露
数据卷	数据、配置、上传文件、日志是否持久化	容器重建后不丢数据
环境变量与密钥	哪些是非敏感配置，哪些必须单独保管	防止泄露和误提交
启动顺序	应用是否依赖数据库、缓存、对象存储	避免容器先起但服务不可用

操作步骤：先梳理依赖，再写 Compose

1. 先确认服务之间怎么通信

很多站点在部署时会把所有端口都映射到宿主机，结果不仅占端口，还把数据库、管理后台一起暴露出去。更稳妥的做法是先区分两类服务：

对外入口：通常是 Web 反向代理、API 网关、前端站点
内部依赖：数据库、缓存、任务队列、对象存储客户端

内部依赖一般只需要容器网络通信，不必映射到宿主机端口。比如数据库只给应用容器访问，应用容器再由 Nginx 或宿主机反代对外提供 80/443。

2. 端口映射先按“入口最少化”设计

在韩国cn2服务器上，跨地域访问性能通常不是瓶颈，真正影响部署稳定性的往往是端口规划是否清楚。建议遵循这几个原则：

公网只暴露必要端口：一般只保留 80/443，其他管理端口尽量不开放
同一台机器上避免端口冲突：如果宿主机已有 Nginx、Apache 或其他站点，先查占用再分配
内部服务优先用 expose，少用 ports：让容器网络内可见即可
管理类端口优先绑定 127.0.0.1：需要临时访问时可配合 SSH 隧道，而不是直接裸露公网

一个常见思路是：应用容器只监听 8080，宿主机用 127.0.0.1:8080:8080 暴露给本机反向代理；数据库不映射到宿主机，只在 Docker 网络内访问。

3. 数据卷按“可恢复”和“可替换”分开规划

容器镜像本身应该是可替换的，真正需要持久化的是数据。部署前最好先把目录分清楚：

数据库数据：必须独立卷保存
上传文件/附件：必须独立卷保存
应用配置：能文件化就文件化，便于回滚
运行日志：如果必须留档，单独挂载目录；如果只看控制台日志，可交给 Docker 轮转

不要把“整个宿主机目录”一股脑挂进去，也不要把虚拟机快照当作容器数据备份方案。快照只能说明某一时刻系统状态存在过，不能替代数据库备份、文件备份和恢复演练。

4. 环境变量和密钥分开处理

Compose 里最容易被忽略的是密钥。像数据库密码、第三方 API Key、短信签名、对象存储密钥这类信息，不建议直接写进 compose.yaml，也不要塞进镜像里。

可区分为两类：

环境变量：镜像版本、时区、站点域名、数据库地址、业务开关
密钥文件：数据库密码、JWT 密钥、Webhook Token、私钥文件

环境变量可以放在 .env，但要限制权限；密钥文件最好单独放到 secrets/，并设置严格权限。镜像来源和版本也要按实际项目确认，latest 不适合上线环境，容易在下次拉取时引入不可预期变化。

5. 参考一个基础 Compose 结构

下面的示例重点演示端口、数据卷、密钥和重启策略的摆放方式，实际镜像名和版本请按项目替换。

services:
  app:
    image: registry.example.com/myapp:${APP_TAG}
    env_file:
      - .env
    environment:
      TZ: Asia/Seoul
      DB_HOST: db
      DB_PORT: 5432
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - /srv/myapp/uploads:/app/uploads
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

  db:
    image: postgres:16.4
    environment:
      POSTGRES_DB: appdb
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
    volumes:
      - db_data:/var/lib/postgresql/data
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U appuser -d appdb"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  db_data:

secrets:
  db_password:
    file: ./secrets/db_password.txt

这里有几个关键点：

app 只绑定到本机 127.0.0.1，更适合再由宿主机 Nginx 统一对外
db 只挂载数据卷，不对外映射端口
restart: unless-stopped 适合单机常驻服务，但不等于高可用
depends_on 只能帮助组织启动关系，不能保证业务已经可用，真正的就绪判断仍要看健康检查和应用重试机制

关键配置怎么落地

端口映射设计：先划分外网入口和内网依赖

如果有多个站点或多个 Compose 项目同时跑在一台韩国cn2服务器上，端口规划最好提前画出来。常见做法是：

80/443 留给统一入口
每个应用的后端端口只绑定到 127.0.0.1
数据库、Redis、MQ 只走容器内部网络
需要临时管理的面板端口，用 SSH 隧道访问，而不是永久开放

这样做的好处是，后面即便迁移反代、切换证书或增加新服务，也不会因为端口散乱而反复改配置。

数据卷持久化：先保证“重建不丢”

部署应用时，真正应该长期保存的是卷而不是容器。建议上线前就把备份策略想清楚：

数据库：先做逻辑备份策略，再考虑物理备份
上传目录：定期同步到独立存储
配置文件：保留版本记录，方便回滚
日志：按保留周期轮转，不要无限增长

如果应用会写入文件，最好统一挂载到一个清晰的宿主机目录，比如 /srv/myapp/，再细分成 data、uploads、logs、config，后期查找和恢复都更直接。

日志与重启策略：只保留需要的内容

Docker 默认日志如果不做轮转，时间久了会占满磁盘。对长期运行的站点，建议至少做两件事：

容器日志开启大小限制和保留文件数
应用内部日志如果单独落盘，要和业务数据分目录管理

重启策略方面，unless-stopped 通常比完全依赖手工拉起更稳，但仍然要配合健康检查和告警。容器重启后能起来，不代表数据库连接、缓存连接和外部接口都正常。

环境变量和密钥：上线前检查权限

.env 和密钥文件最好在部署前就做好权限控制，至少要避免被无关用户读取。一个简单的准备方式是：

mkdir -p /srv/myapp/secrets
chmod 700 /srv/myapp/secrets

cat > /srv/myapp/.env <<'EOF'
APP_TAG=1.0.0
TZ=Asia/Seoul
EOF
chmod 600 /srv/myapp/.env

如果项目支持 Docker secrets，优先用 secrets；如果不支持，也要把密码文件单独存放，并保证只给运行账户可读。

部署后怎么验证

部署完成后，不要只看容器“Running”就结束，至少按这个顺序检查：

先检查配置是否能被 Compose 正确解析
再启动服务并观察容器状态
查看关键日志，确认数据库、应用、反代都没有报错
检查端口监听是否符合预期
访问健康检查地址或首页，确认外部请求正常

常用命令可以这样安排：

docker compose config
docker compose up -d
docker compose ps
docker compose logs --tail=100 -f
ss -lntp
curl -I http://127.0.0.1:8080/health

如果应用是通过宿主机 Nginx 对外提供服务，还要再确认域名解析、证书、反代配置和本机回环访问是否一致。对外页面能打开，不代表容器内部数据库连接稳定；最好再做一次登录、写入、查询和重启后的数据保留检查。

常见错误

把数据库端口直接映射到公网：方便调试，但风险很高。除非确实需要远程维护，并且有白名单和强认证，否则不建议这样做。
端口只看容器内端口，不看宿主机占用：容器里是 80，不代表宿主机能用 80。先查宿主机已有服务。
数据写在容器可写层里：容器删了，数据也没了。数据库和上传目录一定要挂载卷。
把密钥写进镜像或提交到仓库：后期很难清理，泄露风险也最高。
把 depends_on 当成服务就绪判断：它只管启动顺序，不管数据库是否已经接受连接。
用虚拟机快照替代备份：快照不是恢复策略，尤其是数据库和文件类数据，仍然需要独立备份与恢复验证。
所有容器都用 latest：上线后最难排查的就是“昨天还能用，今天行为变了”。

真正适合上线的 Compose 文件，通常不是最短的那个，而是最能说明“哪个端口给谁用、哪个数据放哪里、哪个密钥怎么管、出问题先看什么”的那个。韩国cn2服务器上的部署也是一样，先把端口映射和数据卷规划清楚，再写配置、再启动、再验证，后续扩容或迁移时才不会反复返工。后面如果要继续优化，优先顺序一般是：先补备份与告警，再收紧端口暴露范围，最后再考虑反向代理、分环境配置和滚动更新。

容器运维端口规划数据持久化部署验证韩国cn2服务器

上一篇 服务器日志时间戳偏移对故障定位准确性的影响 下一篇 外贸独立站使用WordPress部署，源站、CDN和备份应如何分工