企业官网建设流程全解析

第一次在 Ubuntu 22.04 上装 Docker，大概率不是被安装本身难住，而是被安装完之后的某个报错搞到怀疑人生。敲下sudo docker ps却看到Cannot connect to the Docker daemon，或者明明照着教程一步步来，最后却在apt update阶段被一串 GPG key 错误卡死。这篇文章就是来把这条路走平的，从系统自带 docker.io 和官方 docker-ce 仓库的区别讲起，完整拆解 Ubuntu 22.04 上的安装流程，再把安装过程中那几类高频报错逐个拎出来，告诉你根因在哪、怎么解决。无论你是在物理机上折腾，还是在虚拟机里准备搭开发环境，这篇都值得直接收藏作为操作手册。

1. 安装 Docker 的整体思路：为什么不用系统自带的 docker.io

1.1 先搞清楚两个消息源：docker.io 和 docker-ce 的区别

Ubuntu 22.04 的官方软件源里其实自带了一个名为docker.io的包，很多人第一次装 Docker 时图省事，直接sudo apt install docker.io一把梭。这个包能用吗？能，但非常不建议在生产环境或者需要长期维护的开发环境里用。原因在于它和 Docker 官方发布的docker-ce（Community Edition）存在明显差异。

docker.io是 Debian/Ubuntu 发行版维护团队自行打包的版本，它的发布节奏跟随着发行版的更新周期，而不是跟随着 Docker 官方的版本更新。这意味着你大概率拿不到最新特性、最新的 bug 修复和安全补丁。Ubuntu 22.04（jammy）仓库里的 docker.io 版本长期停留在比较旧的版本上，像 BuildKit 的默认启用、新的网络能力、Docker Compose v2 的集成支持，这些在旧版本上体验是打折扣的。更重要的是，docker.io缺少官方的docker-ce-cli和docker-compose-plugin这类组件，装完之后你还要另外想办法去折腾 CLI 补全，或者在容器编排时额外安装 Compose，非常绕。

而docker-ce是 Docker 官方维护的软件源，发布节奏快、和上游紧密同步、提供 LTS 版本支持，而且装好之后自带 Buildx、Compose v2 插件、containerd 运行时等一整套生态。既然要用 Docker，就应该从源头选一个清晰、靠谱的版本，这也是我在标题里坚持用“安装 docker”而不是“安装 docker.io”的原因。下文所有步骤均基于 Docker 官方源，按照官方推荐的方式走，减少后续踩坑的概率。

1.2 为什么推荐通过官方 apt 仓库安装

Docker 官方在 Ubuntu 上提供了两种主流安装方式：一种是 Docker Desktop，一种是 apt 仓库安装 Docker Engine。如果你使用的是 Linux 桌面环境，可能会被 Docker Desktop 的宣传界面吸引，但我建议优先考虑通过 apt 仓库安装 Docker Engine，理由有几点。

Docker Desktop 本质上是把虚拟机层面的组件和 GUI 管理工具捆绑在一起，它对系统资源的要求比 Docker Engine 高不少，特别在虚拟机里跑 Ubuntu 22.04 的场景下，启用嵌套虚拟化、保证 GUI 和 WSL2 后端正常协同，这些环节非常容易出问题。网上搜docker desktop failed to start because virtualization support wasn't detected的人一大片，基本都卡在这一步。而 apt 仓库安装的 Docker Engine 直接运行在宿主机上，不依赖额外的虚拟化层，资源占用更小，排错路径也更干净。

另一方面，通过 apt 仓库安装能保证守护进程 systemd 管理、命令行工具链完整、插件体系（Buildx、Compose）随装随用。后续做镜像加速、配置 daemon.json、设置日志轮转都非常直接。命令行操作虽然少了图形界面，但对开发者来说，编辑 daemon.json 和敲 docker compose 命令本来就是日常，不会比点鼠标慢，反而更可控。

1.3 安装前的环境准备

