云服务器到手第一件事装 Docker这个动作本身没什么技术门槛但我在不同配置、不同系统版本的机器上重复过几十次之后发现真正拉开差距的不是安装命令敲得多快而是装完之后环境是否干净、存储路径是否合理、后续拉镜像会不会因为源配置不当而卡住。这篇内容面向的是刚拿到一台云服务器、准备用它跑容器化服务的朋友也适合已经装过 Docker 但总感觉环境不太对劲、想重新梳理一遍的人。我会把安装前该确认什么、安装方式怎么选、装完必须做的几项配置、以及那些文档里不会写的坑按实际操作顺序讲清楚。1. 动手之前先确认机器的底子很多人拿到服务器直接复制一条安装命令就执行结果中途报错才发现系统版本不对或者磁盘空间不够。安装 Docker 本身不复杂但前置条件没确认清楚后面排查起来会浪费大量时间。这一步花五分钟能省掉后面半小时的折腾。1.1 系统版本与内核的匹配关系Docker 对内核有明确要求尤其是用 overlay2 作为存储驱动时内核版本太低会直接导致镜像层无法正常挂载。我一般先跑两条命令确认底子uname -r cat /etc/os-release第一条看内核版本第二条看发行版信息。经验上内核 3.10 是很多老系统的分水岭低于这个版本基本可以放弃折腾直接考虑换系统镜像。主流发行版的较新版本比如各类系统的当前稳定版内核都在 4.x 以上跑 Docker 没有问题。这里有个容易被忽略的点同样是某个发行版云厂商提供的镜像可能做过裁剪内核模块不一定齐全。我遇到过一台机器uname -r显示内核版本够新但 overlay2 驱动加载失败最后查出来是镜像里精简掉了相关模块。所以确认完版本最好再顺手看一眼存储驱动支持情况lsmod | grep overlay有输出说明 overlay 模块已加载没有输出也不一定代表不支持可能是没加载可以尝试modprobe overlay手动加载。如果加载报错那这台机器的镜像就有问题换镜像比修模块省事得多。1.2 磁盘空间与分区规划Docker 默认把数据放在/var/lib/docker这个路径在系统盘上。云服务器常见的配置是系统盘较小、数据盘较大如果不在安装前规划好跑一段时间镜像和容器日志把系统盘撑满机器会直接卡死甚至无法登录。先看磁盘布局df -h lsblkdf -h看各分区使用率和挂载点lsblk看块设备结构。如果发现有一块数据盘没挂载或者挂载在别的路径建议在装 Docker 之前就把它挂到/var/lib/docker或者单独规划一个目录装完之后再迁移数据目录虽然可行但多一步操作就多一分出错概率。我个人的习惯是系统盘只放系统和 Docker 程序本身所有镜像、容器、卷的数据全部指向数据盘。这样即使哪天需要重装系统数据盘上的容器数据还在恢复起来方便很多。具体做法在后面的存储配置章节会展开。提示如果数据盘是全新的需要先分区、格式化、挂载再写入/etc/fstab保证重启后自动挂载。这一步没做就装 Docker重启后数据目录可能变回系统盘路径容器全部消失。1.3 网络与软件源的可达性云服务器装 Docker 最常见的卡点不是命令本身而是软件源访问慢或者不通。不同云厂商、不同地域的机器访问官方源的速度差异很大。安装前先测一下curl -I https://download.docker.com看返回的 HTTP 状态码和耗时。如果长时间无响应或者超时说明直连官方源不理想需要配置镜像加速或者换用系统自带的软件源里打包好的版本。这里要区分两种安装来源一种是系统发行版仓库里自带的 Docker 包版本可能偏旧但安装简单另一种是 Docker 官方仓库提供的包版本新、更新及时但需要额外配置仓库地址。两种方式各有适用场景下一章详细对比。2. 安装方式的选择逻辑与实操安装 Docker 有三条常见路径系统包管理器直接装、配置官方仓库后装、用官方提供的一键脚本装。三条路都能把 Docker 跑起来但装出来的结果、后续升级的便利性、以及出问题时的可排查性差别不小。我按推荐程度从高到低说。2.1 配置官方仓库安装可控性最好的方式这是我最常用的方式优点是版本可控、升级路径清晰、卸载干净。以常见的 Debian 系系统为例完整流程如下。先安装基础依赖apt-get update apt-get install -y ca-certificates curl gnupgca-certificates保证 HTTPS 证书校验正常curl用来下载gnupg用来处理仓库签名密钥。这三个包缺一个都可能导致后续步骤失败。接着添加官方仓库的签名密钥install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc chmod ar /etc/apt/keyrings/docker.asc这里把密钥放在/etc/apt/keyrings目录下是较新版本包管理器的推荐做法比老式的apt-key add更规范也避免了密钥全局生效带来的安全隐患。然后写入仓库地址echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian $(. /etc/os-release echo $VERSION_CODENAME) stable /etc/apt/sources.list.d/docker.list这条命令里有两个动态取值dpkg --print-architecture取当前系统架构$VERSION_CODENAME取系统代号。用动态取值而不是写死是为了让命令在不同机器上都能直接用减少手误。更新索引并安装apt-get update apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin这里装的是一组包而不是单个docker-ce。docker-ce-cli是命令行客户端containerd.io是底层容器运行时docker-buildx-plugin提供多平台构建能力docker-compose-plugin提供docker compose子命令。一次性装齐后面用的时候不会缺东少西。RPM 系系统的流程类似只是包管理器换成dnf或yum仓库配置文件放在/etc/yum.repos.d/下。核心逻辑一致加密钥、加仓库、装一组包。2.2 一键脚本快但要知道它做了什么官方提供了一键安装脚本一条命令搞定curl -fsSL https://get.docker.com | sh这个脚本的好处是自动识别系统类型和架构自动选择合适的仓库和包。适合快速验证、临时环境。但它的问题在于黑盒感较强脚本内部做了哪些检查、装了哪些包、改了哪些配置不细看是不知道的。我的建议是生产环境或者需要长期维护的机器用 2.1 的方式手动装每一步都清楚临时测试机、用完就销毁的环境用一键脚本省时间。如果用了脚本装完至少跑一下docker version和docker info确认客户端和服务端版本、存储驱动、cgroup 驱动这些关键信息符合预期。2.3 系统自带仓库版本旧但省事很多发行版的官方仓库里就有 Docker 包直接apt-get install docker.io或者dnf install docker就能装。这种方式最大的优点是无需额外配置仓库网络条件差的机器也能装上。缺点是版本通常落后官方好几个小版本一些新特性用不上某些镜像对 Docker 版本有最低要求时可能不满足。判断标准很简单如果你只是跑几个常规容器对版本没特殊要求系统仓库的版本够用如果你要用到较新的构建特性、或者某些镜像明确要求较高版本那就走官方仓库。安装方式版本新鲜度操作复杂度升级便利性适用场景官方仓库手动装高中好生产环境、长期维护一键脚本高低一般临时环境、快速验证系统自带仓库低低依赖系统网络受限、无版本要求2.4 装完立即验证的三项信息不管用哪种方式装装完别急着跑容器先确认三件事。第一服务是否正常启动systemctl status docker看状态是否为 active (running)。如果失败用journalctl -u docker --no-pager看日志常见原因是存储驱动不兼容或者 cgroup 配置问题。第二客户端与服务端是否都正常docker version输出里分 Client 和 Server 两段两段都有版本信息才算真正跑通。只有 Client 没有 Server说明守护进程没起来。第三整体环境信息docker info重点看几项Storage Driver是不是 overlay2Cgroup Driver是不是 systemdDocker Root Dir是不是你期望的路径。这三项在后面的章节还会展开因为它们是环境是否健康的关键指标。3. 装完必须调整的几项配置Docker 装好能跑和 Docker 配好能用是两回事。默认配置面向的是通用场景放到云服务器的实际使用中有几个地方几乎一定要改。这一章讲的都是装完之后立刻就该做的事拖得越久后面改起来成本越高。3.1 数据目录迁移到数据盘前面提过默认数据目录在系统盘。如果系统盘不大这一步必须做。迁移的核心思路是停服务、搬数据、改配置、启服务、验证。先停掉 Docker 服务systemctl stop docker systemctl stop docker.socket新版 Docker 有 socket 激活机制只停docker可能不够把docker.socket一起停掉更稳妥。然后创建新目录并迁移数据。假设数据盘挂载在/datamkdir -p /data/docker rsync -avz /var/lib/docker/ /data/docker/用rsync而不是cp是因为它能保留权限、属主、时间戳等元信息Docker 的数据目录对这些比较敏感。迁移完成后确认数据完整再考虑删除原目录。接着修改配置。创建或编辑/etc/docker/daemon.json{ data-root: /data/docker }这个文件是 Docker 守护进程的配置文件JSON 格式改完需要重启服务生效。注意如果文件已存在不要直接覆盖要把新键合并进去。重启并验证systemctl start docker docker info | grep Docker Root Dir输出显示新路径就说明迁移成功。这时候再删原目录rm -rf /var/lib/docker注意删除原目录前务必确认新目录数据可用可以先跑一个测试容器验证读写正常再删旧数据。这一步顺序反了数据就找不回来了。3.2 镜像加速配置的实际写法拉镜像慢是云服务器上最普遍的体验问题。配置镜像加速的思路是让 Docker 从离你更近的镜像站点拉取而不是每次都回源。配置同样写在daemon.json里{ data-root: /data/docker, registry-mirrors: [ https://你的加速地址1, https://你的加速地址2 ] }这里要说明一点加速地址的可用性会随时间变化不同云厂商、不同地域能用的地址不一样。配置的时候多填几个Docker 会按顺序尝试前一个不通自动换下一个。填完之后重启服务用docker info看Registry Mirrors一栏是否生效。验证加速是否真的起作用可以拉一个稍大的镜像看耗时time docker pull nginx:alpine第一次拉取会走加速第二次因为本地已有缓存会很快所以测速要用一个本地没有的镜像标签。如果耗时明显比不配加速时短说明配置生效。3.3 日志驱动与日志轮转Docker 默认的日志驱动会把容器标准输出写到宿主机的 JSON 文件里而且默认不限制大小。一个话多的容器跑几天日志文件能涨到几个 G把磁盘吃满。这个问题在云服务器上尤其常见因为很多人装完 Docker 就不管了直到磁盘告警才回头查。在daemon.json里加上日志配置{ data-root: /data/docker, registry-mirrors: [https://你的加速地址], log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 } }这段配置的意思是单个日志文件最大 50MB最多保留 3 个轮转文件也就是一个容器最多占 150MB 日志空间。对于大多数服务这个量够用需要更详细日志的场景可以适当调大。要强调的是这个配置只对配置生效之后新建的容器起作用已经在跑的容器不受影响。所以日志配置最好在装完 Docker、还没跑业务容器的时候就加上避免后面还要重建容器。3.4 用户组与免 sudo 操作默认情况下只有 root 和 docker 组的用户能操作 Docker。日常用 root 登录操作不是好习惯给普通用户加权限更合理usermod -aG docker 你的用户名加完之后需要重新登录才生效因为用户组信息在登录时加载。验证方式是退出重新登录后跑docker ps不报权限错误就说明生效了。这里有个安全提醒docker 组的权限实际上等同于 root因为能操作 Docker 就能挂载宿主机目录、启动特权容器。所以只给可信用户加这个组不要图省事给所有用户都加上。4. 那些文档里不会写的坑前面讲的都是正确做法这一章讲的是我在实际操作中踩过的、或者见别人踩过的坑。这些内容在官方文档里基本找不到但实际遇到的时候往往卡很久。4.1 存储驱动不匹配导致的启动失败有一类报错很典型Docker 服务起不来日志里出现overlay2相关的错误提示不支持或者挂载失败。原因通常是文件系统类型不支持 overlay2。overlay2 要求底层文件系统是 ext4 或 xfs而且 xfs 必须带ftype1参数格式化。查文件系统类型df -T /var/lib/docker如果显示的是 xfs再确认 ftypexfs_info /挂载点 | grep ftype输出ftype1才支持 overlay2ftype0就不行。这种情况要么重新格式化数据盘带-n ftype1参数要么退而求其次改用其他存储驱动。重新格式化是根治办法但会清空数据操作前务必确认盘上没有重要内容。我见过有人为了省事直接在daemon.json里把存储驱动改成vfs服务确实起来了但 vfs 的性能很差每个镜像层都是完整拷贝磁盘占用和 IO 都会成倍增加。这只适合临时救急不适合长期使用。4.2 磁盘 inode 耗尽的隐蔽问题磁盘空间还有剩余但就是写不进文件报 No space left on device。这种情况大概率是 inode 用完了。Docker 的镜像分层机制会产生大量小文件inode 消耗比普通应用快得多。查 inode 使用情况df -i看IUse%这一列如果接近 100%就是 inode 耗尽。解决办法有两个方向清理无用镜像和容器释放 inode或者换一个 inode 数量更多的文件系统重新挂载数据盘。前者治标后者治本。日常预防的办法是定期清理docker system prune -a这条命令会删除所有停止的容器、未使用的镜像、未使用的网络和构建缓存。执行前确认没有需要保留的停止状态容器。我一般把它做成定期任务每周跑一次避免积累。4.3 容器时间与宿主机不一致容器里跑的服务记录的时间比宿主机慢几个小时或者快几个小时排查半天发现是时区问题。Docker 容器默认继承宿主机的时区设置但如果宿主机本身时区没设对容器里自然也不对。先确认宿主机时区timedatectl看Time zone这一项。如果不对设置成实际所在时区timedatectl set-timezone Asia/Shanghai宿主机设对之后新建的容器会自动继承。已经在跑的容器需要重建才能生效或者在启动时通过挂载/etc/localtime和/etc/timezone的方式显式指定。后者更稳妥不依赖宿主机配置docker run -v /etc/localtime:/etc/localtime:ro -v /etc/timezone:/etc/timezone:ro 你的镜像4.4 防火墙与端口映射的配合容器跑起来了端口也映射了但从外部访问不通。这种情况先分两层排查容器内部服务是否正常监听宿主机防火墙是否放行。先在宿主机上测容器映射的端口curl -I http://127.0.0.1:映射的端口本地通、外部不通基本就是防火墙问题。云服务器通常有两层防火墙系统内的防火墙服务和云厂商的安全组。两层都要放行对应端口缺一层都不行。系统内防火墙以常见的防火墙管理工具为例放行端口firewall-cmd --add-port映射的端口/tcp --permanent firewall-cmd --reload云厂商的安全组需要在控制台配置这个没法用命令解决得登录控制台操作。我踩过的坑是只改了系统防火墙忘了安全组折腾半天以为是 Docker 配置问题。4.5 重启后容器不自动启动服务器重启之后之前跑的容器全没了手动一个个启动很麻烦。Docker 提供了重启策略在启动容器时指定docker run --restartunless-stopped 你的镜像unless-stopped的含义是除非容器被手动停止否则总是自动重启包括宿主机重启之后。这个策略比always更符合日常使用习惯因为手动停掉的容器不会在重启后被意外拉起来。对于已经运行的容器可以用 update 命令补上策略docker update --restartunless-stopped 容器名这个操作不需要重建容器直接生效。建议所有需要长期运行的服务容器都加上这个策略省得每次重启机器都要手动拉起。5. 环境健康度的日常检查习惯装好、配好之后日常还需要一些轻量的检查习惯让环境始终处于可控状态。这些检查不需要多复杂几条命令的事但能提前发现大部分潜在问题。5.1 定期看磁盘和 inode前面提过 inode 的问题日常检查就一条命令df -h df -i两个输出一起看空间和 inode 都在安全线以内才放心。我习惯在每次部署新服务之前跑一遍确认资源够用再动手。5.2 清理策略的取舍docker system prune系列命令很好用但用之前要清楚它会删什么。不带参数只删停止的容器、悬空镜像、未使用的网络带-a会删所有未被容器引用的镜像带--volumes会删未使用的数据卷。数据卷这一项要特别小心很多有状态服务的数据就放在卷里误删就没了。我的做法是清理时永远不带--volumes卷的清理单独手动处理确认无用再删。5.3 版本升级的时机把握Docker 版本不是越新越好升级之前要看变更日志里有没有影响当前使用的破坏性改动。我的习惯是小版本升级比如补丁版本可以跟大版本升级先在一台非关键机器上验证确认现有容器和镜像都正常再推广。升级命令和安装命令类似包管理器直接升级即可apt-get update apt-get install -y docker-ce docker-ce-cli containerd.io升级完成后同样跑docker version和docker info确认状态再抽查几个关键容器是否正常。5.4 配置文件的备份/etc/docker/daemon.json这个文件不大但包含了数据目录、加速地址、日志策略等关键配置。重装系统或者误操作丢失之后重建环境时没有它就得凭记忆重写。我习惯把它纳入日常备份范围改一次备份一次成本极低省心很多。我在实际使用中的体会是云服务器上装 Docker 这件事命令本身十分钟就能搞定真正花时间的是装完之后的环境调优和踩坑排查。把数据目录、镜像加速、日志轮转这三项在装完的第一时间配好后面能避开八成的常见问题。剩下的就是养成定期看磁盘和 inode 的习惯以及清理时对数据卷保持敬畏。这套流程我在不同配置的机器上重复过很多次每次新机器到手按这个顺序走一遍基本不会出岔子。