我先把结论放在这里Docker 命令一点不难难的是不知道每条命令背后到底在干什么。平时接手一台新服务器从零部署一套容器化应用敲来敲去也就是那几十条命令。可偏偏这几十条命令很多人一遇到异常就开始慌docker ps 能看到容器logs 也拉出来了但就是找不到问题在哪。我把日常运维和开发中用得最顺手的命令整理成了一份可以直接抄的清单按镜像、容器、网络、数据卷、构建、编排、排查七块来写还带上了用法场景和踩坑点。新手可以照着一步步做老手也可以拿来当速查手册遇到不确定时翻一翻。1. 命令体系怎么学才不混乱1.1 把 Docker 命令想成一套对象管理模型一个常见误区是“命令太多背不下来”。其实命令结构非常固定所有命令都在管理五种对象——镜像image、容器container、网络network、数据卷volume和编排栈stack/compose。语法是docker 对象子命令 动作 参数。举几个例子docker image ls docker container ls docker network ls docker volume ls看到规律了吗都是“docker 对象 动作”。早期版本的docker ps、docker run这些旧写法其实都可以展开成docker container ps、docker container run。Docker 为了方便保留了短命令但理解时你完全可以用对象管理的思路去归类。比如docker rm管理的是容器docker rmi管理的是镜像i 表示 image看似容易混用对象去理解就不会错。提示docker rm删容器docker rmi删镜像docker volume rm删数据卷一句话就能记住——动词相同对象不同。1.2 一次性摸清命令背后的交互原理我用一个生活类比来说Docker 就像一个管家你的命令相当于给管家打电话。所有docker xxx命令都会通过本地的 socket 文件和后台的dockerd守护进程通信由守护进程去实际执行创建、销毁、拉取等一系列操作。所以当你看到 “Cannot connect to the Docker daemon” 的时候第一反应应该是管家不在线而不是命令敲错了。按使用频率来排序最常用的动作是镜像pull、build、images、rmi、tag、save、load容器run、ps、start、stop、restart、exec、logs、rm、cp、stats网络create、connect、disconnect、inspect、prune数据卷create、inspect、ls、prune编排compose 的一整套 up、down、ps、logs、exec、config这些都是高频操作。建议的学习顺序也别按官方文档来先跑第一个容器再往后端数据、网络、构建、编排一步步扩展符合真实业务推进的节奏理解起来也顺。另外提醒一句执行docker run时背后其实有好几步第一步向 dockerd 发起请求第二步dockerd 检查本地有没有镜像没有就去仓库拉取第三步推送镜像创建容器第四步分配网络与存储第五步启动进程。了解这个链路后面排查问题就快得多。2. 生命周期管理命令镜像到容器的日常操作2.1 镜像操作拉取、查看、删除、备份镜像命令最常见的三个场景是拉镜像、清镜像、导镜像。拉镜像。docker pull nginx:alpine这里:alpine是标签。镜像名带着仓库地址的写法是docker pull registry.example.com/team/nginx:1.24从私有仓库拉。拉取时如果不带标签默认会拉 latest。生产环境我强烈建议写明确版本因为 latest 是个会移动的指针一段时间后再次 pull 拿到的很可能不是你以为的那个版本。查看镜像。docker images是最常用的补充两个参数-a显示所有镜像包含中间层镜像一般排查时才用--format自定义输出比如docker images --format table {{.Repository}}\t{{.Tag}}\t{{.Size}}可以按表格输出仓库、标签、大小真正需要看镜像“里面是什么”的时候用docker history 镜像名能一层层看构建历史docker inspect可以拿到架构、入口点、暴露端口等元数据。删除镜像。docker rmi nginx:alpine可以删除指定镜像docker rmi $(docker images -q)会删除全部镜像谨慎使用。常见的报错是image is being used by running container说明当前有容器在用这个镜像。解决方式是把关联的容器停掉并删除再删镜像。docker image prune可以清理悬空镜像dangling 镜像也就是没有 tag 的中间层镜像加上-a可以清理所有没被容器使用的镜像加-f跳过确认。备份与迁移。docker save -o nginx.tar nginx:alpine能把镜像打包成文件另一台机器上用docker load -i nginx.tar导入。这个操作在没有外网、需要离线交付的场景特别实用。我经历过一次内网环境部署应用在开发机打好包通过 save/load 搬到生产服务器整包传输比直接在目标机拉仓库靠谱得多。2.2 容器生命周期run是起点ps/logs/exec是日常docker run是整个使用频率最高的入口。关键参数列张表参数作用示例-d后台运行容器docker run -d nginx-p 宿主机端口:容器端口端口映射docker run -p 8080:80 nginx-P随机映射容器端口到宿主机docker run -P nginx--name给容器命名docker run --name web nginx-v 卷:容器路径挂载数据卷/目录docker run -v /data:/var/lib/mysql mysql-e 变量值注入环境变量docker run -e MYSQL_ROOT_PASSWORDxxx mysql--restart策略设置重启策略--restartalways--rm容器退出后自动删除适合临时测试-it交互式终端docker run -it ubuntu bash--network 名字指定网络--networkmynet实际项目中我习惯把 run、start、stop、restart、rm 这五个动作串起来理解run 是新建并启动start 是启动已经存在的停止状态的容器stop 是优雅停机发终止信号等应用清理完再强制restart 等价 stopstartrm 是删除。kill 和 stop 的区别也提一嘴stop 是给应用留时间做收尾kill 是直接强杀数据可能没落盘。除非进程真的卡死正常优先用 stop。看容器状态用docker ps注意docker ps只显示运行中的容器docker ps -a显示所有容器也包括退出状态的docker ps -a --format可以定制输出比如docker ps -a --format table {{.Names}}\t{{.Status}}\t{{.Image}}-f过滤docker ps -a -f statusexited进入容器执行命令docker exec -it web bash。这是日常进入正在运行的容器的主要方式附带的好处是-it给你 tty 和 stdin。docker attach是“直接挂到”容器当前的终端上但一敲 CtrlC 容易把容器主进程也停了日常排查我基本不用它。如果当前终端需要退出又不想把容器停掉用 CtrlP、CtrlQ 让容器保持后台再退出。看日志docker logs -f --tail 200 web。这是新手最容易忽略的一招很多容器启动就退出必须先看 logs 而不是反复 start。容器文件复制docker cp web:/etc/nginx/nginx.conf ./nginx.conf可以把容器里的文件拷出来备份或排查。容器重命名docker rename web web-bak有时候版本发布要保留旧容器时就很好用。资源查看docker stats可以实时显示所有容器的 CPU、内存、网络 I/O 和磁盘占用压测或定位内存泄漏时先盯它docker top web可以看容器里跑的进程列表相当于 ps。2.3 清理回收不清理后端磁盘迟早爆容器和镜像都是占磁盘的大户。三条清理命令要分清docker container prune清理所有已停止的容器-f跳过确认docker image prune清理悬空镜像-a清理所有没被容器使用的镜像docker system prune容器、网络、悬空镜像、构建缓存全套清理-a会把没被使用的镜像也清掉docker system df可以看整体磁盘占用统计先分析再决定清理哪些。我自己的经验是CI 环境里跑完构建之后镜像一层层的缓存会非常多每次发布前先看一遍docker system df够用就别乱清避免误删正在用的东西。注意prune 不会清理运行中的容器安全的边界还算清晰但system prune -a依然是危险操作执行前一定要确认没有需要回滚的旧版本镜像。3. 网络与数据卷容器之间怎么连数据怎么留存3.1 三种内置网络模型容器的网络模型必须选对否则服务之间互访会出现“明明在跑但访问不通”的诡异情况。bridge默认网络容器 NAT 模式类似虚拟机里的桥接。宿主机之外访问容器需要-p映射端口host容器与宿主机共享网络栈没有独立 IP端口直接绑宿主机。性能好一点但端口冲突管理不方便none隔离网络常用于跑一些完全不需要网络的离线任务自定义 bridge 是生产中多服务互访的重要手段docker network create --driver bridge mynet docker run -d --name web --network mynet nginx docker run -d --name app --network mynet nginx这样容器之间就可以直接用容器名互相 ping 和调用比如 app 要访问 web直接http://web:80而不是拿那个动态变化的 IP。为什么默认的 bridge 不行默认 bridge 上虽然也有网络但不支持容器名自动解析容器名不能作为一个稳定的主机名来用。自定义 bridge 才有内置的 DNS 解析能力。查看网络用docker network ls查看某个网络下挂了多少容器、每个容器的 IP用docker network inspect mynet。把运行中的容器动态接入一个网络docker network connect mynet web断开是docker network disconnect mynet web。在进行服务迁移或者临时联调的时候非常有用不用重启容器。网络清理docker network prune会清掉所有未被容器使用的自定义网络慎用因为有些“没用”的网络可能是你刚从 compose down 出来的稍后还要再用。3.2 数据卷与挂载方式容器的一个重要特点是没有持久化只要容器删除内部写的数据就没了。为了让数据库、日志文件、上传目录保留下来必须用 volume 或者 bind mount。两种方式bind mount把宿主机目录直接挂进去docker run -v /宿主机目录:/容器目录。优点是直接能看到文件备份方便缺点是宿主机目录不存在时很多版本会自动创建但权限容易出问题named volumedocker volume create pgdata然后docker run -v pgdata:/var/lib/postgresql/data。管理起来像一块真正的卷位置在/var/lib/docker/volumes/pgdata/_data但平时你不需要去动它还有一种挂载语法是--mount typevolume,sourcepgdata,target/var/lib/postgresql/data相比-v更适合脚本化表达可读性强不易混淆。看卷用docker volume ls、docker volume inspect pgdata能看到挂载点、驱动等信息。删卷用docker volume rm pgdata。如果你用 Docker Compose卷在 compose 文件里声明一键 up 自动创建。关于权限问题这是实际踩坑最多的点。容器里的进程是以它自己的 UID 运行的如果 bind mount 的宿主机目录归属 root容器内非 root 进程往往写不进去。经验做法是在挂载前先chown -R 1000:1000 /data或者直接指定正确的 uid:gid。3.3 端口映射与连接排查端口映射是否生效docker port web可以列出来比如0.0.0.0:8080-80/tcp。如果多个项目同时用到 8080run 的时候会直接报bind: address already in use那就要改宿主机端口或者把旧容器停掉。进入容器排查连不上别服务docker exec -it web bash然后curl或者ping对端容器名。如果发现 ping 不通但网络没问题先确认两边是不是在同一个自定义网络里其次确认对端进程有没有监听端口。提示Docker 网络切换后已运行的容器名称解析可能不会立即生效最稳妥的办法是重建容器并用新网络重新跑一遍然后再验证。4. 从镜像到应用构建、仓库与编排4.1 Dockerfile 与构建命令docker build -t myapp:1.0 .是最常用构建命令。几个重要参数-f指定 Dockerfile 路径比如docker build -f docker/Dockerfile -t myapp:1.0 .--no-cache禁用缓存编译类镜像更新依赖时特别有用--build-arg传入构建参数比如版本号--target多阶段构建时指定最终阶段名只构建中间某个阶段构建是一条命令但坑不少。有一个冷知识Dockerfile 里面的每一行 RUN 指令都会生成一层镜像层写在同一 RUN 里的多个命令会合并成一层。层数越多镜像越重执行docker history 镜像名就能看到每一层的大小。真实项目里更推荐把软件源设置、基础依赖安装放在早期层因为层缓存命中机制是“前几步没变就能复用缓存”把不变的东西放前面、变的东西放后面构建速度能差好几倍。如果构建时网络慢可以在 RUN 里换本地软件源这点大家应该都懂。但构建卡住时别急着 CtrlC先看docker build输出的步骤编号确定卡在第几步再对症下药。多阶段构建是另一个值得用起来的特性第一阶段装编译工具链把代码编成产物第二阶段只把产物拷进一个精简运行镜像能有效把最终镜像体积从几个 GB 降到几百 MB。4.2 镜像仓库与离线迁移镜像仓库可以是公共仓库也可以是自建的私有仓库。推送流程三步docker tag myapp:1.0 registry.example.com/team/myapp:1.0 docker login registry.example.com docker push registry.example.com/team/myapp:1.0拉取私有镜像docker pull registry.example.com/team/myapp:1.0。离线迁移前面提过docker save -o 文件名.tar 镜像名目标机器docker load -i 文件名.tar。这里要注意save 打包的是镜像不是容器。如果想保存容器本身的数据应该用 commit 或导出容器的数据卷但 commit 会产生大量中间层实际生产不推荐把它当作持久化手段。一个常见困惑docker export和docker save有什么区别export 导出的是容器的文件系统快照不含镜像层的元数据、历史、标签save 导出的是完整镜像。前者适合临时快照后者适合镜像投递。4.3 Compose 编排命令单容器管理用命令足够多个服务串起来最好用 Docker Compose。常用命令与 docker 的对应关系我列一下命令作用等价理解docker-compose up -d按配置启动所有服务docker run批量版docker-compose down停止并移除所有服务容器默认不删数据卷批量 rmdocker-compose ps查看服务状态docker psdocker-compose logs -f查看多服务日志docker logsdocker-compose exec web bash进入某个服务容器docker execdocker-compose config校验配置文件并展开合并后的配置语法检查实操场景里最重要的参数是-f指定 compose 文件docker-compose -f dev.yml up -d方便开发、测试、生产共用同一份镜像用不同的配置。另一个高频参数是 up 后面不写-d直接docker-compose up会把所有日志打到当前终端前台跑适合排查。down和stop的区别与docker rm和docker stop的区别类似stop 只停down 停掉再删容器。如果要连数据卷一起删down -v这个操作会把数据库文件一并删掉千万要小心。5. 高频故障与排查实战5.1 报错对应表实际使用中会遇到的一堆常见报错我把最典型的列成表报错现象原因最可能的解决办法docker: Error response from daemon: Conflict. The container name /web is already in use容器名冲突docker ps -a找到同名容器删掉或者docker rename改名port is already allocated宿主机端口被占用换宿主机端口或docker ps检查占用端口的容器Cannot connect to the Docker daemon at unix:///var/run/docker.sockDocker 服务没启动启动 daemon 服务比如systemctl start dockerNo such image: xxx:latest本地拉不到镜像docker pull xxx确认镜像名和标签是否正确permission denied while trying to connect当前用户没权限访问 docker socket将用户加入 docker 组并重新登录或使用 sudounable to resolve host容器之间无法用名称解析检查是否在同一自定义网络中5.2 容器“启动即退出”排查五步新手最容易卡的问题是容器一启动就 Exit然后反复 start越点越急。我的排查习惯是五步docker ps -a看退出码。退出码很关键Exit 0 说明进程正常运行完主动退出Exit 1 或 127 多半是命令或环境问题docker logs 容器名看启动日志。很多镜像如数据库、反向代理会把出错原因直接打出来docker inspect 容器名对比镜像的入口点和启动命令。有时候是你 run 的时候把命令写错了覆盖了镜像原本的启动命令docker exec手动执行启动脚本或docker run -it 镜像名 bash进容器手工跑一遍看缺少什么依赖检查启动参数尤其-v挂载目录权限、-e环境变量是否正确。比如数据库镜像必须要指定管理员密码缺了就直接退出5.3 日志分析的几个实用技巧docker logs可以加--tail只看末尾加-f实时跟随加--since 30m看最近半小时。假如日志乱码或者时间不对先确认容器内时区。设置容器的 TZ 环境变量比如-e TZAsia/Shanghai很多容器镜像默认是 UTC日志时间差 8 小时会误导排查方向。资源问题在docker stats里是能看出来的CPU 一直 100%多半是你的业务逻辑死循环内存缓慢上涨可能是容器内程序内存泄漏。日志和资源配合使用基本能定位大部分应用层问题。另外docker inspect里的State.ExitCode、State.Error、Mounts字段是排查“挂载盘没生效”“容器启动失败”的关键信息比瞎猜快得多。最后讲几点我个人操作中的体会。第一命令别死记把 docker 想象成对象管理查一个、记一个比照抄速查表管用得多。第二我的 .bashrc 里常驻三个 aliasalias dpsdocker ps --format table {{.Names}}\t{{.Status}}\t{{.Ports}} alias dlogdocker logs -f --tail 100 alias dcupdocker-compose up -d --build第三也是最重要的一条不要在跑着业务的服务器上随手执行docker system prune -a。我在测试环境误删过一次镜像缓存虽然正在上线的应用没挂但回滚时发现旧镜像没了只好重新拉取白白耽误了半小时。几个教训生产环境少用-f写清版本号编排文件提交到版本库。Docker 命令本身只是工具真正让你不慌的是你对每一步操作后果都心里有数。