动手之前，先把环境状态确认一遍，别装到一半发现系统版本不对或者缺依赖。我用的是 Ubuntu 22.04.3 LTS，内核版本 5.15 系列，这套流程在 22.04 全系列子版本上都验证过。可以用下面的命令先看一眼自己的系统版本和架构：

lsb_release -a uname -m

正常情况下lsb_release -a会输出Description: Ubuntu 22.04.x LTS，uname -m会输出x86_64。如果你在 ARM 架构的设备上跑，后面 apt 源的架构字段会自动适配，不用手动去改。还需要确认你有sudo权限，并且当前用户能执行特权命令。装 Docker 的整个过程基本都在 root 权限下操作，使用普通用户时记得每条命令前加sudo，不要真的切到 root，保持习惯一致能少很多权限问题。

提示：如果你是刚装好的最小化系统，先执行sudo apt update && sudo apt upgrade -y把系统索引和软件包基础版本提上去一次，能避免很多依赖层面的小毛病。但这个步骤不是必须的，如果你的系统已经用了很久、包管理状态良好，可以跳过upgrade，只执行apt update。

2. Ubuntu 22.04 安装 Docker 的完整实操步骤

2.1 第一步：更新系统并安装依赖工具

Docker 官方 apt 仓库的添加过程依赖几个基础工具，包括ca-certificates、curl、gnupg等。如果系统里缺了这些，后面添加 GPG 密钥和 apt 源时会出现命令找不到或者证书校验失败的情况。我习惯先把依赖安装到位再继续：

sudo apt update sudo apt install -y ca-certificates curl gnupg lsb-release

ca-certificates保证curl从 Docker 官方下载 GPG 密钥时能正确校验 HTTPS 证书，gnupg用来处理密钥的导入和转换，lsb-release负责识别当前 Ubuntu 的版本代号。如果不装lsb-release，后面用$(lsb_release -cs)动态获取版本代号时就会报错。

这一步我在不同机器上做过很多次，基本都是一次过。但有几个细节值得留意：如果系统里以前装过 Docker 的旧版本，建议先清理干净；apt update如果提示某些源签名失效，那是系统本身原有的源配置问题，不要混在 Docker 安装流程里处理，先修复系统的源再说。否则后续排错时你会分不清报错到底来自哪一部分。

2.2 第二步：添加 Docker 官方 GPG 密钥

我用的是/etc/apt/keyrings目录来存放 Docker 的 GPG 密钥，这个路径也是 Docker 官方文档目前推荐的做法。以前很多老教程直接把密钥输出到某个临时文件，再用apt-key add导入，但apt-key已经被标记为 deprecated，新版本的 Debian/Ubuntu 对这种方式会越来越不友好。把它按规范存放，后续 apt 源配置时用signed-by参数指向它，既清晰又不会污染全局密钥环。

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 a+r /etc/apt/keyrings/docker.gpg

第一条install -m 0755 -d是创建一个权限合适的目录，如果目录已存在，它也不会报错。第二条命令把 Docker 官方 GPG 公钥下载下来，并用gpg --dearmor转换成二进制格式存入指定文件，apt 在后续校验仓库签名时会读取这个文件。第三条chmod a+r确保所有用户都有读权限，这一步不能省，否则非 root 用户执行 apt 操作时可能提示权限问题。

这里有个容易忽略的点：curl -fsSL中的-f表示遇到 HTTP 错误时直接失败，-s是静默模式，-S是显示错误信息，-L是跟随重定向。如果网络环境访问download.docker.com不稳定，这条命令可能直接失败，你需要先解决网络连通性问题，或者暂时换用能正常访问该域名的网络环境，否则后面所有步骤都会连锁报错。

2.3 第三步：添加 docker-ce 软件源

密钥放好之后，就该把 Docker 的 apt 源地址写进系统了。这里我不建议手工编辑 sources.list 文件，更好的做法是在/etc/apt/sources.list.d/目录下新建一个独立文件，方便管理，也方便卸载时干净移除。

echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

这条命令用dpkg --print-architecture动态获取当前系统架构，用lsb_release -cs动态获取版本代号，Ubuntu 22.04 对应的代号是jammy，所以最终生成的源行应该是：

deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu jammy stable

如果你手动写源，把jammy写成别的版本代号，apt 更新时会提示找不到相应的 Release 文件。写完后先执行cat /etc/apt/sources.list.d/docker.list检查一下内容是否正确，再执行sudo apt update，这次更新应该是干净利落地通过的。如果报 GPG 相关错误，参考本文第 4 章的排查方法。

2.4 第四步：安装 docker-ce 全家桶

源配置好之后，安装本身就非常直接了。我推荐一次性把完整组件装齐，不要只装一个docker-ce包：

sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

逐个说明：

• docker-ce：Docker 守护进程本体，提供容器运行的核心能力。
• docker-ce-cli：命令行客户端，也就是你敲docker命令时实际调用的工具。
• containerd.io：容器运行时，负责镜像管理和容器生命周期，Docker 底层依赖它。
• docker-buildx-plugin：BuildKit 构建插件，支持更高效的镜像构建和多平台构建。
• docker-compose-plugin：Docker Compose v2 插件，用来定义和运行多容器应用。

我第一次装的时候只装了docker-ce，结果发现docker compose命令不存在，还得补装插件。后来干脆每次安装都按全家桶来，省得后面又发现缺组件。装完后可以看一下版本确认安装成功：

docker --version

正常会输出类似Docker version 24.0.7, build afdd53b的信息。如果你看到的是docker: command not found，那大概率是docker-ce-cli没装上，重新执行上面的安装命令即可。

2.5 第五步：启动服务与用户权限配置

安装完并不代表服务就自动跑起来了，还需要显式启动 Docker 守护进程并设置开机自启。Ubuntu 22.04 使用 systemd 管理系统服务，所以这一步用 systemctl 完成：

sudo systemctl enable --now docker sudo systemctl status docker

第一条命令把 Docker 服务设为开机自启并立即启动，第二条命令用于确认服务状态。正常情况下status输出会显示active (running)。如果这里显示inactive (dead)或者failed，先不要急着下一步，跳到第 4 章的启动失败排查部分处理。

服务正常后，还有一个非常关键的权限配置。默认情况下，只有 root 用户和 docker 组内的用户才能访问 Docker 守护进程的 socket，普通用户直接执行docker ps会报permission denied。所以我习惯立即把当前用户加入 docker 组：

sudo usermod -aG docker $USER

这里有一个我踩过多次的坑：执行完usermod后，当前终端会话不会立刻生效，必须重新登录或者执行newgrp docker切换一下组身份。如果不重新登录就直接跑docker ps，依然会报权限问题，网上很多人问“为什么我加了用户组还是没权限”，十有八九就是忽略了这一步。

注意：如果你是在 SSH 远程会话里操作，加组之后建议断开重连一次，或者直接新开一个终端。newgrp docker只能让当前 shell 生效，新开终端更干净。

3. 必须第一时间做的两项配置：镜像加速与系统服务自启

3.1 配置镜像加速，避免 pull 镜像卡死

Docker 装好之后，很多人兴冲冲地docker run hello-world或者去拉一个镜像，结果发现速度像蜗牛爬，甚至卡在Waiting状态半天没反应。原因很简单，默认拉取镜像是从 Docker Hub 走的，网络链路对国内环境极不友好。解决办法是配置镜像加速器。

Docker 的守护进程支持通过/etc/docker/daemon.json配置文件来设定镜像源，我推荐在安装后第一时间就把这个文件写好。使用中科大、网易等公共镜像加速地址，或者如果你有云厂商账号，用云厂商提供的专属加速地址效果更稳定。一个常用的配置长这样：

{ "registry-mirrors": [ "https://docker.mirrors.ustc.edu.cn", "https://hub-mirror.c.163.com" ] }

