云服务器容器化部署实战：从Docker到Compose的轻量进化指南

先说个我自己踩过的坑。前几年帮一个小团队做业务迁移，他们买了台云服务器，配置看着不低——8核16G那种，可就跑了一个 Java 应用和一个 MySQL，内存已经吃紧，CPU 大部分时间在空转。后来我把这套东西拆成容器部署，同样的规格，硬是多塞了好几个业务服务，顺带把日常发布的效率也提上来了。整个过程没有换机器，没有加预算，只是换了一种跑服务的思路。这件事让我对“容器化技术”和“云服务器”这对组合有了一个很直观的判断：云服务器解决的是你“有没有机器”的问题，容器化解决的是“机器怎么用才不浪费”的问题。今天这篇文章，就把我在云服务器上落地容器化的一些心得整理出来，包括怎么选方案、怎么做镜像、怎么处理网络和存储，以及踩过的那些坑，希望能给正准备用云服务器跑业务的朋友一些参考。

1. 容器化技术：为什么云服务器需要一次“轻量进化”

1.1 传统部署的“浪费”和容器化的“省”

早期的云服务器使用方式，大多是直接在上面装环境。Java 项目装 JDK，Python 项目装依赖，再装 Nginx、MySQL、Redis。单个服务这样搞没问题，但服务一多，各种依赖就开始互相打架：Python 2 和 Python 3 并存、不同项目需要同一个库的不同版本、升级一个包把另一个服务搞挂。为了不互相影响，大家又转向虚拟机，一台云服务器上再跑几个虚拟主机，每个里面装一套独立环境。

虚拟机确实把环境隔离得干干净净，但代价也很大。每台虚拟机都要包含一整个操作系统，内存和磁盘被操作系统本身吃掉了很大一部分；虚拟化层还要做指令翻译和资源调度，性能多少有些折损。更重要的是，虚拟机的规格是固定的。你给这台虚拟机分了 4G 内存，不管应用实际用不用，这 4G 就很难再被其他服务使用。结果是：机器配置年年升，利用率一直不高，账单却越来越大。

容器化技术在这儿做了一次“轻量进化”。容器不是独立模拟一个电脑，而是在共享宿主内核的基础上，用 Namespace 做资源隔离，用 Cgroups 做资源限制。你可以把同一个内核同时分配给几十个容器，每个容器看起来像一个独立的小系统，有自己的文件系统、网络、进程空间，但底层用的都是同一套内核。容器镜像也不再是几个 GB 的操作系统镜像，通常只有几百 MB，甚至几十 MB。因为少了操作系统这一层的开销，所以容器的主要成本就是“进程本身的成本”。启动时间从虚拟机的几十秒压缩到几秒甚至毫秒级，一台普通云服务器上跑几十个容器很常见。

打个比方：虚拟机是在一栋楼里给每个住户单独盖独栋别墅，地皮、砖瓦、水电都要重复建设；容器是在同一天然气管道和电路系统下分房间，每个房间自己打扫、自己装修，公共资源集中供给、按需分配。对于个人开发者和小团队来说，云服务器本来就是公共资源，用容器才更合适。

1.2 容器和虚拟机到底差在哪：一张对比表和背后的账单逻辑

拿一张表格把核心差异摆出来，比较直观。

这张表里最需要关注的是“内存开销”和“部署密度”。云服务器的计费模型是按 CPU、内存、带宽、磁盘规格来收钱的，你买下 8C16G，就意味着每个月要为这 16G 内存付钱。传统方式跑三个应用，可能就要开三台虚拟机，每台都要预留自己的系统内存；容器化以后，一台 8C16G 的云服务器可以同时跑十几个应用，只要总内存不超过 16G 即可。

我自己做过一个比较极端的例子：一台 2C4G 的云服务器，上面跑了一个 Nginx、一个 Node.js 应用、一个 MySQL、一个 Redis，还挂了一个定时任务容器。全部用 Docker Compose 管理，内存占用大约 3.2G，CPU 平时只有 20% 左右。如果换成三台虚拟机分别部署，性能和成本都不划算。容器化的出现，让“一台云服务器当好几台用”成了常态，这就是“轻量进化”最直接的含义。

