说个实在话，Docker入门这件事，很多人卡住的位置不是安装，不是写Dockerfile，而是搞不明白镜像到底怎么玩。前面那篇（一）我们聊了Docker的整体概念和第一支容器怎么跑起来，这篇我重点把镜像这块的“日常操作全家桶”讲透：拉取、查看、删除、打标签、导出导入、推送到仓库，以及我在真实环境里踩过的那些坑。目标很直接，看完这篇，你能像用手机装App一样熟练地管理Docker镜像，而且知道每一步背后为什么这么做。
这篇文章适合正在学Docker、已经能跑通docker run hello-world但面对docker images里一堆镜像不知道下一步干什么的读者。也适合那些在生产环境里被镜像清理、版本回滚、离线交付折磨过的运维同事。看完你可以直接照着操作，本地环境敲一遍，基本就通了。
1. 镜像和容器的关系，再捋一遍
很多人命令背得滚瓜烂熟，但一遇到问题就懵，根子在于没把“镜像-容器”这对关系吃透。镜像可以理解成一台计算机的“硬盘克隆模板”，里面预装了操作系统的基础文件、你想要的软件、配置好的一些环境变量，全部打包成一套只读数据。容器则是这个模板每次被你启动出来的“活体实例”——它多了可写层，里面有运行时的日志、临时文件、程序产生的数据。
1.1 镜像的分层存储是怎么回事
Docker镜像不是一个大文件，而是由很多只读层（Layer）堆叠起来的。每一层对应Dockerfile里的一条指令，或者说对应制作镜像时的一次文件系统变更。拉取镜像时看到的Pulling fs layer就是在拉这些层。
这种分层设计带来两个好处：第一是共享，多个镜像可以公用底层的基础层。比如你的nginx镜像和redis镜像可能都基于同一个操作系统基础层，本地只存一份就够了，这也是为什么多个镜像加起来的总磁盘占用比想象中小的原因。第二是增量，更新版本时只需要拉取有变化的层，不需要整个重下。理解了层次，你就明白了为什么删除镜像时偶尔看到删除好几个层，以及为什么镜像构建时要尽量把不常变动的指令写前面。
1.2 镜像在磁盘上到底是什么形态
镜像在Docker环境内有自己的存储目录，Linux上通常在/var/lib/docker/下面，采用的内容寻址存储方式，镜像层的内容通过哈希值来标识和校验。这些你不用直接操作，但要知道：镜像是分层的、内容寻址的、只读的。记住这三个词，后面遇到docker save出来的包比想象中大或者小、docker images显示的镜像大小和实际占用不一致时，你就不会一头雾水。
注意：
docker images列表里显示的SIZE是镜像所有层的总大小，如果多个镜像共享了同一层，磁盘上实际占用并不是简单累加。
1.3 一个镜像能启动出多少容器
没有限制。同一个镜像可以同时启动十个八个容器，它们之间互不干扰，因为每个容器在镜像只读层之上挂了自己的可写层。这也是“一个镜像模板，多次实例化”的思想。换句话说，镜像解决的是“我要什么环境”，容器解决的是“我现在就要跑起来”。
2. 拉取镜像：别只盯着latest不放手
拉取镜像是使用Docker的第一步，命令一看就会，但里面的细节值得掰开揉碎讲一下。
2.1 基本命令和镜像命名规则
拉一个镜像的完整写法是：
docker pull [选项] 仓库地址/命名空间/镜像名:标签比如：
docker pull nginx:1.25-alpine拆解一下：nginx是镜像名，也是Docker Hub官方镜像的简写；1.25-alpine是版本标签，alpine后缀表示这个镜像采用Alpine Linux作为底层系统，体积小。如果你不写标签，默认是latest：
docker pull nginx等价于拉取nginx:latest。
2.2 为什么不建议在关键环境用latest
这个问题我在团队里反复强调过。latest是一个流动标签，官方更新大版本或者调整配置后，同一时间点不同机器上docker pull nginx拉到的内容可能不一样。今天你的测试环境跑的是1.25，明天重新部署就变成了1.27，行为可能完全不同。到时候排查半天发现是镜像版本悄悄变了，特别被动。
在生产环境、脚本、编排文件里，务必指定具体的版本标签。这样每次拉取内容可预期，回滚也方便，想回到旧版本只需要把标签改回去重新pull。
实践里我还会用-alpine、-slim这类精简版本来节省磁盘和内存。但要注意，精简版往往砍掉了很多调试工具，比如bash都没有，只有sh，网络排查工具如curl、ping可能也不存在。适合追求部署效率的场景；如果你进容器要经常调试，还是用标准镜像顺手。
2.3 拉取慢的解决思路
从官方仓库拉取镜像，在国内网络环境经常慢到怀疑人生。最常见的解决方式不是换源下载，而是给Docker配置一个registry mirror，也就是镜像源。修改Docker的配置文件/etc/docker/daemon.json：
{ "registry-mirrors": ["https://换成你网络中可用的镜像源地址"] }改完后执行systemctl restart docker。这里不展开推荐具体哪家，因为可用的公共镜像源一直在变，你只需要知道配置原理：Docker在拉取仓库时，会先问配置的镜像源要数据，源那边往往有缓存，速度会好不少。注意配置生效后拉取镜像的地址写法不变，对使用者完全透明。
重要：配置完
registry-mirrors后，如果发现镜像拉取正常了，别高兴太早。到另外一台机器上部署时，记得这台机器也要配，或者直接把Docker配置纳入统一的初始化脚本里，否则就变成只有你本机快，换台机器又回到慢吞吞的状态。
2.4 拉取过程中的状态怎么看
执行docker pull时，输出里有一堆Pull complete、Digest: sha256:...，很多人直接略过。简单解释一下：
Pulling fs layer：准备拉取分层数据Downloading：下载层内容Extracting：下载完成，解压到本地存储Pull complete：这一层就绪
层下载是并行的，所以你会看到多个层同时跳动。最后出现Digest是镜像清单的哈希，用来做内容校验。如果下次再拉同一个镜像且内容没变，Docker会直接显示Up to date，或者只有部分层需要下载。
3. 查看和管理本地镜像：这些命令要形成肌肉记忆
镜像拉下来之后，日常打交道最多的就是docker images系列了。别觉得它简单，很多排查技巧都藏在这几个命令里。
3.1 docker images到底在看什么
先看一个典型输出：
REPOSITORY TAG IMAGE ID CREATED SIZE nginx 1.25.3 2b7d6d9f3c1a 2 weeks ago 192MB redis 7.2 e4d3b4f2c1d8 4 weeks ago 117MB <none> <none> a2c1d3e4f5b6 6 weeks ago 85MB五列含义分别是仓库名、标签、镜像ID、创建时间、体积。其中IMAGE ID是镜像的唯一标识，前面12位是完整哈希的缩写，你可以在任何需要指定镜像的地方用它来代替名字，比如docker rmi 2b7d6d9f3c1a。
上面那个仓库名和标签都是<none>的，就是悬空镜像。它产生的原因通常是同名同标签的新镜像覆盖了旧镜像，旧镜像失去了标签关联，但数据层还在磁盘上。悬空镜像本身没用，还占空间，需要定期清理。
3.2 过滤和格式化输出
镜像多了以后，直接用docker images看起来费劲，两个实用技巧：
# 按仓库名过滤 docker images nginx # 按标签过滤 docker images nginx:1.25 # 按悬空过滤 docker images -f dangling=true # 自定义格式，只输出镜像ID和仓库名 docker images --format "{{.ID}} {{.Repository}}"--format用的是Go模板语法，不需要背，用到时查一下就行。关键是知道Docker支持结构化输出，这在写自动化脚本、巡检磁盘占用时非常有用。
3.3 docker inspect是排查问题的放大镜
想看得更细，用docker inspect 镜像ID。它会输出一大段JSON，包含镜像的架构、操作系统、环境变量、默认命令、端口暴露、分层数据等。比如排查“这个镜像默认跑了什么命令”就用它查Config.Cmd，想确认镜像暴露了哪些端口查Config.ExposedPorts。拿到这个信息，你就能预判容器启动后的行为，不用盲猜。
3.4 删除镜像的正确姿势与常见翻车现场
删除镜像是docker rmi，一次可以删多个：
docker rmi nginx:1.25 redis:7.2翻车点在于：容器还在运行时，它依赖的镜像删不掉。Docker会返回冲突错误，提醒你镜像正被容器使用。这时候先停容器、删容器，再来删镜像。所以正确的清理顺序是：容器 -> 镜像。
还有一个隐蔽的问题：你删掉了某个镜像的标签，以为释放了空间，但查看磁盘还是占得满满当当。因为可能还有别的镜像依赖它的分层，或者留下了悬空镜像。这时候用docker system df看空间分布，再用清理命令：
# 清理所有悬空镜像 docker image prune # 清理所有未被容器使用的镜像（慎用） docker image prune -aprune -a会把没有容器引用的镜像全部清掉，包括你辛苦拉下来备用的旧版本。用了默认latest标签的团队尤其要小心，建议执行前先docker ps -a确认哪些容器还在，或者先导出备份再清理。
4. 镜像的导出与导入：离线交付和备份的救命稻草
在没有外部网络的环境里部署Docker，是最常见的需求之一。这时候docker pull用不了，就得靠docker save和docker load这对组合。
4.1 docker save与docker load的标准用法
# 把镜像保存成tar包 docker save nginx:1.25-alpine -o nginx-1.25-alpine.tar # 在目标机器上导入 docker load -i nginx-1.25-alpine.tarload执行完，镜像的仓库名和标签都会保留下来，直接docker run就行，不用重新tag。如果tar包太大，可以配合gzip压缩：
docker save nginx:1.25-alpine | gzip > nginx-1.25-alpine.tar.gz # 导入时直接支持压缩格式 docker load -i nginx-1.25-alpine.tar.gz实测下来，docker load能自动识别gzip压缩包，不需要先解压再导入，省一步操作。
4.2 别把save和export搞混了
这是很多入门者踩过的坑。docker export导出的是容器的文件系统快照，而docker save导出的是镜像本身。具体区别我列个表：
| 维度 | docker save | docker export |
|---|---|---|
| 操作对象 | 镜像 | 容器 |
| 是否保留镜像历史层 | 保留完整分层结构 | 扁平化，只保留当前文件系统 |
| 是否保留标签/CMD等元数据 | 保留 | 不保留 |
| 导入方式 | docker load | docker import |
| 典型场景 | 镜像迁移、离线部署 | 检查容器内文件系统、容器级备份 |
如果你误用了export导出一个镜像跑起来的容器，再import回来，会得到一个没有CMD、没有ENTRYPOINT、没有健康检查、标签也丢失的裸镜像。启动时要么手写完整docker run命令，要么进容器手动起进程，极其别扭。
经验：要交付运行环境，永远用
docker save/load；要临时看看容器文件系统里到底有什么，才考虑export。别偷懒混用，踩一次坑就记住了。
4.3 多架构镜像的保存与分发
docker pull默认拉取的是当前平台对应的镜像，比如在ARM服务器上就拉ARM版本的。docker save保存下来的也只是当前平台的镜像。如果你要跨架构分发，比如把一份镜像同时部署到x86和ARM机器上，选择之一是拉取多架构清单，或者分别在对应架构的机器上pull再save。
这个问题在混合架构机房很常见，处理思路通常是根据目标机器的架构分流，而不是试图用一个包解决所有架构。更复杂的多架构清单管理涉及构建和仓库侧能力，入门阶段先记住：save/load是跟着平台走的。
5. 给镜像打标签与内网仓库推送
镜像操作里最容易被忽略、但实际工作中最重要的部分，是docker tag和docker push。没有这两招，你永远只在公共仓库和本机之间打转，无法建立自己的镜像流转体系。
5.1 docker tag到底在干嘛
docker tag不是重命名镜像，而是给同一个镜像多贴一个标签。底层逻辑是：镜像ID不变，但多了个可读的名字指针。语法是：
docker tag 源镜像名:原标签 目标镜像名:新标签典型的用法是把本地镜像改造成符合仓库规范的完整名字：
# 给本地nginx镜像打一个新的完整仓库标签 docker tag nginx:1.25-alpine 127.0.0.1:5000/mynginx:1.25这条命令执行后，本地相当于出现了两个标签，都指向同一个镜像ID。docker push 127.0.0.1:5000/mynginx:1.25时推送的就是这个新标签指向的内容。
理解了标签是可叠加的，你就明白删除镜像时docker rmi后面跟的标签只是删掉一个引用，只有该镜像的所有标签都删完，且没有容器用它，真正的内容才会被回收。
5.2 搭建一个最简内网镜像仓库
私有仓库用官方开源的registry方案就够了。启动起来非常简单：
docker run -d -p 5000:5000 --name my-registry --restart=always registry:2几分钟内，你就有一个监听在5000端口的内网镜像仓库。之后把镜像tag成127.0.0.1:5000/镜像名:标签再推上去：
docker tag nginx:1.25-alpine 127.0.0.1:5000/mynginx:1.25 docker push 127.0.0.1:5000/mynginx:1.25其他机器要从这个仓库拉镜像，同样把镜像地址写成127.0.0.1:5000/mynginx:1.25。如果是远程访问，把127.0.0.1换成这台仓库机器的IP即可。
5.3 仓库地址的HTTP凭证问题
这个坑十个人有八个人会踩。默认情况下，Docker要求仓库走HTTPS加密连接，而你本地搭的这个registry只有HTTP。直接执行docker login 127.0.0.1:5000大概率报错，提示http: server gave HTTP response to HTTPS client。
解决办法是修改Docker配置文件，把这个仓库地址加入insecure-registries白名单，让Docker允许访问不加密的HTTP仓库：
{ "insecure-registries": ["127.0.0.1:5000"] }重启Docker后重试。这个配置只建议用于内网可信环境。公网环境的仓库一定要配好证书走HTTPS，否则镜像内容和登录凭证在网络传输中是明文，这是底线问题。
5.4 push和pull的命名对称性
Docker里push和pull是严格对称的：推送时写的完整镜像名，拉取时必须写一样的，包括仓库地址、命名空间、标签。很多人推上去简单写了push 127.0.0.1:5000/nginx:1.25，但在目标机器上只写pull 127.0.0.1:5000/nginx，结果不匹配，不是拉下来的是latest的旧包，就是直接manifest unknown。养成习惯：推送时怎么写的，拉取时就怎么抄。
6. 常见问题与排查技巧实录
最后这部分，我把实际使用中频率最高的问题做个速查汇总。每一个我都亲自遇到过，给出的是经过验证的处理方式。
| 报错或现象 | 常见原因 | 处理方法 |
|---|---|---|
manifest unknown | 仓库里没有这个标签 | 先查仓库里的标签列表，确认版本号写对了 |
pull access denied | 没有权限访问该仓库或镜像 | docker login登录，或确认镜像名是否属于你的账号 |
image operating system cannot be used on this platform | 架构不匹配 | 换对应架构的镜像，或使用支持多架构的镜像重新拉取 |
Got permission denied while trying to connect | 当前用户不在docker组 | 执行sudo usermod -aG docker 当前用户名后重新登录，或使用sudo docker |
no space left on device | 磁盘写满，包含悬空镜像、日志、构建缓存 | 用docker system df看分布，docker image prune清悬空，必要时docker system prune -a，还要看容器日志 |
| 容器删了但镜像删不掉 | 可能还有别的标签指向它 | docker images -a看看所有标签，全部删除或直接用docker rmi 镜像ID -f（慎用） |
| 容器正常但镜像无法删除 | 容器在运行中 | 先docker rm -f 容器名，再删镜像 |
6.1 镜像占用空间的隐藏杀手
docker image prune -a之后，你会惊奇地发现磁盘空间并没有释放很多。因为真正占空间的往往是停止的容器自带的可写层、构建缓存、日志文件。这几个位置经常被忽略。排查手法依次是：
# 看各对象占用 docker system df # 删除所有停止的容器 docker container prune # 删除构建缓存 docker builder prune # 如果确实想清理趋于全部干净 docker system prune -a --volumes最后一条要谨慎。-a会清掉所有未被使用的镜像，--volumes会删掉未被容器挂载的命名卷，数据一旦删除不可恢复。执行前确认不是生产环境或已做备份。
6.2 架构不匹配的处理细节
ARM机器上运行镜像报平台错误，通常出现在把x86架构的镜像直接搬到ARM服务器上，或者反过来。现在很多常用镜像都发布了多架构版本，直接拉取Docker会自动匹配平台。老镜像或者冷门镜像可能只有单一架构，那就只能找对应架构的替代版本，没有人能绕过。
如果你在开发机上构建了一个x86的镜像，想给家里的ARM小主机用，不能直接把docker save的包拿过去load，那样运行时照样报平台错。要么在目标机上重新build或pull，要么用支持多架构构建的方案提前解决问题。入门阶段不深挖构建链，但记住这句话能少走弯路。
6.3 日志导致的空间暴涨
镜像只占镜像的份额，容器日志却可能悄悄吃掉整个磁盘。一个基础镜像才100多MB，但一个运行了三个月的容器，标准输出日志可能膨胀到几十GB。这种问题靠docker system prune清不干净，正确做法是限制日志大小：在Docker配置里加log-opts限制日志文件和大小，或者用日志轮转机制。这个主题展开又是一篇文章，这里只是提醒一点——排查磁盘异常时，镜像背锅往往不冤，但最狠的嫌疑人其实是日志。
最后再说两句实在话
镜像管理说到底就是一套增删查改再加传输的循环。把docker pull、docker images、docker rmi、docker tag、docker save这几个命令练成肌肉记忆，Docker对你来说就不再是黑盒了。我个人在实际操作里最大的体会是：每一条镜像操作命令背后，都要想清楚它在动分层、标签还是仓库元数据，想清楚了你就能在出问题时快速定位，而不用把Docker数据目录翻个底朝天。
把这篇文章打开，开一个终端，跟着把命令敲一遍。不需要多，就五条：拉一个指定版本的镜像，查看它，打个新标签，导出再导入，最后启动一个容器。跑通了，你对Docker镜像的感觉就完全不一样了。
