我原以为，将Docker从 Snap 安装方式迁移到 APT，会带来更高的灵活性和兼容性。事实却恰恰相反——我亲手将一台运行良好的 Hetzner 根服务器“整瘫痪”了。
这篇文章记录了我在 Ubuntu 22.04 上将 Docker 从 Snap 切换为 APT 后所遇到的系统崩溃问题，以及我如何逐步排查并解决问题的全过程。希望能为遇到类似困境的开发者提供参考。
一、从 Snap 切换到 APT 后问题频发
这台服务器是我在 Hetzner 上的独立物理机，配置为：
- CPU: Intel i7-7700
- 内存: 64GB RAM + 32GB Swap
- 系统: Ubuntu 22.04.5 LTS
- Docker 版本: 28.2.2（APT 安装，build e6534b4）
之前，我一直使用 Snap 版本的 Docker，运行多个容器稳定如初。直到某天我尝试部署 Taiga 项目，发现 Snap 安装的 Docker 无法正常支持其容器构建需求。于是我卸载了 Snap 的 Docker，改用官方推荐的 APT 安装方式：
sudo snap remove docker
sudo apt remove docker docker.io containerd runc
sudo apt update
sudo apt install \
ca-certificates \
curl \
gnupg \
lsb-release
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
https://download.docker.com/linux/ubuntu jammy stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
至此 Docker 安装完成，服务能正常启动，也能拉取镜像。但从那一刻开始，每当我启动 Docker 服务，服务器就会在数分钟后无响应并崩溃，无法 SSH，Ping 也不通。
二、问题表现：系统无预警崩溃、不可访问
我做了以下实验验证：
- 启动 Docker 服务后，即使没有运行任何容器，系统仍会在大约 5–10 分钟后崩溃；
- 崩溃期间没有系统日志写入 /var/log；
- 内存和 CPU 占用并不异常（我在 htop 中持续观察，内存约 1.4GB，CPU 基本空闲）；
- swap 使用情况也正常，df 显示磁盘未满。
每次系统死后，我都需要通过 Hetzner 的救援模式进入、挂载原系统分区，然后手动关闭 Docker 开机启动：
systemctl disable docker
systemctl disable containerd
然后才能正常重启并恢复使用。
三、逐步排查：怀疑点与验证过程
1. 怀疑 containerd 版本不兼容
APT 安装的 Docker 依赖 containerd，而 Snap 安装会独立打包自己的 runtime。通过以下命令验证当前使用的 containerd：
containerd --version
我尝试用如下命令替换为 Docker 官方稳定版本：
sudo apt install containerd.io=1.6.20-1
仍然崩溃，说明并非 containerd 单一问题。
2. 检查 systemd 服务依赖链与内核模块冲突
我查看了 Docker 服务的依赖关系：
systemctl status docker
journalctl -xeu docker
无明显报错。转而查看 dmesg 中是否有内核 panic 或 I/O 锁死提示：
dmesg -T | tail -n 100
结果显示当 Docker 启动后系统运行几分钟内会有某些 cgroup v2 相关的内核调用堆栈触发资源锁死，疑似为 Docker 和系统资源调度器之间的冲突。
3. 确认是否为 overlay2 存储驱动导致的问题
Docker 默认使用 overlay2，而我注意到我的 Hetzner 系统分区可能挂载在不支持 d_type 的文件系统上。验证方式如下：
docker info | grep -i storage
并查看具体挂载信息：
findmnt -no FSTYPE /var/lib/docker
确认如果是 ext4 或 xfs 文件系统，需要挂载参数 ftype=1 才支持 overlay2。否则可以尝试切换为 devicemapper（不推荐）或 fuse-overlayfs（兼容性更好）：
sudo apt install fuse-overlayfs
sudo mkdir -p /etc/docker
echo '{
"storage-driver": "fuse-overlayfs"
}' | sudo tee /etc/docker/daemon.json
sudo systemctl daemon-reexec
sudo systemctl restart docker
此步骤后，我的系统不再出现崩溃现象，Docker 可以正常运行。
四、最终方案
我将目前可稳定运行的配置总结如下：
✅ 替换 Overlay2 为 Fuse-OverlayFS：
sudo apt install fuse-overlayfs
✅ 修改 Docker 配置文件 /etc/docker/daemon.json：
{
"storage-driver": "fuse-overlayfs"
}
✅ 禁用 Snap 残留配置，彻底清除：
sudo apt purge snapd
sudo rm -rf /var/lib/snapd
✅ 检查是否启用了 Systemd 的 swap 限制（建议禁用）：
sudo systemctl edit docker
添加以下配置：
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd --exec-opt native.cgroupdriver=systemd
五、反思与建议
这次的踩坑过程提醒我：
- Snap 与 APT 安装的 Docker 区别不只是包装方式，底层运行时、驱动兼容性都可能存在巨大差异；
- Docker 存储驱动对系统文件系统有特定要求，尤其是 overlay2；
- 如果系统在不跑容器的前提下，只是启动 Docker Daemon 就崩溃，问题很可能出在 存储驱动或 CGroup 与内核的兼容性问题 上；
- “一切正常”并不代表“未来可预测”。Docker 的底层机制更复杂，一定要读官方文档并验证系统支持。
如果你也遇到类似问题，不妨从存储驱动、CGroup 驱动、内核日志等方向深入排查，不要只依赖表面资源监控工具（如 htop 和 df）。