写完后重启 Docker 让配置生效：

sudo systemctl daemon-reload sudo systemctl restart docker

验证配置是否生效，可以用docker info查看输出里的Registry Mirrors字段，能看到你填的加速地址就说明生效了。这里需要说明一点：加速器并不能解决所有镜像的拉取问题，尤其是某些官方镜像体积特别大或者路径特殊，加速器也可能慢。但配置它之后，日常开发中拉取 Ubuntu、Python、Node、MySQL、Redis 这类基础镜像的体感提升是立竿见影的。

如果你在虚拟机里跑 Ubuntu 22.04 并且网络本身就比较紧张，还可以考虑给 Docker 设置 HTTP 代理，但这属于网络环境特定配置，不是通用操作，这里就不展开了。

3.2 开机自启的配置细节与验证方法

前面安装步骤里我用了systemctl enable --now docker，这个命令已经把 Docker 服务设置为开机自启了。但很多教程只写了systemctl start docker，没有写enable，导致每次重启系统后都要手动再启动一次 Docker，非常烦人。所以这里再单独强调一遍，enable和start是两个动作，一个管持久化、一个管立即生效，两个都要做。

如果你想确认 Docker 是否真的设置了开机自启，可以用这个命令查看服务是否被链接到 multi-user.target：

systemctl is-enabled docker

输出enabled就表示开机自启已经生效。如果你之前只执行了systemctl start docker，这里会输出disabled，那就重新执行sudo systemctl enable --now docker补上。

还有一个容易被忽略的细节：如果你的 Ubuntu 22.04 用的是桌面版，开机后 Docker 服务启动时，桌面环境可能还没有完全准备好，但 Docker 服务本身不依赖图形界面，所以这个顺序问题一般不会影响 Docker 的正常运行。我见过有人因为 Docker Desktop 启动失败去折腾桌面环境，其实完全不需要，Docker Engine 和桌面版的 GUI 是两个独立的东西，不装 Docker Desktop 也能正常使用 Docker。

4. 安装过程中最常见的报错与排查方法

4.1 apt 锁冲突：could not get lock 类的报错

如果你在执行sudo apt update或者sudo apt install时看到类似下面的信息：

E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable) E: Unable to acquire the dpkg frontend lock. Is another process using it?

对于 Ubuntu 新手来说，这个报错特别容易让人懵。原因其实很简单：系统里已经有一个 apt 或 dpkg 进程在运行，比如你之前打开的软件更新界面、另一个终端里正在执行的 apt 命令，或者 apt 后台的自动更新任务。

排查思路第一条，别着急暴力删除锁文件。先去查哪个进程占用了 apt：

ps -ef | grep -E "apt|dpkg"

如果看到apt.systemd.daily相关的进程在跑，那大概率是系统在自动检查更新，等它跑完就好。如果你确实有另一个终端在安装软件，去那边把进程结束或者等它完成。只有确定没有任何 apt 进程在运行，才考虑手动清理锁文件：

sudo rm /var/lib/dpkg/lock-frontend sudo rm /var/lib/dpkg/lock sudo rm /var/lib/apt/lists/lock

但这招只能用于锁文件残留，绝不是常规操作。我自己见过不少人一遇到锁报错就删文件，结果把包管理状态搞坏。正确姿势是把“先看进程、再决定是否动手”养成习惯。

4.2 GPG 密钥校验失败：public key not available

添加了 Docker 官方源后，sudo apt update阶段如果在末尾抛出一串 GPG 校验错误，常见的提示包含：

W: GPG error: https://download.docker.com/linux/ubuntu jammy InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY ......

这个问题的根源是 apt 没有找到匹配的 GPG 公钥。要么是你在添加源时没有正确导入密钥，要么是密钥导入的路径和 sources.list 里的signed-by参数不匹配。

解决方法是重新导入并确认路径。我用的 keyrings 方案比较干净，出现这种问题大概率是下面两种场景之一：

