★ FEATURED ARTICLE 1. 这不是命令手册而是一张“Docker操作导航图”你打开终端输入docker --help满屏滚动的子命令像一张密不透风的网——build、run、exec、cp、logs、ps、images、rmi、volume、network……初学者常卡在“知道有这个命令但不确定该用哪个、什么时候用、为什么这么用”的临界点上。我带过不少刚接触容器的开发者他们最常问的不是“怎么写Dockerfile”而是“我改了代码怎么让容器里立刻生效”“容器崩了日志在哪看”“镜像越积越多怎么安全删又不误删正在跑的服务”——这些问题90%都落在“常用命令”这个看似基础、实则承上启下的环节。核心关键词Docker常用命令、容器生命周期管理、镜像操作、卷与网络调试、日志与状态诊断。这不是一份按字母排序的API清单而是一套围绕真实工作流组织的“操作逻辑链”从本地构建→启动运行→交互调试→状态监控→资源清理→故障回溯。它覆盖开发、测试、CI/CD部署、日常运维四个高频场景每个命令都标注了“什么情况下必须用”“什么情况下慎用”“什么情况下根本不用”并附上参数选择背后的工程权衡。比如-d后台运行和--rm退出自动删除从来不是二选一而是根据任务类型动态组合docker cp和docker exec -it bash的取舍本质是“临时调试”和“持久化修改”的边界判断。这篇文章写给那些已经能跑通一个Nginx容器但面对复杂服务拓扑时仍会反复查文档、不敢轻易敲下rm -f的人——我们不讲原理推导只讲“按下回车前你脑子里该过哪几道逻辑”。2. 命令设计逻辑为什么是这32个而不是全部Docker CLI 提供超过50个子命令但实际项目中高频使用的稳定在32个左右。这个数字不是拍脑袋定的而是我过去三年在某高校实验室支撑17个跨平台教学系统、某公司CI/CD流水线维护、以及个人开源项目迭代中通过命令调用日志统计人工归因得出的结论。我把它们按“操作意图”而非“字母顺序”重新分组每组解决一类明确问题并剔除三类命令已废弃或被替代的如docker attach易导致终端阻塞exec更安全、docker wait极少单独使用通常嵌入脚本逻辑强依赖特定插件的如docker buildx需额外安装属于进阶构建能力不在“常用”范畴纯管理型且低频的如docker system df磁盘分析、docker trust镜像签名虽重要但平均使用间隔超72小时。2.1 容器生命周期从创建到销毁的6个关键动作容器不是静态文件而是一个有明确“生老病死”的进程实体。它的生命周期管理命令核心是控制“状态跃迁”的确定性。docker run是唯一能创建并启动新容器的命令但它不是“运行程序”的等价物——它本质是“定义容器运行时契约”。比如docker run -p 8080:80 nginx中-p不是简单端口映射而是告诉Docker Engine“在宿主机8080端口监听所有流量经iptables规则转发至容器内80端口的进程”。这里隐含了网络命名空间隔离、端口代理、连接跟踪三重机制。新手常忽略--name参数结果每次启动都生成随机ID如festive_mccarthy导致后续docker logs festive_mccarthy变成记忆负担。我的习惯是所有需要长期维护的容器必加--name 业务缩写如--name web-api-prod既便于识别也避免因ID重复触发启动失败。docker start/docker stop是对已存在容器的状态切换。注意stop默认发送SIGTERM信号等待10秒后强制SIGKILL。若容器内主进程未正确处理SIGTERM如Python脚本没写signal.signal(signal.SIGTERM, handler)就会跳过优雅关闭直接杀掉可能丢失未刷盘数据。实测某日志采集容器因未捕获信号stop后丢失最后3秒日志。解决方案有两个一是用docker stop -t 30 web-api-prod延长超时二是容器内进程必须实现信号处理逻辑——这是比记命令更重要的底层认知。docker restart看似便捷但它是stopstart的原子组合。问题在于如果容器因OOM被内核杀死restart会直接重启一个“干净”容器丢失所有运行时状态如内存缓存、临时文件。此时应先docker inspect web-api-prod查看State.ExitCode和Status确认是否为非正常退出再决定是restart还是rmrun重建。docker rm是销毁动作但必须理解其前置条件容器必须处于exited状态。若强行docker rm -f正在运行的容器Docker Engine 会先执行stop再rm相当于隐式调用两次状态变更。更危险的是docker rm $(docker ps -aq)这类“一键清空”它不区分容器用途——可能同时删掉数据库卷挂载的容器虽卷数据还在但容器元数据丢失docker volume ls无法关联原业务。我的经验是永远用docker ps -a --filter statusexited --format {{.ID}} {{.Names}}先预览再手动复制ID删除宁可多敲两行不赌一次手滑。提示docker ps -a默认只显示最近创建的容器若列表为空别急着怀疑命令失效先加-n 20查看最近20条或--before container-id定位特定时间点。2.2 镜像操作构建、拉取、清理的3层防御体系镜像是容器的“只读模板”它的操作命令构成研发环境的“可信源”防线。我见过太多团队因镜像管理混乱导致线上事故测试环境用latest标签上线时发现latest已被新版本覆盖接口协议不兼容直接雪崩。docker build的核心参数是-t打标签和-f指定Dockerfile路径。新手常犯的错是docker build .当前目录却忘了.dockerignore文件没配把node_modules、__pycache__全塞进镜像导致镜像体积暴涨3倍。正确姿势是所有build命令必须显式指定-f Dockerfile.prod并加-t myapp:v1.2.0禁止使用latest。-t的价值不仅是标识更是CI/CD中镜像推送docker push和K8s部署image: myapp:v1.2.0的唯一锚点。docker pull表面是下载实则是“校验解压存储”三步。当执行docker pull nginx:alpine时Docker Daemon 会先向Registry请求manifest包含各层sha256摘要再逐层校验本地缓存缺失层才下载。这意味着同一镜像多次pull只要层未变实际只做元数据同步毫秒级完成。这也是为什么CI流水线中pull步骤耗时极短——它不是在传大文件而是在做哈希比对。docker rmi删除镜像前必须确保无容器引用它。docker rmi nginx:alpine若报错conflict: unable to remove repository reference说明有停止的容器仍关联此镜像。此时有两种选择一是docker ps -a --filter ancestornginx:alpine找出所有相关容器并rm二是用docker image prune -f清理所有悬空镜像none:none。但注意prune不会删被引用的镜像它只清理构建过程中产生的中间层——这些层在build时因--no-cache或Dockerfile修改而失效占空间却不提供服务。我每周五下午固定执行docker image prune -a -f --filter until168h删7天前未使用的镜像配合docker system df监控磁盘占用率稳定在45%以下。2.3 卷与网络让容器“活”在真实世界里的2个支点容器默认是“无状态”的但生产系统必须有状态。卷Volume和网络Network就是让容器脱离“沙盒”、融入基础设施的桥梁。docker volume create创建的卷数据存储在/var/lib/docker/volumes/下独立目录与容器生命周期解耦。关键认知是-v /host/path:/container/path绑定挂载和--mount sourcemyvol,target/app/data命名卷不是功能差异而是管理粒度差异。绑定挂载适合开发时实时同步代码-v $(pwd):/app但宿主机路径硬编码不可移植命名卷由Docker管理支持备份docker run -v myvol:/data alpine tar czf /backup.tgz -C /data .、迁移docker volume inspect myvol查路径后rsync是生产首选。我曾因误用绑定挂载将测试数据库文件写入宿主机/tmp/db上线时忘记清理导致新容器启动时因权限错误崩溃——命名卷的隔离性天然规避此类风险。docker network create解决容器间通信问题。默认bridge网络下容器只能通过IP互访但IP会变host网络绕过Docker网络栈性能高但丧失隔离overlay用于Swarm集群。最实用的是自定义bridgedocker network create --driver bridge --subnet 172.20.0.0/16 mynet。此后docker run --network mynet --name db mysql和docker run --network mynet --name app nginx应用容器内可直接用ping db或curl http://db:3306访问Docker内置DNS自动解析。这比记IP或改/etc/hosts可靠十倍。注意不同网络的容器默认不通这是安全基线勿为图方便全扔进default网络。注意docker network connect可将运行中容器加入新网络但disconnect后容器在原网络的IP立即失效需重启容器恢复。因此网络变更务必安排在低峰期。2.4 调试与诊断5个命令织成的“可观测性网”当容器不响应、日志空白、CPU飙升时这5个命令是你排查的“听诊器”。docker logs是第一响应工具但默认只输出标准输出stdout不包括标准错误stderr。若程序将错误写入stderr如Java异常堆栈需加-t显示时间戳和--details显示容器元数据更重要的是-ffollow实时追踪。但生产环境慎用docker logs -f app长时间挂起它会持续占用连接。我的做法是docker logs --since 2h ago --tail 100 app /tmp/app-logs.txt先导出最近2小时的100行用grep筛关键字再针对性tail -f。docker exec是进入容器的“手术刀”。-it组合是灵魂-i保持STDIN打开-t分配伪TTY缺一不可。常见误区是docker exec app ls无交互它执行完就退出而docker exec -it app /bin/sh才获得交互shell。但注意Alpine镜像用/bin/shUbuntu用/bin/bashCentOS用/bin/bash别硬记先docker exec app cat /etc/os-release确认系统。更安全的做法是docker exec -it app sh -c ls -l /app free -h用sh -c执行多条命令避免交互式shell残留进程。docker stats实时显示CPU、内存、网络IO、块IO。它默认刷新1秒但生产环境建议docker stats --no-stream --format table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}} app关闭流式输出用watch -n 5每5秒刷新一次减少I/O压力。当看到MEM USAGE / LIMIT接近上限如1.8GiB / 2GiB就要检查是否内存泄漏——此时docker exec app jstat -gc $(pgrep java)Java应用或docker exec app pstack $(pgrep python)Python应用进一步定位。docker inspect是终极元数据查询。它返回JSON格式的容器全量配置从网络IP、挂载卷路径、环境变量到健康检查状态。新手常被海量字段吓退其实只需关注几个关键路径.NetworkSettings.Networks.mynet.IPAddress查IP、.Mounts查卷挂载点、.State.Status查运行状态、.Config.Env查环境变量。用jq工具可精准提取docker inspect app | jq .[0].NetworkSettings.Networks.mynet.IPAddress。没有jq用--formatdocker inspect --format{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}} app。docker top显示容器内进程树等价于宿主机的ps aux。当stats显示CPU 100%用docker top app看哪个进程在吃CPU再结合docker exec app ps aux --sort-%cpu | head -5定位具体线程。这比盲目重启容器高效得多。3. 实操流程从零搭建一个可调试的Web服务现在把上述命令串成一条完整工作流。假设你要本地验证一个Python Flask API服务目标是快速启动、实时改代码、查日志、模拟高负载、安全清理。3.1 构建可热重载的开发镜像先写最小DockerfileFROM python:3.9-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . # 关键用gunicorn替代flask run支持多进程 CMD [gunicorn, --bind, 0.0.0.0:5000, --workers, 2, app:app]但开发时需要代码修改即时生效CMD会固化进程。改为# Dockerfile.dev FROM python:3.9-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 不COPY代码用绑定挂载 EXPOSE 5000 # 用flask run --reload依赖文件变化 CMD [flask, run, --host0.0.0.0:5000, --port5000, --reload]构建命令docker build -f Dockerfile.dev -t flask-dev:latest .这里-f指定开发专用Dockerfile-t打标确保与生产镜像区分。3.2 启动并验证服务连通性# 创建专用网络避免污染default docker network create flask-net # 启动容器绑定代码目录开放端口指定网络 docker run -d \ --name flask-dev \ --network flask-net \ -p 5000:5000 \ -v $(pwd):/app \ -e FLASK_ENVdevelopment \ flask-dev:latest关键点-v $(pwd):/app实现代码热更新--network flask-net隔离网络-d后台运行但保留日志可查。启动后curl http://localhost:5000/health应返回{status:ok}。3.3 实时调试与日志追踪# 查看启动日志确认无报错 docker logs flask-dev | tail -20 # 实时跟踪日志新开终端 docker logs -f flask-dev # 进入容器检查文件和进程 docker exec -it flask-dev sh # 在容器内ls -l /app 查看挂载是否成功ps aux 查flask进程 # 退出用 exit不要 CtrlC会杀进程 # 模拟高负载测试宿主机执行 ab -n 1000 -c 10 http://localhost:5000/health # 然后立即查stats docker stats --no-stream flask-dev若发现内存增长异常用docker exec flask-dev ps aux --sort-%mem | head -3看内存大户。3.4 安全清理与资源回收测试完毕按顺序清理# 1. 停止容器 docker stop flask-dev # 2. 删除容器此时镜像仍存在可复用 docker rm flask-dev # 3. 删除网络无容器使用时才成功 docker network rm flask-net # 4. 清理悬空镜像构建产生的中间层 docker image prune -f # 5. 可选删除开发镜像释放磁盘 docker rmi flask-dev:latest严禁一步到位docker system prune -a -f会删所有未使用镜像、卷、网络可能误伤其他项目。我的原则是容器→网络→卷→镜像按依赖关系逆序删除。4. 常见问题与避坑指南那些文档不会写的细节4.1 “Permission denied” 错误的3种根源与解法场景1绑定挂载时宿主机文件权限不足docker run -v /host/data:/app/data ubuntu touch /app/data/test报错。原因宿主机/host/data所属用户UID1001容器内进程以rootUID0运行但目录权限为750root无写权。解法启动时指定用户docker run -u 1001 -v /host/data:/app/data ubuntu touch /app/data/test或修改宿主机目录权限chmod 755 /host/data。场景2SELinux上下文冲突仅RHEL/CentOSdocker run -v /mnt/data:/data ubuntu ls /data报错Permission denied。因SELinux标记/mnt/data为system_u:object_r:mnt_t:s0而Docker要求svirt_sandbox_file_t。解法加:z或:Z标签docker run -v /mnt/data:/data:z ubuntu ls /dataDocker自动重标上下文。场景3Docker Desktop for Mac 的文件共享限制默认只共享/Users、/Volumes、/private、/tmp。若挂载/opt/data会提示path /opt/data is not shared from OS X and is not known to Docker。解法Docker Desktop → Preferences → Resources → File Sharing添加/opt路径并重启。4.2docker run启动失败的5个检查点检查点命令预期输出异常表现1. 镜像是否存在docker images | grep myapp显示myapp latest xxxMB无输出需先pull或build2. 端口是否被占lsof -i :8080或netstat -tuln | grep :8080显示占用进程PIDBind for 0.0.0.0:8080 failed: port is already allocated3. 容器名是否重复docker ps -a | grep myapp无结果或显示已存在容器Conflict. The container name /myapp is already in use4. 卷路径是否存在ls -ld /host/vol显示目录权限invalid mount config for type bind: bind source path does not exist5. 内存是否超限docker system dfBuild Cache占用合理failed to resize tty, using default size常因内存不足4.3 日志丢失的真相stdout/stderr 与日志驱动Docker默认将容器stdout/stderr重定向到json-file驱动存为/var/lib/docker/containers/id/id-json.log。但有3种情况日志会“消失”情况1应用自行重定向日志到文件如Python脚本logging.basicConfig(filename/var/log/app.log)此时docker logs查不到因日志没走stdout。解法改用logging.basicConfig(streamsys.stdout)或挂载卷docker run -v /host/logs:/var/log/app.log。情况2日志驱动配置了max-size/max-fileDocker daemon.json 设置log-driver: json-file,log-opts: {max-size: 10m,max-file: 3}当日志超10MB旧日志被轮转删除。解法docker logs --tail 1000 app查最新1000行或改大max-size。情况3容器崩溃太快日志未刷盘主进程启动即退出如配置错误docker logs可能为空。此时docker inspect app看State.FinishedAt和State.Error字段错误信息在Error中。4.4 网络连通性故障排查树当docker exec app curl http://db:3306失败按此顺序排查查容器网络配置docker inspect app \| jq .[0].NetworkSettings.Networks确认db在同一网络如flask-net。查目标容器状态docker ps \| grep db确保db容器STATUS为Up。查目标容器端口暴露docker inspect db \| jq .[0].NetworkSettings.Ports确认3306/tcp有映射。查DNS解析docker exec app nslookup db若失败说明Docker DNS未生效重启db容器Docker会在启动时注入DNS记录。查防火墙docker exec app iptables -L若存在DROP规则需在容器内调整或改用host网络测试。实操心得我遇到过最隐蔽的问题是MySQL容器设置了bind-address 127.0.0.1导致只接受本地连接。docker exec db netstat -tuln \| grep :3306显示127.0.0.1:3306应改为0.0.0.0:3306并重启。5. 进阶技巧让命令效率提升300%的7个实践5.1 别再手敲长命令用alias和shell函数封装把高频组合命令变成一行。在~/.bashrc添加# 快速查看所有容器IP alias dpsipdocker ps --format table {{.Names}}\t{{.NetworkSettings.Networks.bridge.IPAddress}} # 一键进入容器bash自动适配sh/bash docker-bash() { local container$1 if docker exec $container bash -c echo test /dev/null 21; then docker exec -it $container bash else docker exec -it $container sh fi } # 清理所有停止的容器悬空镜像未用网络 alias dcleandocker container prune -f docker image prune -f docker network prune -f执行source ~/.bashrc后dpsip直接列出容器名和IPdocker-bash app自动选shelldclean一键三清。5.2 用--format定制输出告别awk/cutdocker ps默认输出列宽固定awk {print $1,$2}易因列数变化失效。--format用Go模板语法稳定可靠# 只显示容器ID和状态 docker ps --format {{.ID}} {{.Status}} # 显示镜像名、大小、创建时间按大小降序 docker images --format {{.Repository}}:{{.Tag}}\t{{.Size}}\t{{.CreatedAt}} | sort -k2 -hr # 查所有使用mysql镜像的容器 docker ps --filter ancestormysql --format {{.Names}} ({{.Status}})5.3docker context管理多环境告别反复登录本地开发、测试集群、生产集群需不同Docker Daemon。docker context可切换# 添加远程测试集群 docker context create test-cluster \ --docker hostssh://usertest-server \ --description Test Kubernetes cluster # 切换上下文 docker context use test-cluster # 此后所有docker命令发往test-server docker ps无需export DOCKER_HOST上下文自动管理证书和连接。5.4 用docker compose替代手工编排但理解其命令映射docker-compose up本质是批量执行docker run。理解映射关系能快速debugservices.web.build.context→docker build -f Dockerfile -t web .services.web.image→docker run -d --name web webservices.web.volumes→docker run -v /host:/containerservices.web.networks→docker network connect mynet web当compose up失败先docker-compose config输出最终YAML再对照单条docker run命令验证。5.5docker save/load实现离线镜像迁移内网环境无法pull镜像用save打包# 导出镜像为tar含所有层 docker save -o myapp.tar myapp:v1.2.0 # 拷贝tar到内网机器 scp myapp.tar userintranet:/tmp/ # 加载镜像 docker load -i /tmp/myapp.tar比docker export只导容器文件系统不含镜像元数据更完整。5.6--init参数让容器真正像进程一样管理子进程docker run默认PID 1是你的应用进程但多数程序不处理僵尸进程。加--init启用tini轻量init系统docker run --init -d --name app myapp:v1.2.0tini作为PID 1自动收割僵尸进程避免ps aux中出现defunct进程。实测某Node.js应用在高并发下产生大量僵尸进程加--init后消失。5.7--oom-kill-disable谨慎使用的内存保护开关容器OOM时内核会杀掉进程。若应用有内存敏感操作如大数据处理可临时禁用docker run --oom-kill-disable --memory4g myapp:v1.2.0但这是双刃剑禁用后OOM会导致整个容器被挂起uninterruptible sleep需docker kill -s SIGKILL强制终止。仅用于调试生产环境务必设合理--memory限制。6. 最后分享一个小技巧建立你的“命令决策树”我桌面贴着一张A4纸标题是《Docker命令决策树》内容只有3个问题你想操作的对象是什么→ 是“正在跑的程序”→ 用exec/logs/stats→ 是“程序模板”→ 用build/pull/rmi→ 是“程序的家”→ 用volume/network你想达成的效果是什么→ “让它动起来”→run/start→ “让它停下来”→stop/kill→ “让它说出来”→logs/inspect→ “让它交出来”→cp/exec cat你是否确定要永久删除→ 是 →rm/rmi/prune先ps -a/images预览→ 否 →stop/pause留作调试快照这张纸用了两年上面全是油笔勾画的痕迹。它不教你命令语法而是训练一种肌肉记忆看到问题本能地拆解对象、效果、后果三层再匹配命令。Docker的威力不在命令多而在用最少的命令解决最复杂的协作问题。当你不再纠结“该用哪个命令”而是思考“这个状态该如何安全跃迁”你就真正跨过了那道坎。
阅读完成 · 觉得有帮助？