2. 在云服务器上跑容器，方案到底怎么选

2.1 从 Docker 到 Docker Compose 再到 Kubernetes：你的规模决定一切

很多人一提到容器化，第一个想到的就是 Kubernetes，总觉得不用 K8s 就不算容器化。这是最大的误区。Kubernetes 是容器编排工具，它解决的问题是“多台机器上大量容器怎么自动调度、扩容、自愈”。如果你的业务只有一台云服务器或者两三台云服务器，硬上 K8s 等于杀鸡用牛刀，反而会引入新的管理复杂度。

我按服务器规模把方案分成三档。

第一档，单台云服务器，服务数量不多，主要用于个人项目、小工具、博客、测试环境。直接用 Docker Engine 就够了。用命令行跑 docker run 或者在启动脚本里维护几条命令，简单直接。缺点是没有统一管理入口，重启云服务器后要手动恢复所有容器，建议配合 restart 策略使用，例如 --restart unless-stopped。

第二档，一两台云服务器，跑的业务服务有三五个以上，需要考虑容器之间如何配合、如何共享网络、如何统一启停。这时候用 Docker Compose 最合适。Compose 用一个 YAML 文件描述所有服务，一条 docker compose up -d 就能把整套环境拉起来。它能管依赖启动顺序、网络别名、数据卷、资源限制，对中小规模部署来说已经绰绰余。

第三档，服务器数量达到三五台以上，或者业务有明显的伸缩需求，比如高峰期需要临时扩容、需要灰度发布、节点要自动迁移，这时候才值得上 Kubernetes。K8s 能给你自动化调度、声明式管理、滚动更新，但前提是你得有人理解它的工作原理。我见过不少团队在 2 台 2C4G 的小机器上搭 K8s，结果 etcd、网络插件、Ingress Controller 就耗掉大量资源，业务还没跑起来，维护成本先上来了。规模不够的时候，轻量方案能解决 80% 的问题，而那 20% 的弹性需求，留到业务真的涨起来以后再考虑，完全不晚。

2.2 镜像仓库、存储卷和网络模式：三个最容易翻车的选型点

选完编排工具，接下来要面对三个具体的技术点，这三个地方如果选型不谨慎，后面会反复踩坑。

第一个是镜像仓库。Docker 镜像是容器的基础，你可以直接使用 Docker Hub 上的公共镜像，也可以把自己构建的镜像推到仓库里。但公共仓库在国内访问速度往往很慢，而且匿名拉取有频率限制。我的建议是：在云服务器上配置 registry mirror 加速 Docker Hub 拉取；与此同时，自建的镜像尽量推送到云厂商的容器镜像服务，或者本地区域访问快的私有仓库。使用云厂商的镜像仓库还有一个好处：云服务器通过内网拉镜像，速度快且不受公网带宽限制。别小看这一点，镜像一大，公网带宽又低，拉一次可能比构建还慢。

第二个是存储卷。容器默认使用的是可写层，但容器一旦删除，可写层里的数据就跟着没了。凡是需要持久保存的数据，比如数据库文件、用户上传的附件、日志，都必须放到卷里。卷有两种常见用法：一种是 Named Volume，由 Docker 管理，数据存放在 /var/lib/docker/volumes 下，简单好用，推荐给数据库文件；另一种是 Bind Mount，直接把宿主机的某个目录挂载进容器，适合需要直接编辑配置文件的场景。这里要特别提醒：如果云服务器有独立数据盘，一定把数据卷目录放到数据盘上，不要都堆在系统盘。系统盘满了会导致 SSH 都连不上。

第三个是网络模式。单机 Docker 默认用 bridge 网络，容器通过端口映射对外提供服务，例如 -p 8080:80。这种方式最常用，隔离性好，但 NAT 转发会有一点性能损耗；如果应用对延迟特别敏感，或者需要绑定大量端口，可以使用 host 网络，让容器直接使用宿主机网络栈。host 模式性能好，代价是端口管理变得麻烦，容易冲突。多台服务器之间需要跨节点通信时，通常用 overlay 网络配合 K8s 或 Swarm。对个人和小团队来说，单机 bridge 网络加端口映射已经足够，不需要一开始就把网络栈设计得特别复杂。

