docker升级冲突源于服务端配置与依赖变更，而非客户端；需备份daemon.json、核对弃用字段、手动干预containerd/runc依赖。

升级 Docker 客户端（docker-ce-cli）本身不会直接覆盖或修改 /etc/docker/daemon.json 等服务端配置文件，因为客户端只是命令行工具，不管理守护进程配置。真正需要防范冲突的，是整个 Docker Engine 升级过程（含 docker-ce、containerd.io、docker-ce-cli）中对服务端配置和运行时行为的变更。关键在于区分“客户端”与“服务端”，并提前干预易被覆盖或失效的部分。

以下是具体、可操作的避冲突要点：

备份 daemon.json 并验证语法兼容性

• 升级前执行：

  sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak

• 检查当前配置是否含已弃用字段（如 icc、disable-legacy-registry、log-driver 非标准值），这些在 Docker 24+ 中会导致 dockerd 启动失败。可用官方验证工具或手动对照 Docker 24.x daemon.json 文档。

保留原有 containerd 配置（若独立部署）

• 若系统中 containerd 是独立安装（非随 Docker CE 自带），其配置 /etc/containerd/config.toml 不会被 Docker 升级覆盖，但新版本 Docker 可能要求 containerd 版本 ≥ 1.7。升级前确认兼容性：

  containerd --version  # 应 ≥ 1.7.0

• 如不匹配，先升级 containerd.io 包，再升级 docker-ce。

跳过自动替换 runc 或 containerd.io 的依赖冲突

PHP的配置文件php.ini的中文注释版

PHP的配置文件php.ini的中文注释版

下载

• 在 CentOS/RHEL 上，yum install docker-ce 常因 runc 与 containerd.io 冲突失败（二者提供相同二进制）。此时不要用 --allowerasing 强删系统 runc，而应：
  • 先卸载旧版 containerd.io（如有）：sudo yum remove containerd.io
  • 手动下载匹配版本的 containerd.io RPM（如 Docker 24.0 对应 containerd.io-1.7.20-3.1.el8.x86_64.rpm）
  • 用 rpm -Uvh --force 安装，避免依赖链断裂

升级后立即检查并修复运行时名称变更

• Docker 23.0+ 默认运行时从 docker-runc 改为 runc，但旧容器元数据中仍存 docker-runc 字符串，导致启动报错 Unknown runtime specified docker-runc。修复命令：

  sudo systemctl stop docker
  sudo grep -rl 'docker-runc' /var/lib/docker/containers/ | xargs sed -i 's/docker-runc/runc/g'
  sudo systemctl start docker

不重装、只更新：避免全量 purge

• 错误做法：apt-get purge docker-ce → 删除 /var/lib/docker 下所有镜像容器（虽文档说“不删”，但 purge 可能触发清理脚本）。
• 正确做法：停服务后仅更新包，例如 Ubuntu：

  sudo systemctl stop docker
  sudo apt install docker-ce=5:24.0.7-1~ubuntu.22.04~jammy docker-ce-cli=5:24.0.7-1~ubuntu.22.04~jammy containerd.io

  指定版本号确保可控，/var/lib/docker 中的镜像、容器、卷全部保留。

本质上，冲突不是来自客户端，而是服务端组件升级引发的配置语义变化与依赖替换。核心动作就三件：备份配置、核对弃用项、手动干预关键依赖包。做完这三步，升级过程几乎无感。