场景一，你没有执行 2.2 节的密钥命令，只是手工把源写进去了，那么补上即可：

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 a+r /etc/apt/keyrings/docker.gpg

场景二，源配置文件里的签名路径写错了。检查/etc/apt/sources.list.d/docker.list中的内容，确认signed-by指向的确切路径和实际文件路径一致。很多时候你复制教程时把源行截断或者多打了一个空格，也有可能导致校验失败。改完配置后用sudo apt update验证。

还有一个隐藏坑：如果之前使用过apt-key导入 Docker 旧密钥，系统里可能存在多个 Docker 相关密钥，新旧密钥环互相干扰。遇到这种情况，建议先把/etc/apt/keyrings/docker.gpg和/etc/apt/sources.list.d/docker.list清理干净再重新配置，而不是反复叠加源，越叠越乱。

4.3 源配置不生效或下载超时

有时候源配置看着没问题、密钥也对，但apt update时下载 Docker 源的速度极慢，甚至卡在Waiting状态。这一般是网络链路问题，download.docker.com在特定网络环境下访问不畅。

处理办法有三个层级。第一，确认网络连通性，直接用curl -I https://download.docker.com/linux/ubuntu/dists/jammy/Release看能不能返回 200。如果这一步都不通，那 apt 层面无论如何都白搭。第二，如果网络慢但能通，可以把 Docker 源从默认的 HTTPS 改成镜像站，比如部分高校或云厂商提供了 Docker apt 源镜像，但这类镜像的稳定性和时效性参差不齐，使用前先确认。第三，如果你只是apt update因为某个源卡住，可以尝试在命令前临时设置较长的超时时间：

sudo apt -o Acquire::http::Timeout=60 -o Acquire::https::Timeout=60 update

这个方法能缓解某些临时性网络抖动，但如果网络彻底不通，它也只能多等一会儿。另外，不要忘了检查代理设置。如果你系统里配置了 HTTP 代理，curl和apt读取的代理变量可能不一致，这也是这类问题的常见来源。

4.4 Docker 服务启动失败：active (failed) 状态

安装完 Docker 后，执行sudo systemctl status docker时如果发现服务处于failed状态，此时最重要的不是反复systemctl start docker，而是先把日志拉出来看根因：

sudo journalctl -u docker --no-pager | tail -50

我在实际排查中遇到过几类原因。最常见的是iptables规则冲突。Ubuntu 22.04 部分环境默认使用 nftables，Docker 在启动时需要操作 iptables 规则，如果系统里存在其他防火墙管理工具（比如 ufw）且配置不兼容，Docker 守护进程可能直接退出。临时测试可以通过sudo systemctl stop docker后，在 daemon.json 里临时设置"iptables": false来验证是否与防火墙相关，但这不是长期方案。

另一个常见原因是containerd服务的状态异常，Docker 依赖 containerd 运行，如果 containerd 没有正常启动，Docker 也会跟着失败。所以排查时要一起看：

sudo systemctl status containerd

如果 containerd 没问题，把日志里最后几十行贴出来，基本能看到明确的错误描述。还有一种情况是某些云虚拟机环境里内核缺少必要模块，比如 overlayfs 模块未加载，启动日志里会提示存储驱动问题。碰到这种，先看内核模块加载情况：

lsmod | grep overlay

如果为空，执行sudo modprobe overlay后再尝试启动 Docker。这类排查路径比较长，但核心思路是“看日志、找根因、试最小修复”，千万别在没看日志的情况下把所有服务都 restart 一遍，那样只会掩盖问题。

4.5 权限报错：Cannot connect to the Docker daemon

安装完成、服务也正常运行，但执行docker ps时报下面这个错：

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json": dial unix /var/run/docker.sock: connect: permission denied

