Ubuntu安装Docker的三种方式与权限配置详解

1. 项目概述为什么在 Ubuntu 上装 Docker 不只是“敲几行命令”那么简单Docker 这个词现在几乎成了“现代软件交付”的同义词。但如果你刚从 Ubuntu 桌面版点开终端准备照着某篇教程输入sudo apt install docker.io然后期待一个绿色的docker run hello-world就万事大吉——那我得先给你泼一盆常温水这一步背后藏着至少三类人会踩的坑。一类是桌面用户以为装完就能跑服务结果发现 Docker Desktop 那套图形化管理根本没装上连容器日志都得靠journalctl翻半天第二类是服务器运维习惯性加-y一键到底却忽略了 Ubuntu 默认仓库里的docker.io包版本常年滞后去年我们线上一个用buildx做多平台构建的 CI 流水线就因为docker.io自带的buildx插件是 v0.8.2硬生生卡在 Apple Silicon 构建失败上排查了两天才发现是包管理器的锅第三类是开发者本地跑docker-compose.yml时权限报错Got permission denied while trying to connect to the Docker daemon socket反复查文档才明白docker组不是自动加进当前用户的。所以这篇内容不是教你怎么复制粘贴而是带你把 Ubuntu 上 Docker 的安装、验证、权限、首个容器这整条链路像拆解一台机械键盘一样一颗螺丝一颗螺丝地拧开。核心关键词就是Ubuntu Docker 安装、Docker 权限配置、第一个容器验证、Docker 服务管理、Ubuntu 桌面与服务器差异。它适合三类人刚转 Linux 的开发者想搞清本地开发环境中小团队的运维要给新服务器批量部署还有那些被Permission denied报错卡住半小时、最后靠 Stack Overflow 一行命令蒙混过关的同学。你不需要提前懂容器原理但得愿意为自己的终端多敲几行systemctl status和ls -l /var/run/docker.sock。2. 安装方案深度拆解为什么官方脚本、APT 仓库、Snap 三种方式必须分清2.1 官方安装脚本最“干净”也最需警惕的选择Ubuntu 官方文档推荐的curl -fsSL https://get.docker.com | sh这条命令表面看是“一键安装”实则是一把双刃剑。它本质是执行一个由 Docker 官方维护的 Shell 脚本这个脚本会做四件关键事第一检测你的系统发行版和架构确认是ubuntuamd64或arm64第二自动添加 Docker 的官方 APT 仓库https://download.docker.com/linux/ubuntu并导入 GPG 密钥第三更新apt缓存然后安装docker-ce社区版、docker-ce-cli命令行工具和containerd.io底层容器运行时三个核心包第四启动docker服务并尝试将当前用户加入docker组。它的优势在于版本最新——比如 Ubuntu 22.04 LTS 默认仓库里docker.io是 20.10.x而官方脚本能直接装上 24.0.x这对需要docker buildx、docker scan等新特性的项目至关重要。但风险点也很明确脚本是远程下载执行的虽然有 HTTPS 和 GPG 校验但任何网络中间劫持或镜像源污染都可能带来隐患。我见过一次内部 CI 环境因公司代理缓存了被篡改的get.docker.com脚本导致所有构建节点被注入挖矿进程。所以我的实操建议是生产服务器绝对不用curl | sh个人开发机如果要用务必先curl -fsSL https://get.docker.com -o get-docker.sh下载脚本到本地用less get-docker.sh逐行审阅重点看add-apt-repository和apt-get install那几段确认没有可疑的curl http://或wget外部链接再执行。2.2 Ubuntu 官方 APT 仓库稳定但过时适合什么场景sudo apt install docker.io这条命令调用的是 Ubuntu 自己维护的universe仓库。它的逻辑完全不同Ubuntu 团队会将上游 Docker 的某个稳定版本通常是 LTS 版本打上自己的补丁编译成.deb包放入自己的仓库。好处是极致稳定——包经过 Ubuntu QA 团队的完整测试依赖关系严格锁定不会出现docker-ce和containerd.io版本不兼容的问题。坏处是版本滞后严重。以 Ubuntu 22.04 为例其docker.io包在 2023 年底仍停留在 20.10.12而 Docker 官方 CE 版本已是 24.0.5。这意味着你无法使用docker composev2原生集成在 CLI 中、docker buildx bake这类提升效率的命令更别提对cgroupv2的完整支持。那么它适合谁答案是对稳定性要求远高于功能性的嵌入式设备或老旧服务器。比如我们给某工厂的边缘网关Ubuntu 18.04 ARM Cortex-A9部署监控代理整个系统生命周期长达 10 年宁可不要新功能也要确保dockerd进程十年不崩。此时docker.io反而是更优解。安装后服务名是docker但二进制路径是/usr/bin/docker.io这点和官方包的/usr/bin/docker不同写自动化脚本时必须注意。2.3 Snap 安装Ubuntu 桌面用户的“甜蜜陷阱”sudo snap install docker这条命令在 Ubuntu 桌面版尤其是 20.04的 GNOME 软件中心里点几下就能完成看起来最友好。Snap 包的本质是将 Docker 的所有依赖包括containerd、runc、甚至部分内核模块打包进一个沙盒化的、自包含的.snap文件。它最大的卖点是“无需担心依赖冲突”——因为所有东西都隔离在自己的命名空间里。但代价是性能和灵活性。首先I/O 性能下降约 15%这是 Snap 的squashfs文件系统和额外的 FUSE 层带来的开销对频繁读写镜像层的构建场景影响明显其次它默认禁用--privileged模式想跑docker run --privileged nginx会直接报错因为 Snap 的安全策略不允许容器获取宿主机全部能力最后/var/lib/docker数据目录被强制绑定到/var/snap/docker/common/var-lib-docker如果你想用 LVM 或 ZFS 单独给 Docker 数据盘做快照就得手动修改 Snap 的配置比官方包麻烦得多。所以我的结论很直接Ubuntu 桌面用户如果你只是偶尔跑几个nginx或redis容器做本地测试Snap 方便快捷可以接受但如果你是前端开发者要用docker-compose启动整套微服务或者数据科学家要用nvidia-docker调 GPU立刻放弃 Snap选官方脚本。2.4 方案对比决策表根据你的角色快速选择维度官方脚本 (get.docker.com)Ubuntu APT (docker.io)Snap (snap install docker)版本新鲜度★★★★★ (实时同步 Docker CE)★★☆☆☆ (滞后 6-12 个月)★★★☆☆ (Snap 商店更新较慢)安装可靠性★★★☆☆ (依赖网络和远程脚本)★★★★★ (Ubuntu QA 全流程测试)★★★★☆ (Snap 沙盒机制保障)性能开销★★★★★ (原生二进制零额外开销)★★★★★ (同上)★★☆☆☆ (FUSE 层 squashfs 解压)权限灵活性★★★★★ (完全控制docker组和 socket)★★★★★ (同上)★★☆☆☆ (受限于 Snap 安全策略)适用场景开发者本地环境、CI/CD 流水线、新服务器初始化老旧嵌入式设备、对稳定性要求极高的生产服务器Ubuntu 桌面新手、仅需简单容器测试的用户提示无论选哪种方式安装后都必须执行sudo systemctl enable docker否则重启后 Docker 服务不会自启。这是新手最容易忽略的一步也是第二天早上发现“我的容器怎么全没了”的根源。3. 核心细节解析与实操要点权限、服务、存储驱动一个都不能少3.1 权限配置为什么sudo docker run hello-world不是终点而是起点安装完成后绝大多数人会立刻执行docker run hello-world。如果成功屏幕上刷出一段 ASCII 艺术字很多人就以为大功告成。但这里埋着一个巨大的认知陷阱这个命令之所以成功是因为你加了sudo。sudo的本质是临时获得 root 权限而 Docker 的守护进程dockerd默认只监听/var/run/docker.sock这个 Unix 域套接字且该 socket 的所有权是root:docker权限是srw-rw----即只有 root 用户和docker组成员可读写。所以当你不加sudo直接运行docker run hello-world时CLI 工具会尝试连接这个 socket但普通用户不在docker组里自然被拒绝报错就是经典的Got permission denied while trying to connect to the Docker daemon socket。解决方法不是每次敲命令都加sudo这违背最小权限原则且sudo会改变环境变量导致某些容器内程序行为异常而是将当前用户加入docker组。命令是sudo usermod -aG docker $USER。但注意usermod修改的是/etc/group文件这个变更不会立即生效。你必须完全退出当前登录会话关闭所有终端窗口甚至注销 GNOME 桌面再重新登录系统才会重新加载组信息。我曾帮一位同事调试他执行完usermod后立刻新开一个终端还是报错折腾半小时后才发现自己没注销。验证是否生效用groups命令查看输出里是否有docker或者直接id -nG。还有一个隐藏坑如果你用的是 Ubuntu 桌面版且启用了gnome-keyring有时 SSH 登录或图形界面登录的会话环境变量不同groups显示有docker但终端里docker ps仍报错。这时终极办法是newgrp docker它会启动一个新 shell强制加载docker组权限。3.2 服务管理systemctl不是摆设是日常运维的命脉Docker 在 Ubuntu 上是以systemd服务形式运行的服务名是docker。理解systemctl的基本操作是你掌控 Docker 的第一步。sudo systemctl start docker启动服务sudo systemctl stop docker停止服务sudo systemctl restart docker重启服务——这些是基础。但真正体现专业度的是sudo systemctl status docker。这个命令的输出远不止 “active (running)” 这几个字。第一行会显示服务的主进程 PID比如Main PID: 1234 (dockerd)往下看CGroup信息告诉你 Docker 使用的是cgroupv1还是cgroupv2Ubuntu 22.04 默认cgroupv2这对容器资源限制的精度至关重要最关键的是Loaded行它会显示服务文件的路径比如/lib/systemd/system/docker.service这意味着你可以编辑这个文件来定制 Docker 的启动参数。例如你想让 Docker 默认使用overlay2存储驱动这是目前最主流、最稳定的驱动但发现status里显示Storage Driver: vfs这是最慢的驱动只用于调试那就说明配置有误。你需要编辑/etc/docker/daemon.json如果不存在就创建写入{ storage-driver: overlay2, log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }然后sudo systemctl daemon-reload sudo systemctl restart docker。这里daemon-reload是关键它告诉 systemd 重新读取所有服务文件否则restart不会生效。另一个高频操作是sudo journalctl -u docker -f它实时跟踪 Docker 守护进程的日志当容器莫名退出或拉取镜像失败时这是第一手排查依据。我习惯把它和docker events实时监听 Docker 事件流配合使用前者看守护进程自身问题后者看容器生命周期事件。3.3 存储驱动与数据目录别让/var/lib/docker吃光你的根分区Docker 的所有镜像、容器、卷、网络配置最终都落地在/var/lib/docker目录下。这个目录的默认位置在根分区/而 Ubuntu 桌面版的根分区通常只有 20-30GB一旦你开始构建大型 Python 或 Java 应用镜像几十个 GB 的层叠镜像很快就会把根分区塞爆导致系统假死。这就是为什么必须理解存储驱动Storage Driver。Ubuntu 支持多种驱动vfs最慢纯文件拷贝、aufs已废弃、overlay2当前黄金标准基于 Linux 内核的 overlayfs速度快、内存占用低、支持写时复制。overlay2的工作原理可以类比为 Photoshop 的图层每个镜像层是一个只读的“背景图层”容器运行时创建一个可写的“顶层图层”所有修改都发生在这里底层图层保持不变。这样多个容器共享同一个基础镜像如ubuntu:22.04磁盘空间利用率极高。要确认当前驱动docker info | grep Storage Driver。如果显示vfs必须按上一节方法修改daemon.json。此外/var/lib/docker的位置是可以迁移的。假设你有一块独立的 SSD 挂载在/mnt/docker-data想把 Docker 数据迁过去。步骤是先sudo systemctl stop docker然后sudo rsync -avz /var/lib/docker/ /mnt/docker-data/注意末尾的/保证同步内容而非目录本身接着sudo mv /var/lib/docker /var/lib/docker.bak再sudo ln -s /mnt/docker-data /var/lib/docker创建软链接最后sudo systemctl start docker。这个过程实测耗时取决于数据量但能一劳永逸解决空间焦虑。3.4 镜像源加速为什么docker pull ubuntu会卡在 0%在国内网络环境下docker pull官方镜像仓库registry-1.docker.io的速度经常令人绝望动辄几分钟甚至超时。这不是 Docker 的问题而是网络路由和 CDN 节点分布导致的。解决方案是配置国内镜像源。主流选择有阿里云、腾讯云、中科大、网易。我长期用阿里云因为它的https://your-id.mirror.aliyuncs.com是私有加速器需要登录阿里云容器镜像服务控制台免费开通速度稳定在 10MB/s。配置方法是在/etc/docker/daemon.json中添加registry-mirrors字段{ registry-mirrors: [https://your-id.mirror.aliyuncs.com] }然后sudo systemctl daemon-reload sudo systemctl restart docker。验证是否生效docker info输出里会看到Registry Mirrors一行。这里有个重要细节镜像源只对pull操作生效push操作依然走官方仓库除非你docker login到私有仓库。另外daemon.json是 JSON 格式语法必须严格少一个逗号或引号都会导致dockerd启动失败systemctl status docker会显示failed to load JSON file。所以每次修改后务必用jq工具校验sudo jq . /etc/docker/daemon.json如果输出格式化后的 JSON说明语法正确如果报错立刻修复。4. 实操过程与核心环节实现从零到第一个真正有用的容器4.1 验证安装hello-world之后必须做的三件事docker run hello-world成功只证明 Docker 引擎能跑起来不代表一切就绪。接下来必须做三件验证性操作缺一不可。第一检查 Docker 版本和信息docker --version确认 CLI 版本docker version查看 Client 和 Server即dockerd的详细版本及 Git Commitdocker info获取完整的系统信息包括存储驱动、Cgroup 版本、总镜像数、容器数等。第二测试网络连通性docker run --rm alpine ping -c 3 google.com。这里--rm参数很关键它让容器退出后自动删除避免产生一堆Exited状态的垃圾容器。如果 ping 不通说明 Docker 的默认桥接网络docker0或 iptables 规则有问题常见于某些企业防火墙策略或ufw未配置。第三测试镜像拉取和运行docker run --rm -it ubuntu:22.04 cat /etc/os-release。-it是-i交互式和-t分配伪 TTY的组合让容器能接收键盘输入cat /etc/os-release是一个轻量级命令能快速验证容器内 Ubuntu 系统是否正常启动。如果这三步都通过你的 Docker 环境才算真正“活”了。4.2 第一个实用容器Nginx Web 服务器的完整部署链路hello-world是玩具nginx才是第一个真正能干活的容器。部署它能串起端口映射、卷挂载、后台运行、日志查看等核心概念。第一步拉取官方 Nginx 镜像docker pull nginx:alpine。选择alpine版本是因为它基于 Alpine Linux镜像大小仅 5MB比nginx:latest基于 Debian约 140MB小得多启动更快内存占用更低。第二步运行容器docker run -d -p 8080:80 --name my-nginx -v $(pwd)/html:/usr/share/nginx/html:ro nginx:alpine。这里每个参数都有深意-d让容器在后台运行detached mode-p 8080:80是端口映射把宿主机的8080端口映射到容器内的80端口这样你在浏览器访问http://localhost:8080就能看到 Nginx 欢迎页--name my-nginx给容器起个好记的名字方便后续docker stop my-nginx-v是卷挂载$(pwd)/html是当前目录下的html文件夹/usr/share/nginx/html是 Nginx 默认的网页根目录:ro表示只读挂载防止容器内程序意外修改宿主机文件。第三步验证curl http://localhost:8080应该返回 Nginx 的 HTML 源码docker logs my-nginx查看 Nginx 的访问日志docker exec -it my-nginx sh进入容器内部ls /usr/share/nginx/html确认挂载的文件存在。这个过程你实际上已经完成了 Web 服务的容器化部署比传统apt install nginx更轻量、更可复现。4.3 容器持久化为什么docker commit是反模式Dockerfile才是正道很多新手在容器里改完配置比如vi /etc/nginx/nginx.conf想保存这个状态会用docker commit my-nginx my-custom-nginx。这看似合理实则是 Docker 的反模式。commit生成的镜像是“黑盒”它把容器当前的整个文件系统快照打包你不知道里面具体改了什么也无法版本化管理更无法审计安全漏洞。正确的做法是用Dockerfile。假设你想定制一个 Nginx让它默认返回 “Hello from My Docker!”。创建一个DockerfileFROM nginx:alpine COPY index.html /usr/share/nginx/html/index.html # COPY nginx.conf /etc/nginx/nginx.conf # 如果需要改配置也放这里再创建index.html!DOCTYPE html html headtitleHello/title/head bodyh1Hello from My Docker!/h1/body /html然后docker build -t my-nginx .构建镜像。docker build的过程就是 Docker Engine 逐行执行Dockerfile指令先拉取nginx:alpine作为基础镜像然后把index.html复制进去。这个过程是可重复、可审计、可版本化的。.dockerignore文件类似.gitignore可以排除构建上下文中的无用文件加快构建速度。docker history my-nginx能清晰看到每一层的构建指令和大小这是commit永远做不到的。我坚持的原则是任何需要长期维护、多人协作、上线部署的容器必须用Dockerfile构建commit只用于紧急故障排查时的临时快照。4.4 容器编排初探docker-compose.yml让多容器协作变得简单单个 Nginx 很酷但真实应用往往是 Nginx PHP-FPM MySQL 的组合。手动docker run三个命令还要处理网络、卷、启动顺序很快就会乱成一团。docker-compose就是为此而生。安装它很简单sudo apt install docker-compose-pluginUbuntu 22.04 推荐用插件方式docker compose命令是原生命令非docker-compose。创建一个docker-compose.ymlversion: 3.8 services: web: image: nginx:alpine ports: - 8080:80 volumes: - ./html:/usr/share/nginx/html:ro depends_on: - php php: image: php:8.2-apache volumes: - ./html:/var/www/html:rw这个 YAML 文件定义了两个服务webNginx和phpPHP Apache。depends_on声明了启动顺序web会等php启动后再启动。volumes的挂载路径是相对于docker-compose.yml文件所在目录的。运行docker compose up -dDocker Compose 会自动创建一个专用的网络myproject_default让web和php容器可以通过服务名php互相访问无需暴露端口到宿主机。docker compose ps查看所有服务状态docker compose logs -f web实时查看 Nginx 日志。这比手动管理十个docker run命令效率提升了十倍。Compose 文件本身就是基础设施即代码IaC的雏形可以提交到 Git实现环境的完全可复现。5. 常见问题与排查技巧实录那些让你抓狂半小时的“小问题”5.1 经典报错速查表从现象到根因的精准定位报错现象根本原因排查命令解决方案Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?dockerd服务未启动或当前用户无权限访问 socketsudo systemctl status docker,ls -l /var/run/docker.sock,groupssudo systemctl start docker;sudo usermod -aG docker $USER并完全注销重登Error response from daemon: failed to create endpoint ... on network bridge: failed to add the host (veth) interface: operation not supported内核模块veth未加载常见于精简版内核或 WSL2lsmodgrep veth,sudo modprobe vethError response from daemon: Conflict. The container name /my-nginx is already in use by container ...容器名冲突同名容器已存在即使已停止docker ps -a | grep my-nginxdocker rm my-nginx删除旧容器或docker run --name my-nginx-new ...换个名字Error: No such container: my-nginx容器已删除或名字拼写错误docker ps -a用docker ps -a列出所有容器确认名字或用docker ps -a --filter namemy-nginx过滤Pulling from library/nginx ... waiting ...卡在 0%镜像源配置错误或网络不通docker info | grep Registry Mirrors,curl -v https://your-mirror检查/etc/docker/daemon.json语法用curl测试镜像源 URL 是否可达5.2 实操中踩过的坑那些文档里不会写的“血泪教训”坑一Ubuntu 桌面版的snapd与 Docker 的无声战争在 Ubuntu 20.04 桌面版snapd服务默认启用它会定期扫描/var/lib/snapd/snaps/下的 snap 包。而 Docker 的overlay2驱动使用的upperdir和workdir目录如果恰好和snapd的扫描路径重叠比如/var/lib/docker/overlay2/xxx/uppersnapd的扫描会触发overlay2的copy_up操作导致 I/O 飙升docker ps命令卡顿数秒。现象是top里snapd进程 CPU 占用 100%。解决方案是sudo systemctl mask snapd禁用 snapd或sudo systemctl stop snapd sudo systemctl disable snapd。这不是反对 Snap而是避免两个重量级服务在同一文件系统上争抢资源。坑二ufw防火墙与 Docker 网络的“信任危机”Ubuntu 默认的ufw防火墙其规则优先级高于 Docker 的 iptables 规则。当你docker run -p 8080:80后Docker 会在iptables的DOCKER-USER链里加一条ACCEPT规则允许外部访问8080。但如果ufw的全局策略是DENY它会在INPUT链里拦截所有流量DOCKER-USER链根本没机会执行。结果就是curl http://localhost:8080成功本地回环但局域网其他机器curl http://ubuntu-ip:8080失败。解决方法有两个一是sudo ufw allow 8080显式放行端口二是sudo nano /etc/default/ufw将DEFAULT_FORWARD_POLICYDROP改为DEFAULT_FORWARD_POLICYACCEPT让ufw不拦截转发流量Docker 容器间通信依赖此。坑三docker system prune的“温柔一刀”docker system prune -a是清理所有未使用镜像、容器、网络、构建缓存的“神器”。但它的-a参数会删除所有未被任何容器引用的镜像包括你docker pull下来的ubuntu:22.04、nginx:alpine。下次docker run时又得重新拉取。更危险的是它会删除所有dangling悬空镜像而有些 CI 工具生成的中间镜像会被标记为 dangling删掉可能导致构建失败。我的经验是日常清理用docker system prune不带-a它只删dangling镜像和停止的容器彻底清理前先docker image ls确认哪些镜像是你主动拉的再docker image rm image-id逐个删除或者用docker image prune -f --filter until24h只删 24 小时内未使用的镜像更安全。5.3 性能调优小技巧让 Docker 在 Ubuntu 上跑得更稳更快技巧一调整dockerd的--default-ulimitLinux 进程有资源限制ulimit比如最大打开文件数nofile。Docker 容器默认继承宿主机的限制但高并发 Web 服务如 Nginx很容易达到上限报错Too many open files。解决方案是在/etc/docker/daemon.json中添加{ default-ulimit: { nofile: { Name: nofile, Hard: 65536, Soft: 65536 } } }然后重启dockerd。这样所有新建容器的ulimit -n都是 65536无需在每个Dockerfile里RUN ulimit -n 65536。技巧二为overlay2启用d_typetrueoverlay2驱动依赖文件系统支持d_typedirectory entry type它决定了能否正确处理readdir系统调用。XFS 文件系统默认开启但 ext4 需要挂载时指定d_typetrue。检查方法xfs_info /XFS或dumpe2fs -h /dev/sda1 \| grep Filesystem featuresext4看输出是否有d_type。如果没有需要重新格式化或修改/etc/fstab在 ext4 分区的挂载选项里加上dax,errorsremount-ro,d_type然后sudo mount -o remount /。技巧三禁用dockerd的live-restore仅限生产live-restore是一个特性允许dockerd进程崩溃或升级时正在运行的容器不退出。听起来很美但在 Ubuntu 服务器上它会增加dockerd的内存占用和复杂度且对大多数场景并非必需。禁用方法/etc/docker/daemon.json中添加live-restore: false。重启后docker info里Live Restore Enabled显示false。这能让dockerd更轻量、更稳定。我在实际使用中发现把daemon.json配置好、docker组加好、镜像源配好这三件事做完90% 的 Docker 问题就消失了。剩下的 10%基本都是业务逻辑或网络拓扑的问题和 Docker 本身无关。所以别急着去学k8s先把 Ubuntu 上这台“容器引擎”的每一个螺丝都拧紧这才是真正的基本功。