奶茶余香最近一段时间好几个朋友都在问同一个问题：从网上弄一个 Docker 镜像，怎么在完全不联网的机器上跑起来？问的人多了，我觉得干脆把这套完整的流程写明白——从搜索镜像、拉取镜像、打包镜像、删除本地镜像、重新加载镜像，最后把 Redis 容器跑起来，每一步都拆开揉碎，讲清楚命令什么、背后干了什么、踩坑点在哪里。这套流程不光是 Redis 能用，MySQL、Nginx、自己打的应用镜像都一样适用，理解了它的原理，你就能处理绝大多数镜像和容器的日常管理。这篇东西适合刚接触 Docker 不久、对镜像和容器概念有点模糊的新手，也适合已经写了几天 Dockerfile、但没系统整理过镜像搬运流程的人。
1. 先把“为什么”讲清楚：这套流程到底解决什么问题
很多教程上来就是三条命令复制粘贴，跑完就完事，完全不解释为什么是这个顺序、为什么要做这一步。但实际工作中，镜像管理这块的需求远不止“我拉一个镜像下来跑容器”这么简单，日常开发里遇到最多的场景往往是这些。
1.1 日常开发里最常见的镜像管理场景
第一个场景是环境迁移。你在自己电脑上把一个服务调通了，用的 Redis 或者 MySQL 镜像，现在要在公司测试服务器上部署，但测试服务器在内网，没有外网权限，这时候最简单可靠的方案就是把本地已经验证过的镜像打包带走，到目标机器上重新加载。这个过程用到的就是 save、load 这两个命令，而不是重新拉取——因为拉取这个动作在离线环境下根本做不了。
第二个场景是版本固化。镜像仓库里的 tag 是会被覆盖的，例如 redis:latest 今天指向的是 7.2，下个月可能就变成 7.4 了。你要是 Dockerfile 或者启动脚本里写死 latest，下次重新部署很可能拉到一个和你之前验证的版本完全不同的镜像，Redis 还好，有些应用镜像内部行为差异很大，这就是典型的“在我这里好好的，部署上去就炸了”。把验证过的镜像通过 save 打包归档，等于给自己的环境上了一道保险。
第三个场景是离线分发给客户。很多做 toB 项目的朋友都干过这事：客户现场没有外网，但需要部署一套服务，其中依赖了 Redis。你不可能让客户自己去配镜像加速、去拉包，最省事的办法就是本地把镜像打成 tar 包，U盘或者上传到客户内网服务器上，然后 load 进去，一气呵成。
1.2 镜像与容器的关系，以及镜像保存背后的一张“分层快照”
聊具体命令之前，必须把镜像和容器这两个概念掰扯清楚，否则后面你会被各种报错搞得一头雾水。镜像你可以理解成一摞只读的模板文件，里面装好了操作系统的基础环境、Redis 的二进制文件、配置文件、依赖库，所有的层加起来就是“一个能跑的 Redis 程序”。容器则是基于这份模板复制出来的一个沙箱进程，它有自己独立的文件系统、网络、进程空间，你在容器里写的任何数据都落在容器自己的可写层上，不会改动镜像本身。
这里有一个非常关键的点：你运行一个容器之后，改了里面的配置文件、写入了数据，这些内容都在容器的可写层里。如果直接把容器删了，这些改动就全没了，镜像还和之前一模一样。所以后面讲到的“把镜像打包”，它打的是镜像本身的内容，不包含某个容器的运行状态和数据。如果你想把某个正在运行的容器连同它里面的改动一起导出去，那是 export 命令的活，但 export 出来的东西不再是一个标准镜像，它丢掉了镜像的历史分层信息，通常只用来做临时的文件系统备份，不适合用来重新构建容器。这个区别后面实操部分我还会再提。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手前的关键准备：镜像仓库、版本选择与 Redis 基础参数
我见过很多新手上来就是 docker run redis，然后发现拉不动、连不上、数据没了，一路踩坑踩到怀疑人生。其实大部分问题在一开始配置好环境就能避免，所以别急着敲 run 命令，先把这几件事想清楚。
2.1 拉不到镜像怎么办：镜像加速配置与仓库选型
Docker Hub 的访问速度在国内一直是个玄学问题，有时候快有时候慢，慢起来一个几十兆的镜像能拉半个小时。解决办法是配置镜像加速器，也就是 registry mirror。在 Docker Desktop（Windows 和 Mac 都有这个工具）的设置里，找到 Docker Engine 的配置项，在 json 里加上 registry-mirrors 就好。
json复制{
"registry-mirrors": [
"<你的镜像加速地址>"
]
}
Linux 上也一样，编辑 /etc/docker/daemon.json，没有这个文件就新建一个，配置完执行 systemctl restart docker 让配置生效。这里提醒一句：网上有很多公开的加速地址，不同服务商的可用性差异很大，而且免费地址经常变动，要是发现不生效了，换成其他可用的即可。这个配置是给 Docker 拉镜像用的，你需要先配好，后面 docker pull 才能顺畅。
另外多提一嘴仓库选型。如果你用的是公司内部搭建的 Harbor，或者云厂商的容器镜像服务，那没这些破事，直接配置成私有仓库地址就行。自己玩的话，优先从官方镜像仓库拉 redis、nginx 这些官方维护的镜像，安全性和稳定性都有保障，别去一些冷门第三方仓库下载来路不明的镜像，里面塞了什么脏东西你完全不知道。
2.2 Redis 镜像版本怎么选：标签不是越新越好
拉 Redis 镜像之前先选版本，这个选择直接影响你后面踩不踩坑。Redis 大版本之间的差异不小，比如 Redis 6.0 引入 ACL、Redis 7.0 改进了很多底层机制，不同的业务代码可能只适配了特定版本。你要是看到 redis:latest 就直接拉，结果最新的主版本变了，在容器里访问 CONFIG GET maxmemory 这类命令时行为可能不一样，业务表现也会跟着变。
我给一个简单靠谱的选择思路：先去 Docker Hub 的 redis 仓库页面，或者直接在命令行里 docker search redis，看看官方都提供了哪些 tag。然后优先选带具体版本号的，比如 redis:7.2-alpine。-alpine 后缀表示这个镜像基于 Alpine Linux 构建，体积小，通常比标准版小一半以上，适合部署和学习。如果你需要完整的 glibc 兼容性或者要装额外的编译工具，再考虑标准版 redis:7.2。
还有一个小细节：Redis 的镜像 tag 里有些带 -alpine、有些带 -bookworm、-bullseye，这些后缀表示基础操作系统版本。Alpine 用 musl libc，标准版用 glibc，绝大多数场景下 Alpine 都没问题，但如果你要在容器里做编译或者加载一些动态库，可能会遇到兼容性问题，这时候选标准版更稳。总之，选定一个版本之后别频繁换，保持稳定。
2.3 运行 Redis 容器前必须知道的三件事
跑 Redis 容器不是 docker run redis 一个命令就完事的，你至少要先想清楚三件事，不然跑起来也白搭。
端口映射。Redis 默认监听 6379 端口，容器内部是 6379，宿主机这边你要决定暴露到哪个端口。开发环境一般就是直接 -p 6379:6379，左边是宿主机端口、右边是容器端口。如果宿主机的 6379 已经被别的 Redis 占了，就换成 -p 6380:6379，然后你连接的时候用 6380 就行。
持久化。Redis 的数据默认是存在进程内存里的，容器一删，数据就没了。所以生产环境里跑 Redis 容器必须挂载数据卷，把 Redis 的持久化文件（RDB 快照或者 AOF 日志）放到宿主机上。做法是用 -v redis-data:/data 命名一个数据卷，或者映射到宿主机某个目录，比如 -v /my/redis/data:/data。后面实操部分我会把完整命令写出来。
密码认证。默认 Redis 是无密码裸奔的，你要是直接把端口暴露到公网，几分钟内就会被扫描并植入挖矿程序。要么在 Docker run 命令里通过 --requirepass 传启动参数，要么挂载一个配置好 requirepass 的 redis.conf 进去。这个环节千万不要省。
3. 完整实操：从搜索到运行 Redis 容器的全流程
环境准备这部分假设你已经装好了 Docker。Windows 用户建议直接用 Docker Desktop，装完不用配什么虚拟机；Linux 用户根据自己的发行版用包管理器装上 docker-ce 或 docker.io 都行。下面我按顺序走一遍完整流程，每步命令都给出，并解释为什么要这么做。
3.1 搜索镜像：先看清官方镜像和 tags
搜索镜像是很多人忽略的一步，觉得直接拉不就完了吗？其实 docker search 能帮你确认镜像是否存在、官方维护的还是第三方上传的、大概有多少星。命令行敲这个命令：
bash复制docker search redis
输出里会有 NAME、DESCRIPTION、STARS、OFFICIAL、AUTOMATED 这几列。看 OFFICIAL 这一列，如果是 [OK]，说明是官方镜像，可以放心用；没有标记的第三方镜像要谨慎。STARS 数字某种程度上反映了社区认可度，虽然不是绝对标准，但至少有参考价值。
搜索结果只能让你初步判断，具体的 tag 列表在命令行里看不了太全。建议这时候打开 Docker Hub 的网站，搜索 redis，进到 Tags 标签页，你会看到一长串版本列表。选版本的时候注意几个点：latest 是滚动更新的，不适合固定环境；7.2 这类大版本号会跟着小版本往前走；7.2-alpine 这种带后缀的是精简版。确定了要用的 tag，再进入下一步拉取，这样才能保证你不会拉错版本。
3.2 拉取镜像：带标签拉取比 latest 靠谱
确定好版本之后就可以拉取了。这里我强烈建议不要直接 docker pull redis，而是指定 tag。举个例子：
bash复制docker pull redis:7.2-alpine
可以看到 Docker 会显示拉取进度，包括每一层的 digest 和下载状态。Redis 镜像不大，一会儿就拉完了。拉完之后你可以用 docker images 命令确认一下：
bash复制docker images
输出类似这样：
code复制REPOSITORY TAG IMAGE ID CREATED SIZE
redis 7.2-alpine xxxxxxxxxxxx 2 weeks ago 15MB
这里能看出来，基于 Alpine 的 Redis 镜像才 15MB 左右，非常轻量。如果你拉的是标准版，大小会到 100MB 以上。看你自己的网络环境和部署需求来决定用哪个。
如果你已经拉了 latest，发现自己想用的其实是某个具体版本，那也没关系，再拉一次具体 tag 就行，Docker 会自动按 tag 区分镜像。要注意的是，不同 tag 可能指向同一个镜像 ID，也可能不是，只要 tag 不同，docker images 里就会显示为两条记录。
3.3 打包镜像：docker save 的常见误区
镜像拉下来、验证过能用了，下一步是打包。打包镜像用 docker save，这个命令把镜像的所有分层打包到一个 tar 归档文件里。命令格式：
bash复制docker save -o redis-7.2-alpine.tar redis:7.2-alpine
-o 表示输出文件路径，后面跟上镜像的仓库名和标签。执行完你就会在本地看到一个 tar 文件。这个 tar 文件就是你可以拷走、上传、离线分发的宝贝。
这里有一个很重要的区别，很多人会把 save 和 export 搞混。save 打包的是镜像，保留镜像是分层结构和所有元数据，load 回去之后可以继续基于它 run 容器；export 打包的是容器的文件系统，不包含镜像的分层信息，import 回去之后你得到一个镜像，但这个镜像的历史记录都没了，也不能直接还原成原本的镜像结构。我的建议是：做镜像迁移和分发，一律用 save + load 组合，不要用 export + import，后者只适合特殊场景下的紧急备份，比如容器里生产了临时数据，你只想把这个文件系统整体导出来留个底。
打包完可以再验证一下文件：
bash复制ls -lh redis-7.2-alpine.tar
大约 15MB 左右。如果你打包的是标准版，可能会到 100MB 以上，属正常现象。
3.4 删除本地镜像：先停容器再删，否则会遇到怪问题
打包好了 tar 文件，接下来我们要模拟一下“把本地镜像删掉，再用 tar 重新加载”的完整闭环，这样你才能确认这个 tar 是可用的。删除本地镜像的命令是 docker rmi，但删除之前有个前置条件：如果有容器正使用这个镜像，是删不掉的。
所以第一步是先把容器停掉并删掉。假设你已经有一个用这个镜像跑的容器：
bash复制docker stop redis-container
docker rm redis-container
docker stop 会优雅地停掉容器，发送 SIGTERM 信号给 Redis 进程，让它可以做退出前的清理工作。然后再 docker rm 删除容器本身。如果你只想快速移除，也可以 docker rm -f redis-container，直接从强制停到删一步到位，但这不会给 Redis 优雅退出的机会，正常环境我建议先 stop 再 rm。
确认没有容器引用之后，再删镜像：
bash复制docker rmi redis:7.2-alpine
docker rmi 后面同样跟上镜像名或镜像 ID。执行完再 docker images 看一眼，redis 镜像已经从列表里消失了。如果你只有这一个 Redis 镜像，现在本地己经没有任何 Redis 镜像了，这正是我们要的效果——模拟一台全新机器上什么都没有的场景。
这里要提醒一个小坑：如果 docker rmi 报错说 image is being used by container，说明你忘了删掉依赖这个镜像的容器，哪怕容器是停止状态也不行。Docker 不允许删除一个已经被容器引用的镜像，因为容器可能随时被启动，启动时还需要依赖这个镜像来创建新的可写层。解决方式就是先删容器，或者记住容器的 ID 之后再删。
3.5 重新加载镜像：在另一台机器上还原 tar 为可用镜像
现在到了整个流程的核心环节——把 tar 包重新加载成镜像。假设你已经把 redis-7.2-alpine.tar 拷贝到了目标机器上，执行命令：
bash复制docker load -i redis-7.2-alpine.tar
或者也可以用输入重定向的写法：
bash复制docker load < redis-7.2-alpine.tar
两种方式效果一样，-i 参数更直观一些。执行之后，Docker 会解析 tar 文件里的分层数据和元数据，把镜像恢复到本地镜像库。加载完成后，再用 docker images 确认一下，你会发现 redis 镜像又回来了，仓库名、标签、镜像 ID 都和之前一模一样。
加载成功之后有个小技巧，帮你在离线环境快速验证：直接 docker run 一下这个镜像，看能不能正常启动 Redis。如果能起来，说明 tar 文件没损坏、镜像内容完整；如果启动失败，那多半是 tar 文件在拷贝过程中出了问题，重新拷贝或者重新打包就行。
如果加载之后发现镜像名和标签是 <none>，也就是所谓的悬空镜像，那可能是打包的时候用了镜像 ID 而不是仓库名加标签。打包命令用完整的 redis:7.2-alpine 就不会有这个烦恼，load 回去之后还能保留原名。这也是我推荐大家打 tag 而不是打镜像 ID 的原因。
3.6 运行 Redis 容器：从简单 run 到带持久化的完整命令
镜像恢复好了，最后一步就是把容器跑起来。先看一条最基础的运行命令：
bash复制docker run -d --name redis-container -p 6379:6379 redis:7.2-alpine
拆解一下这条命令的参数：-d 表示后台运行；--name 给容器起名字，方便后面管理；-p 6379:6379 把宿主机的 6379 端口映射到容器的 6379 端口；最后指定镜像名。执行完可以用 docker ps 看到容器的运行状态，再用 docker logs redis-container 看 Redis 的启动日志，会看到熟悉的“Ready to accept connections”字样。
但我前面说了，直接这样跑不够稳，至少要把数据持久化和密码认证加上。推荐的生产级起步命令是这样：
bash复制docker run -d \
--name redis-container \
-p 6379:6379 \
-v redis-data:/data \
--restart unless-stopped \
redis:7.2-alpine \
redis-server --appendonly yes --requirepass yourpassword
这条命令多了几个东西，我一个个解释：
-v redis-data:/data：创建一个名为 redis-data 的卷，挂载到容器的 /data 目录下。Redis 的 RDB 快照和 AOF 日志默认都会写到这个目录。这样即使容器被删除，数据也还在宿主机上。
--restart unless-stopped：设置容器的重启策略，Docker 守护进程启动时自动拉起这个容器。除非你手动 stop 过它，否则机器重启后 Redis 会自动恢复，省去人工干预。
redis-server --appendonly yes --requirepass yourpassword：这是容器启动时要执行的命令。redis-server 是 Redis 的启动入口，后面的参数可以直接覆盖默认配置。--appendonly yes 开启 AOF 持久化，--requirepass 设置访问密码。把密码里的 yourpassword 替换成你的强密码，别用什么 123456。
跑起来之后验证一下能不能连接：
bash复制docker exec -it redis-container redis-cli -a yourpassword ping
-a 后面跟密码，能正常返回 PONG 就说明容器内的 Redis 服务是好的，密码认证也生效了。如果你是在宿主机上直接连，也可以用 redis-cli -h 127.0.0.1 -p 6379 -a yourpassword ping，走的是端口映射通道，确认宿主机的端口真的映射上去了。
这一步完成后，你其实已经走完了从搜索到运行的完整流程。整条链路是：search 确认镜像 → pull 拉取指定 tag → save 打包成 tar → stop/rm 容器 → rmi 删镜像 → load 重新加载 → run 启动容器，每一步环环相扣，理解了这条链路，以后你面对任何镜像迁移需求都不会慌。
4. 实战踩坑与排查记录
命令都走完了，并不代表万事大吉，实操中总有些问题会反复出现，有些甚至不报错但行为诡异。下面把最常见的几个坑和排查思路整理一下，希望能帮你省点时间。
4.1 容器启动了但应用连不上 Redis
这个坑出现频率极高。你用 docker ps 看到容器 Up 状态，日志里 Redis 也正常起来了，但你的应用连接就是超时或者被拒绝。排查思路从这几个角度入手。
第一，检查端口映射是否生效。在宿主机上执行 docker port redis-container，看有没有正确的端口映射输出。如果输出为空，说明 run 的时候 -p 参数没生效，容器内部端口没有映射到宿主机。
第二，检查防火墙。Linux 服务器上最常见的问题就是宿主机的防火墙没放行对应端口。CentOS 用 firewall-cmd --list-ports 查看，Ubuntu 用 ufw status。这里有个很容易忽略的点：你容器跑了 6379，宿主机防火墙也得放行 6379，因为数据包要先经过宿主机的网络栈再被 Docker 转发进容器。
第三，检查 Redis 的绑定地址。如果你用了自定义配置文件启动 Redis，并且配置文件里设了 bind 127.0.0.1，那 Redis 只会监听容器内的回环地址，端口映射也白搭。默认 Redis 镜像里没有配置 bind，所以一般不会遇到这个问题，但如果你自己写配置文件挂载进去，要特别注意。
4.2 redis-cli 连接时提示 NOAUTH Authentication required
这个问题很直白，就是设置了密码没带。用 redis-cli -a 密码 或者连上之后执行 AUTH 密码 都能解决。但这里有个安全隐患要提醒：在命令行里直接写 -a 密码，密码会出现在命令历史和进程列表里，生产环境尤其是多人共用服务器的情况下，建议用 REDISCLI_AUTH 环境变量。在容器里临时调试的话，可以先进容器再执行 redis-cli，然后交互式输入 AUTH，避免密码留在 shell 历史里。
另外一个容易搞混的场景是：你设置了 --requirepass，但在 docker exec 进入容器后再用 redis-cli，同样需要带上密码，和宿主机上用客户端连接是两回事。容器内的 redis-cli 是经由本机 socket 还是 TCP 连接，认证规则一样，总之知道密码才能干活。
4.3 容器重启后数据全没了
这条踩坑率极高。大部分人说“我的 Redis 数据重启就丢失”，原因就一个：没挂数据卷。Redis 镜像里 /data 目录是它的工作目录，持久化文件默认落在这里，如果你 run 的时候没有用 -v 挂载，数据就留在容器的可写层里，容器一删数据就没了——注意，不是重启，是删除容器。如果你只是 docker restart，容器可写层还在，数据不会丢。
所以排查思路很简单：docker inspect redis-container，看 Mounts 那一节，确认有没有把 /data 映射到宿主机。如果 Mounts 为空，说明你没挂卷，数据都在容器层里。这时候趁容器还没删，赶紧用 docker cp redis-container:/data/appendonlydir/ ./backup/ 把数据拷出来，后续再重新用挂载卷的方式启动容器。数据救命这招很有用，但最好是早点养成挂卷的习惯，别等到数据丢了才想起来。
4.4 docker load 之后镜像名变成了 <none>
这个问题的根因我前面提过：save 的时候用的不是完整的仓库名加标签，而是镜像 ID。docker save -o redis.tar <镜像ID> 打包出的 tar 在 load 回去之后，镜像会缺失仓库名和标签信息，docker images 里显示成 <none>，虽然能 run，但管理起来很别扭。
解决办法有两个。一个是 save 的时候严格用 仓库名:标签，比如 redis:7.2-alpine，这样 load 回来就是完整的名字。另一个是已经出现 <none> 的情况，可以用 docker tag <IMAGE_ID> redis:7.2-alpine 手动补上标签。这个坑在写脚本批量打包镜像的时候特别容易踩，脚本里你拿到的可能就是一个 ID 变量，要格外小心。
顺便再说一下 save 和 export 的选择，这里再强调一遍：save 是镜像的完整快照，带分层、带原数据，适合镜像分发；export 是容器文件系统的扁平导出，不带分层，通常只用来备份容器现场。你要做“把一台机器上的镜像搬到另一台机器”，用 save 准没错。
4.5 Windows / Mac 的 Docker Desktop 与 Linux 服务器的差异
如果你开发机是 Windows 或 Mac，用的 Docker Desktop 跑这套流程，有个地方要特别注意：路径分隔符和文件权限。
Windows 上当你用 -v D:/redis-data:/data 挂载宿主机目录时，路径要用正斜杠或者 Windows 风格加引号，否则 Docker 可能解析失败。另外跨平台复制 tar 文件时，Windows 上生成的 tar 包到 Linux 上 load 一般没问题，但反过来如果有权限问题，检查一下文件的当前属主。
Mac 上 Docker Desktop 的挂载性能比 Linux 原生要差一些，大量 IO 密集的操作（比如 Redis 做 RDB 快照）可能在 Mac 上明显变慢，这在开发环境问题不大，但生产环境还是建议直接跑在 Linux 服务器上，别在 Docker Desktop 里生产。
Docker Desktop 还有个小毛病：它依赖宿主机的虚拟化支持，Windows 上如果没开启 Hyper-V 或 WSL2，启动时会报错。遇到这类问题基本就是去 BIOS 里打开虚拟化开关，或者把 WSL2 配好，网上资料很多，这里不展开。
5. 经验小结：这套流程还能怎么扩展
回到最开始的问题：为什么这整套流程值得掌握？因为镜像管理这个东西，不管 Docker 出到第几个大版本，搜索引擎怎么变，底层逻辑就这一套——拉、存、传、载、跑。你把这条链路在本地走顺了，后续不管是给内网服务器部署 Redis、MySQL，还是自己构建一个业务镜像发给同事试用，思路都是一样的。
关于命令顺序再补充一个实用心得：我实际操作时一般会在 save 之后顺便 docker images 看一眼镜像 ID，再把 ID 记录在 tar 包旁边的文本文件里，这样传到目标机器上 load 完，可以逐一核对镜像 ID 是否一致，防止 tar 包传错版本的问题。特别是批量迁移多个镜像的时候，做一个简单的清单文件，比靠脑子记要靠谱得多。
后面可以延伸的方向也很多。比如你可以在 save 之前用 docker history 查看镜像分了哪些层，理解镜像体积为什么这么大；也可以写一个小脚本批量 save 多个镜像，自动生成 tar 包和校验文件；或者研究一下 Compose 文件，把 Redis 容器和其他服务一次性编排起来。这些都是很多人的实际需求。如果这篇文章帮到你了，欢迎收藏也好，分享也好，转头再去折腾的时候少踩一个坑，就算值了。