云服务器安装 Docker 教程：从环境准备到容器运行全流程

摘要

Docker 是绝大多数自托管服务的运行底座，网盘、博客、AI 应用、监控系统的部署文档几乎都以「已安装 Docker」为前提。本文在一台全新的云服务器上完成 Docker Engine 与 Docker Compose 的安装，包含系统准备、安装源选择、权限配置、镜像加速、容器验证与常见故障处理，最后给出资源占用与磁盘清理的长期维护建议。读完本文，你会得到一台可以直接执行 docker compose up -d 的服务器。

一、适用场景与前置条件

Docker 把应用及其依赖打包在一起运行，解决的核心问题是「在我机器上能跑，在服务器上跑不起来」。对个人和中小团队来说，它带来三个实际收益：部署步骤从十几条命令收敛为一个配置文件；不同服务的依赖互不干扰；卸载时删除容器即可，不会在系统里留下残余。

本文适用于以下情况：

• 准备部署 Nextcloud、Immich、Dify、Gitea 等以容器方式分发的开源服务。
• 需要在同一台机器上跑多个技术栈不同的应用，不希望它们互相污染环境。
• 想要一套可重复、可迁移的部署方式，换机器时能快速还原。

开始前需要准备：

内存是这里最容易被低估的一项。Docker 本身占用不高，但单台机器上跑三四个容器化服务时，2 GB 内存很快就会触发 OOM。如果计划部署带数据库的服务，建议直接从 4 GB 起步。

轻量应用服务器在创建实例时默认已放通 22 端口，可以直接通过 SSH 登录；使用云服务器 CVM 时需要确认所在安全组已放通 22 端口。登录方式可参考控制台提供的登录入口，或使用本地 SSH 客户端连接。

二、系统环境准备

登录服务器后，先更新软件包索引并安装后续步骤需要的基础工具。

Ubuntu 与 Debian：

sudo apt update && sudo apt upgrade -y
sudo apt install -y ca-certificates curl gnupg lsb-release

确认系统版本和架构，后面添加软件源时需要用到：

cat /etc/os-release | grep -E "^(ID|VERSION_CODENAME)="
uname -m

uname -m 返回 x86_64 表示 amd64 架构，返回 aarch64 表示 ARM 架构。两者的安装源不同，如果搞错会在安装阶段报「找不到软件包」。

如果系统里存在早期版本或发行版自带的 Docker 包，先卸载干净，避免与官方版本冲突：

sudo apt remove -y docker docker-engine docker.io containerd runc 2>/dev/null

这一步只移除程序，不会删除 /var/lib/docker 下的镜像和容器数据。如果这是一台全新机器，命令会提示没有可移除的包，属于正常情况。

三、安装 Docker Engine

发行版仓库里的 docker.io 包版本通常偏旧，而且往往不包含 Compose 插件。推荐使用官方软件源安装，能同时拿到 Engine、CLI 和 Compose 插件。

添加官方 GPG 密钥与软件源：

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

Debian 系统把上面两处 linux/ubuntu 替换为 linux/debian 即可，其余保持不变。

安装 Engine 与相关组件：

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

如果服务器访问境外源速度不理想，可以改用国内镜像站提供的 Docker 仓库地址，把上面软件源中的域名替换为对应镜像站地址，安装流程完全一致。

对于 OpenCloudOS、TencentOS 等 RPM 系发行版，使用 yum 或 dnf 安装：

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo yum install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

安装完成后启动服务并设置开机自启：

sudo systemctl enable --now docker
sudo systemctl status docker --no-pager

状态输出中出现 active (running) 表示服务已正常启动。

四、配置运行权限与镜像加速

默认情况下 Docker 守护进程通过 Unix socket 通信，只有 root 用户可以直接访问，普通用户执行命令会提示 permission denied。把当前用户加入 docker 组：

sudo usermod -aG docker $USER

这条命令需要重新登录才会生效。想在当前会话立即生效，可以执行 newgrp docker。

