说实话Docker 的命令行看一遍文档谁都会难的是把“能敲出几条命令”变成“脑子里有一套完整的操作逻辑”。尤其那些天天上热搜的问题docker 安装失败、desktop 起不来、权限报错、网络不通、MySQL 和 Redis 装好却连不上根源大多不是命令本身记不熟而是对 Docker 的命令行体系、对象关系、网络和数据卷的底层工作原理缺少一个整体认知。这篇内容没有太多“介绍”和“概述”我直接把自己这些年从入门到能独立维护生产环境的经验拆开了写。全文围绕 Docker 命令行核心命令展开从环境初始化、镜像和容器管理、Compose 编排到网络、数据卷、高频排错一路写到日常维护习惯。适合两类人一类是刚接触 Docker想系统性把命令学扎实的新手另一类是已经在用 Docker但遇到问题只能靠百度、搜完还是不知道原因的实践者。读完这篇至少你拿到任何一个容器项目都能用命令行把它盘清楚。1. 先把环境盘明白安装、守护进程与命令行入口命令行本质上只是一个客户端真正干活的是后台的 Docker 守护进程。很多人刚上手就卡在环境上所以我先把安装、版本选择和 Socket 权限这几个基础问题说透。1.1 Linux 安装 Docker 时我为什么推荐走官方源而不是无脑一键脚本Linux 上安装 Docker常用的方式有三种系统自带包管理器里的旧版本、官方一键脚本、手动配置官方源的完整安装。我的建议是——生产环境不要用系统源里的 docker.io版本太老一键脚本虽然快但有时会默认拉取你不太想要的版本而且脚本执行过程不可控。以 Ubuntu 为例我习惯手动配置 Docker 官方源步骤并不复杂sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg 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 ar /etc/apt/keyrings/docker.gpg随后写入源文件注意 Ubuntu 版本代号要和官方路径匹配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接着执行sudo apt-get update安装核心组件sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin这里有几个点需要解释。docker-ce是社区版守护进程docker-ce-cli是命令行工具这两者分开装的好处是以后即使你只要个远程客户端也不需要在服务器上跑守护进程。containerd.io是运行时底座镜像真正由 containerd 管理Docker CLI 只是上层封装。docker-buildx-plugin和docker-compose-plugin一个是多架构构建工具一个是 Compose v2 插件后面编排都会用到。安装完成后用docker version验证。如果只看到 Client 版本而 Server 部分是空的说明守护进程没起来先查systemctl status docker必要时手动sudo systemctl start docker。这一步很多人忽略导致后面所有命令都报“Cannot connect”。1.2 单机环境与 Docker DesktopCLI 行为差异很多 Windows 和 macOS 用户接触 Docker 是从 Docker Desktop 开始的。它的本质是在本机虚拟化一个 Linux 环境CLI 只是发指令的窗口。Desktop 的优势是图形化、免 Linux 安装劣势是它在操作系统和 Docker Engine 之间多了一层一旦虚拟化层出问题命令行就会报一堆看起来很吓人的错。安装 Docker Desktop 后先运行docker context ls看一下当前使用的是哪个上下文。你会看到类似desktop-linux *的条目星号表示当前环境。如果误删或切换了 context可以用docker context use desktop-linux切回来。这个命令知道的人不多但排错时很关键。Desktop 环境下还要注意命令行报npipe:////./pipe/dockerDesktopLinuxEngine连不上绝大多数不是你的命令写错了而是 Docker Desktop 里 Linux Engine 没起来。常见原因有三个宿主机没有开启硬件虚拟化WSL2 内核或系统组件版本过旧以及 Desktop 服务被安全软件拦截。第一个问题要到 BIOS 里找 Intel VT-x 或 AMD SVM 开关Windows 功能里也要确保“虚拟机平台”和“适用于 Linux 的 Windows 子系统”两项已勾选。做完这些再重启 Docker Desktop基本都能解决。1.3 最常见的启动失败Socket 权限与守护进程检查Linux 下首次运行docker ps新手最容易碰到的是permission denied while trying to connect to the Docker daemon socket这个报错的原因很简单Docker CLI 默认通过/var/run/docker.sock和守护进程通信这个 socket 文件属于 root 用户和 docker 组普通用户不在 docker 组里自然没权限。解决方案两条路。临时用sudo没问题但如果天天sudo docker文件归属和权限会变得一团糟而且很多生成物比如挂载出来的文件都会带 root 权限后续清理很烦。推荐把当前用户加入 docker 组sudo usermod -aG docker $USER newgrp docker执行后重新登录终端再docker ps即可。这里要泼一盆冷水把用户加入 docker 组等同于授予该用户 root 级别的宿主机权限因为容器可以挂载宿主机目录、甚至直接读写/。所以只对可信用户这么做生产服务器上尽量用 sudo 临时提权别图省事。还有一种情况是守护进程完全没起来。systemctl status docker会显示 active (running) 才是正常如果不是查看journalctl -u docker -n 50看具体失败原因。常见的有网络桥接创建失败、iptables 配置被安全软件改写、磁盘满等。这些问题在命令行阶段暴露得越早越好。2. 镜像与容器两个核心对象吃透Docker 的日常操作里镜像和容器几乎占据所有高频命令。镜像是一个只读模板容器是模板运行后的实例。很多命令就是围绕这两个对象增删改查理解它们的关系命令就背住了三分之二。2.1 镜像命令pull/images/tag/rmi/save/load先看拉取镜像。默认从 Docker Hub 拉取docker pull nginx:1.25-alpine后面附带的标签tag非常重要。:1.25-alpine表示 Nginx 1.25 的 Alpine 精简版本体积小、攻击面少适合做基础镜像。不写 tag 默认拉latest但latest是一个滑动标签昨天是 1.25明天可能变成 2.0生产环境最忌讳这种不确定性。所以我会给线上服务固定一个具体 tag必要时再附带摘要digest锁定镜像版本。查看本地镜像用docker images也可以简写为docker image ls。输出里包含 REPOSITORY、TAG、IMAGE ID、CREATED、SIZE。SIZE 看着很小不表示完整系统占用因为它显示的是单层大小多层累加可能更大。打标签是给镜像起别名docker tag nginx:1.25-alpine registry.example.com/prod/nginx:1.25-alpine这一步在做私有仓库推送前几乎必用把项目名、环境、版本都写进标签里。删除镜像用docker rmi image_id或docker image rm。遇到容器还在使用镜像时会报 conflict需要先删容器再删镜像或者直接加-f强删——但我不推荐轻易用强删容易把还在运行的依赖层关系搞乱。离线传输和备份我会用 save/loaddocker save -o nginx.tar nginx:1.25-alpine docker load -i nginx.tardocker save保留了镜像的所有历史层和元数据适合跨机器迁移。对应地还有docker export但它导出的是容器文件系统不是镜像常用于紧急取文件不要混用。看镜像内部细节用docker inspect返回的是 JSON 格式包含了 entrypoint、环境变量、端口暴露、挂载点等大量信息。我最常搭配--format输出指定字段比如只查看入口命令docker inspect --format{{.Config.Entrypoint}} nginx:1.25-alpinedocker history则能看到每一层执行了什么命令排查“为什么镜像这么大”时非常有用。2.2 容器生命周期run/ps/logs/exec/rm容器的完整生命周期是创建-启动-运行-暂停/停止-删除。但日常用docker run一条命令直接完成创建和启动它也是最复杂的核心命令没有之一。先看一个综合示例docker run -d \ --name nginx-web \ -p 8080:80 \ -v /data/nginx:/usr/share/nginx/html \ -e TZAsia/Shanghai \ --restart unless-stopped \ nginx:1.25-alpine各参数的含义我拆开讲-d后台运行容器终端输出不挂住。--name给容器起名比用随机 ID 有辨识度。-p 8080:80宿主机 8080 映射到容器 80。端口冲突时 Docker 不会自动换端口而是直接报错所以我习惯先ss -tlnp | grep 8080检查端口占用。-v挂载数据卷或目录。-e传入环境变量。时间是容器里最容易忽略的很多容器默认 UTC 时区必须用TZAsia/Shanghai指定。--restart unless-stopped容器异常退出会自动拉起手动 stop 后不会重启。这是最推荐的保活策略always在某些主动停止场景下反而会反复拉起。查看容器运行状态docker ps只看存活容器docker ps -a看全部包括已退出的容器。输出里的 STATUS 字段很重要Up 3 hours正常Exited (0)是正常退出Exited (137)通常是内存溢出被 killRestarting要重点关注。查看日志是排错第一手段docker logs -f --tail 200 nginx-web-f实时跟踪输出--tail 200只显示最后 200 行。想做时间范围过滤可以加--since 10m否则大日志会直接刷爆终端。进入正在运行的容器分两种docker attach和docker exec。attach是把当前终端接到容器主进程上容易挂住甚至导致容器等主进程退出排错时我极少用它。exec是在容器内新起进程更安全docker exec -it nginx-web sh-i保持标准输入-t分配伪终端。两个参数经常一起用少一个都可能出现输入无效或排版错乱。停止和删除也有讲究。docker stop会先给容器一个优雅停止时间默认 10 秒超时再强制 kill。数据库类容器我建议docker stop -t 60给更多时间刷盘。删除容器用docker rm删除正在运行的容器需要先停再删或者docker rm -f直接强制删。但我遇到过很多次-f导致数据没来得及落盘的案例所以生产环境我尽量不用。2.3 用 MySQL 8.0 实战验证常用参数理论说多了容易晕这里用一个具体的 MySQL 8.0 部署把命令串起来。很多网上教程会直接让你跑一条 run但实践中我的步骤是分层的。第一步准备好宿主机数据目录避免 mysql 容器以 root 身份在目录里创建文件后难以维护mkdir -p /data/mysql/{data,conf,logs}第二步运行容器docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDRoot123456 \ -e TZAsia/Shanghai \ -v /data/mysql/data:/var/lib/mysql \ -v /data/mysql/conf:/etc/mysql/conf.d \ -v /data/mysql/logs:/var/log/mysql \ --restart unless-stopped \ mysql:8.0 \ --character-set-serverutf8mb4 \ --collation-serverutf8mb4_unicode_ci镜像后面跟的--character-set-serverutf8mb4不是 docker 命令参数而是传给 MySQL server 的启动参数这是 run 的一种经典透传特性。如果不方便写在命令行还可以放在挂载的/etc/mysql/conf.d下写一个character-set.cnf效果一样。第三步验证。先看启动日志里是否出现 ready for connectionsdocker logs mysql8 21 | grep -E ready for connections然后进入容器用 MySQL 客户端测试docker exec -it mysql8 mysql -uroot -p如果外部工具连不上优先检查宿主机防火墙、-p 3306:3306是否生效以及 MySQL 里 root 的 host 是否被限制为 localhost。很多人第一次部署 MySQL 都在最后一步翻车因为 root 用户默认只能从容器内登录。这时候在容器里执行一条授权即可CREATE USER dev% IDENTIFIED BY Dev123456; GRANT ALL PRIVILEGES ON *.* TO dev%; FLUSH PRIVILEGES;2.4 用 Redis 主从理解自定义网络与内部通信Redis 主从部署看起来只是多跑一个容器但其中藏着一个 Docker 网络的重要考点容器之间不要依赖宿主机 IP而应该用容器名通信。先创建一个自定义网络docker network create redis-net再启动主节点docker run -d --name redis-master \ --network redis-net \ -p 6379:6379 \ redis:7-alpine \ redis-server --appendonly yes从节点启动时指向的不是宿主机127.0.0.1:6379而是容器名redis-masterdocker run -d --name redis-slave \ --network redis-net \ -p 6380:6379 \ redis:7-alpine \ redis-server --replicaof redis-master 6379验证主从状态docker exec -it redis-slave redis-cli info replication输出里master_link_status:up表示主从正常。这里的关键是自定义网络上启用了 Docker 内置 DNS容器名可以被同网络下的其他容器解析成对应 IP。如果用默认 bridge 网络旧版本容器之间只能靠 IP 访问一旦容器重建 IP 就变了非常痛苦。所以从 Redis 主从这个需求开始我就建议养成“先建网络再跑容器”的习惯。3. 用 Compose 把多容器编排成一条命令当容器数量超过三四个逐条 run 已经不适合维护了。Compose 的价值不是省那几行命令而是把容器、网络、卷、依赖关系写进一个声明式文件让整套环境可移植、可追踪、可审计。Docker 官方现在的推荐是docker composev2 插件而不是老旧的docker-compose。3.1 Compose 的核心配置字段与启动命令一个最小可用的 compose 文件长这样services: web: image: nginx:1.25-alpine ports: - 8080:80 restart: unless-stopped不用写顶层的version字段新版本 Compose 已经忽略它写了反而可能带来旧版兼容提示。核心是services映射里面每个 key 都是一个服务名也就是网络上的主机名。常用字段我需要单独说几个image直接指定镜像。如果下面还有build则优先构建。build指定 Dockerfile 目录例如build: ./backend配合docker compose up --build使用。ports端口映射写成宿主机端口:容器端口。注意就算值看起来是数字也建议加引号避免 YAML 解析成其他类型。environment环境变量可以写成列表或字典推荐字典格式更清晰。volumes数据卷或目录挂载。depends_on依赖启动顺序。但这只是“等容器启动”不保证“等容器可用”。比如数据库容器虽然起来了但初始化还没完成后端连接就失败。要解决这个问题需要配合healthcheck。healthcheck健康检查定义常用test、interval、timeout、retries。启动命令整套如下docker compose up -d docker compose ps docker compose logs -f backend docker compose exec backend sh docker compose down其中down本身不删数据卷默认只停容器和网络。如果要清掉所有关联卷用down -v。这个-v相当危险会把数据库数据一起删掉操作前一定确认有没有持久化。3.2 一个后端 MySQL Redis 的微服务项目落地方案空讲字段不够直观我用一个常见的微服务启动场景完整展示。假设项目有 backend 服务依赖 MySQL 和 Redis后端 Dockerfile 在./backend目录。compose 文件services: mysql: image: mysql:8.0 container_name: demo-mysql restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: Root123456 MYSQL_DATABASE: demo TZ: Asia/Shanghai volumes: - mysql-data:/var/lib/mysql ports: - 3306:3306 healthcheck: test: [CMD, mysqladmin, ping, -h, localhost, -pRoot123456] interval: 10s timeout: 5s retries: 5 redis: image: redis:7-alpine restart: unless-stopped command: redis-server --appendonly yes volumes: - redis-data:/data ports: - 6379:6379 healthcheck: test: [CMD, redis-cli, ping] interval: 10s timeout: 3s retries: 5 backend: build: ./backend restart: unless-stopped ports: - 8080:8080 environment: DB_HOST: mysql DB_USER: root DB_PASSWORD: Root123456 REDIS_HOST: redis TZ: Asia/Shanghai depends_on: mysql: condition: service_healthy redis: condition: service_healthy执行docker compose up -d注意观察依赖。MySQL 容器只有通过mysqladmin ping检查才算健康backend才会真正创建。这套机制比单纯depends_on可靠得多是我在 dev 和测试环境反复验证后的标准做法。进入后端排查时容器名或者服务名backend在网络里可以直接访问mysql:3306和redis:6379一点都不需要关心宿主机 IP。这也是 Compose 带来的最大便利。3.3 Compose 与生产环境相关的几个坑第一容器内时区。很多镜像基础层是 UTC如果不在environment里加TZAsia/Shanghai日志和数据库时间都会偏 8 小时。别指望所有镜像默认设置好时区加一个环境变量是最稳的。第二挂载目录的权限。bind mount宿主机目录到容器里很容易出现Permission denied本质是 UID/GID 不匹配。简单粗暴的方案是把宿主机目录权限改成 777但生产环境不推荐。更好的方式是在镜像或 compose 里指定运行用户组或者在 Dockerfile 里useradd一个和宿主机 UID 相同的用户。第三端口冲突。compose 里如果把多个项目都映射到3306:3306第二个项目启动就会失败。一个很有用的思路是应用之间的内部访问尽量走容器网络不要每次都映射到宿主机端口。只有真正需要外部访问的服务才暴露端口。4. 网络与数据卷持久化与互联的底层原理很多人 docker 命令敲得溜但一遇到网络不通、数据丢失就懵。这一节把两个最容易被表面命令掩盖的底层机制讲清楚。4.1 四种网络模式与自定义网络的工作方式Docker 网络先看大框架默认存在四种模式。bridge是默认模式通过虚拟网桥为容器分配内网 IP容器和外界通信经过 NAT 转换。host模式直接共享宿主机网络栈没有端口映射概念性能好但隔离差网络配置容易冲突。none模式关闭网络用于极端隔离场景。overlay模式主要用于 Swarm 集群跨节点通信日常单机用得少。命令层面掌握三条docker network ls docker network create app-net docker network inspect app-netinspect能看到具体有哪些容器挂在网络下、每个容器的 IP、网关、子网掩码。排查网络不通时第一步不是 ping而是“你俩到底在不在一张网里”。不同网络下的容器不能直接互通除非通过宿主机端口映射。为什么自定义网络比默认 bridge 好用核心是内置 DNS。在默认 bridge 中Docker 旧版本不提供 DNS 解析容器间访问只能靠--link或固定 IP自定义 bridge 则会为每个容器记录主机名容器名就是域名。只要两个容器在同一个app-net里我用docker exec app1 ping app2直接就通了。这一点在 2.4 的 Redis 主从里已经体现过。生产环境排网络问题我的固定顺序是检查docker network inspect确认容器在同一网络。进入容器 ping 网关和对方容器名。如果内部通、外网不通查宿主机防火墙和端口映射。如果端口映射不通查ss -tlnp看宿主机端口有没有被占用或防火墙放行。4.2 数据卷、绑定挂载与容器权限容器删除后文件系统并不会消失但只有写在挂载卷或数据卷里的内容才能持久保留。理解三种挂载方式的区别很重要bind mount把宿主机目录挂到容器目录例如-v /data/mysql:/var/lib/mysql。好处是文件直接可见、方便备份坏处是宿主机目录权限直接决定容器内访问权限目录不存在时需要先创建。named volume由 Docker 管理例如-v mysql-data:/var/lib/mysql。数据存放在/var/lib/docker/volumes/mysql-data/_data作用上像一个数据抽屉容器删了数据还在。tmpfs写入宿主机内存不落盘适合放临时文件。常用命令docker volume create app-data docker volume ls docker volume inspect app-data docker volume rm app-data备份数据卷最直接的方式是先用一个临时容器把卷打包出来docker run --rm \ -v app-data:/data:ro \ -v /backup:/backup \ alpine tar czf /backup/app-data.tar.gz -C /data .这里--rm表示临时容器用完自动删除:ro表示以只读方式挂载原卷避免备份过程中写坏数据。4.3 GitLab 社区版部署80/22 端口冲突与数据卷规划把 GitLab 社区版用 Docker 跑起来是很多团队维护内部代码仓库的常见需求。它有明确的“官方 docker run 最佳实践”直接抄即可但里面有两个坑必须提前说清楚。先看部署命令docker run -d \ --name gitlab \ --restart always \ -p 8080:80 \ -p 8443:443 \ -p 2222:22 \ -v /srv/gitlab/config:/etc/gitlab \ -v /srv/gitlab/logs:/var/log/gitlab \ -v /srv/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:16.4.0-ce.0第一个坑是宿主机 SSH 端口。GitLab 镜像内部的 SSH 默认监听 22但宿主机 22 通常已经被 system sshd 占用所以映射成2222:22。这意味着 git clone 地址要改成ssh://gityourhost:2222/group/repo.git而且需要在 GitLab 配置里同步修改docker exec -it gitlab editor /etc/gitlab/gitlab.rb配置项是gitlab_rails[gitlab_shell_ssh_port] 2222。改完执行docker exec -it gitlab gitlab-ctl reconfigure第二个坑是初始密码。新部署的 GitLab 会生成一个随机初始 root 密码保存在容器的/etc/gitlab/initial_root_password文件中且 24 小时后自动删除。如果你没设置环境变量务必第一时间查看docker exec -it gitlab grep Password: /etc/gitlab/initial_root_password生产环境我还会把external_url改成正式域名例如http://gitlab.example.com否则生成的 clone 地址永远是容器主机名。5. 命令行排错实录那些年我踩过的坑这条线上踩坑多了自然就能形成一套快速排查的直觉。我把最高频的几类问题拿出来把原因和解决路径一次讲清。5.1 Permission denied 与 npipe 连接失败Linux 下的权限问题前面已经提到加入 docker 组。但如果已经加入 docker 组依旧报错另一个常见原因是 docker 守护进程没起来或者 socket 文件权限被改动。先检查ls -l /var/run/docker.sock如果这个文件不存在说明守护进程根本没有正常启动服务拉起来再说。Windows 下 Docker Desktop 报npipe:////./pipe/dockerDesktopLinuxEngine连接失败我遇到最多的情况是引擎还没启动完成。命令行等个十几秒再敲命令往往就通了因为 Desktop 的图形面板启动很慢但 CLI 不会告诉你“再等等”。如果一直失败就回到 1.2 检查虚拟化、WSL2 和系统组件。不要在还没有确认 Engine 状态时反复重启终端这会误导判断。5.2 bind: address already in use 端口排查启动容器时最常见的报错之一docker: Error response from daemon: driver failed programming external connectivity on endpoint xxx: Bind for 0.0.0.0:3306 failed: port is already allocated原因明确了端口被占用。排查顺序ss -tlnp | grep 3306 netstat -tlnp | grep 3306 lsof -i:3306如果是另一个容器占用了同端口docker ps就能看到。如果是宿主机进程占用就要决定是杀掉旧进程还是给新容器换端口。我一般倾向换端口而不是强杀未知进程尤其生产服务器上你并不知道那个进程在干什么。5.3 镜像拉不动、超时怎么办docker pull超时或者极慢是最常见的问题之一。原因大多是默认 Docker Hub 的 registry 镜像源在我们这边访问不稳定。解决方案是配置加速源也就是registry-mirrors。Linux 下改/etc/docker/daemon.json{ registry-mirrors: [https://docker.mirrors.example.com] }改完执行sudo systemctl daemon-reload sudo systemctl restart dockerDocker Desktop 用户则可以在设置界面的 Docker Engine 配置里加入同样的 JSON 字段然后重启 Desktop。配置好之后再用docker pull会明显顺畅。需要注意不要每个镜像都写死某个私有加速源团队环境里最好统一维护一份标准配置否则换一个人排错头大如斗。5.4 容器秒退/反复重启的检查顺序docker ps -a里经常看到Exited (1)或Restarting这种状态通常不是 Docker 的问题而是容器内应用的问题。检查顺序我固定为第一步看日志docker logs --tail 200 --details 容器名日志里如果显示配置文件不存在、环境变量为空、端口连不上先去补这些外部依赖。第二步看入口命令。如果镜像默认入口是nginx -g daemon off;但你覆盖成了/bin/bash没有附加-it的情况下 bash 拿到无终端输入会立刻退出。此时改成docker run -it就能看到退出前的真实输出。第三步检查健康检查是否过严。Compose 里 healthcheck 连续失败会触发重启但不说明应用真挂了有时只是mysqladmin ping的密码不对导致一直被认为不健康。6. 提升效率的命令习惯与日常维护命令本身学会不难难在把它变成肌肉记忆和高效习惯。最后这部分是我个人日常维护里最常用的小技巧不写长篇大论都是可以直接抄作业的。6.1 格式化输出与批量操作docker ps默认打印所有列列一多就眼花。我更推荐的写法是自定义格式docker ps --format table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}甚至可以把它设置成 shell 别名比如alias dpsdocker ps --format table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}查看资源占用用docker stats但默认是持续刷新的跑完就退出可以加docker stats --no-stream批量操作容器时docker ps -q是核心docker stop $(docker ps -q) docker rm $(docker ps -aq)xargs也很常用比如批量删除所有 exited 容器docker ps -aq --filter statusexited | xargs docker rm6.2 空间清理prune 的正确打开方式磁盘被镜像和容器日志占满是我接手服务器后最常见的故障。docker system df可以先看整体占用docker system df输出会按镜像、容器、卷、构建缓存分别显示占用。然后谨慎使用清理命令docker container prune docker image prune docker volume prune docker system prune -asystem prune -a会清掉所有未使用的镜像、停止的容器和网络但默认不会删数据卷。加上--volumes才删卷。反向警示这条命令一旦执行很多本地的历史镜像和旧卷将无法恢复。我的习惯是准备清理前先docker image ls确认没有需要保留的版本确认后再加-a -f并且永远不要把生产库所在的数据卷交给 prune 自动处理。6.3 我的日常命令组合拳最后分享一个我自己的习惯。每次接手新项目我第一步永远是docker ps -a加docker inspect看状态而不是直接启动服务。第二步看日志第三步看环境变量和挂载。这个顺序永远不会错。另一个习惯是把常用命令写成脚本。比如我本地有个dc.sh内容类似docker compose ps docker compose logs -f --tail 100 docker compose down --remove-orphans docker compose up -d --build这样即使换了新机器只要脚本文件在环境很快就能搭起来。命令行不是背出来的是每天在真实场景里敲出来的。多部署几个 MySQL、Redis、GitLab多把 compose 编排理解透再遇到报错你不需要搜遍全网光看字段和日志就能猜到问题在哪。
