前阵子写完了《docker入门第一章安装与核心概念》就有不少读者私信催更说第一章太概念化想看真刀真枪的命令操作。这一章我就直接把日常工作中高频使用的那批 Docker 命令拎出来一条一条拆开讲。还是老规矩不讲那种“面向搜索引擎”的冷门参数只讲你在真实项目里一定会碰到、会反复敲进终端的那些操作包括镜像拉取、容器启停、文件互通、日志排查最后再带你串一个实际案例把命令完整跑一遍。先说个结论Docker 命令并不难背难的是搞明白“这条命令到底在操作哪个对象”。只要你脑子里先分清“镜像”和“容器”这两个概念后面所有命令其实都是一套逻辑找对象、操作对象、清理对象。这一章我的目标是让你看完之后能自己从一个干净的运行环境开始拉镜像、起容器、改配置、看日志、清理资源遇到问题还能自己排查三分。咱不追求一次吃透全部命令先把最常用的这批练到肌肉记忆。1. 先搞清楚命令作用的“两个阵地”镜像仓库 vs 本地环境很多新人一上来就盯着命令背背了半天还是晕。我建议反过来先把 Docker 命令按操作对象分个类。其实日常命令基本就落在四个维度上镜像层、容器层、数据层、系统状态层。搞清楚你当前要操作的是哪一个维度命令自然就对号入座了。1.1 镜像与容器先别急着混淆我上课的时候特别喜欢用一个生活化类比镜像相当于“做蛋糕的模具和配方”容器相当于“按这个配方实际做出来的蛋糕”。你可以用同一个模具做一百个外观一样但略有差异的蛋糕也可以做完一个不要了直接丢掉再重新做一个模具还在你手里。套到 Docker 里就是镜像是只读模板容器是镜像运行后产生的实例。你在容器里写文件、改配置、装软件这些改动不会动到镜像本身。等你把容器删了改动就一起没了但镜像还在你随时可以再启动一个全新容器。这个心智模型一旦建立很多命令行为都能解释通。比如为什么docker rmi删除镜像时经常报错提示“被容器引用”因为镜像和容器之间存在引用关系容器依赖镜像作为运行基础。你得先停掉并删掉相关容器才有资格删镜像。这也是新手操作顺序最容易出错的地方。1.2 查看环境信息的三条命令开始拉镜像前我强烈建议先做三件事确认 Docker 客户端和服务端都正常、确认当前机器资源情况、确认有没有残留的悬空镜像占用磁盘。这三句话分别对应三条命令。docker version docker info docker system dfdocker version主要看 Client 和 Server 两个部分的版本号是否正常显示。如果能看到 Server 信息说明你本机的 Docker daemon 正常跑着。有时候客户端装好了服务端没启动这里就会卡住报错这是排查环境问题的第一步。docker info输出信息更长我一般只看几个关键字段Containers当前容器总数、Images镜像总数、Docker Root Dir数据存放目录、Server Version服务端版本。特别是磁盘告警时Docker Root Dir能告诉你镜像数据存在哪个路径下方便去清理。docker system df就更有用了它直接列出 Docker 各种资源占了多少磁盘空间包括镜像、容器、本地卷、构建缓存。我见过太多人磁盘满了还找不到原因跑一下这个命令基本一眼定位。这个命令要养成习惯每个月至少看一次。2. 镜像常用命令拉取、查看、清理一条龙镜像命令是 Docker 世界的“进货”环节。你要跑什么应用先得把应用对应的镜像拉到本地。这一节我按实际使用频率排序把最刚需的镜像操作梳理清楚。2.1 拉取镜像docker pull 与 tag 的配合镜像拉取命令的完整形态是docker pull [选项] 镜像名[:标签]。最常见的例子docker pull nginx:1.25这里的1.25就是标签也就是版本号。有件事我必须拎出来单独说不建议直接写docker pull nginx去拉 latest 标签。很多坑都是这么踩出来的——lastest 看起来方便但实际镜像内容可能和你想的版本不一致。等下次重新拉的时候版本又悄悄往前滚了连个通知都没有。生产环境里项目一跑镜像版本锁得死死的才好回滚。有人会问那我怎么知道这个镜像有哪些标签两种思路一种是去你正在使用的镜像仓库网站上直接查人肉翻页面另一种是拉取后通过docker inspect拿到镜像的元数据看具体版本特征。我平时写得比较多的长命令形态是这样docker pull myregistry.example.com/team-app/backend:20250115-release这里涉及一个企业里很常见的概念镜像名里可以带仓库地址前缀。如果不带地址Docker 默认去官方源拉带了内部仓库地址就相当于告诉 Docker 去企业内部源拿。这样拉下来的镜像已经天然分好了归属哪些是官方基础镜像哪些是自研应用镜像一眼就能看出来。2.2 查看与筛选镜像docker images 与 --filter镜像拉进来之后怎么本地查看最基础的就是docker images它默认展示仓库名、标签、镜像 ID、创建时间和大小。docker images输出列里最重要的是IMAGE ID这一列。这个 ID 不是完整哈希通常只有前 12 位但已经足够用于删除、标记、引用镜像。注意它和docker pull时看到的完整校验值不是一回事平时操作只需要这个短 ID 就够了。镜像多了之后docker images全量输出就很乱。这时候开始用到筛选参数docker images --filter danglingtrue这个命令专门列出“悬空镜像”也就是没有任何标签引用的镜像。它出现的原因一般是反复重新构建镜像旧的镜像层失去引用后留在磁盘里既占空间又干扰查看。看到它们之后下一步通常就是清理。如果你只想看某一个镜像名下的所有版本还可以这样docker images | grep nginx虽然教条一点的玩家会说“不要 grep 命令行输出”但日常排查时这种方式确实快我承认自己也经常这么干。需要说明的是这是终端方式不是脚本里的严谨姿势。如果写自动化脚本还是建议用带--filter的完整参数。2.3 清理无用镜像docker rmi 与 docker image prune有进必有出镜像一多磁盘就难看了。删除单个镜像用docker rmidocker rmi nginx:1.25这个命令本身不复杂但有一个高频报错需要专门提醒。假设你裸敲docker rmi nginx:1.25系统可能回一句image is being used by running container。这说明当前有正在运行的容器基于这个镜像Docker 为了保护数据不会直接放你删。遇到这种情况不要硬删。先docker ps找出引用它的容器把容器停掉、删掉再回来删镜像。如果确实想让 Docker 强制删除可以在 rmi 后面加-f但我不建议把强制删除当成默认习惯。强制行为容易留下后患尤其有些容器是别人或别的事故脚本跑的你没搞清楚就强删很容易影响在线服务。批量清理则是另一条命令docker image prune这条命令把悬空镜像都清掉系统会提示你要释放多少空间输入y确认。如果想更激进一点把没有被容器使用的镜像全部清掉docker image prune -a我个人的建议是日常维护用不带-a的docker image prune安全又够用。带-a的风险在于它会把那些你暂时没起容器但后面马上要用到的镜像一起删掉下次再拉一遍时间成本也是成本。2.4 给镜像打标签docker tag打标签这个操作平时用得不少但它往往被新手忽略。核心场景是镜像本来有默认标签你想把它归入自己的仓库命名体系。docker tag nginx:1.25 myregistry.example.com/nginx-common:1.25打标签的命令本质上是创建一个“别名指针”不是复制镜像内容。所以使用起來极快也不会占额外空间。但有个坑要提醒同一个镜像可以有多个标签如果后面你用docker rmi删其中一个标签而镜像还有其他标签引用那么实际镜像层并不会被删除只有那个标签被移除而已。反过来理解只要还有任何标签指向镜像Docker 都不会真正清理镜像层。3. 容器常用命令创建、启动、进入、停止与删除镜像只是“材料”容器才是真正动起来的东西。这一节我们重点讲容器生命周期的完整闭环创建并启动、查看状态、进入交互、停止删除。这些命令是日常运维和本地开发最高频的没有之一。3.1 最核心的 docker run参数怎么加才顺手我把docker run视作 Docker 命令里最重要的一个没有之一。它把“从镜像创建容器并启动”一次性完成。基础用法docker run -d -p 8080:80 --name web-demo nginx:1.25拆解一下我这段时间用得最多的两个参数-d后台运行。不加的话容器在前台运行你会一直盯着一堆日志刷屏CtrlC 后容器就被打断了。日常起服务我几乎总加-d除非是调试阶段需要看即时输出。-p 8080:80端口映射宿主机 8080 端口映射到容器内 80 端口。这个设计是为了让外部能访问容器里的服务。容器内部网络默认是隔离的外部进程默认摸不到它必须通过端口映射开一个“小门”。--name给容器起个名字后面所有针对它的操作都能直接用这个名字而不是一长串 ID写起来清爽很多。假设我现在要跑一个带交互的容器进去调试就用docker run -it nginx:1.25 /bin/bash-i保持标准输入打开-t分配一个伪终端这两个参数基本总是连写-it联合起来效果就是“让你可以像在本地终端里一样操作容器内部”。后面紧跟的/bin/bash是容器启动时默认要执行的命令覆盖掉镜像自带的启动命令。很多基础镜像里没有 bash只有 sh那你就要写成/bin/sh按实际来。3.2 后台运行和前台调试的选择容器启动状态到底怎么选很多人一开始分不清。我做个小对照使用场景推荐参数原因跑正式服务、API、数据库-d后台运行不阻塞终端方便集中管日志临时调试镜像内容-it直接进入容器内执行命令并看结果只想跑一次性任务-it --rm执行完自动删除容器不留下垃圾需要常驻又要进容器操作-d后再exec服务照常跑调试另开入口还有一个参数--rm我单独说说。它的语义是容器退出后自动删除自身。这策略对什么场景最友好测试一次性任务的时候。比如我经常拿一个容器专门跑某个数据迁移脚本跑完直接退出连清理容器都省了。对比一下如果不用--rm每次跑完测试都会留下一个状态为 Exited 的死容器时间久了docker ps -a全是垃圾看着都烦。但注意--rm不能和-d共存时产生“永不删除”的误解。你仔细想如果你用了-d --rm容器确实一直在后台跑但你要是手动 stop 它一次Docker 会直接把它删了。所以在正式服务上我不会加--rm防止有人误 stop 后容器直接蒸发。3.3 查看容器状态docker ps 与 docker ps -a容器跑起来之后第一件事是确认它活着并且状态正常。查看正在运行的容器docker ps输出的列里有容器 ID、镜像名、当前命令、创建时间、状态、端口映射、名称。我最常看的是两个位置STATUS列能直接分辨 Up、Exited、PausedPORTS列能看到宿主机和容器端口的对应关系。如果 Up 状态后面还跟着(healthy)说明容器通过健康检查但如果显示Up 3 minutes前头却没有 healthy也不一定有大问题有些镜像没配健康检查不代表服务坏了。docker ps默认只看运行中的容器。如果要看已经退出、停止的容器包括那些跑完任务就挂掉的要加-adocker ps -adocker ps -a是排查问题的第一神器。为什么这么说因为你经常碰到“刚才还跑得好好的不知道什么时候变成 Exited”的情况-a会把所有历史状态摊开让你看到。配合后面讲到的日志命令基本就能定位是退出原因还是资源限制问题。3.4 停止、启动、重启与删除stop/start/restart/rm容器生命周期里停启和删除三兄弟我合并起来讲因为它们的命令模式非常相似都是“动词 容器名或ID”。docker stop web-demo docker start web-demo docker restart web-demo docker rm web-demostop会先给容器里的主进程发一个停止信号让它有“喘息”的余地可以执行清理、保存状态等收尾动作。如果等一段时间后还是停不下来可以加-t指定超时时间或者改用kill强制终止。日常开发stop就够了养成好习惯尽量别一上来就kill毕竟有些程序中断后状态会损坏。restart就是先停后启一条命令完成。这个在改完配置文件后很常用但这里有个重要的经验如果容器内的应用支持热加载那就不需要 restart直接刷新页面就行。频繁 restart 反而可能让大应用启动变得很慢。删除容器用docker rm。如果容器还在运行不能直接删需要先 stop或者加-f强制删除。但和删除镜像的道理一样-f不是常态操作需要谨慎。另外有个高频坑是顺序先删容器、再删镜像顺序反了就容易报“容器还在使用镜像”的错误。每次清理前都默念一遍这个顺序能少踩一半的坑。批量删除的形态也补充一下docker rm -f $(docker ps -aq)这条会把所有容器全部删掉包含运行中的。查看写法里$(docker ps -aq)的意思是先查所有容器 ID再作为参数传给rm -f。我只建议在完全确定没有在用容器的时候执行试错环境里跑一跑还行正式机器别随便碰。3.5 进入正在运行的容器docker exec进入正在运行的容器内部是调试时逃不开的操作。这个命令是docker exec -it web-demo /bin/bash理解它的语义很关键它是在一个已经存在的容器里“额外开一个进程”来执行命令而不会影响容器原有的主进程。意味着你可以在容器里随便敲命令、看文件只要不重启容器服务照跑。这种隔离又有交互的模式非常适合线上问题定位。docker exec和docker attach的差别也值得知道。attach是把你的终端接到容器的主进程上看到的是容器主进程的输出甚至可能因为主进程退出而把容器一起带停掉。所以日常调试尤其需要操作容器内部环境的我基本只用exec。只有要看服务实时输出时我才考虑 attach但多数场景下一句docker logs -f就解决问题了。你在 exec 里修改的东西会保留在容器层里容器不删就还在。但如果你用docker rm把这容器删了所有修改也跟着没了。别再纠结“我改了容器里的配置怎么会丢”答案就在这句话里。4. 数据复制与端口映射本地和容器怎么互通容器虽然方便但它的文件系统本质是隔离的。本地想往容器里放个配置文件或者想从容器里取出日志就需要掌握数据互通的方法。这一节我把端口映射、文件复制、目录挂载三个场景一次讲透。4.1 端口映射-p 和 -P 的不同端口映射刚才在docker run里已经提到但值得再单独展开。它的意义一句话就能概括让宿主机外面的请求能进到容器内部服务里。如果你在启动时写了-p 8080:80意思是宿主机 8080 端口的所有请求会被转发到容器的 80 端口。这时你通过浏览器访问http://localhost:8080实际上访问的就是容器内的 Nginx。还有个小参数-P大写。它的作用是把容器内所有暴露的端口随机映射到宿主机的某个高位端口上。好处是省得自己一个个指定坏处是你得去docker ps里找回实际映射到哪个端口了。这种方式更适合开发环境里快速体验不适合需要固定端口的正式场景。关于-p的写法我还想补充一个容易忽略的变体可以把容器端口绑定到本机回环地址上如-p 127.0.0.1:8080:80。这样只有本机能访问端口其他机器从局域网访问不进来。这在本地调试跑一些带敏感数据的服务时是很有用的保护手段哪怕是开发机也不想随便让整个局域网都能连上。4.2 复制文件docker cp 的双向操作有时候你不想进容器敲命令只想简单地把文件塞进去或取出来。这时用docker cpdocker cp ./index.html web-demo:/usr/share/nginx/html/ docker cp web-demo:/var/log/nginx/access.log ./access.log第一条是本地 copy 进容器第二条是从容器 copy 到本地。方向就是把宿主机路径写在前面容器路径写在后面顺序别颠倒了。docker cp一个明显优点是不需要容器里跑什么额外服务不要求容器处于运行状态只要容器存在即可操作。所以哪怕容器已退出你照样可以从中拷出日志等关键文件。需要注意的一点是docker cp是“一次性复制”复制完了两边就再无关系。你不能靠它在容器里“实时同步”文件。如果你有持续同步的需求对应方案是下一节的目录挂载。4.3 挂载目录-v 的坑与建议挂载目录是让宿主机的一个目录直接映射到容器内某个路径。最常见写法docker run -d -p 8080:80 -v /home/myuser/site:/usr/share/nginx/html nginx:1.25这行命令的效果是宿主机/home/myuser/site目录下的文件和容器里的/usr/share/nginx/html完全同步容器里读到的就是这个目录。这样想改静态网站就直接改宿主机文件连进容器的步骤都省了。这个命令在本地开发时极其爽但有几个坑必须提前说第一冒号左边的路径必须是宿主机绝对路径写相对路径会挂不上去或者莫名奇妙的路径错乱。我见过有人写./site:/usr/share/nginx/html看起来没问题但 Docker 有时候解析的不是当前目录导致容器根本读不到文件。第二把宿主机目录塞进容器后要注意权限问题。容器内进程一般以特定用户运行如果宿主机目录权限是root容器内用户可能无权写入。环境不同问题多样我处理过很多次这类问题经常用chmod来解决但更稳妥的方式是先了解容器运行时用的 UID再对宿主机目录做对应授权。第三如果容器内原本的目录里有文件用宿主机目录替换挂载上去后原文件会被隐藏不见。很多人挂载之后容器报错什么文件找不到就是踩了这个坑。解决办法很简单想保留容器内原有文件就先把它们复制到宿主机目录里再挂载。5. 日志、进程与资源排查出问题不慌容器跑起来之后并不代表万事大吉。实际开发中最耗时间的部分大多是“服务怎么启动不了”“内存怎么一直涨”“日志怎么全空了”。这一节就是让你掌握看日志、看进程、看资源的三板斧。5.1 查看实时日志docker logs -f查看容器日志最常用两个形态docker logs web-demo docker logs -f web-demo前者是打印容器当前日志用完就退出;后者-f是持续跟踪日志输出效果类似 Linux 下的tail -f能实时看到新写入的日志。退出的方式不是 CtrlC而是回到终端就完了随时可以再跑。有两个细节很实用。第一容器里输出到标准输出的内容才会被 Docker 日志捕获如果你只把日志写进文件Docker 默认是看不到的得进去容器看或者挂载出来。第二docker logs可以加--tail 100只看最后 100 行加-t给每条日志带上时间戳。这几个参数组合起来排查“刚才发生了什么”非常高效。docker logs --tail 200 -t web-demo如果容器重启过但你想看它启动失败那一刻的报错用docker logs加--tail和-t足够定位大部分启动问题。如果日志量特别大也可以用--since 1h只看最近一小时的日志把历史数据隔离出去免得刷屏晃眼。5.2 查看进程和资源占用docker top、docker stats调试容器里出现僵尸进程、CPU 飙升、内存泄漏的现象时不时会遇到。这时配合两条命令docker top web-demo docker statsdocker top能列出容器内的进程列表类似宿主机上的top命令。它可以让你直接看到容器里跑了哪些进程尤其适合确认容器主进程有没有退掉、有没有残留子进程或者是不是启动脚本拉起了一堆额外进程。docker stats则是实时查看所有容器的资源占用报表。CPU、内存、网络 IO、容器数量一屏都列出来。我需要提醒一点不要用docker stats的数据直接替代正式监控系统它是即时快照数据过了几秒就变了适合临时观察。但当你怀疑哪个容器把机器内存吃没了在终端跑一下谁是真凶立刻原形毕露。docker stats还有一个零基础就能用的价值容器 ID 对应你的服务名对照docker ps同时看哪个服务占用内存异常就非常清楚。我在本地排查问题时就靠它定位过好几次内存暴涨的元凶效率属实高。5.3 查看容器内部细节docker inspect如果说docker ps是看容器“外在状态”docker inspect就是扒开容器“内脏”看全部细节。它以一个超大的 JSON 结构输出容器的配置、网络、挂载、环境变量等等信息。docker inspect直接输出会很长。我平时很少全量看一般用--format提取所需字段。比如现在想知道容器 IP 就执行docker inspect --format{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}} web-demo再比如想看容器启动时到底挂了哪几个目录docker inspect --format{{json .Mounts}} web-demo虽然这样的语法长得凶但真正上手就觉得特别香。它把 JSON 里的字段像模板一样抽取出来你不用在几百行 JSON 里翻来翻去。这里如果想省心还可以先把完整输出存到文件里再翻docker inspect web-demo inspect.json6. 从零跑通一个真实示例把命令串起来讲概念的阶段到此为止。这一节完全走实操我用一个特别常见的场景——本地跑一个网页服务并实时改页面把前面讲的命令按真实操作顺序全部串起来。这个流程不仅适合学命令套用到很多日常开发场景里也都成立。6.1 目标场景跑一个轻量的演示服务我现在手头有一个纯静态网页项目目录叫/home/dev/site里面有个index.html。我想要的效果是起一个 Nginx 容器托住这个站点宿主机 8080 端口访问它改index.html后页面即时生效。同时我要观察它的启动日志最后完成测试再干净利落地清理掉。这个场景覆盖了拉镜像、起容器、挂载目录、端口映射、查看状态与日志、停删容器等绝大多数常用命令。跟着我一行行来。6.2 完整命令序列第一步确认环境docker version docker ps -adocker ps -a是为了看看当前有没有历史残留容器顺便让自己进入状态。第二步拉取 Nginx 镜像。这里我用明确版本1.25不用 latestdocker pull nginx:1.25拉取完成后可以顺手docker images | grep nginx确认一下。第三步启动并挂载docker run -d -p 8080:80 -v /home/dev/site:/usr/share/nginx/html --name web-demo nginx:1.25这条命令跑完后docker ps查看容器状态。如果显示 Up说明容器已经正常在后台运行了。浏览器访问http://localhost:8080应该能看到你自己的页面。第四步故意制造一次更改检验挂载生效echo h1Hello Docker/h1 /home/dev/site/index.html顾及到有的读者可能正好在看这个页面刷新一下就能看到修改。如果没生效大概率是路径挂载问题回头检查绝对路径写法。第五步看日志确认访问记录docker logs -f --tail 50 web-demo这时浏览器访问两次终端里应该能看到访问请求行。这是最简单直接的“我确实访问到了容器内服务”的证据重点要确认。第六步模拟一次问题定位进入容器看配置docker exec -it web-demo /bin/sh进入后可以执行ls /usr/share/nginx/html、cat /etc/nginx/nginx.conf之类的确认容器内部环境。观察完输入exit退出容器。第七步测试完成清理docker stop web-demo docker rm web-demo如果还想确认一下容器真的没了再执行docker ps -a | grep web-demo不会有任何输出。这一整套流程从拉镜像到清理加起来 10 分钟以内能跑完。6.3 这个流程背后的设计意图这套命令不是随便挑的每一步都有目的。开头用docker version、docker ps -a是“上手前体检”省得到后面出问题时才把锅安在某个环节上。docker run里把端口映射、目录挂载、命名一次配齐是为了让容器和宿主机真正联动起来不然容器就是个孤岛没有实际业务价值。拉到nginx:1.25而不是 latest是为了保证实验可复现你照着敲出来的结果和我不会差版本。日志和 exec 两个环节分别对应了线上定位问题的两条路线一条是从外面看输出一条是从里面看现实。清理阶段强调先 stop 再 rm也顺手养成了标准操作习惯。这套习惯养成之后不管你以后业务多复杂底层的容器管理思路始终是这一套。7. 常见问题速查与避坑清单命令学到最后最有用的不是“背”而是“遇到问题了能快速想到哪个命令”。我把日常处理过的高频问题整理成一个速查表每一条都是实操中真真切切遇到的。你可以把这张表收藏起来或者抄在本子旁边等出问题时直接对号入座。症状可能原因解决方法docker pull很慢网络环境对源站连接不理想确认仓库地址正确可考虑切换内部专属源注意不要轻信来源不明的所谓“加速脚本”docker run后马上退出容器主进程是一个短任务或启动失败docker ps -a看退出码docker logs查错误日志端口访问不通端口映射没配或容器没起来docker ps看端口映射列确认宿主机端口没被占用容器删不掉容器还在运行中先docker stop必要时docker rm -f挂载目录不生效路径写得不对或权限不一致检查用绝对路径确认容器内用户对目录有权限镜像删除报错被引用有容器还在使用该镜像先删容器再删镜像日志显示中文乱码容器内编码和宿主机不同在容器里设置字符集环境变量或日志文件用 UTF-8 保存容器越多系统越卡资源竞争或日志文件膨胀docker stats找资源占用大头docker system df查磁盘占用清理不再用的镜像和容器再补充一句日常维护心得每周定期跑一遍docker ps -a和docker system df是个好习惯。你根本不知道系统里那些没人管的死容器和悬空镜像什么时候会把磁盘吃满。等磁盘真的满了你再去关一个重磅服务清理空间那个体验是真的难受。如果在看日志的时候发现只有少量输出但服务明显异常也请第一时间看健康检查相关字段。有的容器状态是 Restarting说明它一直在崩溃重启循环里这时docker logs的内容绝不能只看最后几行而是要配合时间戳看时间规律找出崩溃周期才知道是依赖没起来还是内存溢出。我自己踩过最严重的一次坑是为了图省事直接docker rm -f $(docker ps -aq)清掉了一堆容器结果发现数据库容器也在里面数据卷虽然还在但中间件配置全没了。所以我格外想强调批量清理命令尤其是带-f的永远要先核对容器列表。宁可多敲两条命令也别把生产数据环境的一天心情搭进去。这章内容到这里Docker 常用命令的骨架应该已经装进你脑子里了。命令是死的场景是活的。照着 6.2 节的完整流程练上三五遍让手和脑都形成记忆之后再去看复杂实际项目中的 Docker 配置就不会心虚。下一章我可能会挑着讲讲镜像构建与 Dockerfile 的写法如果把“做蛋糕的配方”本身掌握好配合这章已经会用的“烤蛋糕”命令整个 Docker 开发闭环才算真正打通。