需要说明的是，docker 组权限等价于 root 权限，因为容器可以挂载宿主机任意目录。生产环境请只把确实需要管理容器的账号加入该组，不要为了省事给所有用户开放。

国内服务器拉取默认镜像仓库经常超时，配置镜像加速可以显著改善。编辑守护进程配置文件：

sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json > /dev/null <<'JSON'
{
  "registry-mirrors": ["https://mirror.ccs.tencentyun.com"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "20m",
    "max-file": "3"
  }
}
JSON
sudo systemctl restart docker

这里除了镜像加速，还顺手限制了容器日志大小。默认配置下容器日志没有上限，一个话痨型服务跑几个月就能把系统盘写满，这是自建服务最常见的磁盘告急原因之一。max-size 与 max-file 组合表示每个容器最多保留 3 个 20 MB 的日志文件。

确认配置已加载：

docker info | grep -A 2 "Registry Mirrors"

五、验证安装是否成功

安装类教程最容易被忽略的一步是验证。仅看到「安装完成」不代表环境可用，下面三个检查逐层确认。

第一层，确认版本信息可正常输出：

docker --version
docker compose version

注意 Compose 插件的命令是 docker compose，中间是空格。老文档里的 docker-compose（带连字符）属于独立安装的旧版本，两者不通用。如果 docker compose version 报错，说明 docker-compose-plugin 没装上。

第二层，运行官方测试镜像，验证拉取镜像和启动容器的完整链路：

docker run --rm hello-world

输出中出现 This message shows that your installation appears to be working correctly. 表示 Engine 与镜像仓库都正常。--rm 参数让容器退出后自动删除，不留垃圾。

第三层，用一个真实服务验证端口映射是否通畅：

docker run -d --name nginx-test -p 8080:80 nginx:alpine
curl -I http://127.0.0.1:8080

返回 HTTP/1.1 200 OK 说明容器网络和端口映射工作正常。

如果想从外网浏览器访问这个测试页，需要在控制台放通 8080 端口。轻量应用服务器在实例详情页的「防火墙」页签中「添加规则」，协议选 TCP、端口填 8080、策略选允许；云服务器 CVM 在安全组的「入站规则」中添加对应规则。验证完记得清理：

docker rm -f nginx-test

这里有个容易踩的坑：容器端口没在控制台放通时，服务器本机 curl 是通的，外网却打不开。遇到「本地能访问、外网不能访问」，先查控制台的防火墙或安全组规则，再查系统内的 iptables 或 ufw。

六、Compose 编排入门

单个 docker run 命令参数一多就难以维护，Compose 把这些参数写进 YAML 文件，用一条命令管理整组服务。

建立项目目录并写一个包含两个服务的示例：

mkdir -p ~/apps/demo && cd ~/apps/demo

services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"
    volumes:
      - ./html:/usr/share/nginx/html:ro
    restart: unless-stopped
    depends_on:
      - redis

  redis:
    image: redis:7-alpine
    command: redis-server --appendonly yes
    volumes:
      - redis-data:/data
    restart: unless-stopped

volumes:
  redis-data:

把上面内容保存为 compose.yaml，然后准备一个测试页面并启动：

mkdir -p html && echo "<h1>compose works</h1>" > html/index.html
docker compose up -d
docker compose ps

几个关键字段值得单独理解：

• volumes 决定数据放在哪里。./html:/usr/share/nginx/html 这种写法把宿主机目录挂进容器，适合配置文件和需要直接编辑的内容；redis-data:/data 使用命名卷，由 Docker 管理，适合数据库文件。凡是重建容器后不能丢的数据，必须落在挂载路径上，否则容器一删就没了。
• restart: unless-stopped 让容器在服务器重启后自动拉起，同时保留手动停止的意图。自建服务基本都应该配上，否则机器重启后服务不会自己回来。
• depends_on 只控制启动顺序，不等待被依赖服务真正就绪。应用启动时仍需自己做连接重试。

