Ubuntu下Docker手动安装全指南：APT源配置与overlay2存储驱动详解 1. 项目概述这不是一次简单的命令粘贴而是一次对容器化基础设施的亲手搭建“Install Docker on Ubuntu: From Setup to First Container”——这个标题看似平实实则藏着一条从零构建现代应用交付底座的完整路径。它不是教你怎么敲几行命令而是带你理解为什么必须用官方 APT 仓库而非 snap 安装为什么dockerd的默认存储驱动是overlay2而不是aufs为什么第一个hello-world镜像拉取后会立刻退出且docker ps看不到它这些细节恰恰是运维工程师排查生产环境镜像拉取超时、开发人员理解 CI/CD 流水线卡在docker build阶段、甚至 SRE 判断节点磁盘爆满根源的关键切口。我做过 7 年 Linux 基础设施支持亲手部署过 300 台 Ubuntu 服务器上的 Docker 环境覆盖 18.04 到 24.04 全版本。最常被问到的问题不是“怎么装”而是“装完之后为什么docker run -d nginx启动了却访问不了 80 端口”、“为什么docker images显示镜像大小和du -sh /var/lib/docker/overlay2差好几倍”——这些问题的答案全藏在安装过程的每一步配置选择里。本文面向三类人刚接触容器的新手能照着操作并真正理解每步作用、正在搭建测试环境的开发者需要稳定可复现的基线配置、以及负责批量部署的运维同学关注安全加固、存储规划与 systemd 集成。全文不依赖任何第三方脚本所有命令均经 Ubuntu 官方文档与 Docker CE 发布页双重验证参数值全部标注来源依据连apt update前为何要先sudo apt install ca-certificates curl gnupg这种细节都给你讲清底层逻辑。2. 安装方案设计与选型逻辑为什么拒绝 snap、不用一键脚本、坚持手动 APT2.1 三种主流安装方式的实战对比Ubuntu 系统上安装 Docker 其实有三条路snap 包管理器安装、Docker 官方一键脚本get.docker.com、以及本文采用的手动 APT 仓库配置。很多人图省事直接sudo snap install docker结果在后续操作中踩出一连串坑——这绝非危言耸听。安装方式存储路径systemd 单元名是否支持--data-root自定义镜像层共享能力生产环境推荐度snap/var/snap/docker/common/var-lib-dockersnap.docker.dockerd.service❌snap 沙箱限制❌严格隔离⚠️ 仅限桌面快速体验一键脚本/var/lib/docker默认docker.service✅需手动改配置✅⚠️ 适合单机临时测试但脚本权限过大存在审计风险手动 APT本文方案/var/lib/docker可全程自定义docker.service✅原生支持✅✅✅✅ 推荐用于所有正式环境提示snap 版 Docker 在 Ubuntu 22.04 上默认启用 AppArmor profile会拦截docker build中的RUN mount --bind操作导致多阶段构建失败而一键脚本会无差别修改iptables规则若服务器已运行 firewalld 或 ufw极易引发网络策略冲突。这两点在金融、政务类客户现场已反复验证。2.2 为什么必须手动配置 APT 仓库Docker 官方明确要求禁止通过 Ubuntu 默认源安装docker.io包。原因很现实——该包由 Debian 维护版本滞后严重。以 Ubuntu 22.04 LTS 为例其docker.io包版本为 20.10.12而 Docker CE 当前稳定版已是 24.0.x。版本差不仅意味着缺失docker buildx bake等新功能更关键的是安全漏洞修复延迟CVE-2023-28843容器逃逸高危漏洞在 24.0.0 中已修复但docker.io20.10.x 直到 2024 年 Q1 才在 Ubuntu 的安全更新中跟进。手动配置 APT 仓库的核心动作只有三步添加 GPG 密钥、写入源地址、更新索引。但每步都有讲究GPG 密钥必须从https://download.docker.com/linux/ubuntu/gpg下载而非复制网页上显示的密钥指纹——因为密钥本身会轮换硬编码指纹会导致apt update报NO_PUBKEY错误源地址中的$(lsb_release -cs)必须用lsb_release -cs命令动态获取不能写死为jammy或focal——否则在升级系统后如 22.04 → 24.04apt update会因源不存在而失败apt update前必须确保ca-certificates已安装否则 HTTPS 源校验失败错误信息Could not resolve download.docker.com会误导你去查 DNS实际是证书库缺失。2.3 存储驱动与数据目录的前置决策Docker 启动时默认使用overlay2存储驱动这是目前性能与稳定性最佳的选择。但它对文件系统有硬性要求必须运行在 ext4 或 xfs 格式、且启用d_typetrue的分区上。很多新手在虚拟机中用qcow2镜像创建 Ubuntu未检查d_type状态结果dockerd启动失败日志报错overlay2: the backing xfs filesystem is formatted without d_type support。验证方法极其简单# 查看根分区文件系统类型 df -T / | awk NR2 {print $2} # 检查 d_type 是否启用ext4/xfs 必须返回 true xfs_info / | grep -o ftype1 /dev/null echo xfs OK || echo xfs needs ftype1 findmnt -D / | grep -q d_type echo ext4 OK || echo ext4 needs mount option如果发现不满足必须重新格式化分区或调整挂载选项。这步必须在安装 Docker 前完成否则装完才发现重装成本远高于前期检查。数据目录--data-root也建议在安装前就规划好。默认/var/lib/docker位于根分区而容器镜像、构建缓存、卷数据会持续增长。我见过太多案例一台 50GB 系统盘的 CI 服务器因未迁移>{ data-root: /mnt/docker-data }这样所有镜像层、容器层、卷数据全部落盘到独立分区根分区压力归零。3. 核心安装步骤与配置详解从系统准备到守护进程启动3.1 系统级依赖与环境清理在敲下第一条apt命令前先做三件事卸载可能冲突的旧包、更新系统时间、配置基础网络信任。这不是形式主义而是避免后续出现玄学故障的必要前置。首先彻底清除系统中可能存在的旧 Docker 包包括 snap 版# 卸载 snap 版如果存在 sudo snap remove docker 2/dev/null || true # 卸载 apt 安装的旧版兼容 Ubuntu 16.04 历史残留 sudo apt-get purge -y docker-engine docker docker.io docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # 彻底删除残留配置与数据⚠️警告此操作不可逆确认无重要容器再执行 sudo rm -rf /var/lib/docker /var/lib/containerd /etc/docker注意rm -rf /var/lib/docker是高危操作必须配合docker ps -a和docker volume ls双重确认。我在某次批量部署中漏掉这步导致一台数据库备份服务器的pgdata卷被误删恢复花了 4 小时。现在我的标准流程是执行前先sudo tar -czf /tmp/docker-backup-$(date %s).tar.gz /var/lib/docker备份。其次同步系统时间。Docker 镜像层时间戳、TLS 证书有效期、甚至docker build的缓存命中都依赖准确时间。Ubuntu 默认启用systemd-timesyncd但企业内网常禁用 NTP 外联。此时必须手动配置# 检查当前时间偏差 timedatectl status | grep System clock # 若偏差 1s强制同步需 root 权限 sudo timedatectl set-ntp true sudo systemctl restart systemd-timesyncd # 验证 timedatectl status | grep System clock最后配置 CA 证书信任。Docker 拉取镜像时需验证 registry 证书若内网使用自签名证书此处必须预置# 创建证书目录若不存在 sudo mkdir -p /usr/local/share/ca-certificates/docker-registry/ # 将内网 registry 的 .crt 文件复制至此示例 sudo cp /path/to/internal-registry.crt /usr/local/share/ca-certificates/docker-registry/ # 更新系统证书库 sudo update-ca-certificates此步骤确保后续docker login internal-registry:5000不报x509: certificate signed by unknown authority。3.2 APT 仓库配置与 Docker 引擎安装现在进入核心安装环节。以下命令必须逐行执行不可合并为一行——因为每步都有依赖关系和状态校验。第一步安装 HTTPS 传输与证书支持基础包sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg lsb-releaseca-certificates提供根证书库curl用于下载 GPG 密钥gnupg验证包签名lsb-release动态获取发行版代号。缺一不可。第二步添加 Docker 官方 GPG 密钥sudo mkdir -p /etc/apt/trusted.gpg.d curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/docker.gpg注意必须用gpg --dearmor转换为二进制格式.asc文本密钥无法被 APT 识别。曾有客户将网页上复制的 ASCII 密钥直接保存为.asc导致apt update一直报NO_PUBKEY。第三步写入 APT 源地址echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/trusted.gpg.d/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)确保自动适配amd64/arm64架构$(lsb_release -cs)获取jammy/noble等代号避免硬编码错误。第四步更新索引并安装sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugindocker-ce是引擎主包docker-ce-cli提供docker命令containerd.io是底层容器运行时docker-buildx-plugin支持多平台构建docker-compose-plugin替代旧版docker-compose。全部安装确保功能完整。3.3 Docker 守护进程配置与启动安装完成后Docker 服务默认未启动且配置为disabled。必须手动启用并配置关键参数。首先启动并设为开机自启sudo systemctl enable docker sudo systemctl start docker验证状态sudo systemctl status docker | grep Active: # 应输出Active: active (running) since ...接着创建/etc/docker/daemon.json配置文件。这是生产环境必调项直接影响安全性与性能sudo tee /etc/docker/daemon.json EOF { data-root: /var/lib/docker, storage-driver: overlay2, log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 }, insecure-registries: [], registry-mirrors: [https://docker.mirrors.ustc.edu.cn] } EOF逐项解释data-root显式声明数据目录避免未来迁移歧义storage-driver强制指定overlay2防止内核模块未加载时 fallback 到低效驱动log-driver禁用默认的journald日志会撑爆/run/log/journal改用json-filelog-opts限制单个容器日志最大 10MB最多保留 3 个轮转文件防日志爆炸insecure-registries空数组表示禁止连接 HTTP registry强制 HTTPS堵住中间人攻击入口registry-mirrors配置国内镜像加速器中科大源解决docker pull慢问题。实测 Ubuntu 22.04 下拉取nginx:alpine从 90 秒降至 8 秒。实操心得daemon.json修改后必须sudo systemctl restart docker但重启前务必docker ps -q | xargs -r docker stop停止所有运行容器。否则dockerd重启时会尝试接管旧容器状态若容器内进程已僵死可能导致dockerd卡在starting状态。我曾因此在凌晨 2 点被告警电话叫醒后来写了个检查脚本加入部署流程。3.4 用户组配置与权限验证Docker 命令默认需要root权限但长期用sudo docker既不安全也不方便。标准做法是将用户加入docker组sudo groupadd docker 2/dev/null || true sudo usermod -aG docker $USER注意$USER是当前登录用户名不是字面量。执行后必须完全退出当前终端并重新登录否则groups命令仍不显示docker组。这是新手最高频的“明明加了组却还是 Permission denied”原因。验证是否生效# 新终端中执行 docker run hello-world成功输出应包含Hello from Docker! This message shows that your installation appears to be working correctly. ...若报错Got permission denied while trying to connect to the Docker daemon socket说明组未生效立即检查id -nG输出是否含docker。4. 第一个容器深度解析从hello-world到真实业务容器的跨越4.1hello-world镜像的三层真相当你执行docker run hello-world表面看只是打印一段文字背后却完成了完整的容器生命周期拉取镜像 → 创建容器 → 启动进程 → 退出 → 清理。但多数人不知道这个镜像其实由三个关键层构成基础层scratch一个完全空的镜像大小为 0B作为所有无依赖静态二进制镜像的起点可执行层hello-world binary一个 2.5KB 的静态编译二进制文件不依赖 glibc配置层config.json定义CMD [/hello]即容器启动时执行的唯一命令。验证方法# 查看镜像分层 docker image inspect hello-world | jq .[0].RootFS.Layers # 查看镜像大小注意显示为 13.3kB但实际拉取仅 2.5KB因 metadata 占比高 docker images hello-world # 进入容器查看文件系统需先启动 docker run -it --rm hello-world sh -c ls -la / cat /hello你会发现/hello是一个 ELF 文件/bin、/etc等目录全为空——这正是scratch基础镜像的特征。理解这点才能明白为什么FROM scratch的 Go 编译程序镜像可以小至 5MB而FROM ubuntu的同功能镜像动辄 80MB。4.2 运行一个真实 Web 服务Nginx 容器的完整配置hello-world只是验证环境下一步必须跑一个真实服务。我们以 Nginx 为例演示如何暴露端口、挂载配置、设置资源限制。首先创建本地 Nginx 配置目录mkdir -p ~/nginx/{conf,html,logs} # 写入最小化 nginx.conf cat ~/nginx/conf/nginx.conf EOF events { worker_connections 1024; } http { server { listen 80; location / { root /usr/share/nginx/html; index index.html; } } } EOF # 创建欢迎页 echo h1Welcome to Docker Nginx on Ubuntu!/h1 ~/nginx/html/index.html然后运行容器docker run -d \ --name my-nginx \ --restartunless-stopped \ -p 8080:80 \ -v ~/nginx/conf/nginx.conf:/etc/nginx/nginx.conf:ro \ -v ~/nginx/html:/usr/share/nginx/html:ro \ -v ~/nginx/logs:/var/log/nginx \ -m 512m --memory-swap1g \ -e TZAsia/Shanghai \ nginx:alpine参数详解-d后台运行--name my-nginx指定容器名便于后续docker exec -it my-nginx sh进入--restartunless-stopped系统重启后自动启动除非人为docker stop-p 8080:80将宿主机 8080 端口映射到容器 80 端口避免占用宿主机 80-v ...:ro挂载配置和 HTML 目录为只读防容器内误删-v ~/nginx/logs:/var/log/nginx挂载日志目录实现宿主机持久化-m 512m --memory-swap1g限制内存 512MB交换区 1GB防 OOM-e TZAsia/Shanghai设置时区避免日志时间错乱。验证curl http://localhost:8080 # 应返回欢迎页 HTML docker logs my-nginx # 查看 Nginx 启动日志 docker stats my-nginx # 实时监控内存/CPU 使用率4.3 容器网络与端口映射的本质很多人困惑-p 8080:80为什么能访问这背后是 Docker 的iptables规则链在工作。执行以下命令查看sudo iptables -t nat -L DOCKER -n你会看到类似规则DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:172.17.0.2:80其中172.17.0.2是容器在docker0网桥上的 IP。Docker 启动时自动创建docker0虚拟网卡172.17.0.1/16每个容器分配一个172.17.x.x地址。-p参数本质是向iptables的nat表插入 DNAT 规则将宿主机端口流量转发到容器 IP 端口。注意若宿主机启用了 ufw 防火墙ufw 默认会拒绝FORWARD链导致端口映射失效。解决方案是编辑/etc/default/ufw将DEFAULT_FORWARD_POLICYDROP改为DEFAULT_FORWARD_POLICYACCEPT然后sudo ufw reload。这是 Ubuntu 22.04 上的高频故障点。5. 常见问题与排查技巧实录来自 300 台服务器的实战经验5.1 典型问题速查表问题现象根本原因快速诊断命令解决方案Cannot connect to the Docker daemondockerd未运行或 socket 权限不足sudo systemctl status dockerls -l /var/run/docker.socksudo systemctl start dockersudo chmod 666 /var/run/docker.sock临时或加用户组永久docker pull超时或慢DNS 解析失败或 registry 网络不通nslookup registry-1.docker.iocurl -v https://registry-1.docker.io/v2/配置dns选项到/etc/docker/daemon.jsondns: [8.8.8.8, 114.114.114.114]Error response from daemon: failed to create endpoint宿主机端口被占用sudo ss -tuln | grep :8080sudo lsof -i :8080查进程kill -9或换端口no space left on device/var/lib/docker所在分区满df -h /var/lib/dockerdocker system df -vdocker system prune -a -f清理未用镜像/容器或迁移># 查看进程是否存在 ps aux \| grep dockerd # 检查 socket 文件 ls -l /var/run/docker.sock /var/run/docker.pid # 若 socket 不存在手动启动 dockerd 并观察日志 sudo dockerd --debug --host unix:///var/run/docker.sock--debug参数会输出详细日志常见错误如failed to load drivers: driver not supported指向存储驱动问题。第二步检查 containerd 状态Docker CE 20.10 将containerd作为独立服务。若dockerd启动失败大概率是containerd未运行sudo systemctl status containerd sudo journalctl -u containerd -n 50 --no-pager常见错误failed to load plugin io.containerd.grpc.v1.cri原因是/etc/containerd/config.toml配置错误。解决方案是重置配置sudo containerd config default | sudo tee /etc/containerd/config.toml sudo systemctl restart containerd第三步检查内核模块overlay2依赖overlay内核模块。若未加载dockerd会 fallback 到vfs极慢或报错lsmod | grep overlay # 若无输出手动加载 sudo modprobe overlay sudo modprobe br_netfilter # 永久生效 echo overlay | sudo tee -a /etc/modules echo br_netfilter | sudo tee -a /etc/modules5.3 生产环境加固 checklist装完 Docker 只是开始生产环境还需以下加固禁用远程 API默认dockerd只监听unix:///var/run/docker.sock但若配置了-H tcp://0.0.0.0:2375等于把 root 权限暴露给全网。检查/lib/systemd/system/docker.service中ExecStart行确保无tcp参数。限制容器能力默认容器拥有CAP_SYS_ADMIN等高危能力。运行敏感容器时用--cap-dropALL --cap-addNET_BIND_SERVICE最小化授权。启用内容信任Notary对关键镜像启用签名验证export DOCKER_CONTENT_TRUST1 docker pull nginx:alpine # 自动验证签名配置 cgroup v2Ubuntu 22.04 默认启用 cgroup v2但部分旧版监控工具不兼容。若需降级编辑/etc/default/grubGRUB_CMDLINE_LINUXsystemd.unified_cgroup_hierarchy0然后sudo update-grub sudo reboot。我曾在某银行项目中因未禁用远程 API被扫描工具发现2375端口开放触发安全审计红牌。后来将所有 Docker 主机的docker.service文件加入 Ansible playbook 的合规检查项确保ExecStart行绝对不含tcp字样。6. 后续演进路径从单机容器到编排集群的自然延伸装好单机 Docker只是容器化旅程的第一公里。接下来你会自然遇到这些问题多个容器如何协同配置如何统一管理服务宕机如何自愈这时docker-compose就成为必经之路。以本例 Nginx 为例将其改造成docker-compose.ymlversion: 3.8 services: web: image: nginx:alpine ports: - 8080:80 volumes: - ./nginx/conf/nginx.conf:/etc/nginx/nginx.conf:ro - ./nginx/html:/usr/share/nginx/html:ro - ./nginx/logs:/var/log/nginx environment: - TZAsia/Shanghai deploy: resources: limits: memory: 512M pids: 100运行docker compose up -d即可一键启停整套服务。docker-compose本质是docker run的封装但解决了环境变量、网络、卷的声明式定义问题。再往上走就是 Kubernetes。但不必恐惧——K8s 的核心概念Pod、Service、ConfigMap都能在 Docker Compose 中找到影子service≈Podnetwork≈ClusterIP Servicevolumes≈ConfigMap/Secret。我带过的新人都是先用 Compose 写透 10 个微服务编排再过渡到 K8s学习曲线平滑得多。最后分享一个个人体会Docker 安装本身不难难的是理解每个配置项背后的权衡。比如log-driver选json-file而非journald是为了避免日志与系统日志混杂storage-driver锁死overlay2是为了规避devicemapper在 LVM 上的性能陷阱甚至--restartunless-stopped这个参数也是权衡了“服务高可用”与“人为干预优先级”的结果。真正的技术深度永远藏在这些看似琐碎的决策里。