要说 Docker 最让人头疼的地方不是它有多少新概念而是命令行工具里动不动就是几十个参数、几十条子命令。我刚接触那会儿也走了不少弯路容器跑不起来不知道看哪里端口映射不通怀疑镜像有问题后来才发现是网络模式没选对。我把平时真正会用到的指令按场景整理了一遍顺手把容易踩的坑也标了出来。这份内容适合两类人看一类是刚把 Docker 装好、还不知道怎么下手的新手另一类是会敲 docker run 但部署和排障总要临时翻文档的开发者。读完你可以把它当成一份可持续使用的速查手册而不是收藏完就吃灰的清单。我尽量不讲太高深的理论只聊实际怎么用、为什么这么用、以及哪些参数组合会坑你。指令以 docker CLI 为核心从容器生命周期一直讲到 Compose 项目级操作覆盖开发、测试、上线前常用的几大场景。1. 容器生命周期run 全家桶和它背后的一长串状态1.1 用 run 创建容器参数要按场景记住docker run是把镜像变成运行中容器的唯一入口也是大多数人的第一个 Docker 命令。它的完整写法是docker run [选项] 镜像 [命令] [参数...]日常开发里最常用的一套参数大概长这样docker run -d \ --name demo-api \ -p 8080:80 \ -v /home/test/app-code:/app \ -e APP_ENVproduction \ --restart unless-stopped \ demo/api:latest逐条拆开说-d表示后台运行不会占住当前终端。配合日志命令使用是服务类容器最常见的启动方式。--name给容器起个唯一名字。如果不指定Docker 会随机生成一个名字后续 stop、logs、exec 的时候特别难记。我强烈建议正式环境一律用--name。-p 8080:80表示把宿主机的 8080 端口映射到容器内的 80 端口。这里有个很容易搞反的位置左边是宿主机端口右边是容器端口。第一次用的时候写反的人不在少数。-v /home/test/app-code:/app表示目录挂载。左边宿主机路径右边容器内路径规则跟端口一样。-e APP_ENVproduction是向容器里注入环境变量。不同镜像定义的环境变量名称不同比如 MySQL 镜像通常用MYSQL_ROOT_PASSWORD。--restart unless-stopped表示容器异常退出或宿主机重启后自动拉起除非是你手动 stop。这个参数对长期跑的服务非常有用。还有一个--rm参数它会让容器在退出时自动删除。它适合临时跑一次性命令的场景比如docker run --rm -it ubuntu:22.04 bash如果你给一个长期运行的容器加了--rm容器一旦异常退出就会被直接删掉连日志都没机会保留所以服务类容器不推荐加--rm。-it是另外两个参数的组合展开来是-i和-t。-i保持标准输入打开-t分配一个伪终端。想进入容器交互式操作时离不开这俩参数比如docker run -it ubuntu:22.04 bash。去掉-t的情况下很多命令的交互界面会显示异常比如缺少终端控制字符。1.2 查看容器状态不要只盯着 docker psdocker ps只显示当前正在运行的容器这本身就藏了个坑容器退出后你明明记得自己启动过但docker ps里就是看不到。这时候需要加-a参数显示所有容器包括已退出的docker ps -a看到全部容器之后你会遇到另一个麻烦容器一多光靠人眼找目标太累。加过滤条件或者定制输出格式会直观很多docker ps -a --filter statusexited docker ps -a --format table {{.Names}}\t{{.Image}}\t{{.Status}}--filter statusexited能筛出所有已退出的容器清理的时候配合删除命令特别好用。--format则让你自定义输出列脚本里抓容器名非常方便。看容器状态时还要习惯关注退出码。退出码 0 表示容器正常结束非 0 意味着当时发生了什么异常。这块我会在后面的排查章节展开先说一个最常见的现象容器一直处于 restarting 状态说明它启动即崩溃而 Docker 正在按 restart 策略不断重启它。这时候要抓紧看日志而不是反复重启。1.3 停止、删除、重启别把 rm 和 rmi 混着用容器的启停指令很直接docker start 容器名 docker stop 容器名 docker restart 容器名 docker kill 容器名stop和kill的区别值得说一说。stop会先给容器主进程发 SIGTERM 信号让它有机会做退出前清理动作如果超时还没退出再发 SIGKILL 强制结束。kill则是直接发 SIGKILL不留情面。正常情况下优先用stop只有容器卡死、怎么都停不下来的时候才用kill。删除容器对应的是docker rm注意别和删除镜像的docker rmi搞混这两个命令名字只差一个字母但作用完全不同。我之前就见过有人把docker rm mysql当成删除镜像来用结果把运行中的 MySQL 容器删掉了。docker rm 容器名 docker rm -f 容器名rm只能删除已停止的容器如果容器还在运行需要加-f强制删除。-f会先强制终止容器再删除所以生产环境用之前一定要确认容器不是不可中断的服务。批量清理退出容器的常用写法是docker rm $(docker ps -aq --filter statusexited)这条命令先找出所有退出状态的容器 ID再逐一把它们删除。如果机器上已经没有任何退出容器命令会在docker rm这边报“参数为空”的错误不影响其他操作。如果想把机器上的容器全部清掉可以这样写docker rm -f $(docker ps -aq)这条命令风险很大一旦执行所有容器都会消失包括运行中的。我只建议在彻底不需要的测试机上使用。1.4 进入容器用 exec不要依赖 attach进入运行中容器的最常用方式是docker exec -it demo-api bashexec会在容器里启动一个新进程然后通过终端连接到这个新进程。你在这个新进程里做的操作不会影响容器的主进程关掉终端也不会导致容器退出。不少人一开始会误用docker attach。attach是把当前终端直接连到容器的主进程上。问题是你在 attach 的终端里按 CtrlC可能直接给主进程发去中断信号导致容器停了。我吃过这个亏在 attach 终端里想退出结果把整个服务干掉了。所以日常调试尽量用exec少用attach。有时候容器很精简连 bash 都没有那就用shdocker exec -it nginx sh还有一点进入容器后默认是 root 用户但有些生产镜像出于安全考虑会禁用 root。此时用-u指定用户即可docker exec -it -u www-data demo-api bash在容器内做调试时建议只读不要随手改文件。容器是临时状态重启后会丢改了也白改真要改配置应该回宿主机改挂载目录或者重新构建镜像。2. 镜像管理从 pull、tag 到 build、save/load 的完整闭环2.1 拉镜像和打标签先理解仓库路径结构拉取镜像几乎人人都会docker pull nginx docker pull mysql:8.0 docker pull registry.example.com/team/app:v1.0第二条能看懂第三条的含义就需要解释一下了。镜像的完整名称由三段组成仓库地址、命名空间、镜像名和标签。如果省略仓库地址默认去官方仓库拉取如果省略标签默认拉取latest。latest虽然方便但对正式部署来说是个定时炸弹。因为同一个latest今天和明天的镜像内容可能完全不一样那么你在服务器上拉到的构建版本就不再可控。真实项目里应该给镜像打上明确的版本号比如demo/api:v1.2.0。docker tag起到的是“复制引用”的作用不是复制镜像实体docker tag demo-api:v1.0 registry.example.com/team/demo-api:release-1.0给本地镜像补一个带仓库地址的标签后才能推送到远端仓库。因为推送时镜像名里必须包含目标仓库的完整路径。想确认镜像到底存在哪里可以用docker images docker image ls这两条等价。看的时候关注两点IMAGE ID是不是多个标签共用同一个 ID以及镜像大小是否异常膨胀。多个标签指向同一个 ID 时删除其中一个标签不会释放空间只有所有引用都删完镜像本身才会被清理。2.2 用 Dockerfile 构建镜像上下文目录比 Dockerfile 更重要构建镜像的核心指令是docker build -t demo/api:v1.2 .这条命令里-t指定构建后的镜像名和标签最后的.叫上下文路径。很多人会以为.只是告诉 Docker“Dockerfile 在当前目录”实际上它表示“把当前整个目录发给 Docker 守护进程”。也就是说上下文里的所有文件都会被传入构建环境。如果你在一个包含几 GB 日志、依赖目录的文件夹里执行 build整个过程会非常慢因为 Docker 要先把整个目录打包传输。解决办法很简单在项目根目录放一个.dockerignore文件语法类似.gitignorenode_modules .git *.log .cache dist这样构建时这些目录和文件就不会被发送给守护进程既加快速度也避免把密钥、日志等敏感内容打进镜像。构建过程还有两个高频参数docker build --no-cache -t demo/api:v1.2 . docker build --target release -t demo/api:v1.2 .--no-cache用于强制重新下载依赖和执行所有层适合排除了“缓存导致构建结果不对”的情况。--target用于多阶段构建中指定构建到哪一层比如只构建到builder阶段不产出最终精简镜像。构建的时候如果发现某一步执行了RUN却没有任何输出变化大概率是 Docker 层缓存生效了。判断是否真的用了旧缓存的标志是构建日志里有CACHED字样。想彻底重建就使用--no-cache。2.3 镜像离线迁移用 save/load别用 export/import 结果来装镜像在内网或离线环境部署经常要把镜像从一台机器搬到另一台。最稳的组合是docker save -o nginx-1.27.tar nginx:1.27 docker save nginx:1.27 | gzip nginx-1.27.tar.gz docker load -i nginx-1.27.tar docker load nginx-1.27.tar.gzsave会保留镜像的层级结构、历史元数据、标签信息load加载后得到的还是完整镜像可以直接 run也可以 push。文件体积大时建议搭配 gzip 压缩再传输能省很多带宽。这里要特别提醒一句不要用docker export/import来做镜像迁移。export针对的是容器导出的只是容器的文件系统快照不带镜像层信息、环境变量、默认启动命令都会丢失。导出后导入得到的是个“裸文件系统”用它来当镜像跑往往起动不了或缺少变量。区别概括一下镜像用save/load一次性容器快照才用export/import。2.4 清理镜像rmi 和 prune 一起配合删除单个镜像用docker rmidocker rmi demo/api:v1.0 docker rmi $(docker images -q demo/api)如果后续的这个镜像正在被某个容器使用删除会报错。可以先停容器、删容器再删镜像。更常见的“悬空镜像”dangling image清理方式是docker image prune悬空镜像指的是构建时被覆盖、已经没有标签引用的旧镜像层留着白白占空间。prune会把这些none镜像清掉。如果是开发机偶尔跑一下没问题。真正危险的是docker image prune -a-a会把所有没有被容器使用的镜像全部删除包括你精心构建、准备稍后部署的版本。这个命令一旦执行只能重新拉取。在 CI 临时环境或资源紧张的测试机上可以考虑生产环境请务必三思。3. 数据卷与网络这两块最容易翻车也是最需要提前规划的地方3.1 持久化不是把数据写在容器里而是挂到宿主机上容器本身是临时状态删掉容器容器内写入的文件就全部消失了。想让数据留存必须用卷。Docker 里有两类持久化方式绑定挂载和命名卷。绑定挂载就是把宿主机目录直接挂进容器docker run -d --name demo-web \ -v /home/test/website:/usr/share/nginx/html \ nginx:1.27宿主机上的/home/test/website会直接映射成容器内的网站根目录。好处是宿主机改文件容器内立刻能看到非常适合本地开发。代价是你需要小心宿主机的目录权限和属主容器内进程没有权限写入时会报权限错误。命名卷是由 Docker 管理的存储区域docker volume create app-data docker run -d --name demo-db \ -v app-data:/var/lib/mysql \ mysql:8.0app-data是卷名/var/lib/mysql是容器内数据目录。MySQL 数据会写到app-data卷里容器删除后卷依然存在重新创建容器时指定同一个卷名旧数据就回来了。命名卷的好处是不用关心数据散落在宿主机的哪个具体路径还能被多个容器共享。查看和管理卷用这几条docker volume ls docker volume inspect app-data docker volume rm app-data docker volume prunedocker volume prune会删除所有没被容器使用的卷。这里我想多提醒一句单独的一份system prune并不会删除卷卷要单独清理。很多人以为已经清理干净了实际磁盘空间几乎没有变化原因多半就是卷还赖在系统里。绑定挂载和命名卷的选择原则很简单开发调试、需要直接看文件时用绑定挂载正式服务和数据库用命名卷。3.2 文件进出容器靠 docker cp容器与宿主机互拷文件用docker cpdocker cp demo-web:/etc/nginx/nginx.conf ./nginx.conf docker cp ./index.html demo-web:/usr/share/nginx/html/index.html第一个命令把容器里的 nginx 配置拷出来第二个把宿主机里的 html 文件放进容器。这个命令在排查问题时非常有用。比如容器里的服务读不到某个配置文件你可以在宿主机准备好正确版本cp进去再重启容器验证。注意cp只能用于复制文件不能修改容器内文件权限和属主涉及到属主问题还是得用 exec 处理。3.3 网络默认 bridge、自定义网络和 host 模式Docker 默认提供了三种网络模式bridge、host、none。查看docker network ls默认情况下容器都跑在名为bridge的默认网络中。同一个默认网络里的容器可以用 IP 互相访问但问题是 IP 会随容器重建变化很不稳定而且默认网络不支持容器名解析。也就是说在容器 A 里直接用容器名访问容器 B 是不行的。解决办法是创建自定义 bridge 网络docker network create demo-net创建时把容器都加入这个网络docker run -d --name demo-api --network demo-net demo/api:latest docker run -d --name demo-web --network demo-net nginx:1.27自定义网络自带 DNS 解析demo-web容器里直接curl http://demo-api:8080就能访问到 API 容器。这不仅消除了 IP 变化问题也让服务之间的地址变得可读。已经启动的容器想加入某个网络不需要重启docker network connect demo-net demo-db docker network disconnect demo-net demo-dbconnect是动态操作很多时候比重新创建容器灵活得多。排查问题时可以先让容器临时加入某个网络试验完再断开。host模式则是完全不同的思路docker run -d --name demo-api --network host demo/api:latesthost 模式下容器不再拥有独立网络栈直接共享宿主机网络也就是说不需要-p做端口映射容器内监听什么端口宿主机就监听什么端口。优点是网络性能好、延迟低缺点是端口冲突风险高隔离性弱。除非你有明确的性能需求否则不推荐默认使用 host 模式。三种模式的选择我建议记一个原则容器间需要互相访问就建自定义网络不需要通信就各自用默认 bridge 网络只有追求极低延迟的本地工具类容器才考虑 host。3.4 端口映射查证docker port 比 ps 好用排查端口问题时我经常用docker portdocker port demo-api它会输出容器端口和宿主机端口的对应关系。比docker ps里那一长串PORTS列直观很多。它显示的格式一般是80/tcp - 0.0.0.0:8080看到这个就知道访问宿主机的 8080 就会转发到容器的 80 端口。4. 日志与资源排障时最能救命的那组命令4.1 日志先看 tail 和 follow再谈其他查看容器日志的基础命令是docker logs demo-api不加任何参数时会把容器启动以来写入标准输出的全部日志打出来。如果日志很多终端直接淹没。日常用得最多的是组合参数docker logs -f --tail 200 demo-api-f表示持续跟踪输出类似tail -f。--tail 200表示只显示最近 200 行。先看最近日志再决定是否往上翻这是排障的固定节奏。按时间过滤也经常用到docker logs --since 30m demo-api docker logs --until 10m demo-api--since 30m是近 30 分钟的日志--until是比较冷的用法一般配合排查特定时间窗口的异常。一个很容易忽略的点docker logs只能看到容器主进程写入标准输出或标准错误的内容。如果容器里的应用直接写日志文件而不打 stdoutdocker logs什么都看不到。遇到“容器没日志”的情况先确认应用日志是输出到控制台还是写到文件。写文件的场景下要么改应用配置要么用 exec 进入容器查看对应日志文件。日志体积无限增长也是个常见隐患。可以在启动时给日志加上轮转限制docker run -d --name demo-api \ --log-driver json-file \ --log-opt max-size10m \ --log-opt max-file3 \ demo/api:latest这样单份日志最大 10MB最多保留 3 份。不配置这个参数跑上一段时间后/var/lib/docker里的日志文件会悄悄吃满磁盘。4.2 inspect 是一台侦探工具别只会 catdocker inspect输出的是容器完整配置和运行时状态内容非常长实际使用中不推荐整段硬看docker inspect demo-api demo-api.json更多时候是用它来提取某个字段。比如只看容器状态docker inspect -f {{.State.Status}} demo-api只看 OOM 标志docker inspect -f {{.State.OOMKilled}} demo-api只看挂载信息docker inspect -f {{json .Mounts}} demo-api | jq这里的关键是-f配合 Go 模板语法。如果你不熟悉模板记两个最基础的就够用字段路径用点号逐级深入用{{json .某字段}}输出 JSON 格式。OOMKilled字段是排查内存超限被杀的核心指标很多时候容器显示 exited但原因不明就是它。内存或 CPU 飙升的时候docker top可以用来查看容器内进程的实时视图docker top demo-api它展示容器内各进程的 PID、用户、CPU 占用和启动命令是确认“容器里到底哪个进程在消耗资源”的第一手信息。4.3 实时资源看板与资源配置限制docker stats是最直观的资源看板docker stats docker stats --no-stream不加参数时它会持续刷新按 CtrlC 退出。--no-stream表示只输出一次当前快照适合用来抓瞬时状态。输出里包含 CPU 使用率、内存使用、网络 IO、磁盘 IO。生产环境要留意的是内存和 CPU 占用如果某个容器长期接近资源上限就要优化应用或增加实例数。限制容器资源配额是在 run 时指定参数docker run -d --name demo-batch \ --cpus1.5 \ --memory1g \ --memory-swap1g \ demo/batch:latest常见参数对照参数作用示例--cpus限制最多使用几个 CPU 核心--cpus1.5--memory/-m限制内存上限--memory1g--memory-swap限制内存加交换分区总和--memory-swap1g--pids-limit限制容器内可创建的进程数--pids-limit200--memory-swap有个细节它要大于--memory。如果设置的是--memory1g --memory-swap1g意味着容器最多用 1G 内存而且不允许使用交换空间内存一到上限就可能被 OOM 杀掉。如果你希望允许容器在内存吃紧时使用交换可以把 swap 设成 2g。不设置这些限制的后果我在实际环境里看过太多次某个容器的应用出现内存泄漏把整台宿主机的内存吃满其他服务全部变慢甚至宕机。所以只要是在同一台机器上跑多个容器就必须加配额。这不是可选优化而是基本操作。4.4 看退出码快速判断死因容器退出后第一件事就是看退出码。常见对应关系如下退出码含义常见场景0正常退出任务执行完成或主进程正常关闭130128 2被 SIGINT 中断有人用 CtrlC 中断了前台容器137128 9被 SIGKILL 强制杀死手动docker kill或被 OOM 杀143128 15被 SIGTERM 终止docker stop发信号后容器退出127命令找不到启动命令或 exec 里的命令在镜像里不存在拿到退出码之后再配合docker inspect -f {{.State.OOMKilled}} container验证是否 OOM。如果确实被 OOM 杀掉优先排查应用内存占用而不是盲目重启。重启只会重复相同的结果。5. Compose 指令把常用操作从单容器扩展到项目级编排5.1 compose 的日常命令和 Docker 原生命令的对照单容器用 docker 命令没问题项目一多、服务一多就得用 Compose。它的核心文件是compose.yaml或docker-compose.yml里面定义了一组服务。在最常见的用法下命令从docker run变成了docker compose up -d这条命令会读取当前目录下的 Compose 文件把里面定义的所有服务构建、创建并启动-d表示后台运行。这里有个 Google 提醒docker compose是新的子命令写法老式写法docker-compose是一个独立工具命令参数略有差异本文以新版docker compose为准。项目管理的几个对照操作原生命令Compose 命令查看所有服务状态docker psdocker compose ps查看日志docker logs 容器名docker compose logs 服务名进入服务容器docker exec -it 容器名 shdocker compose exec 服务名 sh停止服务docker stop 容器名docker compose stop删除服务容器docker rm 容器名docker compose rm停止并删除多条命令组合docker compose down定位更精确的日志命令docker compose logs -f --tail50 apiapi是 Compose 文件里的服务名不是容器名。Compose 会自动管理容器名的前缀和序号所以日常操作直接按服务名来比记容器名省心得多。5.2 配置变更和重建镜像时的常用组合Compose 项目改动配置后不需要down再up直接执行docker compose up -dCompose 会检测配置或镜像变化按需重建服务。如果你改了 Dockerfile希望重新构建镜像再启动用docker compose up -d --build--build会先重新构建涉及的服务镜像再更新容器。这样避免了你手动 build 之后再 up 的两个步骤。单独运行某个服务的临时命令用docker compose run --rm db sh这个命令不会启动项目里的其他服务只启动db服务并执行sh退出后自动删除容器。用来做一次性命令行操作非常方便。注意它和docker compose exec的区别run创建新容器exec进入已运行容器。临时扩展服务副本数可以这样docker compose up -d --scale worker3这个用在对 worker 类服务做本地扩容测试的场景。不过需要提醒--scale会让服务名称附加上数字后缀容器名会变成项目名-worker-1、项目名-worker-2这种清理时如果忘了down容易留下多余的容器。down这个命令也有些讲究docker compose down docker compose down -v不带-v的down会删除服务容器和默认网络但保留命名卷。带-v会连卷一起删除。-v一旦执行数据库和持久化数据就没了。所以生产环境或重要数据环境不要直接用-v除非你备份完备。我个人的习惯是在一个 Compose 项目里默认只执行不带-v的down卷单独按需清理。6. 清理与维护prune 很爽但红线必须明确6.1 先看磁盘占用再动手清理之前先摸清家底docker system df它会显示镜像、容器、卷、构建缓存的占用总量以及有多少“可回收”空间。想看更细的加-vdocker system df -v这个命令展示的是每个镜像、容器、卷的具体占用和复用情况是判断“到底是什么在占空间”的起点。我见过不少人动不动就system prune -a结果空间没释放多少反倒把想留的镜像都清走了原因就是没有先看 df 直接动手。6.2 prune 的参数含义和保命技巧docker system prune是“安全模式”的清理docker system prune它会清理已停止的容器、悬空的镜像、未被使用的网络、构建缓存。这个命令对运行中的容器和正在被使用的镜像没有影响所以相对安全。危险版本是docker system prune -a多了一个-a会把所有没有被容器引用的镜像全部清理掉。包括你刚构建好、还没来得及部署的版本也包括你打算保留下来做回滚的旧版本。执行之后再去docker images看镜像列表会突然空掉一大半。生产环境下这条命令等同于“删库重来”。需要保留特定对象时可以用 label 过滤。给需要保留的资源打上标签docker volume create app-data --label keeptrue执行清理时排除带该标签的对象docker volume prune --filter label!keeplabel!keep表示只清理“没有 keep 标签或标签值不等于 keep”的卷。这样就给重要卷上了一道保险。prune 还有一些实用过滤参数docker system prune -a --filter until24h docker image prune --filter until24huntil24h只清理创建时间超过 24 小时的对象最近构建的镜像、最近的临时容器会被保留这让清理命令在开发机上可用性高了很多。6.3 几个省事的“顺手指令”除了 prune还有几条命令虽然不是天天用但关键时刻能省大把时间。宿主机信息查看docker system info它包含 CPU 核心数、内存、存储驱动、容器数量上限等信息。排查“为什么资源配额上限不对”时第一眼就应该看这里。事件监听docker events这条命令会持续输出 Docker 守护进程的所有事件比如容器创建、销毁、异常退出。当你想确认“某个容器是不是因为 OOM 反复被杀”docker events能直接给出时间线和事件类型。镜像历史docker history demo/api:latest它展示镜像每一层的构建指令和大小。排查“为什么镜像这么大”时逐层看能很快定位到是哪一条RUN或者哪一次文件复制撑大了镜像。写到这里其实已经把日常最常用的 Docker 指令库整理完了。如果让我提炼几条真正值得长期坚持的习惯我会说创建容器一定带--name服务类容器一定加配额限制和日志大小上限跨容器访问一律用自定义网络清理磁盘先看system df再决定 prune 的力度。按这个节奏操作大多数和 Docker 相关的“诡异问题”都能少碰一大半。