3. 云服务器容器化部署：从购买配置到业务上线

3.1 服务器怎么选：CPU、内存、磁盘和“128G”到底指什么

很多新手在买云服务器时会看到这样的规格：“32核128G”。第一个问题就是，这里的 128G 指的是什么？答案很直接：128G 是指内存，而不是磁盘。云服务器规格里通常写的是核数和内存，“32核128G”表示 32 个 vCPU、128GB 内存。硬盘容量一般会单独标注为“系统盘 40G”“数据盘 100G”之类。搞清楚了再看容器化部署，就知道该关注什么了。

容器本身占用资源很低，真正吃资源的是容器里运行的应用和数据。如果你的业务是 Web 应用加数据库，内存通常比 CPU 更容易成为瓶颈。MySQL 这类数据库的缓存池会主动占用内存，内存不足极易导致容器被系统 OOM Kill。所以选购云服务器的时候，我一般建议先满足内存需求，再考虑核数。一个普通的业务组合，2 核 4G 起步；带 MySQL 和 Redis 的，4 核 8G 更稳；如果是 Java 应用，直接上 8G 内存，Java 对内存的胃口比较大。

磁盘选择也要注意。容器镜像、日志、数据卷都要占空间。如果系统盘只有 40G，堆几个镜像和日志很快就不够了。建议额外购买一块云盘作为数据盘，挂载到 /data 或者直接把 Docker 数据目录 /var/lib/docker 放到数据盘上。带宽方面，云服务器按带宽计费，镜像拉取和业务访问都要占用带宽。只是在控制台看看监控没问题，一旦从 Docker Hub 拉几个大镜像，就会直观感受到带宽的价值。

最后说一句关于成本的话。买云服务器之前，多看看各家的新用户优惠和免费试用额度，很多厂商会提供可用的免费云服务器试用期，适合学容器化或跑小项目。但别因为便宜就选极度低配的机器，容器化再轻量，也扛不住内存只有 512M 还强跑数据库。我的经验是，从规格够用、价格能承受的低配机型开始，真正不够了再升级，别一开始就追求满载配置。

3.2 系统初始化与 Docker 安装：一次说清

选择 Ubuntu 22.04 LTS 或者 Debian 12 作为宿主机系统，比较省心。拿到云服务器后，先更新系统并安装必要依赖：

bash复制sudo apt update
sudo apt install -y ca-certificates curl gnupg

接着添加 Docker 官方 GPG 密钥和软件源。虽然有些一键脚本很方便，但我更推荐用标准仓库方式安装，能更清楚装了什么，也方便后续升级。

bash复制sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

安装完成后，把当前用户加入 docker 组，避免每条命令都加 sudo：

bash复制sudo usermod -aG docker $USER

然后配置 Docker 镜像加速和日志限制。这一步强烈建议一开始就做，否则后面磁盘被日志填满再来改会很痛苦。编辑 /etc/docker/daemon.json：

json复制{
  "registry-mirrors": [
    "https://你的镜像加速地址"
  ],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  },
  "data-root": "/data/docker"
}

如果数据盘挂在 /data 下面，把 Docker 数据目录移到 /data/docker，这一步能避免系统盘被容器数据塞满。重启 Docker：

bash复制sudo systemctl daemon-reexec
sudo systemctl restart docker
sudo systemctl enable docker

验证安装结果：

bash复制docker version
docker compose version

这样基础环境就准备好了。

3.3 用 Compose 跑起一组服务：镜像、数据卷和资源限制怎么写

现在来看一个直接的例子。假设要在云服务器上跑一个 Web 应用，包含业务容器、Nginx 入口和 MySQL 数据库。在项目目录创建 docker-compose.yml：

yaml复制version: "3.8"

