1. 为什么是Docker 20.10.24一个被低估的稳定版本选择如果你最近在服务器或者开发机上折腾Docker可能会发现一个有趣的现象无论是官方文档还是社区教程推荐安装的版本大多是“最新稳定版”。但当你真正点开Docker Engine的发布页面面对从20.10.0到25.0.x的几十个版本号时选择困难症就犯了。今天我们不聊最新版也不聊最老的版本而是聚焦一个在特定时期扮演了“承上启下”关键角色的版本——Docker 20.10.24。这个版本发布于2023年5月是Docker 20.10.x LTS长期支持分支的最后一个补丁版本。你可能想问现在都Docker 25.0了为什么还要回头去装一个“旧”版本原因很简单稳定压倒一切。对于生产环境、CI/CD流水线或者任何你希望“一次部署长期运行”的场景一个经过长时间社区验证、Bug修复完备的LTS终结版本往往比追逐前沿的新版本更可靠。20.10.24集成了20.10 LTS系列近三年的所有安全补丁和关键修复避开了早期版本的一些已知坑同时又没有引入25.0.x系列可能存在的、尚未被广泛发现的兼容性问题。它就像一个经验丰富的老兵知道战场上所有的陷阱。对于个人开发者或学习者从20.10.24入手也是一个明智的选择。它的API和命令行与后续版本保持了高度兼容你在此版本上学到的绝大多数知识镜像构建、容器管理、网络配置都能无缝迁移到新版本。更重要的是围绕20.10.24的解决方案和排错经验在互联网上最为丰富当你遇到“docker权限错误怎么解决”、“docker desktop failed to start”这类经典问题时搜到的答案大概率是基于这个版本或相近版本试错成本更低。所以无论你是要在CentOS 7上部署一个坚如磐石的服务还是在Ubuntu上搭建学习环境选择Docker 20.10.24都是一个兼顾稳定性、学习曲线和社区支持的务实决策。接下来我们就抛开图形化的Docker Desktop深入到命令行层面从零开始完成一次干净、可控的Docker Engine 20.10.24安装。2. 安装前的深度准备避开90%的失败源头很多安装教程会直接让你执行curl -fsSL https://get.docker.com | sh这确实是最快的方式但也是最“黑盒”的方式。它自动安装了最新版本你对自己的系统做了什么改变一无所知。要精细控制版本为20.10.24并且确保一次成功我们必须先做好充分的准备工作。这一步做得好能帮你避开后续绝大部分的权限错误、启动失败和内核兼容性问题。2.1 系统环境与内核兼容性检查Docker Engine的运行严重依赖Linux内核的特性。首先确认你的操作系统。虽然Windows可以通过WSL2安装DockermacOS有Docker Desktop但今天我们聚焦于Linux原生环境这也是生产环境的主流选择。主流的发行版如Ubuntu 20.04/22.04 LTS、CentOS 7/8、Debian等都是完全支持的。打开终端第一件事是检查内核版本和关键模块uname -r你需要确保内核版本在3.10以上对于CentOS 7或4.x以上对于Ubuntu/Debian。现代发行版通常都满足。接下来检查两个至关重要的内核模块是否已启用overlay2存储驱动和iptables防火墙框架。lsmod | grep overlay lsmod | grep iptable如果overlay模块没有显示可能需要手动加载或确认内核支持。overlay2是Docker推荐且默认的存储驱动性能比旧的devicemapper好得多。然后检查cgroups控制组的支持。Docker使用cgroups来限制和隔离容器的资源。检查/proc/cgroups文件或使用grep cgroup /proc/filesystems。只要你的系统不是极度老旧这一般都没问题。注意如果你在虚拟机或云服务器上操作并且后续遇到了“virtualisation support not detected”或“failed to start because virtualisation support wasn’t detected”这类错误问题通常不在Docker本身而在于你的虚拟化环境。对于VMware/VirtualBox虚拟机请确保在虚拟机设置中开启了CPU的虚拟化支持Intel VT-x/AMD-V。对于某些云服务器尤其是KVM虚拟化的默认就支持无需额外操作。这个错误常见于Windows上的Docker Desktop在纯Linux环境下安装Docker Engine时较少出现但了解其根源有助于全面排错。2.2 彻底清理旧版本与冲突组件这是避免各种灵异错误的关键一步。如果你的系统上曾经安装过任何Docker相关软件可能是旧版的docker、docker-engine、docker.io或者是podman、containerd的冲突版本必须彻底清除。执行以下清理命令适用于基于APT的系统如Ubuntu/Debiansudo apt-get remove docker docker-engine docker.io containerd runc对于基于YUM的系统如CentOS/RHELsudo yum remove docker \ docker-client \ docker-client-latest \ docker-common \ docker-latest \ docker-latest-logrotate \ docker-logrotate \ docker-engine \ podman \ runc移除后相关的镜像、容器、卷和网络配置文件默认会保留在/var/lib/docker/。如果你确定不需要可以手动删除这个目录sudo rm -rf /var/lib/docker但这会永久删除所有Docker数据请谨慎操作。2.3 配置软件源锁定20.10.24版本的核心这是实现安装特定版本20.10.24的核心步骤。我们将使用Docker官方提供的APT或YUM仓库而不是发行版自带的软件源因为官方源版本更新且能明确指定版本号。对于Ubuntu/Debian更新包索引并安装依赖sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg lsb-release添加Docker官方GPG密钥用于验证软件包签名sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg设置稳定版stable仓库。注意这里我们添加的是stable仓库它包含了所有的LTS版本。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对于Debian将URL中的ubuntu替换为debian。对于CentOS/RHEL安装yum-utils包它提供了yum-config-manager工具。sudo yum install -y yum-utils添加Docker官方仓库sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo如果你的系统是RHEL可能需要根据实际情况调整repo文件中的baseurl。完成仓库添加后务必再次更新一次本地软件包缓存Ubuntu/Debian:sudo apt-get updateCentOS/RHEL:sudo yum makecache现在你的系统已经准备好了从官方源安装指定版本的Docker。所有前置的清理和配置工作都是为了确保安装过程纯净、可追溯从源头上减少“docker安装失败”这类问题的发生概率。3. 分步安装与验证从软件包到运行服务准备工作就绪后安装过程本身反而变得直截了当。我们将明确指定版本号20.10.24确保安装的正是我们想要的版本。3.1 执行安装命令在Ubuntu/Debian上首先查看可用的Docker版本确认20.10.24存在apt-cache madison docker-ce | grep 20.10你会看到类似docker-ce | 20.10.24~3-0~ubuntu-focal | https://download.docker.com/linux/ubuntu focal/stable amd64 Packages的输出。注意完整的版本字符串如20.10.24~3-0~ubuntu-focal安装时需要用它。然后执行安装sudo apt-get install -y docker-ce20.10.24~3-0~ubuntu-focal docker-ce-cli20.10.24~3-0~ubuntu-focal containerd.io docker-buildx-plugin docker-compose-plugin请务必将focal替换为你实际系统的代号如Jammy对应Ubuntu 22.04。安装多个相关插件docker-buildx-plugin,docker-compose-plugin是为了获得完整的现代Docker开箱体验。在CentOS/RHEL上同样先查看版本列表yum list docker-ce --showduplicates | sort -r | grep 20.10然后安装指定版本版本号格式可能略有不同sudo yum install -y docker-ce-20.10.24 docker-ce-cli-20.10.24 containerd.io docker-buildx-plugin docker-compose-plugin实操心得在yum install命令中docker-ce-20.10.24这样的写法yum会自动匹配以该字符串开头的最高版本通常就能准确安装到20.10.24这个特定版本。如果系统提示找不到可以尝试使用yum list显示出的完整版本字符串。3.2 启动Docker服务并设置开机自启安装完成后Docker服务dockerd守护进程并不会自动启动。我们需要手动启动它并设置为开机启动这样服务器重启后Docker服务会自动恢复。# 启动Docker服务 sudo systemctl start docker # 设置Docker服务开机自启 sudo systemctl enable docker # 检查Docker服务状态确认其处于活跃active运行状态 sudo systemctl status docker运行status命令后你应该看到绿色的active (running)字样。如果状态不是active或者有红色的错误信息就需要根据错误日志进行排查。常见的首次启动问题可能与前面提到的内核模块、cgroups或存储驱动有关。3.3 验证安装与运行基础容器服务运行起来只是第一步我们还需要验证Docker CLI能够正常与守护进程通信并且能够执行最基本的容器操作。运行经典测试命令sudo docker run hello-world这个命令会从Docker Hub拉取一个极小的测试镜像hello-world:latest并在容器内运行它。如果一切正常你将在终端看到一段欢迎信息最后以Hello from Docker!结尾。这个过程验证了Docker守护进程在正常运行。网络通畅可以访问Docker Hub镜像仓库。具备拉取镜像和创建运行容器的完整能力。检查安装版本docker --version输出应为Docker version 20.10.24, build ...这确认了我们安装的确实是目标版本。运行一个更实用的交互式容器可选但推荐sudo docker run -it --rm ubuntu:20.04 bash这个命令会拉取Ubuntu 20.04镜像启动一个容器并进入其bash shell-it参数。--rm参数表示退出容器后自动删除它避免留下无用的容器。在容器内你可以执行cat /etc/os-release查看系统信息然后输入exit退出。这个测试验证了Docker运行完整操作系统容器的能力。至此Docker Engine 20.10.24已经成功安装并验证。但为了让日常使用更高效、更安全我们还需要进行一些关键的优化配置。4. 安装后的关键配置让Docker更好用刚安装好的Docker处于“默认”状态直接使用可能会遇到拉取镜像慢、需要频繁使用sudo、日志文件膨胀等问题。下面几个配置能极大提升使用体验。4.1 配置国内镜像加速器从Docker Hub拉取镜像在国内网络环境下速度可能很不理想。通过配置镜像加速器可以将镜像拉取请求代理到国内的镜像站点速度会有质的提升。编辑Docker守护进程的配置文件。对于Linux系统通常是/etc/docker/daemon.json。如果文件不存在就新建一个。sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [ https://docker.mirrors.ustc.edu.cn, https://hub-mirror.c.163.com, https://mirror.baidubce.com ] } EOF这里我添加了中国科技大学、网易和百度的镜像源。你可以选择一个延迟最低的或者全部保留Docker会按顺序尝试。重新加载配置并重启Docker服务使更改生效sudo systemctl daemon-reload sudo systemctl restart docker验证加速器是否生效docker info在输出信息中查找Registry Mirrors部分你应该能看到刚才配置的镜像地址。注意事项不同的镜像加速器同步Docker Hub的频率不同有时可能会遇到某个镜像在加速器上找不到返回404的情况。如果拉取镜像失败可以尝试临时注释掉daemon.json中的registry-mirrors配置重启Docker后直接从Docker Hub拉取或者换一个镜像源试试。4.2 免sudo执行Docker命令管理用户组默认情况下只有root用户和docker组的用户才能直接与Docker守护进程通信即运行docker命令。每次命令前都加sudo既麻烦又不安全相当于赋予了普通用户root权限。更安全的做法是将当前用户加入docker组。# 将当前登录用户加入docker组。请将your-username替换为你的实际用户名。 sudo usermod -aG docker $USER重要执行此命令后必须完全注销当前会话然后重新登录或者打开一个新的终端窗口用户组的更改才会生效。之后你就可以直接运行docker ps、docker run等命令而无需前缀sudo了。验证是否生效# 重新登录后运行以下命令不应再要求输入密码 docker ps如果仍然提示权限拒绝可以检查用户是否在docker组内groups $USER查看输出中是否包含docker。4.3 配置日志驱动与存储限制可选但重要Docker容器的日志默认会无限制地增长如果某个容器异常疯狂输出日志可能会在短时间内塞满你的磁盘空间/var分区。在生产环境中对日志进行轮转和限制是必须的。我们可以通过修改/etc/docker/daemon.json来配置默认的日志驱动和选项。在上一步的配置文件基础上追加内容sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [ https://docker.mirrors.ustc.edu.cn, https://hub-mirror.c.163.com, https://mirror.baidubce.com ], log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } } EOFlog-driver: json-file: 使用JSON文件作为日志驱动这是最常用且兼容性最好的方式。max-size: 10m: 每个日志文件的最大大小为10MB。max-file: 3: 最多保留3个日志文件例如container.log,container.log.1,container.log.2。当第一个文件写满10MB后会轮转成.1新建一个container.log继续写依此类推只保留最新的3个。修改后同样需要重启Docker服务sudo systemctl daemon-reload sudo systemctl restart docker这个配置是全局的对所有新创建的容器生效。对于已经运行的容器需要重建才能应用新的日志策略。5. 基础命令实战与排错思路安装和配置完成后我们来演练几个最核心的docker命令并模拟一个常见的“权限错误”场景展示完整的排查思路。这比单纯罗列命令更有价值。5.1 你必须熟悉的五个核心命令docker ps: 列出正在运行的容器。加上-a参数可以查看所有容器包括已停止的。这是你使用频率最高的命令之一用于快速了解当前容器的状态。docker images: 列出本地已下载的镜像。配合docker rmi 镜像ID可以删除不再需要的镜像释放磁盘空间。docker run: 从镜像创建并启动一个新容器。它有大量参数最常用的组合是-d后台运行、-p端口映射如-p 8080:80、-v卷挂载持久化数据、--name给容器命名。# 示例后台运行一个Nginx容器将宿主机的8080端口映射到容器的80端口 docker run -d -p 8080:80 --name my-nginx nginx:alpinedocker exec -it 容器名 命令: 在正在运行的容器内执行命令。-it通常组合使用提供一个交互式终端。这对于调试容器内部状态至关重要。# 示例进入上面创建的my-nginx容器的bash shell docker exec -it my-nginx /bin/shdocker logs 容器名: 查看容器的日志输出。加上-f参数可以实时跟踪日志类似tail -f。当容器运行不符合预期时这是第一个要检查的地方。5.2 模拟排错解决“Got permission denied”错误假设你没有执行“免sudo配置”4.2节或者配置后未重新登录直接运行docker ps你很可能会遇到如下错误Got 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这是一个经典的Docker权限错误。别慌我们按照一个清晰的排查链路来走第一步确认Docker服务状态sudo systemctl status docker如果服务是inactive (dead)那就不是权限问题而是服务没启动。用sudo systemctl start docker启动它。第二步检查docker.sock文件权限如果服务是active (running)问题大概率出在/var/run/docker.sock这个Unix套接字文件上。这个文件是Docker守护进程对外提供API的接口。ls -l /var/run/docker.sock你会看到类似这样的输出srw-rw---- 1 root docker 0 Apr 10 10:00 /var/run/docker.sock关键信息是文件所有者是root所属用户组是docker权限是660即所有者root可读可写docker组成员可读可写其他用户无权限。第三步确认当前用户身份whoami groupswhoami告诉你当前用户名groups告诉你当前用户属于哪些组。如果groups的输出里没有docker那么你自然没有权限访问docker.sock。第四步实施解决方案根据第二步和第三步的分析解决方案很明确将当前用户加入docker组。sudo usermod -aG docker $(whoami)然后必须重新登录退出SSH会话再重连或新开一个终端。这是很多新手忽略的关键步骤因为用户组信息是在登录时加载的。第五步验证解决重新登录后再次运行docker ps应该能正常列出容器即使为空列表而不再报权限错误。这个排查过程体现了Linux系统下“权限问题”的标准解决思路检查服务状态 - 检查关键资源权限 - 检查用户身份 - 修正身份或权限 - 验证。掌握了这个思路你就能应对大部分类似的“Permission denied”问题。6. 进阶一步使用Docker Compose编排多容器应用单容器操作满足了基本需求但现实中的应用往往由多个容器组成例如一个Web应用需要数据库、缓存、应用服务器。手动用docker run启动每一个容器并管理它们之间的网络连接非常繁琐。这时Docker Compose就成了必需品。我们在安装时已经通过docker-compose-plugin安装了Compose的V2版本命令是docker compose注意中间没有横线。6.1 编写你的第一个docker-compose.yml让我们用一个最经典的组合来演示WordPress博客需要PHP应用容器和MySQL数据库容器。在你的项目目录下创建一个docker-compose.yml文件version: 3.8 # 指定Compose文件格式版本 services: db: image: mysql:8.0 # 设置环境变量用于初始化数据库 environment: MYSQL_ROOT_PASSWORD: somewordpress MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress # 将数据库数据持久化到宿主机的./db_data目录避免容器删除后数据丢失 volumes: - ./db_data:/var/lib/mysql # 设置容器重启策略除非手动停止否则总是重启 restart: unless-stopped wordpress: depends_on: - db # 指明依赖关系Compose会先启动db服务 image: wordpress:latest # 将容器的80端口映射到宿主机的8080端口 ports: - 8080:80 environment: WORDPRESS_DB_HOST: db:3306 # 注意这里用的是服务名dbCompose会提供内部DNS解析 WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: wordpress WORDPRESS_DB_NAME: wordpress volumes: - ./wp_content:/var/www/html/wp-content # 持久化WordPress的主题和插件 restart: unless-stopped这个配置文件定义了两个“服务”servicesdb和wordpress。它清晰地声明了镜像、环境变量、端口映射、数据卷和依赖关系。depends_on确保了数据库容器先于WordPress容器启动。6.2 启动、管理与停止Compose项目在包含docker-compose.yml文件的目录下执行以下命令启动所有服务后台模式docker compose up -d-d代表“detached”让服务在后台运行。Compose会自动拉取镜像如果本地没有创建独立的网络然后按依赖顺序启动容器。你会看到容器名被自动命名为目录名_服务名_序号。查看运行状态docker compose ps这个命令只显示当前目录下Compose项目管理的容器比docker ps更聚焦。查看服务日志# 查看所有服务的合并日志 docker compose logs # 实时跟踪日志 docker compose logs -f # 只看某个特定服务如wordpress的日志 docker compose logs wordpress停止服务docker compose down这个命令会停止并删除由up创建的所有容器、网络。但不会删除卷volumes因此你的数据库数据./db_data和WordPress内容./wp_content会得以保留。如果也想删除卷需要加上-v参数docker compose down -v请谨慎使用。通过Docker Compose你用一个声明式的YAML文件就替代了一长串复杂的docker run命令并且能轻松管理多容器应用的完整生命周期。这对于部署“微服务项目”、本地开发环境搭建比如需要MySQL、Redis、Nginx组合来说效率提升是巨大的。7. 镜像管理优化与日常维护随着使用时间增长你的系统中可能会积累很多不再使用的镜像、停止的容器和悬空dangling的构建缓存它们会占用可观的磁盘空间。定期清理和维护是保持系统健康的好习惯。7.1 清理无用Docker资源删除所有已停止的容器docker container prune系统会询问你是否确认输入y即可。如果你想强制删除不询问可以加-f参数。删除所有未被任何容器引用的镜像悬空镜像docker image prune这通常能清理出不少空间尤其是在频繁构建镜像之后。删除所有未被使用的镜像、容器、卷和网络更彻底的清理docker system prune -a警告-a参数会删除所有未被容器使用的镜像而不仅仅是悬空镜像。这意味着你本地所有没有被运行中容器引用的镜像都会被删除下次使用需要重新拉取。请确保你了解其后果后再执行。如果只想清理卷可以加上--volumes参数但同样要小心这会删除数据。7.2 高效使用镜像理解Tag与分层拉取镜像时你可能会注意到命令如docker pull nginx。这实际上拉取的是nginx:latest标签。在生产环境中永远不要使用:latest标签因为它是一个移动的指针今天和明天拉取的latest可能是完全不同的版本会导致不可预期的行为。最佳实践是始终使用明确的版本标签docker pull nginx:1.24-alpinealpine是一个基于Alpine Linux的微小镜像比默认的debian基础镜像小很多更适合生产部署。理解镜像的标签Tag和选择合适的基础镜像是优化镜像拉取速度和容器安全性的重要一环。Docker镜像采用分层存储结构。当你构建一个新镜像时如果Dockerfile中的某一层指令没有变化Docker会直接复用本地已有的层这能极大加速构建过程。因此在编写Dockerfile时一个常见的技巧是将变化频率低的层放在前面变化频率高的层如复制应用代码放在后面。例如先COPY package.json和RUN npm install再COPY .这样当你只修改了源代码而没有更改依赖时npm install这一层缓存可以被复用。从指定版本安装、细致的前置检查、服务配置、权限管理到多容器编排和日常维护这一套流程走下来你获得的不仅仅是一个可用的Docker 20.10.24环境更是一套应对容器化任务的标准方法和排错思路。这个版本作为LTS的终点提供了一个极其稳定的平台让你可以安心地在上面构建和运行你的应用而不用担心底层引擎的频繁变动。