一台CentOS 7上的Docker-CE装到一半挂了,yum源里残留旧包、docker daemon反复报错、容器数据乱成一团——这种场景我处理过不止一次。大多数人遇到这种局面,第一反应是yum remove docker-ce然后重新yum install docker-ce,结果装完发现新版镜像还在,旧配置还在,问题一样没解决。所谓的"彻底重装",真正的难点从来不在"装",而在"清"。这机器上有哪些历史残留、哪些目录该删、哪些依赖没卸载干净,全都要理清楚,否则重装一百遍也是白搭。
这篇内容我按照自己在一台CentOS 7上从"Docker彻底重装"的真实操作来写,包含完整卸载链路、残留清理、yum源切换、干净安装、以及重装后的配置和验证。适合遇到Docker升级失败、数据异常、源冲突、或者想从混乱状态恢复的运维人员和自建服务玩家。我会把每一步的"为什么这样做"讲清楚,而不是把命令扔给你就完事。
1. 先分清楚:你需要的是一次卸载重装,还是一次彻底重装
1.1 三种"重装"之间的差别
很多人在网上搜"重装docker-ce",其实需求差别很大。按我的经验,至少分成三种:
- 普通卸载重装:
yum remove docker-ce再yum install docker-ce,旧镜像、旧容器、旧配置全都在。适合只是软件包版本太老、想换个同系列新版本的情况。 - 升级失败后的修复:从20.10想升到24.0,升到一半yum中断,或者升级后发现
docker daemon起不来。这时候只需要把docker相关包重新装一遍,数据目录可以保留。 - 彻底重装:Docker的历史状态已经完全失控,比如多年没动过、换过多套源、手动装过二进制、
/var/lib/docker里残留了大量老版本元数据。这时候必须把软件和数据一起清掉,从零开始。
这篇讲的"彻底重装",对应的是第三种。核心判断标准是:**/var/lib/docker目录要不要留。** 想保留旧容器和镜像,那就不是"彻底重装";想让它回到一台全新机器的状态,那这个目录必须删掉。
1.2 先摸清当前机器的真实状态
动手之前先花三分钟确认现状,这一步能帮你决定该走哪种方案。
docker version docker ps -a docker images docker volume ls systemctl status docker journalctl -u docker --no-pager | tail -50重点看三件事:
docker version能不能输出,服务端版本是多少。如果连客户端都报Cannot connect to the Docker daemon,说明 daemon 根本没起来。docker ps -a能不能列出旧容器。能列出,说明/var/lib/docker还是可读的,数据还在。journalctl -u docker里的报错信息。常见的有:failed to load listeners、devmapper相关、overlay2相关、iptables failed,这些都能帮你判断是软件问题还是数据问题。
如果daemon起不来,但/var/lib/docker里还能看到docker ps -a的容器列表,说明数据目录本身大概率是完整的;如果连列表都出不来,那基本就是数据目录元数据损坏或版本格式不匹配了,留在手上也没什么意义,走了"彻底重装"这条路就别回头。
1.3 彻底重装不等于把一切扔掉
这里要强调一个原则:"彻底重装"清的是Docker软件的运行数据和元数据,不是让你连业务数据都不要。之前的容器里如果有数据库、配置文件、用户上传文件,动手前必须备份。很多时候Docker重装其实是次要的,保住数据才是主要任务。
我见过有人rm -rf /var/lib/docker删得特别痛快,结果后来发现有个容器的卷里有半年的订单备份文件,直接傻眼。所以接下来的第2节我会把备份清单完整的列一遍,每一条都值得执行。
2. 动手之前的备份清单,这一步省了后面后悔
2.1 先看清机器上到底有什么
备份之前,先把当前Docker的状态完整导出来。下面的命令会把容器、镜像、卷、网络的清单分别记录下来,作为备份的操作依据。
mkdir -p /opt/docker-backup docker ps -a > /opt/docker-backup/containers.txt docker images > /opt/docker-backup/images.txt docker volume ls > /opt/docker-backup/volumes.txt docker network ls > /opt/docker-backup/networks.txt不要小看这几个txt文件。重装完之后你想恢复某些东西,第一步就是对着这个清单找:"那个容器叫什么名字、用的哪个镜像、挂的哪个卷。"没有清单,重装完对着空空的docker ps -a发呆,连当初跑了什么都不知道。
2.2 三类数据分别怎么备份
镜像
镜像可以通过docker save打包成tar文件。如果镜像不多,可以直接全部打包:
docker save -o /opt/docker-backup/images-all.tar $(docker images -q)如果机器上有几十个镜像,全量打包会很占空间。可以按需打包,只备份将来确定要用的:
docker save -o /opt/docker-backup/nginx.tar nginx:latest容器数据
注意,docker save备份的是镜像,不是容器里的运行数据。运行中的容器你可以在线导出文件系统快照:
docker export -o /opt/docker-backup/mycontainer.tar mycontainer但docker export导出的是容器文件系统,不包含卷(volume)。卷的数据存在/var/lib/docker/volumes/<卷名>/_data目录下,备份卷最直接的方式就是打包这个目录:
tar -czf /opt/docker-backup/volumes.tar.gz -C /var/lib/docker/volumes .配置文件
/etc/docker/daemon.json、/etc/systemd/system/docker.service.d/下的自定义配置、以及你自己写的docker-compose.yml、.env文件,这些都要单独拷走。特别是docker-compose.yml,里面包含了容器端口映射、环境变量、数据卷声明,重装后最大的工作量其实都在这里。
cp -r /etc/docker /opt/docker-backup/config-etc-docker cp /etc/systemd/system/docker.service.d/*.conf /opt/docker-backup/ 2>/dev/null find /home /opt /srv /data -maxdepth 3 -name "docker-compose.yml" -o -name ".env" 2>/dev/null2.3 业务时间窗确认:别在业务高峰期动手
这一步容易被忽略但非常关键。如果这台机器上有数据库、有正在对外提供服务的容器,彻底重装意味着/var/lib/docker整个删掉,旧容器全部不可用。你要确认:
- 确认这些容器对应服务没有在跑核心业务,或者至少停服窗口足够长。
- 如果有数据库容器,确认数据文件已经通过
mysqldump、pg_dump等逻辑备份方式额外导出了一份,而不是指望下面的tar目录备份就能直接恢复。 - 有主从关系的机器,先处理从库,确认同步恢复节奏再上主库。
3. 卸载阶段最容易漏的五个位置:不只是yum remove
3.1 停止服务与socket激活:只stop docker是停不彻底的
正式开始卸载,第一步是停止运行中的Docker服务:
systemctl stop docker systemctl stop docker.socket systemctl disable docker docker.socket这里有一个非常容易踩的坑:很多人只执行systemctl stop docker,没有停docker.socket。Docker实际上由两个systemd单元组成:一个是docker.service,负责实际运行dockerd;另一个是docker.socket,负责监听/var/run/docker.sock这个Unix套接字,一旦有客户端通过套接字发起请求,它会自动把docker.service拉起来。如果你只systemctl stop docker,socket还活在系统里,之后只要有程序碰一下sock,dockerd又会被自动拉起。后面卸载过程中你刚停掉的服务可能又自己活了,一脸懵。
所以docker.socket必须和docker.service一起disable,两个都停才算停干净。
3.2 卸载软件包的正确姿势
把Docker全家桶包列出来,一次清掉:
yum remove -y docker \ docker-ce \ docker-ce-cli \ docker-ce-selinux \ docker-engine \ docker-engine-selinux \ docker-client \ docker-client-latest \ docker-common \ docker-latest \ docker-latest-logrotate \ docker-logrotate \ docker-rootless-extras \ docker-compose-plugin \ docker-buildx-plugin \ containerd.io \ runc有些包其实并不存在,yum会提示No matching Packages,不用在意,直接略过就行。这个命令的意义在于:把docker客户端、服务端、containerd、runc、插件这些组件一次性清掉,避免装了新版docker之后还残留一套旧的runc或containerd,导致版本错配。
卸载之后执行一次:
yum autoremove -yautoremove会把那些因为装Docker而作为依赖自动装进来、但现在已经没有用处的包清掉。有时候能清理出一两百MB的垃圾,让系统更干净。
3.3 残留文件与目录清理清单:不该删的别删,该删的一个别留
这是整个重装过程里最关键的一步。卸载软件包只是删了二进制文件,但Docker运行时产生的所有数据都在磁盘上。下面这个清单是我在实际环境里整理出的残留目录,按重要程度排列:
| 路径 | 里面是什么 | 影响 |
|---|---|---|
/var/lib/docker | 镜像层、容器元数据、卷数据、网络配置 | 不删的话,新版dockerd启动时会读到旧格式数据,原版本和新版本containerd之间经常出现storage-driver不兼容、容器启动不了 |
/var/lib/containerd | containerd自己的工作目录 | 残留的containerd元数据可能和新版containerd冲突 |
/etc/docker | daemon.json等配置 | 旧配置可能指定旧的data-root或无效的加速地址,新版本启动时报错 |
/run/docker/run/docker.sock | 运行时目录、套接字 | 旧套接字会导致Cannot connect to the Docker daemon假象 |
/opt/containerd | containerd全量安装时的目录 | 有些环境装过独立containerd,会在这里留数据 |
软链接/etc/systemd/system/docker.service等 | 曾经的systemd覆盖配置 | 卸载不清的话,重装后systemctl daemon-reload可能会加载失败 |
清理命令:
rm -rf /var/lib/docker rm -rf /var/lib/containerd rm -rf /etc/docker rm -rf /run/docker rm -rf /opt/containerd rm -f /run/docker.sock rm -f /etc/systemd/system/docker.service rm -f /etc/systemd/system/docker.socket rm -rf /etc/systemd/system/docker.service.d要特别小心:删/var/lib/docker是不可逆操作。删之前请再三确认第2节的备份已经完成。如果你实在舍不得旧数据,那你就应该走"升级失败修复"路线,而不是"彻底重装"。又想保留数据又想干净重装,这两个目标本身就是冲突的。
3.4 systemd单元、自启软链、用户组残留
卸载软件包通常不会自动清掉自定义的systemd配置。执行完上面的rm之后,再检查一下:
systemctl list-unit-files | grep docker ls -l /etc/systemd/system/multi-user.target.wants/ | grep docker正常情况下现在的输出里应该什么docker相关的东西都没有。如果还有docker.service、docker.socket之类的单元残留,手动delete掉:
rm -f /etc/systemd/system/multi-user.target.wants/docker.service systemctl daemon-reload systemctl reset-failed还有一个非常隐蔽的残留是用户组。以前为了免sudo运行docker,通常会把用户加入docker组。卸载软件包不会自动删除这个组。重装后如果你发现某个用户不需要docker权限了,但groups输出里还有docker组,可以这样清:
groupdel docker重装后组会自动被重新创建,所以这里删掉没有坏处。
3.5 iptables规则残留:不处理干净,重装后网络必炸
Docker会在宿主机上往iptables里写入大量规则,特别是NAT表的DOCKER链、docker0网桥对应的规则。卸载软件包时,这些规则并不会自动消失。重装dockerd后,它启动时会尝试重新初始化iptables,新旧规则叠加经常导致端口映射失败、容器之间无法互相访问。
处理办法很简单:如果真的决定彻底重装,那么在卸载干净之后、重装之前,重启一次系统或者直接把iptables规则清空。重启系统是最省心的方式,因为会自动把dokcer0网桥、所有虚拟网卡、残留规则一起清掉。如果不想重启,可以手动清理:
systemctl stop iptables 2>/dev/null iptables -F iptables -t nat -F iptables -t mangle -F注意,清空iptables规则会对宿主机已有服务有影响,如果这台机器有别的业务直接暴露在公网,谨慎操作,或者干脆重启系统更稳妥。我之前在CentOS 7上重装Docker,第一次就是偷懒没有清iptables,装好后起了个nginx映射8080端口,外部死活访问不了,最后从iptables -t nat -L -n看到里面躺着一条旧的DOCKER链规则,清空规则重启iptables服务后立即正常。
4. yum源和缓存:卸载后必须处理的"下一脚"
4.1 旧的docker-ce.repo怎么处理
卸载之后,如果之前配过Docker官方的yum源,通常会在/etc/yum.repos.d/下留一个docker-ce.repo。这里有两种处理策略:
- 彻底重装的语境下,推荐直接重建这个repo文件。因为旧文件可能指向官方源地址,在国内环境拉取速度感人,而且如果之前是从第三方源的acked包装的,这个repo文件里的GPG密钥可能已经失效或不对应。
- 先备份一下,再重写:
mv /etc/yum.repos.d/docker-ce.repo /opt/docker-backup/docker-ce.repo.bak4.2 yum缓存彻底清除:不clean干净,下次安装用的还是旧索引
yum安装时不是每次实时去下载repo元数据的,而会用本地缓存。如果旧缓存里还保留着旧版本的docker-ce包索引,你重装时yum install docker-ce可能依然从旧索引里找版本,导致装出来的还是旧的。
yum clean all rm -rf /var/cache/yum/x86_64/7/docker-ce yum makecacheyum clean all会清空所有repo的元数据缓存,/var/cache/yum/x86_64/7/docker-ce是docker-ce源的缓存目录,rm -rf确保它彻底消失。然后再yum makecache重新生成索引。这样装的时候才是基于最新的源数据。
4.3 残留依赖与冲突定位
卸载完、缓存清理完,最后再确认一遍没有任何docker相关的东西残留:
rpm -qa | grep -E 'docker|containerd|runc'正常情况下输出为空。如果还有东西,逐个卸载:
yum remove -y $(rpm -qa | grep -E 'docker|containerd|runc')这里有个细节:runc在有些CentOS 7系统上是作为docker-ce的依赖装进来的,有些环境是之前手动装过独立runc。新版docker-ce自带docker-ce包依赖的runc版本较新,如果有手动装的旧runc残留,重装后运行容器时往往会出现OCI runtime create failed的报错。所以这一步尽量清理干净。
另外一个常见的坑是container-selinux。这个包负责为容器运行提供SELinux策略。在CentOS 7上安装docker-ce时,如果系统没有这个包,安装过程会报错或者装完启动时报SELinux相关的错误。旧环境里它通常已经存在,但如果你做过系统裁剪,记得重装前先装上:
yum install -y container-selinux5. 干净安装docker-ce的操作路线
5.1 先确认系统基础条件
重装前,快速过一遍系统环境:
cat /etc/redhat-release uname -r getenforceCentOS 7默认内核是3.10系列,如果uname -r显示的内核版本太老(比如3.10.0-327),建议先把内核更新到3.10.0-1160以上的补丁版本:
yum update -y kernel reboot内核版本太老会导致新版containerd和runc在底层能力判断上出问题,比如overlay2存储驱动需要ftype=1的文件系统属性,旧内核在xfs上经常不支持,运行容器时会报failed to mount overlay的错误。还有一个常被忽略的点是:重装前确认这台机器网络能不能访问外网。CentOS 7上常见的"无法ping通百度"问题,通常是DNS配置错误或默认网关不对,这种情况在配置yum源之后会立刻暴露,因为yum makecache会卡住。先ping一下镜像站域名,确认解析正常再往下走。
5.2 用阿里云镜像站配置Docker-CE仓库
面向国内VPS和自建服务器,我强烈建议直接把docker-ce的repo源写成阿里云镜像站的地址,而不是Docker官方地址。原因很简单:官方源在海外,CentOS 7上如果不配代理,yum install docker-ce经常卡在下载阶段,装到一半超时,然后留下一个半残的环境,反而更麻烦。
新建/etc/yum.repos.d/docker-ce.repo:
cat > /etc/yum.repos.d/docker-ce.repo <<'EOF' [docker-ce-stable] name=Docker CE Stable - $basearch baseurl=https://mirrors.aliyun.com/docker-ce/linux/centos/7/$basearch/stable enabled=1 gpgcheck=1 gpgkey=https://mirrors.aliyun.com/docker-ce/linux/centos/gpg EOF然后:
yum clean all yum makecachemakecache能成功跑完,说明源没问题。这一步其实顺带把CentOS 7的yum源可用性验证了一轮。
5.3 装哪个版本:先看列表,再决定
不要上来就yum install docker-ce,先看仓库里到底有哪些版本:
yum list docker-ce --showduplicates输出里会列出所有可用的docker-ce版本号。以我这些年在CentOS 7上的实践经验,重装时我会优先选择20.10.x 稳定分支,尤其是20.10.24。理由有三点:
- CentOS 7默认内核是3.10,20.10这个系列在RHEL 7/CentOS 7上的测试覆盖最充分,社区里跑的坑最少。
20.10.24是这个分支里最后的版本,当时官方对RHEL 7的兼容性支持做得最完善。- 新版docker(24.0+、26.0+)对cgroup v2、新版containerd有更强的依赖,而CentOS 7的cgroup还是v1体系,强行上新版可能带来兼容性风险。
如果你想装更新的版本,也建议先用yum list docker-ce --showduplicates看看可用版本,然后指定版本安装。安装命令:
yum install -y docker-ce-20.10.24 docker-ce-cli-20.10.24 containerd.io docker-compose-plugin这里面的containerd.io会自动装上报的1.6.x系列,与20.10.24兼容性良好。注意:docker-compose-plugin提供的是docker compose子命令,如果你在使用老的docker-compose(带连字符那个),那是另一个python写的工具,不在这个安装范围里,需要单独装。
5.4 启动与开机自启
安装完成后,启动并设置开机自启:
systemctl start docker systemctl enable docker systemctl status docker docker versiondocker version要能看到Server端版本才说明daemon正常。如果只看到Client版本、看不到Server,说明dockerd没起来,去查日志:
journalctl -u docker --no-pager | tail -506. daemon.json与国内加速:安装完成后的头十分钟
6.1 daemon.json里值得先配的三件事
Docker装好之后,别急着拉镜像。先把/etc/docker/daemon.json写好。这个文件是dockerd的配置文件,很多人装完Docker不碰它,用着用着一堆问题才来找根因。
mkdir -p /etc/docker cat > /etc/docker/daemon.json <<'EOF' { "exec-opts": ["native.cgroupdriver=systemd"], "log-driver": "json-file", "log-opts": { "max-size": "100m", "max-file": "3" }, "storage-driver": "overlay2", "registry-mirrors": ["https://<你的加速地址>.mirror.aliyuncs.com"] } EOF这是我在CentOS 7上最常用的一套配置,逐项说明:
exec-opts设置成native.cgroupdriver=systemd。CentOS 7上默认cgroup驱动可能是cgroupfs,配置成systemd会让容器与systemd的管理方式更一致,不配有时会出现Kubernetes等工具跑的时候报驱动不一致。log-driver和log-opts限制单个容器日志文件最大100MB,最多保留3个文件。这是很多人吃过亏的地方。/var/lib/docker/containers/<容器ID>/<容器ID>-json.log这个文件会无限增长。我亲眼见过一台机器上某个容器的json.log涨到30多GB,直接把根目录撑爆。不配这个限制,脏日志日志多的容器几个月就能塞满磁盘。storage-driver配置成overlay2。CentOS 7上默认支持overlay2,但前提是文件系统支持d_type。如果之前清理不彻底或分区是老的xfs格式,某些情况下会无法使用overlay2,此时可以先用docker info查看Storage Driver字段,确认是overlay2而不是vfs。vfs性能很差,基本是"能跑但慢很多"的状态。
配置完成后必须重启Docker生效:
systemctl daemon-reload systemctl restart docker6.2 国内镜像加速的设置逻辑
registry-mirrors是配置镜像加速的字段。对国内环境来说,拉取docker.io官方仓库的镜像极其折磨人:几十层的镜像经常拉到一半超时,重试到崩溃。配置加速地址之后,dockerd会优先从加速地址拉取,速度提升非常明显。
最稳定的方式是在阿里云容器镜像服务控制台里申请一个专属加速地址,每个人申请到的地址形如https://xxxxxxxx.mirror.aliyuncs.com,填入上面的registry-mirrors数组里。申请过程几十秒,不需要额外装任何东西。
如果暂时没有专属地址,也可以先用一些公共加速地址。注意公共加速地址的稳定性并不总是理想,实测拉不动的时候换一个就行。加速配置好之后的验证方式:
docker info | grep -A 3 "Registry Mirrors"如果能列出你配置的地址,说明生效了。
6.3 配置完成后必须做的检查:json格式和字段名
daemon.json是最容易出低级错误的地方。最常见的坑有三个:
- JSON里不能有注释。很多人会把
// 这是日志限制写进去,dockerd直接启动失败。 - 字段名不能拼错。
registry-mirrors不是registry-mirror,log-opts不是log-ops,写错之后dockerd通常不会报错,而是静默忽略或者起不来。 - 多行数组的逗号问题。配了多个镜像加速地址时,最后一个元素后面不能有逗号。
如果配置不正确导致dockerd起不来,排查方法很简单:
journalctl -u docker --no-pager | tail -30或者直接前台启动dockerd看报错:
dockerd前台模式会把配置解析错误直接打在终端上,能省去不少猜的时间。
7. 验证与重装后的排错:我实测遇到的情况
7.1 跑一遍标准验证流程
配置完成、服务启动后,用最简单的镜像验证整个链路是否正常:
docker run --rm hello-world这个镜像特别小,网络好的情况下几秒就拉完并打印出"This image is running successfully"之类的消息。能跑通,说明daemon、镜像拉取、容器运行、日志输出整个闭环都是正常的。
进一步测试网络映射,可以把Nginx测试容器的端口映射出来:
docker run -d -p 8080:80 --name test-nginx nginx:alpine curl http://127.0.0.1:8080如果在宿主机上能curl通8080,说明iptables规则重建正常,端口映射链路没问题。测试完删掉测试容器:
docker rm -f test-nginx到这里,重装基本完成。
7.2 真实排错经历:重装后镜像还在,我以为操作错了
我把自己在重装过程中遇到过的两个典型情况写出来,希望你能少走弯路。
情况一:重装后docker images竟然还有东西
有一次我执行了yum remove docker-ce,但没有删/var/lib/docker目录,然后重新安装了docker-ce。装完之后docker images竟然列出了旧的镜像。当时我第一反应是"我卸载失败了吗?"后来查了一圈才明白,yum remove只卸载了/usr/bin/docker、dockerd这些二进制文件,/var/lib/docker目录原封不动。新版dockerd启动时会读取这个目录里的镜像层和元数据,大部分情况下能直接沿用,所以docker images还能看到旧镜像。
这个现象提醒我:如果你在重装后要求"必须彻底干净",那么卸载阶段删/var/lib/docker这一步绝对不能跳过。反过来,如果你只是想升级Docker且确实需要保留旧镜像,那倒是可以利用这个机制,但升级前后要注意老版本Docker和新版本containerd在元数据上是否有兼容性问题。
情况二:daemon.json写错导致dockerd起不来
有一次我在重装后配置daemon.json,里面加了一个公共加速地址,但那段时间这个地址恰好宕机了,dockerd启动时解析这个地址超时,一直卡在start状态。我看systemctl status docker一直显示activating(auto-restart),日志里全是connect: connection timed out。当时的处理是在daemon.json里临时去掉那个加速地址,启动成功后换个稳定地址再加回去。
这个案例的启示是:换加速地址时不要频繁重启Docker,尤其是多个地址一起换时要逐个验证。加速地址列表尽量保持两到三个,一个挂了还有备份。
7.2.1 与SELinux和内核相关的问题
CentOS 7默认启用了SELinux,重装Docker后第一次启动容器,如果报Permission denied或者operation not permitted,优先检查SELinux状态:
getenforce如果输出是Enforcing,有两种做法。一种是临时调试,先setenforce 0,容器能跑起来就去查对应的SELinux审计日志,判断是否缺策略模块;另一种是确定这台机器没有必要开SELinux保护容器运行,直接修改/etc/selinux/config把SELINUX=enforcing改成SELINUX=permissive,然后重启。在CentOS 7上跑Docker,生产环境我倾向于保持SELinux开启并确保container-selinux包存在,熊本地上因为一些奇奇怪怪的业务容器会访问宿主文件系统,SELinux限制太严,选择permissive也是一种现实策略,但你要清楚这么做的安全代价。
7.3 给普通CentOS 7用户的重装建议
最后总结几条实操层面的建议,都是我实际踩出来的:
- 重装和升级不是一回事。如果现状还能苟着用,别手贱去重装;重装的代价远高于直接
yum upgrade。但一旦决定彻底重装,就别半途而废,既想保留旧数据又想全清,两头不讨好。 - 重装之后,如果iptables和网桥残留问题始终无法解决,最快的方式是
reboot。重启一次让内核网络栈完全归零,比手动清各种残留规则省时间得多。我通常在干净安装完Docker并写好daemon.json之后,会主动重启一次机器,确认开机自启正常再交出去。这个习惯帮我省掉了大量"为什么重启后又不行了"的排查时间。 - 备份清单别删。把
/opt/docker-backup留着,等系统稳定运行一两周再删,以确保旧数据真的不需要了。 - docker-compose容器编排文件是重装后最有价值的配置资产。把之前容器的compose文件、环境变量、挂载路径、端口映射完整记录下来,重装后只需要
docker compose up -d就能快速恢复业务,不用一行行手敲docker run参数。
重装Docker这件事,技术本身并不复杂,复杂的是把旧状态理解清楚、把残留清干净、把新环境一步到位配置好。处理好这几件事,这台CentOS 7上的Docker基本就能稳定跑很久不出幺蛾子。