Docker-ce安装全攻略：在线与离线部署详解及生产环境避坑指南

1. 为什么Docker-ce的安装方式值得单独拎出来讲？

如果你刚开始接触容器技术，可能会觉得“安装一个软件”有什么好讲的，照着官方文档敲命令不就行了？我最初也是这么想的，直到我在内网服务器、没有稳定外网的生产环境，甚至是在一些定制化的Linux发行版上反复碰壁之后，才意识到Docker-ce的安装远不是一句apt-get install docker.io那么简单。Docker-ce，作为Docker社区版，是大多数人学习和生产使用的起点，但它的安装过程恰恰是第一个“筛选器”，区分了“能跑起来”和“能稳定、合规地用起来”。

网上教程千千万，但很多都只告诉你“在线安装”这一条路，仿佛全世界服务器都畅通无阻地连着Docker的官方仓库。现实是，金融、军工、政企等对安全有严格要求的场景，服务器往往是纯离线的；一些云主机虽然能出公网，但可能因为网络策略或镜像源速度问题，让你卡在apt-get update这一步半天不动。更头疼的是，不同Linux发行版（Ubuntu, CentOS, Debian等）的包管理器和依赖库天差地别，一个在Ubuntu上好用的脚本，放到CentOS上可能直接报错。

所以，这篇内容我会把“在线”和“离线”这两种核心场景拆开揉碎了讲，不仅告诉你命令是什么，更会解释每个命令背后的意图、不同发行版的差异，以及我在各种环境下趟过的坑。比如，为什么官方推荐用仓库安装而不是直接下deb/rpm包？离线安装时，如何确定庞杂的依赖关系？安装完成后，哪些配置是必须马上改的？这些才是从安装环节就奠定稳定性的关键。

2. 在线安装：不只是“一键脚本”那么简单

在线安装是最常见的方式，前提是你的服务器能够访问互联网。但“在线”不等于无脑执行，其中的版本选择、源配置、后续配置都藏着细节。

2.1 环境准备与发行版确认

动手之前，先搞清楚自己的战场。执行cat /etc/os-release查看系统发行版和版本号。这一步至关重要，因为Docker为不同的发行版（如Ubuntu、Debian、CentOS、RHEL、Fedora）提供了不同的安装仓库和依赖包。

一个常见的误区是直接使用网上搜到的、针对特定版本（如Ubuntu 20.04）的安装命令，而不做任何修改就用到自己的系统上，这很可能因为版本不匹配导致依赖解析失败。我的习惯是，无论用什么教程，第一个命令永远是确认系统版本。

2.2 卸载旧版本与清理环境

这不是可选项，而是必选项。如果你的系统里存在旧版本的Docker（可能是docker、docker-engine或docker.io），它们会与新版本产生冲突，导致无法预测的错误。

对于基于APT的系统（如Ubuntu, Debian）：

sudo apt-get remove docker docker-engine docker.io containerd runc

注意，这个命令可能提示某些包未安装，这是正常的。关键在于containerd和runc，它们是Docker的核心依赖，如果系统存在旧版本，一定要清理。

对于基于YUM的系统（如CentOS, RHEL, Fedora）：

sudo yum remove docker \ docker-client \ docker-client-latest \ docker-common \ docker-latest \ docker-latest-logrotate \ docker-logrotate \ docker-engine

你会发现CentOS系列的包名更加细分，卸载也更彻底。执行后，不要以为就结束了。残留的配置文件和数据目录（如/var/lib/docker/）有时也会引发问题。对于全新的安装，我建议在卸载后顺带清理一下：

sudo rm -rf /var/lib/docker sudo rm -rf /var/lib/containerd

注意：/var/lib/docker是Docker默认的镜像、容器存储目录。如果这是生产环境，并且你希望保留已有的镜像和容器数据，请务必不要执行这条删除命令！或者，在删除前先做好备份。

2.3 配置官方仓库：为什么比直接用系统包好？

很多Linux发行版自带的仓库里也有Docker包（如Ubuntu的docker.io），但版本往往非常陈旧。使用Docker官方维护的仓库，能确保你获得最新的稳定版，并且更新路径一致。

Ubuntu/Debian 系配置：

1. 安装基础工具：sudo apt-get update和sudo apt-get install ca-certificates curl gnupg是必须的，用于处理HTTPS和软件源签名。
2. 添加Docker的官方GPG密钥：这个密钥用于验证从Docker仓库下载的软件包的完整性，防止被篡改。

   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

   这里有个细节：gpg --dearmor命令是将ASCII格式的GPG密钥转换为二进制格式，这是apt源所要求的。
3. 设置稳定版仓库：

   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

   这个命令看起来很复杂，其实是在动态构造源地址。$(dpkg --print-architecture)会自动获取系统架构（如amd64, arm64），$(. /etc/os-release && echo "$VERSION_CODENAME")会自动获取系统版本的代号（如jammy for Ubuntu 22.04）。这样做的好处是通用性强，无需手动修改。

