平时排查问题、部署服务我最依赖的工具里Docker 绝对排前三。它把应用、环境、配置全部打包成标准单元终于让“在我机器上好好的”这类老问题有了统一的解法。今天不聊 Dockerfile 怎么写高大上也不聊集群编排平台只把日常摸爬滚打里最常用的 Docker 常用指令完整过一遍从容器生命周期、镜像管理到网络数据卷和 Compose 编排每一组都带上我的使用习惯和踩坑记录方便你随时查、抄、改。内容会偏实战默认你已经装好了 Docker 环境。如果你正在学习或维护云主机这套指令绝对是最高频的骨架。遇到命令记不清直接看对应小节遇到容器退不出、镜像删不掉、磁盘被日志打满跳到最后那节排查清单就行。1. 啃指令之前先把基础视图搭起来1.1 确认版本和环境健康度很多奇怪的问题第一章其实是版本不对。Docker 分为客户端和服务端两部分平时敲docker version两条信息会一起显示但经常被人忽略如果你本地 Docker 命令是新版而远端服务端还是老版本某些参数就可能不支持表现出的症状往往是“同样的命令别人能用我这报错”或者“参数没反应”。我每次接手新环境第一件事就是跑三条命令docker version # 查看客户端和服务端版本 docker info # 查看系统、存储驱动、运行容器数等环境信息 docker system df # 查看镜像、容器、数据卷、构建缓存占了多少磁盘docker info里有两个关键信息要看一个是 Storage Driver现在绝大多数是 overlay2另一个是 Server Version。这两个和故障排查直接相关。比如容器读写性能异常或者镜像层合并行为不符合预期基本都会先怀疑存储驱动。docker system df很多人不爱敲但它是磁盘爆炸前的预警器。它会告诉你多少空间被镜像占用多少被可写层占用多少是被停止的容器占着还有多少是 Build Cache。在连续构建很多次镜像之后Build Cache 膨胀起来非常夸张有时候比镜像本身还大。养成每周看一眼的习惯比等到服务器告警再救急舒服得多。1.2 先把命令行语法框架装进脑子Docker 命令的通用结构是docker [全局选项] 子命令 [子命令选项] [参数]全局选项常用的有-H指定服务端地址、--tlsverify启用 TLS 认证单机场景很少用到。真正高频的是各个子命令的参数例如docker run -d --name nginx nginx:1.26中run是子命令-d、--name是子命令选项nginx是镜像名。理解这个框架后你会发现 Docker 的指令设计很有规律。很多子命令之间是互补关系镜像是模板容器是运行实例pull负责拉取build负责制作run负责启动commit负责从容器生成新镜像save/load用于离线迁移export/import用于平铺打包。把它们按场景分组而不是单个单个死记效率会高很多。我个人的记忆线索是四组处理容器run、start、stop、restart、rm、pause处理镜像pull、images、build、tag、push、rmi处理网络和卷network、volume、port、cp组合管理compose、stack后面每个章节就按这套分组展开遇到不会的随时回来翻。2. 容器生命周期最高频的一组指令2.1 容器创建与启动run里的隐藏学问docker run是绕不过去的第一条指令。它本质上做了好几步先检查本地有没有对应的镜像没有就走pull然后基于镜像创建一个可写容器层再启动这个容器最后默认把终端接到容器的标准输入输出上。所以这条命令的参数非常密集。给你看一条我常用的相对完整版本docker run -d \ --name nginx-web \ -p 8080:80 \ -v /home/data:/usr/share/nginx/html \ -e TZAsia/Shanghai \ --restart unless-stopped \ --network my-net \ nginx:1.26逐个拆解一下-d后台运行终端不用一直挂着。不加的话前台运行Ctrl-C 或退出终端容器就会被终止除非配置了其他策略。--name给容器起名字。不指定的情况下 Docker 会随机生成一个名字排查问题时不好认能起名尽量起名。-p 8080:80把宿主机的 8080 端口映射到容器的 80 端口。这个参数可以写多组例如-p 3000:3000 -p 8080:80。-v /home/data:/usr/share/nginx/html目录挂载。宿主机目录和容器目录一一对应容器里的文件修改会直接写回宿主机这是数据持久化的核心手段。-e TZAsia/Shanghai注入环境变量。很多镜像都需要通过环境变量配置初始密码、时区、运行模式。--restart unless-stopped自动重启策略。这个参数比我预想的重要得多生产环境里我几乎每台容器都会带上。它的语义是容器异常退出时自动拉起但如果是被手动stop的则不会再拉起来。--network my-net加入指定网络。容器默认在 bridge 网络里独立网络可以方便容器间用名字互访。还有一个好用参数是--rm表示容器停止后自动删除。临时跑一条命令、调试一个脚本时特别合适比如docker run --rm -it ubuntu:22.04 bash退出 shell 后容器立刻消失不会留一堆垃圾容器。但注意如果你同时用了-d和--rm容器后台运行停止时同样会触发自动删除千万别把它和经济型-d搞混。2.2 查看、进入容器内与日志追踪容器起来了接下来要看状态、看日志、进容器内部操作。docker ps是最常用的查询指令docker ps # 只看运行中的容器 docker ps -a # 查看所有容器包含已停止的 docker ps -q # 只输出容器 ID docker ps -a --filter namenginx-web # 按名字过滤 docker ps --filter statusexited # 只看已退出的容器我实际使用中-q和--filter的搭配很强。清理资源时可以快速拿到一批容器 ID直接传给删除指令docker rm $(docker ps -aq --filter statusexited)连贯操作比一条条点确认舒服得多。查看日志用docker logsdocker logs nginx-web # 查看全部日志 docker logs -f nginx-web # 实时跟踪类似 tail -f docker logs -f --tail 200 nginx-web # 只跟踪最近 200 行 docker logs -t nginx-web # 每行带时间戳容器启动失败时第一时间看日志几乎能定位 80% 的问题。先确认容器是否真的起来了再确认日志内容不要一上来就重构或改文件。进入运行中容器内部最常用的是docker exec -it nginx-web bash-i表示保持标准输入打开-t分配一个伪终端合在一起才能进入交互式 shell。如果容器镜像比较精简没有 bash就换成sh。还有docker attach它会把终端挂到容器的主进程上但一旦你按 Ctrl-C容器主进程可能会收到 SIGINT 而退出。生产环境我基本不用 attach需要交互和调试时一律走exec。另外几个实用指令顺手提一下docker top nginx-web # 查看容器内的运行进程 docker port nginx-web # 查看端口映射关系 docker diff nginx-web # 查看容器内文件系统的新增、修改和删除 docker cp 宿主机文件 nginx-web:/容器路径 # 拷贝文件进出容器docker diff容易被忽略但它对排查“容器运行后到底改了哪些系统文件”非常有用。某个镜像被篡改、或者你在容器里手滑改了配置文件都能通过它快速定位差异。2.3 停止、删除与批量清理的安全操作停容器有讲究。docker stop给容器主进程发送 SIGTERM让它优雅退出等待默认 10 秒后再发送 SIGKILL 强制杀死。如果应用有收尾逻辑比如写缓存、保存状态它会在这 10 秒内完成。docker restart同理只是多一步重启。docker stop nginx-web docker start nginx-web docker restart nginx-web docker pause nginx-web # 暂停容器中所有进程但容器仍在运行 docker unpause nginx-web # 恢复 docker rm nginx-web # 删除容器删除前最好先 stop docker rm -f nginx-web # 强制停止并删除pause和stop很多人分不清。pause 只是冻结进程容器状态依然显示 UpPaused内存和文件系统都保留适合暂时挂起比如做备份、做一致性检查。stop 是真正把主进程结束再启动时会以原状态重新开跑。清理容器时我最常用的批量命令是docker container prune # 清理所有已停止的容器它会提示你要删除的容器列表确认后才动手。如果想一次性连确认都不打加-f。批量删所有容器包括运行中的比较危险docker rm -f $(docker ps -aq)这条命令一定要想清楚再执行。它会把机器上所有容器全部干掉常用于清场重来。在测试机无所谓在生产线就要慎重我习惯先跑docker ps -a看一遍再执行。3. 镜像管理拉取、构建、导出与瘦身3.1 镜像搜索、拉取与标签规范镜像就是容器的模板文件系统。docker pull负责从仓库拉取docker pull ubuntu:22.04 docker pull nginx:1.26如果不指定 tag默认拉latest。latest是个方便但危险的标记因为它会指向最新版本每次拉取可能内容都不一样。我个人的线上规则是所有正式环境镜像必须锁定精确版本号无论是nginx:1.26还是postgres:16.2都不允许裸用latest。这样升级可控、回滚也方便。了解仓库里有哪些镜像可以用docker search nginx docker images # 列出本地镜像 docker image ls -a # 包含中间镜像层docker search用于在 Docker Hub 上搜镜像名但能看到的信息有限关键指标是官方源标记OFFICIAL和星标数。生产环境优先选择官方源其次选更新时间近、星标记较大的维护版本。镜像命名规则看起来简单却常有人踩坑。完整镜像名格式是[仓库地址/命名空间/]镜像名[:标签]缺省仓库地址时默认 Docker Hub缺省命名空间时默认library官方源。例如nginx:1.26实际就是docker.io/library/nginx:1.26。自建仓库时镜像名要带上仓库地址比如my-registry:5000/app/web:1.0。构建和推送时最容易在这块出错。3.2 构建镜像build、tag、push的完整链路本地写好了 Dockerfile一条docker build就能生成镜像docker build -t myapp:1.0 .-t指定镜像标签后面的.是构建上下文路径。所谓构建上下文就是把该目录下所有文件打包发送给 Docker 守护进程用于解析 Dockerfile 中的COPY和ADD。所以平时别把大型临时文件、node_modules、缓存文件放进构建目录避免镜像构建变慢、变臃肿。调试构建时常用两个参数docker build --no-cache -t myapp:1.0 . # 完全重新构建命令不缓存 docker build --target build-stage -t myapp:1.0 . # 只构建多阶段中某个阶段--no-cache在依赖更新出问题或 Dockerfile 的缓存策略异常时很好用。--target用于多阶段构建的调试阶段比如只想编译产物不想一直完成最终精简阶段。生成新镜像的另一条指令是docker commit它会把一个运行中容器的当前文件系统状态保存为新镜像。这个方法能跑但我强烈不建议作为常规手段因为它会把容器运行中的脏状态、历史操作全打包进去镜像内容不可控也无法复现。我只有在极特殊情况下比如辅助排障复盘才会用它做一次性归档。镜像打标签和上传docker tag myapp:1.0 my-registry:5000/library/myapp:1.0 docker push my-registry:5000/library/myapp:1.0tag不复制镜像内容只是给镜像增加一个引用。同一个镜像 ID 可以有多个 tag删除其中一个 tag 不会影响镜像实体只有所有 tag 都删掉后镜像才会真正被清理。离线环境迁移常用docker save -o myapp.tar myapp:1.0 # 把镜像打包成 tar 文件 docker load -i myapp.tar # 从 tar 文件导入镜像save保存的是镜像层完整历史load后能保留 tag 和构建信息适合跨机器共享整套镜像。还有一组export/importdocker export -o container.tar nginx-web # 把容器文件系统导出 docker import container.tar myapp:imported # 导入为镜像export是把容器当前文件系统全部平铺出来原有分层信息和历史记录全部丢失导入后是一个扁平的镜像。前者适合镜像分发后者适合“截取当前容器状态”做快照两者不要混用。3.3 镜像删除、历史审查与空间瘦身删除镜像用docker rmidocker rmi nginx:1.26 docker image rm myapp:1.0如果发现删不掉大概率是有容器还在引用这个镜像哪怕容器已经停止。Docker 的引用关系是容器存在于镜像之上只要容器没删除镜像就无法释放。所以正确的删除顺序是先删容器再删镜像。批量清理悬空镜像dangling images非常有用。悬空镜像指没有被任何 tag 引用、只剩\none\的镜像层通常是多次 build 后残留的中间产物docker image prune docker image prune -a # 删除所有未被容器使用的镜像要谨慎我处理大型磁盘占用时会先跑docker system df看分布然后分类型清理。整体一条命令docker system prune -a --volumes这条命令会把停止的容器、无用网络、悬空镜像、未使用的构建缓存全清掉如果加了--volumes连同未使用的数据卷一起干。除非确认机器上所有数据都不再需要否则不要带--volumes我见过有人图省事把重要卷删了后面再也找不回。查镜像构建历史和信息docker history myapp:1.0 # 查看镜像每一层的构建指令及大小 docker inspect myapp:1.0 # 查看镜像配置、环境变量、入口、卷等详细信息history是排查镜像体积的关键入口。看到某一行容量特别大基本就能锁定是哪个 RUN 阶段引入了大量文件随后可以针对性做清理或多阶段拆分。inspect输出的 JSON 很长我通常只关心某几个字段docker inspect -f {{.Config.Env}} myapp:1.0 docker inspect -f {{.Config.ExposedPorts}} myapp:1.0这种格式化输出比整个 JSON 翻找舒服很多适合写脚本批量提取配置。4. 网络与数据卷让容器不再“孤立”4.1 端口映射与网络模式到底在映射什么默认情况下容器内部是独立的网络命名空间宿主机访问不到它外部更访问不到。端口映射-p就是在宿主机和容器之间做一道转发规则。三种写法需要分清楚-p 8080:80 # 将宿主机的 8080 映射到容器的 80 -p 8080:80/tcp # 指定 tcp 协议默认就是 tcp -p 127.0.0.1:8080:80 # 只允许本机访问宿主机的 8080更安全如果你用-P大写Docker 会把容器内暴露的端口随机映射到宿主机高位端口适合临时测试。但生产环境我基本不碰大写-P因为端口不确定性太强维护困难。Docker 有多种网络模式。最常见的几个bridge默认容器通过虚拟网桥与宿主机通信容器间默认隔离。host容器直接使用宿主机网络栈没有端口映射性能高但隔离性差。none容器没有网络只有回环接口适合跑纯计算任务。自定义网络使用docker network create创建支持容器间 DNS 自动解析。和网络相关的指令组是docker network ls # 列出网络 docker network create -d bridge my-net # 创建 bridge 自定义网络 docker network connect my-net nginx-web # 把运行中的容器加入网络 docker network inspect my-net # 查看网络详情 docker network disconnect my-net nginx-web自定义网络是我强烈建议优先使用的方案。它的最大特点是同一个网络里的容器可以用容器名直接互相访问而不需要依赖局域网 IP。比如后端容器里访问数据库可以直接postgres:5432IP 变了也没事。如果用默认 bridge 网络容器之间只能通过 IP 互访而 Docker 容器 IP 重启后会变维护难度直线上升。4.2 数据卷和数据挂载容器可以删数据不能丢容器删除后可写层会跟着被销毁。如果应用把状态写在容器内部比如数据库文件、上传的图片、日志文件容器一删这些数据就全部蒸发了。所以数据必须持久化到容器外部。Docker 提供两种主流方式U1. 数据卷Volume使用-v 卷名:/容器路径。docker volume create mydata docker run -d --name app -v mydata:/data app:latest docker volume ls docker volume inspect mydata数据卷由 Docker 管理存储在宿主机特定目录下有统一的文件组织。推荐在需要跨容器共享数据、不需要直接操作宿主文件时使用。绑定挂载Bind Mount使用-v /宿主机路径:/容器路径。docker run -d --name web -v /home/web/html:/usr/share/nginx/html nginx:1.26绑定挂载直接把宿主目录映射进容器。好处是在宿主机上就能直接改文件、读日志、备份数据非常直观。坏处是目录位置一旦移动容器就得重建对宿主机目录权限也更敏感。还有一种更推荐的写法是--mountdocker run -d \ --name web \ --mount typebind,source/home/web/html,target/usr/share/nginx/html \ nginx:1.26--mount的键值对清晰支持readonly等选项比-v更容易读明白特别是选项多的时候。数据卷删除需要格外小心docker volume rm mydata docker volume prune # 删除所有没有被任何容器引用的卷 docker volume prune -avolume prune会清掉没有容器使用的卷。问题是容器被删除后卷虽然还在但你根本没有提示说哪些是重要的、哪些是垃圾。所以我每次手工清理卷之前都会先docker volume ls加docker volume inspect看一遍确认没有生产数据混在里面。用一句话总结我的习惯容器可以随时删镜像可以重新拉卷里的数据一旦没了神仙难救。5. Docker Compose 指令一套命令管理一组服务5.1 启动与停止up、down、restart单容器用上面的指令就行但多服务项目应用、数据库、缓存、队列再用一长串docker run就太折磨了。Compose 解决的是“一组容器”协同管理的问题。它通过一个 YAML 文件描述服务、网络、卷然后用一条指令完成整体启停。最核心的是docker compose up -d docker compose downup -d会根据当前目录下的compose.yaml或docker-compose.yaml创建网络、拉取/构建镜像、启动所有服务。-d表示后台运行不带它时前台运行日志会直接滚到你终端上Ctrl-C 会停掉所有服务适合调试。down默认会停止并移除由 compose 创建的所有容器还会删除默认生成的网络。注意它不会删除数据卷除非显式带-v。docker compose down # 停止并移除容器和网络 docker compose down -v # 额外删除数据卷数据无慎用 docker compose down --rmi local # 额外删除本地构建的镜像如果只是临时停一下服务又不想拆掉网络和容器用docker compose stop # 停止所有服务容器和网络都保留 docker compose start # 重新启动已停止的服务 docker compose restart # 重启所有服务这个组合在日常开发中比down更常用因为保留容器意味着再次启动速度更快卷和网络状态也基本保持。Compose 文件示例不用太长我给一个能跑通的最小结构services: web: image: nginx:1.26 ports: - 8080:80 volumes: - ./html:/usr/share/nginx/html app: build: . environment: - DB_HOSTdb db: image: postgres:16 volumes: - dbdata:/var/lib/postgresql/data volumes: dbdata:在这个结构下只需两个指令就能完成整套环境的拉起和销毁docker compose up -d docker compose down绝大多数的本地联调场景这两条指令足够。5.2 查看、调试与校验ps、logs、exec、configCompose 模式下不推荐再挨个用docker ps、docker logs去查单个容器虽然能查到但太麻烦了。有更贴合场景的指令docker compose ps # 只显示 compose 管理下的服务状态 docker compose logs -f --tail 100 # 查看整个项目的日志-f 实时跟踪 docker compose logs web # 只查看某个服务日志 docker compose exec web bash # 进入某个服务容器 docker compose top # 查看各服务容器内进程这里有一个容易踩坑的点docker compose logs是按服务名过滤的不是按容器名。在docker logs -f 容器ID里你要找容器名但在 Compose 里直接用服务名写错名字会提示不知道这个服务。还有一个经常被遗忘但非常实用的指令docker compose config它会把你当前目录的 compose 文件解析并输出最终配置。出现 YAML 缩进错误、字段拼错、环境变量格式不对等问题时config是最快的检查手段。如果文件有问题它会直接指出哪一行不合法。在修改 compose 文件后完整生效需要重新加载docker compose up -d不要随手就down再up。对于配置变更直接up -d就足够它只会重建配置变动的服务其他服务保持不动。这套“增量更新”逻辑比“全量重启”高效且风险低。Compose 也支持查看事件流和资源统计docker compose events # 流式显示容器生命周期事件 docker compose cp web:/data/log.txt ./log.txtcp在 Compose 下同样好用只不过第一参数是“服务名:路径”不需要记容器 ID。6. 实际踩坑与排查技巧实录6.1 容器启动失败到底该怎么定位容器一启动就退出新手常见操作是反复run、反复看日志但定位效率很低。我给你一套固定排查路径。第一步确认容器当前状态docker ps -a如果有个容器状态是 Exited (1)说明主进程退出并传出了状态码。1 通常代表通用错误137 是被 SIGKILL 杀了143 是被 SIGTERM 正常终止。状态码能提供第一层线索。第二步看日志docker logs --tail 200 --timestamps 容器名日志里常出现配置文件路径不对、依赖连接不上、权限不足、端口被占用等问题。如果完全没有日志多半是主进程直接被 signal 杀掉或者应用在前台模式下没有成功绑定。第三步用 inspect 看宿主机视角的信息docker inspect 容器名 docker inspect -f {{.State.ExitCode}} 容器名 docker inspect -f {{.HostConfig.PortBindings}} 容器名重点看State、Error、HostConfig。有时候端口映射已经占了容器启动后立即拒绝监听报错反而不会出现在应用日志里。还有一个非常常见的原因容器主进程是前台进程但 Docker 要求容器必须有一个持续运行的前台进程。如果你的镜像里写的是CMD tail -f /dev/null这类占位命令它没问题但如果写了后台启动命令容器可能秒退因为主进程结束就等于容器结束。排查时先问一句容器的 PID 1 是什么。6.2 磁盘被容器日志撑爆怎么快速止血运行中的容器会产生大量日志Docker 默认不限制日志文件大小时间一长/var/lib/docker/containers/...下面的日志文件会飙到几十 GB。最直观的预判指令是docker system df如果看到容器可写层和日志占用异常大就要立刻处理。常用的手工清理方式truncate -s 0 $(docker inspect -f {{.LogPath}} 容器名)这条命令会把指定容器的日志文件直接清空可以临时止血但治标不治本。更推荐在创建容器时就限制日志上限docker run -d --log-opt max-size10m --log-opt max-file3 nginx:1.26在 Compose 文件里同样可以配置services: web: image: nginx:1.26 logging: driver: json-file options: max-size: 10m max-file: 3配置之后每个日志文件最多 10 MB最多保留 3 个滚动轮换不会无限膨胀。这是我认为性价比最高的磁盘保护手段比事后清理强太多。6.3 拉取镜像慢或失败时先别急着反复 pull拉取镜像超时最常见的是公共仓库连通性受网络环境影响。很多人第一反应是重试但重试只能缓解不能根治。除了等待网络恢复更有效的方法是配置镜像加速器。在 Docker 配置文件中添加registry-mirrors把公共仓库请求转发到可用加速地址可以显著提高pull成功率。配置后记得重启 Docker 服务然后重新pull测试。如果配置了镜像加速仍然拉不动建议检查这几项docker info | grep -i registry-mirror # 如果配置成功会显示加速地址 ping 对应域名 # 检查基础连通性另外注意架构差异。在 ARM 服务器上拉 x86 镜像或者反过来会报错或者运行直接崩。明确指定平台拉取docker pull --platform linux/amd64 ubuntu:22.04 docker pull --platform linux/arm64 ubuntu:22.04这个参数在异构服务器运维时特别重要。如果一个镜像同时支持多种架构平台不对会干扰判断。6.4 误删容器和数据卷后还有救吗先把最残酷的结论讲在前面数据卷被删除后没有常规恢复手段。无论用什么工具丢失的数据都很难找回来。所以我强烈建议整个团队约定一条规则关键数据一定要使用绑定挂载放在宿主机明确目录而不是藏在一个匿名卷里。这样即使容器全被清理目录备份、同步、迁移都还在可控范围内。如果只是误删容器情况相对乐观。镜像还在的话重新docker run一个同样配置的容器就能恢复服务。麻烦的是配置参数没了所以我建议所有重要服务尽量用 Compose 描述而不是靠一串手打的docker run参数。参数写进 YAML 文件后容器再删只要文件还在原地up -d就能拉起来。docker cp也可以当作“生命线”来用。我习惯在重要容器运行稳定后定期从容器里拷贝关键配置出来docker cp nginx-web:/etc/nginx/nginx.conf ./backup/nginx.conf虽然直接用卷挂载更便于管理但在某些“容器内部动态生成配置”的场景下这种定期备份的做法能避免很多尴尬。根据我个人的踩坑经验最稳妥的组合是重要数据全部绑定挂载到宿主机目录所有服务参数写进 Compose 文件日志配置max-size限制每周执行一次docker system df检查空间。平时不需要背所有命令只要知道每组指令解决什么问题遇到场景能想起来“该去翻哪一章”就比硬背命令强很多。这组指令是骨架实际业务往里面填充流程就行但无论如何别在数据卷这件事上偷懒那是 Docker 使用中最贵的学费。