这个报错在 Linux 上几乎 80% 的起因都是“当前用户不在 docker 组”。解法就是第 2.5 节讲的sudo usermod -aG docker $USER，然后重新登录。如果重新登录后还是报错，执行id看看当前用户的组信息里有没有docker。如果没有，说明usermod没有正确执行，或者你登录的账户和usermod指定的账户不是同一个。

还有一个小概率的可能：/var/run/docker.sock的属组不是 docker，而是 root。检查一下：

ls -l /var/run/docker.sock

正常输出应该是srw-rw---- 1 root docker ...，如果属组不对，手动执行sudo chgrp docker /var/run/docker.sock。但这个修改在服务重启后可能会被重置，根本上还是要保证 docker 服务从正确的配置启动。

4.6 高频报错速查表

这张速查表是针对安装阶段的，但拉取镜像阶段的大多数问题也能靠它解决。记住一个原则：报错信息里的关键词远比教程里的某一步重要，学会读报错，比背命令更能避免走弯路。

4.7 虚拟机环境下容易忽略的坑

很多我身边的人是在 VMware 或者 VirtualBox 里跑 Ubuntu 22.04 来学习 Docker 的，这个场景有一些特有的坑。首先，虚拟机网络模式如果是 NAT，Docker 拉取镜像时走的是宿主机的网络，如果宿主机网络没问题，一般也不会出太大故障。但如果宿主机本身网络环境受限，虚拟机里的 Docker 源更新就会很痛苦，优先考虑用桥接网络让虚拟机直接获取局域网地址。

其次，虚拟机里开启嵌套虚拟化的问题只影响 Docker Desktop，对 Docker Engine 没有影响，所以不要因为在虚拟机里看到“virtualization support not detected”就以为装不了 Docker Engine，你放心继续装。我在 VMware Workstation 和 VirtualBox 上都实测过 Docker Engine，只要系统内核支持 namespace 和 cgroup，容器就能正常运行。只有当你非要用 Docker Desktop 才需要去折腾宿主机 BIOS 和 VMware 的虚拟化引擎设置。

最后，虚拟机的磁盘分配要留足。Docker 镜像和容器会占用不少空间，默认安装完后，Docker 的数据目录在/var/lib/docker，如果根分区只有 20GB，几个大镜像就会把空间吃光。建议虚拟机磁盘至少 40GB，如果觉得不够可以单独给/var/lib/docker挂一块数据盘，或者直接把 Docker>docker run --rm hello-world

如果一切正常，你会看到一段来自 Docker 的欢迎信息，提示你的安装似乎正确。如果是第一次运行，它会先从仓库拉取镜像；如果你配置了镜像加速，这个过程通常几秒钟就能完成。如果拉取卡住了，先检查镜像加速配置，而不是反复重试。

这里有个细节：执行docker run时如果本地不存在该镜像，Docker 会先 pull 再 run。所以这条命令实际上验证了“拉取镜像”和“运行容器”两个能力。如果你的网络环境无法连接外部仓库，可以在本地先导入一个已有的镜像文件，或者直接跳过 hello-world，用docker version来检查客户端的服务端连通性。docker version会输出 Client 和 Server 两段信息，如果 Server 段能正常显示版本、操作系统、内核等，说明守护进程接口正常，即便暂时拉不了镜像也不代表安装失败。

5.2 拉取镜像慢的优化手段整理

镜像加速器只能解决一部分问题，实践中我还发现几个能让拉取体验更好的细节。

第一，尽量使用带-t参数指定完整镜像标签，比如python:3.12-slim而不是python:latest。显式指定标签不仅可复现性更好，镜像体积通常也更小，拉取速度更快。第二，对于体积大的镜像，可以改用docker pull分步拉取，不要直接docker run让它隐式拉取，这样能在网络中断时更快重试。第三，某些场景下可以通过docker save和docker load在有网络的机器上导出镜像，再拷贝到离线环境导入，这比让离线机硬拉镜像可靠得多。