CentOS/RHEL 系配置：

1. 安装yum-utils：它提供了yum-config-manager工具，方便管理仓库。

   sudo yum install -y yum-utils

2. 添加Docker官方仓库：

   sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

   这条命令会在/etc/yum.repos.d/目录下生成一个docker-ce.repo文件。这里有个坑：如果你用的是RHEL或Rocky Linux/AlmaLinux，这个命令添加的仍然是centos的仓库地址，但Docker官方仓库通常是兼容的。如果遇到问题，可能需要手动下载对应发行版的.repo文件。

2.4 安装与验证：安装完就万事大吉了？

配置好仓库后，安装就简单了。

对于APT系统：sudo apt-get update && sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin对于YUM系统：sudo yum install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

这里注意，我们不仅安装了docker-ce（守护进程和客户端），还安装了docker-ce-cli（命令行工具）、containerd.io（容器运行时）以及两个插件。docker-buildx-plugin用于多架构镜像构建，docker-compose-plugin是原docker-compose的集成版，现在推荐通过插件方式安装。

安装完成后，千万不要急着启动。先做两件事：

1. 启动Docker服务并设置开机自启：

   sudo systemctl start docker sudo systemctl enable docker

2. 运行一个测试容器：

   sudo docker run hello-world

   这个命令会从Docker Hub拉取一个极小的测试镜像并运行。如果能看到“Hello from Docker!”等欢迎信息，说明Docker引擎、网络、镜像拉取功能全部正常。这是验证安装是否成功的黄金标准。

3. 离线安装：应对内网与无外网环境的完整方案

离线安装才是真正考验功底的地方。你需要把所有依赖从一台能上网的机器“搬运”到目标服务器上。核心思路是：在联网机器上下载所有需要的软件包（包括依赖），然后复制到离线机器上进行安装。

3.1 在联网机器上准备离线包

我们以CentOS 7/RHEL 7为例，因为其在企业内网中非常常见。使用yum的downloadonly插件可以只下载不安装。

1. 在联网机器上安装downloadonly插件（如果未安装）：

   sudo yum install -y yum-plugin-downloadonly

2. 创建用于存放离线包的目录：

   mkdir -p ~/docker-offline cd ~/docker-offline

3. 下载Docker-ce及其所有依赖包：

   sudo yum install --downloadonly --downloaddir=./ docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

   执行后，当前目录下会出现一堆.rpm文件。这里有个关键点：--downloadonly参数必须配合--downloaddir指定目录，否则包会下载到默认的缓存目录，不好整理。

对于Ubuntu/Debian系统，过程类似，但工具不同，需要使用apt-get download和dpkg来递归获取依赖。这个过程更复杂一些，通常需要借助apt-rdepends这类工具来列出所有依赖，然后手动下载。一个相对省事的办法是，在一台干净的、同版本系统的联网机器上直接安装Docker-ce，然后从APT缓存目录（/var/cache/apt/archives/）中把所有的.deb包拷贝出来。

3.2 传输与离线安装

将打包好的整个目录（例如docker-offline）通过U盘、内网共享或任何可行的方式，复制到目标离线服务器的某个路径下，比如/tmp/docker-offline/。

在CentOS/RHEL离线服务器上：