services:
  app:
    image: registry.example.com/myapp:1.2.3
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      - DB_HOST=mysql
      - DB_PORT=3306
      - DB_NAME=myapp
    depends_on:
      - mysql
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "0.50"

  nginx:
    image: nginx:1.25-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - ./cert:/etc/nginx/cert:ro
    depends_on:
      - app

  mysql:
    image: mysql:8.0
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: change_me
      MYSQL_DATABASE: myapp
    volumes:
      - mysql_data:/var/lib/mysql
    deploy:
      resources:
        limits:
          memory: 1G
          cpus: "0.75"

volumes:
  mysql_data:

这个文件覆盖了三个关键点。第一，通过 ports 把容器端口映射到宿主机，外部请求通过云服务器公网 IP 和对应端口访问。第二，MySQL 数据使用 Named Volume 持久化，容器删了数据还在。第三，通过 deploy.resources 限制内存和 CPU，防止某个容器异常占用全部资源后把整台云服务器拖垮。

启动服务：

bash复制docker compose up -d

查看状态：

bash复制docker compose ps

查看日志：

bash复制docker compose logs -f

需要升级时，改镜像版本或配置后执行：

bash复制docker compose pull
docker compose up -d

如果担心数据卷意外丢失，部署前先备份 /var/lib/docker/volumes，或者用云服务器的快照功能给数据盘打个快照。快照是最便宜的后悔药。

3.4 网络调优：TCP连接数、并发和端口映射

很多人在云服务器控制台看到“TCP 连接数”这个指标，以为它等于在线用户数，这是一个常见的误解。TCP 连接数统计的是服务器当前打开的所有 TCP socket，既包括用户连接，也包括数据库连接、调用外部 API 的连接、爬虫扫描等。在容器化部署后，你可能发现连接数增长得很快，这不一定代表业务在增长，可能是某个长连接没释放，或者被大量半连接打满。

先用命令看一眼当前状态：

bash复制ss -s
ss -lntp

ss -s 会显示 TCP 连接汇总，ss -lntp 可以看到正在监听和已经建立的连接。如果连接数接近系统上限，通常需要调整内核参数。常见的优化配置写在 /etc/sysctl.d/99-network.conf：

bash复制fs.file-max = 1000000
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.core.somaxconn = 4096

然后执行：

bash复制sudo sysctl -p /etc/sysctl.d/99-network.conf

ip_local_port_range 决定客户端端口范围，如果端口用完，主动发起的连接会报错；tcp_tw_reuse 可以复用 TIME_WAIT 状态的连接，显著降低短连接场景下的连接数峰值。调整内核参数前先在测试环境验证，不要直接在生产机器上大改，避免影响稳定性。

端口映射也很重要。容器启动后，你还需要到云服务器控制台的安全组或者防火墙里放行对应端口。端口只在系统层面开放了还不够，云服务器的外部访问是先在安全组做过滤的。常见做法是只放行 22、80、443，以及业务自己需要对外开放的端口，其他端口一律关闭。数据库的 3306 端口千万不要直接暴露到公网，否则就会被扫库。

4. 容器跑起来之后：存储、日志和监控别忽略

4.1 日志无限膨胀？镜像占满磁盘？三招解决存储问题

容器化部署的最大隐患之一，就是磁盘被日志和镜像悄悄占满。Docker 默认把容器日志记到 /var/lib/docker/containers/<容器ID>/ 下的 JSON 文件里，如果不限制大小，一个失控的容器可能一天写几个 GB 日志。日志一多，不是先影响应用，而是让云服务器系统盘爆掉，连 SSH 都连不上。

第一招，在 daemon.json 里限制日志轮转，就是前面配置过的 max-size 和 max-file。已经跑起来的容器不会自动应用新配置，需要重建容器才生效。想立刻清日志，可以这样做：