如果你经常构建镜像，BuildKit 能提供更好的多阶段构建和缓存管理。安装时我已经装了docker-buildx-plugin，所以直接用docker buildx build就能启用。还可以设置环境变量DOCKER_BUILDKIT=1来强制使用 BuildKit 的构建路径，但现代 Docker 版本默认已经启用了，这个环境变量更多是保险。

5.3 Docker Compose 的配套安装说明与确认

很多人习惯单独使用docker-compose这个命令，但是注意，我们安装的docker-compose-plugin提供的是新版本命令docker compose（中间没有横杠）。Ubuntu 22.04 系统源里虽然有docker-compose这个包（老版 Python 实现），但官方推荐的是 Compose v2 插件。执行以下命令确认：

docker compose version

输出类似Docker Compose version v2.21.0就说明插件工作正常。如果你习惯了老命令，可以建一个 alias，但尽量不要在老版本 docker-compose 上依赖太久，新版本的docker compose与 Docker Engine 集成更紧密，启动多容器时性能更好，配置解析也更严格。后续使用docker-compose.yml文件时，只要文件里语法符合规范，直接docker compose up -d就能拉起来。别再花时间单独去折腾安装老版 docker-compose 了，除非你维护的是老项目、必须兼容旧命令。

5.4 日志、卸载与清理的常规操作

安装之后，如果你发现版本有问题或想彻底重装，卸载要干净。下面是一套完整的清理命令，按顺序执行即可：

sudo systemctl stop docker sudo apt purge -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin sudo rm -rf /var/lib/docker sudo rm -rf /etc/docker sudo rm /etc/apt/sources.list.d/docker.list sudo rm /etc/apt/keyrings/docker.gpg

apt purge会移除软件包但保留配置，所以/etc/docker里的 daemon.json 和/var/lib/docker里的所有镜像数据都要手动清理。如果你打算重新装一遍并希望保留镜像数据，可以跳过rm -rf /var/lib/docker，但这种情况不多见，环境不对就用docker system prune先清理无用镜像更安全。

日常使用中，我习惯给 Docker 配置日志轮转。容器产生的日志会无限增长，不处理会撑爆磁盘。在 daemon.json 里加上：

{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }

这样单个容器日志超过 10MB 就会轮转，并且只保留三个文件，在生产环境里很有用。但这不属于安装阶段的硬性要求，属于锦上添花的优化项。

6. 几个实际验证过的经验总结

整个安装流程走下来，我自己在反复重装和排错中总结出几条习惯，分享给大家参考。

第一条，把“重新登录”当作权限配置的一部分，别忽略。usermod加到 docker 组后如果不重新登录，权限报错会一直存在，而且很多人会误以为是 Docker 服务挂了，浪费大量时间去重启服务。我在帮朋友排查时，发现他卡在权限报错上整整一下午，就是因为没有重新登录，这个问题真的值得反复强调。

第二条，报错时先看日志，别猜。不论服务启动失败还是 apt 更新失败，系统都给了足够多的线索。journalctl -u docker和apt update的完整输出远比网上搜索来的结果更有针对性。网上教程能帮你建立方向感，但真正定位问题要靠自己的系统信息。

第三条，如果你在 Ubuntu 22.04 上做开发，建议把 Docker Engine 的配置放在安装当天就做完整，包括镜像加速、日志轮转、用户组权限、开机自启。一次性做完这些，后续使用体验会顺畅很多。很多人装完基础包就觉得完事，结果第二天 pull 镜像慢得想砸键盘，才又翻回来折腾配置，反而更浪费时间。

最后再多说一个细节：重启系统后 Docker 服务如果没有自动启动，优先检查systemctl is-enabled docker。虚拟机环境里偶尔会出现服务 enable 了但实际没生效的奇怪问题，重新执行一次enable就好。这个操作不复杂，但能避免重启后的措手不及。有了一个稳定运行、服务自启、镜像加速到位的 Docker 环境，后面跑容器、写 Dockerfile、搭 MySQL、Redis、开发环境，都会轻松很多。