聊到容器生态很多人第一反应就是 Docker但实际工作中我发现一个很有意思的现象大家讨论的焦点全在怎么写 Dockerfile、怎么做编排、怎么上 K8s反而把最基础的安装部署这一步当成装完就行的琐事。可恰恰是这一步决定了后面所有环节是否顺畅。这篇博文我打算把 Docker 安装部署这条线从头到尾捋一遍从版本选型、系统准备到各平台的安装实操、装完之后的配置验证再到第一个容器真正跑起来最后汇总我这些年踩过的坑和排查思路。内容主要围绕 Docker 容器生态里的安装部署环节展开适合刚接触容器、准备在服务器或本机装 Docker 的开发者也适合已经用过一阵 Docker 但一直没认真整理过安装细节的同学。这里说的方案都是我实际验证过的照着做基本不会翻车。1. 安装部署在容器生态里到底是什么位置1.1 先理解 Docker 不是装个软件那么简单我经常跟团队里的新人说一句话Docker 装得好不好不是看你执行了多少条命令而是看你装完之后这个环境稳不稳、能不能维护。很多人以为 Docker 就是一个把应用打包成镜像的运行时装个二进制包、启个服务就完事了。但如果你把它放在整个容器生态里看安装部署其实是地基。为什么这么说容器生态里向上有镜像仓库、编排调度、服务发现向下依赖的是容器运行时把内核特性用好。Docker 安装部署这件事本质上是在你的操作系统上构建出一层容器运行时的能力层。这层能力包括 cgroups 的资源隔离、namespace 的进程隔离、网络栈的虚拟化、存储驱动的镜像分层管理。安装 Docker 不是往系统里拷几个文件而是把这套能力以正确的方式接到你的操作系统上。我见过太多因为安装阶段偷懒后面排查半天的问题。比如某次线上环境容器网络一直间歇性丢包最后发现是当初装 Docker 时用了某个旧版存储驱动和后面的内核版本产生了兼容性问题。还有一次某人直接在系统上用脚本装了个 Docker结果系统里有两套 Docker 在抢 /var/run/docker.sock 的权限服务起来了但所有容器操作都报错。这些问题的根源全是安装部署阶段没有认真对待。所以这篇博文的第一个观点就摆在这里安装部署不是下一步下一步的无脑流程它需要你理解几个关键决策点并且知道每一步在做什么。1.2 安装部署要解决的核心问题如果在安装 Docker 之前把自己带入我要在这台机器上长期跑容器的角色你会发现需要解决的问题其实可以拆成几个层次。第一层是系统兼容性。Docker 依赖 Linux 内核的特定能力你的内核版本太旧、缺少某个模块、或者系统是某个不常见发行版都会导致装不上或者装上跑不稳。这一层靠的是选对安装源、选对版本、验证内核。第二层是运行时配置。装完 Docker 之后默认配置只是能跑不等于跑得好。存储驱动用什么、cgroup 驱动和 init 系统是否匹配、iptables 和 firewalld 怎么共存、日志驱动怎么配这些都属于部署配置的范畴直接影响容器的稳定性。第三层是使用体验和运维入口。普通用户能不能直接敲 docker 命令、daemon 要不要开机自启、需不需要配合 registry 加速、数据目录放哪个分区这些看似小的问题在长期使用中都会被放大。下面的内容我会按照装之前 → 怎么装 → 装完怎么办 → 怎么用 → 出了问题怎么排查这条主线把这几个层次的问题逐一展开。你会发现安装部署这套东西看起来是命令实际全是决策。2. 装之前先想清楚版本、内核和磁盘2.1 CE 还是 EE版本号怎么读打开 Docker 官网你会看到 Docker Engine 和 Docker Desktop 两个大方向再往下分有 Community Edition社区版和 Enterprise Edition企业版。对绝大多数个人开发者、创业团队和中小公司来说选 CE 就够了。CE 版本功能上和 EE 的核心运行时没有本质差别EE 多出来的主要是商业化支持、认证镜像、额外的安全管理能力。我合作过的几家公司除非是银行、政务这类对合规有硬性要求的场景基本都在 CE 上跑得好好的。版本号这方面现在 Docker Engine 的版本命名已经切换到 YY.MM 的日历版本模式比如 24.0、25.0、26.0每个月有 patch 版本。需要注意的一点不要盲目追最新。我在生产环境里一般会看一个版本的发布时间至少发布两到三个月之后再考虑升级因为刚发布的版本总会有一些小毛病等社区跑过一轮再上更稳妥。反过来也不要停留在特别老的版本上比如停留在 19.x 时代后面遇到 CVE 修复、镜像兼容性问题时会很被动。还有个非常实用的小建议同一套环境里Docker Engine 和 Docker CLI 的版本尽量保持一致。我见过有人服务器上 Engine 是 20.10本地 CLI 是 24.0结果本地敲的某些新命令在服务器上根本不识别排查起来非常绕。虽然 CLI 和 daemon 的 API 有兼容性设计但版本差得太多体验真不好。2.2 内核版本和系统要求白纸黑字看这里安装 Docker 之前第一件事就是确认内核版本。Docker 官方要求 Linux 内核版本不低于 3.10但这是最低门槛实际用下来至少 4.18 以上才有比较好的稳定性和性能表现。如果跑的是 Ubuntu推荐用 18.04 之后的 LTS 版本CentOS 那边7.x 虽然还能装但内核比较老建议尽量往 Rocky Linux 或 AlmaLinux 9 这种新一点的发行版上走。怎么看内核版本一条命令uname -r输出类似5.15.0-91-generic这种格式说明内核是 5.15 系列没问题。如果发现内核版本太低Ubuntu 上可以通过 HWE 内核更新CentOS 系则要考虑升级整个系统别想着在旧内核上勉强跑 Docker后面网络和存储的问题会把你折磨疯。除了内核还要看系统架构。绝大多数服务器是 x86_64用uname -m确认。如果是 ARM 架构比如树莓派或者某些国产平台Docker 也能装但部分镜像没有 ARM 版本需要自己构建提前做好心理准备。安装 Docker 还需要系统里有正确的软件源。Ubuntu 要用 apt 的官方源CentOS 要用 yum 或 dnf 的官方源。这一步的意义在于让你的系统包管理器认识 Docker 的软件包后面的安装、升级都能走正常的包管理通道而不是下载一个二进制文件丢到 /usr/bin 里就完事。2.3 存储驱动和数据目录现在就要想Docker 的镜像和数据默认存在 /var/lib/docker 目录下。这是安装部署阶段最容易被忽略、后期最难受的一个点。第一个要考虑的是分区大小。/var/lib/docker 所在的分区如果太小拉几个大镜像、跑几个带数据量的容器磁盘立刻报警。我在生产环境里会单独给 /var/lib/docker 挂一块盘容量根据业务量预估一般建议不低于 100GB。如果是测试环境至少也要保证系统盘剩余空间在 20GB 以上。第二个要考虑的是存储驱动。现代 Docker 默认使用 overlay2这是目前最推荐的驱动性能好、稳定性高。官方已经放弃了对老设备映射的支持所以如果你的环境还在用什么奇怪的存储驱动尽快切到 overlay2。比较常见的存储驱动问题发生在 CentOS 7 上默认文件系统是 XFS需要开启 d_type 支持否则 overlay2 会报错。简单验证方式xfs_info /var/lib/docker | grep ftype输出里要有ftype1才说明支持。大多数云服务器默认创建的 XFS 文件系统是支持 d_type 的但如果你自己手动格式化过分区就要注意了。第三个要考虑的是 daemon 的数据目录位置。如果你不想用默认的 /var/lib/docker可以通过修改 /etc/docker/daemon.json 里的>{ data-root: /data/docker }改完重启 Docker。这个操作我建议在装完 Docker 之后马上做因为如果已经拉了一堆镜像再改Docker 不会自动帮你迁移数据你还得手动操作磁盘上那一大堆目录非常麻烦。3. 各主流平台的安装实操照着敲就行3.1 Ubuntu / Debian 系的安装流程Ubuntu 系的安装流程是最顺滑的因为 Docker 官方直接提供 apt 仓库全程走标准包管理。第一步是装前置依赖然后添加 Docker 的官方 GPG 密钥和软件源。sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg 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 ar /etc/apt/keyrings/docker.gpg然后是添加 apt 源。不同 Ubuntu 版本的 Codename 不同比如 22.04 是 jammy24.04 是 noble。如果担心写错可以在命令里动态获取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这里有个很实用的经验$(. /etc/os-release echo $VERSION_CODENAME) 这串东西能自动识别系统代号省得每次都要查表。当然如果你的 Ubuntu 版本已经停止维护这个代号可能不在 Docker 的仓库列表里那就得手动改成相近的可用代号。源添加好之后更新索引然后安装sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin我建议一次性把 docker-buildx-plugin 和 docker-compose-plugin 也装上。现在的新项目基本都要用 BuildKit 构建镜像Compose 也已经内置成插件了与其后面单独折腾不如装的时候一起解决。Debian 系的流程跟 Ubuntu 几乎一样把源地址里的 ubuntu 换成 debianGPG 密钥拉取地址也改成 debian 对应的即可。3.2 CentOS / Rocky Linux 系的安装流程CentOS 7 时代大家习惯用 yum新一点的 Rocky Linux 9 或者 AlmaLinux 9 用的是 dnf但命令差异不大。第一步还是装前置依赖加 yum 源sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo如果你是 Rocky Linux这个 centos 的 repo 文件也能用因为 Rocky 本身兼容 RHEL 系的仓库布局。装的时候sudo yum install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-pluginCentOS 系装完默认不会启动服务需要手动sudo systemctl start docker sudo systemctl enable docker这里有个坑值得单独说CentOS 7 和部分老版本的 RHEL 系系统如果之前系统里装了 firewalld 并且启用了默认规则Docker 起来之后 iptables 的管理权和 firewalld 会发生冲突表现就是容器端口映射出去不通或者某些主机端口规则突然失效。我后面会专门讲这个问题的排查和规避方式。3.3 Windows 和 macOSDocker Desktop 还是远程引擎到了 Windows 和 macOS情况就不同了。官方推荐的是 Docker Desktop它本质上是在你本机跑一个轻量虚拟机再在虚拟机里运行 Docker Engine。Windows 上基于 WSL 2macOS 上基于 HyperKit 或 Apple Virtualization Framework。Windows 装 Docker Desktop 之前先确认几件事系统是 Windows 10/11 专业版或企业版BIOS 里虚拟化已经开启WSL 2 内核已经装好。如果满足这些下载 Docker Desktop 的安装包一路装完它会自动帮你配置 WSL 2 后端。需要注意Docker Desktop 在 Windows 上对 C 盘空间要求很高因为默认 WSL vhdx 虚拟磁盘就放 C 盘很容易把 C 盘撑爆。建议在安装完 WSL 2 之后手动把发行版迁移到其他分区。macOS 这边M 系列芯片和 Intel 芯片的注意点不同。M 系列芯片默认能跑 arm64 的镜像但很多镜像只有 amd64 版本。Docker Desktop 做了交叉模拟速度会打折扣遇到这种情况我会优先找该镜像有没有 arm64 的 tag。不过说句实话如果条件允许我建议开发者在 Linux 服务器上装 Docker Engine本机用 IDE 的远程开发插件或者 Portainer 这种 Web 管理面板来操作。开发环境跟生产环境保持一致是减少在我机器上是好的这类问题的最有效手段。Docker Desktop 适合本地演示和轻量开发真要把容器当作基础设施来用它的资源消耗和维护成本都不划算。3.4 离线安装内网环境的硬核方案很多公司内网服务器无法直接访问外网这时候在线安装的路子走不通。离线安装本质上就是提前在外网环境把需要的软件包和镜像下载好然后搬到内网机器上装。Docker Engine 的离线安装最简单的方案是在外网机器上下载 docker-ce 的 rpm 或 deb 包以及所有依赖包一起拷贝进去安装。Ubuntu 上可以用 apt 的 download 模式sudo apt-get download docker-ce docker-ce-cli containerd.io依赖怎么办还有一种更省事的思路找一个同架构、同系统的外网机器装好 Docker然后用docker save把镜像导出成 tar 文件再在内网用docker load导入。比如# 外网机器 docker save -o nginx-alpine.tar nginx:alpine # 内网机器 docker load -i nginx-alpine.tar如果内网要长期跑容器离线方案里还必须架一个内网镜像仓库否则每次部署新镜像都要手动搬运 tar 包太痛苦。这块内容如果展开讲会牵扯到仓库认证、TLS 配置、镜像同步脚本等一系列东西暂时不是本篇的重点。记住结论离线部署的核心是先准备好软件包 镜像 tar 配置文件三件套按顺序往里搬就不会乱。4. 装完不是结束验证和配置才是真正的开始4.1 三步验证安装是否真的成功装完 Docker 别急着拉镜像先花两分钟做一套完整的验证。第一步看版本docker version注意看 Server 端的输出有没有正常显示。如果只有 Client 信息没有 Server 信息说明 Docker daemon 根本没起来下面所有操作都白搭。出现这种情况先看服务状态systemctl status docker第二步看系统信息docker info这个命令输出的内容非常密集但重点看三块Storage Driver 是不是 overlay2、Cgroup Driver 是不是 systemd如果配合 systemd 初始化系统、Server Version 是否正常。如果 Storage Driver 显示的是 vfs 或者其他不常见驱动说明环境有问题大概率是文件系统不支持 overlay查内核和文件系统配置。第三步是跑一个 hello-world 验证链路docker run hello-world如果能看到一段Hello from Docker!的说明文字说明从 CLI 到 daemon 到镜像拉取到容器运行整条链路都是通的。跑完docker rm $(docker ps -aq)清理一下测试容器保持环境干净。4.2 把当前用户加进 docker 组省掉一万次 sudo装完 Docker 后你会发现直接用 docker 命令会提示 permission denied因为 docker.sock 的权限默认归属 root 和 docker 用户组。很多人这时候就开始疯狂 sudo其实没必要。把当前用户加进 docker 组sudo usermod -aG docker $USER然后重新登录会话让新用户组生效。验证一下id -nG输出里能看到 docker 就说明没问题。这个操作背后有个安全注意点能操作 docker 的用户实际上等同于 root 权限因为通过容器可以挂载宿主机目录到容器里间接获得宿主机文件的读写能力。所以这个组不要随便加人只给确实需要做运维操作的同事加。4.3 镜像加速与仓库配置国内拉取 Docker Hub 官方镜像速度确实不理想。最常做的事情就是配置 registry mirror。修改 /etc/docker/daemon.json{ registry-mirrors: [https://你的加速器地址] }配置完重启 Dockersudo systemctl restart docker然后验证配置是否生效docker info | grep -A 4 Registry Mirrors如果这里列出的加速地址没有生效或者报错检查 daemon.json 的 JSON 格式是不是有问题以及地址能不能访问。我见过不少因为 daemon.json 里多写了一个逗号导致整个 Docker daemon 启动失败的案例。改完配置可以用docker info看是否正常千万别只看配置文件就觉得 OK。再补一句关于仓库认证的常用操作。如果你用的是私有镜像仓库登录docker login registry.example.com凭证会存在 ~/.docker/config.json 里。特殊情况下需要脚本化登录可以提前用docker login登录一次然后把 config.json 里的 auth 字段拿到 CI 环境用。不过这个做法有安全隐患我更建议 CI 环境使用专门的服务账号配合秘钥管理工具来管理。4.4 开机自启与服务管理服务器的 Docker daemon 必须设置开机自启否则重启一次机器所有容器跟着遭殃sudo systemctl enable docker除了 enable还有几个常用的服务管理命令。查看运行状态、重启、停止systemctl status docker systemctl restart docker systemctl stop docker要注意的是如果你的容器是通过docker run --restart设置了自动重启策略的那么 daemon 重启之后会自动拉起来。这个机制在生产环境里很重要。我建议任何生产环境启动容器都带上自动重启策略至少加上--restart unless-stopped这样只要 daemon 活着容器挂了会自动拉起省掉很多半夜被叫起来重启容器的时间。5. 从安装到部署让第一个容器真正跑起来5.1 先跑一个 Nginx理解镜像和容器的关系第一部署实践我推荐用 Nginx轻量、常见、效果直观。拉取镜像并运行docker pull nginx:alpine docker run -d --name web-test -p 8080:80 nginx:alpine解释一下这条命令的每个部分-d表示后台运行--name给容器起个名-p 8080:80表示把宿主机的 8080 端口映射到容器的 80 端口。执行完之后浏览器访问 http://服务器IP:8080能看到 Nginx 的欢迎页说明整个链路通了。这时候看看容器状态docker ps docker logs web-testdocker logs是个好东西容器里所有打到标准输出的日志都会汇总到这里部署任何一个新容器之前我都会先看一眼日志确认进程真的起来了、没有任何报错再进行下一步。停止和删除容器docker stop web-test docker rm web-test注意 stop 和 rm 是两回事stop 只是停止进程容器对象还在rm 才会删除这个容器实例。如果像我一样经常测试可以用docker rm -f web-test强制停止并删除一步到位。不过生产环境别这么干先考虑优雅停止给应用处理完收尾工作的机会。5.2 端口映射和数据卷从能跑到能用刚才那条命令里-p 8080:80是端口映射但真正到生产环境端口映射要考虑的事情更多。比如如果我跑的是一个数据库容器是不是应该把端口暴露到外网答案通常是不应该。容器内网通信的场景在同一个 Docker 网络里容器之间可以直接通过服务名互联根本不需要映射端口。端口映射只提供给真正需要从宿主机或外部访问的服务。数据卷是另一个绕不开的话题。容器是一次性的删了重跑里面写的数据就没了。数据库、日志、配置这类数据必须挂载到宿主机。比如跑一个 MySQLdocker run -d \ --name mysql-demo \ -v /data/mysql:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORDyour_password \ mysql:8.0-v /data/mysql:/var/lib/mysql就是把宿主机的 /data/mysql 目录映射到容器的数据目录。容器删了数据还在宿主机上下次重新运行同一个挂载就能恢复。关于数据卷我自己有个习惯目录权限不要用 root挂载之前先把宿主机目录创建好并且 chown 成合适的属主。很多 MySQL、Redis 容器启动失败就是因为挂载目录的属主权限不对容器内的进程没权限写入。5.3 Compose 多容器编排部署的正式姿势当你需要同时部署 Nginx、后端服务、数据库等多个容器时一条条 docker run 就会变得难以维护。这时候应该用 Docker Compose。前面安装时我特意提到了 docker-compose-plugin现在它已经作为 Docker CLI 的插件直接可用命令就是docker compose version写一个 compose.yaml内容如下services: web: image: nginx:alpine ports: - 80:80 volumes: - ./html:/usr/share/nginx/html depends_on: - api api: image: your-api:latest environment: - DB_HOSTdb depends_on: - db db: image: mysql:8.0 environment: - MYSQL_ROOT_PASSWORDsecret volumes: - db-data:/var/lib/mysql volumes: db-data:启动整个应用栈docker compose up -d查看状态docker compose ps这个文件的规则很简单但有讲究services 下定义每个服务depends_on 控制启动顺序environment 存环境变量volumes 挂载数据。我常用的调试命令还有docker compose logs -f可以同时跟踪所有服务的日志输出排查问题效率极高。使用 Compose 的意义在于把部署配置变成代码放进 Git 里管理。任何一台新机器clone 项目、装好 Docker、docker compose up -d一套服务就拉起来了。这才是容器部署的正确姿势。5.4 生产环境部署的几个硬建议如果前面是入门这块是进阶。生产环境部署 Docker 容器我总结过几条实操层面的硬建议。第一条确保数据库类容器有持久化存储和定期备份。容器可以随便删但数据不能丢。数据卷做好备份计划做好别把容器当保险箱。第二条环境变量里不要写明文密码。compose 文件支持 .env 文件但 .env 文件本身也不要进 Git 仓库。密码、密钥这类敏感信息用 Docker secret 或者配置中心管理实在不行至少用变量替换别把真实密码硬编码进去。第三条资源限制必须配。生产环境一定要给容器设置内存和 CPU 上限否则一个容器内存泄漏能把整台宿主机拖垮。run 的时候加--memory和--cpus限制compose 里对应 mem_limit 和 cpus。这属于用不到不知道用到就救命的配置。第四条日志要配置轮转。Docker 默认的日志驱动会把所有容器日志无限写到宿主机的 /var/lib/docker/containers 目录下时间一长磁盘必满。配置 daemon.json 加上日志轮转{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }这是每一个生产环境的 Docker 宿主机都应该有的基础配置。6. 安装部署中最高频的问题和排查思路6.1 Permission denied 和 socket 连接问题最常见的报错是Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?这个报错背后一般有两种可能。第一是 daemon 确实没起来用systemctl status docker看服务的状态如果显示 failed再用journalctl -u docker看详细日志。第二种可能就与我们前面说的一致当前用户不在 docker 组里没有权限访问 socket。解决方法是用户加组后重新登录。如果是 CentOS 系遇到这个问题还有一种可能系统开启了 SELinuxDocker 和 SELinux 的权限策略产生冲突。排查时执行getenforce如果输出 Enforcing可以先临时用setenforce 0验证是不是它的原因。生产环境建议保留 SELinux 开启但需要正确配置容器相关的布尔值或者让运维统一评估策略。6.2 拉镜像超时和网络问题拉镜像失败或速度极慢是最破坏心情的问题。常见错误信息包括net/http: TLS handshake timeout或者dial tcp ... i/o timeout。排查思路分三步。第一步确认网络本身通不通用curl -I试一下镜像仓库地址看响应是否正常。第二步看 registry-mirrors 配置有没有生效docker info看 Registry Mirrors 字段。第三步如果以上都没问题但拉取仍然超时考虑是不是 DNS 解析被污染了修改 /etc/docker/daemon.json 里的 dns 配置指定可靠的公共 DNS。需要注意改完配置必须重启 Dockersudo systemctl restart docker如果重启之后问题依旧再看 daemon 日志journalctl -u docker -n 100日志里会明确告诉你连接失败的具体原因。别凭猜看日志。6.3 端口映射不通与防火墙的纠缠容器启动了端口也映射了但从外部就是访问不到。这个问题的排查顺序很重要。先在宿主机上验证端口监听状态ss -tlnp | grep 8080能看到监听说明 Docker 的映射规则已生效。然后验证防火墙规则。如果你是 CentOS 系并且开着 firewalldfirewall-cmd --zonepublic --add-port8080/tcp --permanent firewall-cmd --reload如果是 Ubuntu 的 ufwufw allow 8080/tcp还有一种少见的但极其阴险的情况宿主机上有两个网络栈容器网络和宿主机网络产生了路由冲突导致端口映射后从某些网络路径访问不通。这种情况排查起来很费劲直接抓包看 SYN 包的走向是最快的方式。6.4 磁盘占满和日志爆炸容器一多宿主机磁盘被日志和镜像占满属于典型慢性病。排查用docker system df这个命令会显示镜像、容器、数据卷、构建缓存各自占多少空间。对症下药docker system prune -a这条命令能清理所有不再使用的镜像和数据但对数据卷默认不删除需要加--volumes参数。清理前务必确认哪些容器数据不再需要别把没备份的数据卷删了那是事故。磁盘问题的根治方案有两个前面说的日志轮转必须配数据目录的磁盘要单独监控配合告警。我还会定期写个脚本把超过一定时长的容器日志清理掉避免磁盘写满导致生产服务全部停摆。6.5 常见问题速查表症状可能原因快速处理docker 命令提示权限不足用户不在 docker 组usermod -aG docker $USERserver 端无响应daemon 未启动systemctl start docker journalctl 查日志拉镜像超时网络或镜像源问题配置 registry-mirrors 并重启容器端口外网不通防火墙未放行添加对应端口放行规则磁盘逐渐满日志无轮转或镜像堆积配置 log-opts docker system pruneoverlay2 报错文件系统不支持 d_type检查 xfs ftype1 或更换块设备daemon.json 改错导致无法启动JSON 格式错误docker daemon 校验配置修正格式这张表我建议截图存着等你在生产环境真的遇到这些问题时对着表格一条条排查效率会高很多。7. 安装部署复盘我最想让你带走的三件事这篇博文写到这里核心内容基本讲完了。最后分享一点我自己的实践体会。第一件事安装部署阶段多花半小时后面能省几十个小时。内核确认、磁盘规划、daemon.json 配置、日志轮转、用户组设置这些事情做在装完的那一刻成本最低。我见过太多人图省事直接一路默认三个月后磁盘报警、权限报错、网络不通轮番轰炸那时候再回头补课代价完全不是一个量级。第二件事把部署文档当作代码来维护。我自己的习惯是任何一台机器的 Docker 安装配置都会在项目仓库里留一份 markdown记录操作系统版本、内核版本、daemon.json 内容、遇到的问题和解决方案。下次换机器的时候直接照抄并且能避免重复踩同样的坑。第三件事容器部署的核心理念是不可变和可重复。镜像不可变部署可重复这意味着任何一台新机器只要你按照统一的流程装好 Docker配好 daemon拉取同一个 compose 项目运行出来的环境就是一样的。这个一致性正是容器生态最伟大的地方。如果你正打算在一台新机器上部署 Docker或者你的环境已经有一些说不清道不明的容器问题照着这篇博文的顺序从头理一遍大概率能找到答案。装好 Docker 只是万里长征第一步把这一步走稳后面的容器化改造、编排调度、微服务建设才有坚实的基础可以依赖。