常用运维命令：

docker compose logs -f web      # 跟踪指定服务日志
docker compose restart web      # 重启单个服务
docker compose pull             # 拉取新版本镜像
docker compose up -d            # 应用变更并重建有更新的容器
docker compose down             # 停止并移除容器，命名卷会保留
docker compose down -v          # 连命名卷一起删除，数据会丢失

docker compose down -v 是个危险命令，-v 会删掉命名卷里的数据库文件。清理环境前先确认卷里没有需要保留的内容。

七、常见问题与排查

拉取镜像超时或反复重试

先确认镜像加速配置已生效，再用 docker info 检查 Registry Mirrors 是否包含预期地址。如果仍然缓慢，可能是目标镜像不在加速节点覆盖范围内，可尝试更换镜像标签或从其他仓库拉取。

容器启动后立刻退出

用 docker logs 容器名 查看退出前的输出，多数情况是配置文件路径写错、必填环境变量缺失或挂载目录权限不对。docker compose ps 中状态显示 Exited (1) 通常是应用自身报错，Exited (137) 则是被系统 OOM Killer 终止，说明内存不够。

端口已被占用

启动时报 port is already allocated，用以下命令找出占用进程：

sudo ss -lntp | grep :8080

要么换一个宿主机端口，要么停掉占用端口的服务。多个服务都想用 80 和 443 时，正确做法是前面加一层反向代理统一接管，而不是让它们互相抢端口。

挂载目录内文件权限异常

容器内进程使用的 UID 可能与宿主机用户不同，导致写入失败。可在 Compose 中通过 user 字段指定运行身份，或调整宿主机目录归属，使容器内进程对挂载目录有写权限。

磁盘空间被镜像和日志吃掉

先看占用分布：

docker system df

清理未被使用的镜像、停止的容器和构建缓存：

docker system prune -a

这条命令会删除所有未被运行中容器引用的镜像，执行前确认没有仅存在于本地、无法重新拉取的镜像。命名卷不会被 prune 删除，需要单独用 docker volume prune 处理，操作前务必确认卷内数据已不再需要。

八、长期维护建议

规划数据目录：把所有容器的持久化数据集中在一个父目录下，例如 /data，备份时只需处理这一个路径。数据量增长后，可以为该目录单独挂载云硬盘，扩容时不必迁移整台服务器。

在变更前创建快照：升级镜像版本、调整系统配置这类操作，建议先给实例创建一份快照。轻量应用服务器在实例详情页的「快照」页签点击「创建快照」即可，通常 5 分钟内完成，创建过程无需关机。需要注意，回滚快照会将整块系统盘恢复到快照时间点，之后写入的数据都会被清除，且运行中的实例在回滚时会自动关机，所以回滚前建议再打一份当前状态的快照。另外，使用存储型套餐的实例不支持创建快照，规划时需要留意。

固定镜像版本：生产环境不要使用 latest 标签。明确写成 postgres:16 或更精确的版本号，把升级动作变成一次主动决策，而不是某次 docker compose pull 之后的意外。

定期检查资源占用：用 docker stats 观察各容器的 CPU 与内存实时占用。如果某个容器长期贴着内存上限运行，说明该升配置了。云服务器 CVM 的实例规格支持按需调整，业务增长后可以在控制台变更配置，不必重建实例。

为容器设置资源上限：在 Compose 中通过 deploy.resources.limits 限制单个容器可用的内存，避免一个服务异常时把整台机器拖垮，导致其他服务一起不可用。

装好 Docker 之后，下一步通常是配置反向代理，把多个容器服务通过域名对外提供访问并启用 HTTPS，这样它们就不必各自占用不同端口。

如果你正准备一台机器来跑这些容器化服务，可以了解一下轻量应用服务器，套餐式规格与可视化控制台对个人和小团队的自建场景比较省心；需要更灵活的规格调整与网络控制时，云服务器 CVM 是更合适的选择。