1. 进入包目录：cd /tmp/docker-offline
2. 使用rpm命令本地安装。切记不要直接用rpm -ivh *.rpm，因为包之间有依赖顺序，可能会报错。正确的做法是使用yum localinstall，它会自动解决本地包的依赖关系：

   sudo yum localinstall ./*.rpm

   yum localinstall会读取当前目录下的所有rpm包，并计算安装顺序，比手动安装可靠得多。

在Ubuntu/Debian离线服务器上：

1. 进入包目录：cd /tmp/docker-offline
2. 使用dpkg批量安装：

   sudo dpkg -i ./*.deb

   这条命令可能会因为依赖问题而报错，提示缺少某些包。这是dpkg的常态。我们需要接着运行：

   sudo apt-get install -f

   这个-f参数是--fix-broken的缩写，它会尝试修复因为依赖关系而中断的安装。但是，在离线环境下，apt-get install -f会失败，因为它需要联网去下载缺失的依赖。这就是为什么Ubuntu离线安装更麻烦——你必须确保docker-offline目录里包含了所有依赖包，一个都不能少。通常需要在上一步的下载环节做更精细的依赖分析。

3.3 离线安装后的关键配置

离线环境下，安装完成只是第一步。由于无法访问Docker Hub，你需要配置一个内部的私有镜像仓库，或者修改Docker引擎的配置，使其能使用离线的镜像归档文件。

1. 启动并设置开机自启（与在线安装相同）：

   sudo systemctl start docker sudo systemctl enable docker

2. 配置镜像加速器或私有仓库（关键）：编辑Docker守护进程配置文件/etc/docker/daemon.json（如果不存在则创建）：

   { “registry-mirrors”: [“https://your-private-registry.com”], “insecure-registries”: [“your-private-registry.com:5000”] }

   对于纯离线环境，registry-mirrors可能用不上，重点是insecure-registries，如果你用的是没有HTTPS证书的内网私有仓库，需要在这里声明。配置完成后，重启Docker生效：sudo systemctl restart docker。
3. 加载离线镜像：如果你有事先导出的镜像文件（如myimage.tar），可以使用docker load命令导入：

   sudo docker load -i myimage.tar

   然后使用docker images查看导入的镜像。

4. 安装后的必须操作与避坑指南

很多人安装完Docker，跑通hello-world就觉得结束了。其实，以下几个配置关乎安全性和日常使用的便利性，是生产环境部署前必须考虑的。

4.1 免sudo执行docker命令

默认情况下，Docker守护进程以root用户运行，而docker命令需要Unix socket通信，该socket文件属于root:docker用户组。将当前用户加入docker组，即可免sudo执行。

sudo usermod -aG docker $USER

执行后，必须彻底退出当前终端会话（关闭所有窗口或断开SSH连接），然后重新登录，用户组变更才会生效。这是一个高频踩坑点，很多人加了组后直接在当前终端测试，发现依然要sudo，误以为命令没生效。

验证：重新登录后，执行docker ps，如果不报权限错误，说明成功。

重要安全提示：docker组的用户权限等同于root，因为可以通过挂载宿主机目录等方式获得宿主机的高权限。因此，仅将受信任的用户加入此组。在生产环境中，应结合审计日志等手段进行监控。

4.2 修改默认数据目录与存储驱动

Docker默认将所有数据（镜像、容器、卷、网络配置）存放在/var/lib/docker。如果根分区空间不足，或者你想使用性能更好的SSD，就需要迁移这个目录。

1. 停止Docker服务：sudo systemctl stop docker
2. 迁移数据（如果已有数据）：sudo rsync -avz /var/lib/docker/ /new/path/docker/
3. 修改配置文件：编辑/etc/docker/daemon.json，添加：

   { “data-root”: “/new/path/docker” }

4. 启动Docker：sudo systemctl start docker

另一个高级配置是存储驱动。对于较新的Linux发行版（内核4.x以上，文件系统如ext4, xfs），默认的overlay2驱动是最佳选择，通常无需更改。只有在使用老版本系统（如CentOS 6）或特殊文件系统（如aufs, btrfs）时，才需要考虑修改storage-driver配置项。

4.3 配置日志与资源限制

Docker容器默认的日志驱动是json-file，日志会一直累积，可能撑爆磁盘。我们需要配置日志轮转。

同样在/etc/docker/daemon.json中配置：

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

这表示每个容器日志文件最大10MB，最多保留3个文件（即总共最多30MB日志）。超过后，旧日志会被自动删除。

对于资源限制，虽然可以在运行容器时通过-m,--cpus等参数指定，但在/etc/docker/daemon.json中也可以设置默认的cgroup驱动（如systemd）等全局参数，这在与Kubernetes（k8s）集成时尤为重要。

4.4 常见安装故障排查

• 问题：在CentOS 7上安装时，提示与container-selinux冲突。

  • 原因：旧版本或未安装的container-selinux包与Docker-ce的依赖不匹配。
  • 解决：先尝试安装或更新此包：sudo yum install -y container-selinux。如果官方源版本太低，可以从CentOS Extras仓库或EPEL仓库获取更新版本。

• 问题：启动Docker服务失败，systemctl status docker显示Failed to start Docker Application Container Engine。

  • 排查：查看详细日志：sudo journalctl -xe -u docker。常见原因包括：
    1. daemon.json配置文件格式错误（JSON格式要求严格，最后一个条目后不能有逗号）。
    2. 防火墙或SELinux阻止。可尝试临时关闭SELinux（setenforce 0）和防火墙（systemctl stop firewalld）进行测试。生产环境应配置正确的规则而非直接关闭。
    3. 与已有容器运行时（如Podman）冲突。

• 问题：离线安装Ubuntu/Debian包时，dpkg -i报大量依赖错误，apt-get install -f无法运行。

  • 原因：离线包依赖不完整。
  • 解决：这是最棘手的情况。唯一可靠的办法是回到联网机器，使用更精确的方法下载所有依赖。可以尝试用gdebi工具（需先离线安装它本身）来安装主包，它会提示更清晰的缺失依赖，但最终仍需备齐所有包。因此，准备Ubuntu离线包时，建议使用与目标系统版本完全一致的干净虚拟机进行操作。

安装Docker-ce就像盖房子的地基，在线安装提供了便捷，而离线安装则考验着你对系统依赖和部署流程的理解。把每一步的原理和备选方案都想清楚，尤其是在面对内网、隔离环境时，这份前期工作的扎实程度，直接决定了后续开发和运维的顺畅度。我个人的经验是，对于生产环境，即使是在线安装，也最好先在测试环境用完全相同的系统版本演练一遍离线安装流程，这能让你对整套依赖体系有更深的掌控感，真到了紧急时刻才不会抓瞎。