bash复制docker logs --tail 20 容器名
truncate -s 0 /var/lib/docker/containers/<容器ID>/*-json.log

注意修改后不要直接删除日志文件，应该用 truncate 清空，否则 Docker 还持有文件句柄，磁盘空间不释放，只有重启容器才会好。

第二招，定期清理无用镜像和构建缓存。构建镜像时会产生大量临时层，时间久了非常占空间。查看当前占用情况：

bash复制docker system df
docker system df -v

清理未使用的资源：

bash复制docker system prune
docker system prune -a

prune -a 会删除没有被容器使用的镜像，保险起见先看清楚要删什么。

第三招，用数据卷把业务数据放到独立磁盘。如果容器应用会写大量文件，比如上传附件、生成文件，尽量挂载到数据盘目录，别写到容器可写层。容器可写层本来就是为了临时运行数据准备的，不适合长时间积累。

4.2 docker stats 与简单的监控手段

出现问题时，第一步是看资源使用情况。docker stats 能实时看到每个容器的 CPU、内存、网络 I/O：

bash复制docker stats --no-stream

只看一次结果用 --no-stream，不会一直刷屏。如果多台云服务器，可以用更完整的监控方案，比如在宿主机上装 node_exporter，配合 Prometheus 和 Grafana 采集指标。但我不建议小团队一开始就上这么重的方案。最轻量的做法是每天晚上定时跑 docker ps，配合云服务器的监控图表观察数据。

还有一点经验：容器重启时，先用 docker inspect 看重启原因。比如容器反复重启，执行：

bash复制docker ps -a
docker inspect 容器名 -f '{{.State.OOMKilled}}'

如果输出是 true，说明容器是被系统 OOM Killer 杀掉的，问题大概率出在内存跟不上，不是代码本身。把 docker-compose.yml 里的内存限制调大，或者优化应用内存占用，才能根治。

5. 容器化常见问题与排查实例

5.1 容器反复重启、端口冲突、OOM，逐个击破

我把实际运维中频率最高的问题整理成了下面这个表格，适合场景对号入座。

这几个场景里，最常见也最容易忽略的是容器反复重启。很多人第一反应是改代码重新部署，但有时候问题很简单：比如应用要连接数据库，但 depends_on 只保证了 mysql 容器先启动，并没有保证 MySQL 真正就绪。应用连不上数据库就崩溃退出，然后重启循环。解决办法是在应用侧加等待重试，或者用健康检查配合 Compose 的 depends_on.condition。把基础问题排查完，再考虑改代码。

5.2 低成本云服务器上车的个人建议

聊完技术，说点选云服务器的经验。如果你只是想学容器化、跑一个个人博客或者小工具，完全可以用新用户优惠或云厂商的试用资源。免费云服务器适合验证流程，但别把重要业务放在试用机上，试用机往往没有完整售后和备份保障，到期可能直接销毁。上线业务之前，建议先给关键数据盘做个快照。

预算有限的时候，选择配置也要有策略。我一贯的观点是：内存优先于 CPU，磁盘 I/O 优先于容量。容器化部署老是 OOM，多半是内存不够；数据库卡顿，多半是磁盘 I/O 太差。至于那种价格异常低的云服务器，要格外小心“便宜”背后的隐性限制——CPU 可能被限频，带宽可能按流量计费，跑业务一热闹，最后账单反而更高。

如果连云服务器的维护都不想做，也可以考虑托管容器平台。很多 PaaS 平台，比如 Railway、Fly.io 这类，底层就是容器技术，你只需要把代码推上去，平台负责构建、运行和扩容。它们特别适合个人项目或原型阶段，不需要自己管系统和 Docker。不过 PaaS 对数据和配置的定制能力有限，业务发展到一定阶段，最终还是会回到自己购买的云服务器上。

6. 结尾的一些个人体会

我自己的体会是，容器化真正带来的价值不只是省机器，也不是让你追新工具。它的核心是把“环境”变成和代码一样可以打包、可以版本化的对象。以前部署最怕“在我电脑上明明是好的，到了服务器就出问题”；容器化以后，镜像在本地什么表现，云端基本就是什么表现，这种确定性对工程效率的提升非常明显。

最后再分享一个习惯：我每次给云服务器做容器化部署，都会先把 daemon.json 的日志限制、数据卷挂载、资源限制“老三样”配好，再用 Compose 管理服务运行。前期多花十几分钟，后面能省掉很多半夜被监控告警吵醒的时间。容器化本质上是把复杂的问题拆成简单的单元，按照这个思路做，云服务器上的服务才会真正“轻”下来。