Hadoop容器迁移实战：Docker导出导入与数据卷备份恢复

前几篇我们把 Hadoop 装进 Docker从镜像搭建到伪分布式跑通再到多节点集群调优整个过程还算顺。但真正让我觉得这套方案省事的是环境配置好之后怎么把它搬到别的机器上。这一篇就专门讲容器导出导入对应系列第四篇把已经在 Docker 里跑通的 Hadoop 容器打包带走到新环境里恢复使用。如果你也遇到过这种场景——家里调好的环境到公司电脑上还要重新拉镜像、改配置、重新格式化或者要把一套测试集群完整交付给同事对方只需要一条命令就能起起来——那这篇应该能帮上忙。我会把导出导入的链路、原理、坑点都拆开讲你自己动手操作的时候能少走不少弯路。1. 动手之前先搞清楚你打包的是“容器”还是“镜像”1.1 为什么同样叫导出export 和 save 结果差很多Docker 里有两组非常容易搞混的命令docker export和docker save。从表面看它们都是把环境打成一个 tar 文件但底层逻辑完全不同。docker export针对的是容器它把容器当前的文件系统整个导出一份快照。你可以把它理解成给一台正在运行的电脑做硬盘克隆里面所有文件、配置、已安装的程序都在但是不包含这个文件系统是怎么构建出来的。Dockerfile 里的 ENV、CMD、ENTRYPOINT 这些元数据export 的时候全部丢弃。导入时用docker import得到的只是“一个包含 Hadoop 文件系统的裸镜像”启动容器时 Docker 不知道该执行什么命令自然也就不会自动拉起 SSH 或者 Hadoop 服务。docker save针对的是镜像它把镜像的每一层、标签、历史记录、启动配置等完整保留下来。导入时用docker load加载出来的镜像和原来的镜像几乎一模一样之前容器里设置过的默认命令、环境变量都还在。对于 Hadoop 这种依赖启动脚本、SSH 服务、环境变量才能正常工作的环境选择哪条链路直接决定了迁移后会不会翻车。1.2 Hadoop 容器适合用哪条链路我个人的结论非常明确Hadoop 容器迁移优先走docker commit→docker save→docker load这条链路不要直接用docker export。原因很简单。Hadoop 要跑起来不只是文件在不在的问题还涉及几个容易被忽略的东西容器启动时有没有执行 SSH 服务环境变量有没有保留比如JAVA_HOME、HADOOP_HOME默认启动命令有没有丢失/etc/hosts和主机名配置是否完整。这些东西在 commit 的时候都会保留下来因为 commit 是基于容器当前状态生成一个新镜像镜像的元数据会继承原镜像。而 export 只导出文件系统不带这些启动层面的信息。1.3 三种方案怎么选方案命令链路保留启动配置保留数据卷内容适用场景风险方案一export → import否否只需要文件不关心启动方式启动容易出问题方案二commit → save → load是否完整迁移一个已配置好的容器低推荐方案三Dockerfile compose 重建是是想要干净重建不迁移历史数据需要重新配置注意方案三能保留数据卷是因为数据卷本身独立于容器和镜像存在迁移时单独处理和方案本身关系不大。如果你用 volume 存放 HDFS 数据方案二也能配合 volume 迁移实现完整恢复。2. 源机器上把跑得好好的 Hadoop 容器变成可移植镜像2.1 导出前必须做的四件事很多人一上来直接docker commit结果导出的环境文件系统是脏的或者容器里有大量无用日志镜像体积巨大。我建议按下面四步先清理一遍。先停掉 Hadoop 相关服务保证文件系统处于一致状态。HDFS 和 YARN 在运行过程中会不断写日志和临时数据直接导出虽然一般不会导致文件损坏但可能会出现 active 状态的临时文件残留。稳妥做法是在容器里执行docker exec -it hadoop-master bash $HADOOP_HOME/sbin/stop-dfs.sh $HADOOP_HOME/sbin/stop-yarn.sh exit接着清理临时文件、日志和回收站。Hadoop 运行一段时间后/usr/local/hadoop/logs下会有大量日志/tmp下也可能有 mapreduce 任务产生的临时数据。这些对迁移没有价值但会让镜像体积变大。容器内执行rm -rf /usr/local/hadoop/logs/* rm -rf /tmp/hadoop-*再检查一下数据目录。NameNode 的数据目录和 DataNode 的数据目录是否在容器可写层里还是在之前挂载的 volume 里。这个直接影响迁移策略后面第 5 章会专门说。最后确认磁盘空间。commit 出来的镜像可能是几个 GBsave 成 tar 之后更大。先执行du -sh /usr/local/hadoop看看大小再确认宿主机磁盘够不够。2.2 用 docker commit 固化容器状态先看一下当前有哪些容器docker ps假设你的容器名是hadoop-master执行docker commit -a yourname -m hadoop 3.3.6 master with hdfs/yarn fully configured hadoop-master hadoop-master:20250601-a是作者信息-m是提交说明纯粹为了以后识别方便。镜像名和标签建议带上日期不然时间一久一堆hadoop-master:latest根本分不清哪个是哪个。commit 完成后用docker images确认新镜像已经生成。注意commit 保存的是容器当前可写层的文件系统状态和部分配置但不会保存容器运行时的端口映射、网络模式、数据卷挂载和--hostname参数。这些信息在目标机器启动容器时需要重新通过docker run指定。如果你的环境是 master slave 多节点需要把每个节点容器分别 commit 成单独的镜像比如hadoop-master:20250601、hadoop-slave1:20250601后续逐个打包传输。2.3 用 docker save 打包成单文件镜像有了接下来把它打成单文件。基本命令docker save -o hadoop-master-20250601.tar hadoop-master:20250601默认是不压缩的几个 GB 的镜像打出来就是几个 GB 的文件。我实际使用中更推荐管道压缩docker save hadoop-master:20250601 | gzip hadoop-master-20250601.tar.gz这样传输和存储压力小很多。加载的时候两种文件都能直接识别不用提前解压。打完包后确认一下文件完整性用ls -lh查看文件大小最好顺手做个 md5md5sum hadoop-master-20250601.tar.gz记录下 md5 值传到目标机器后核对避免传输过程中文件损坏。这步看起来多余但对大文件传输非常重要Hadoop 环境打包出来动不动几个 GB网络中断或者磁盘问题都可能导致 tar 包损坏。2.4 传输文件到目标主机打包文件传到目标机器方式看你的网络环境。推荐使用rsync支持断点续传大文件传一半断了也不用重来rsync -avP hadoop-master-20250601.tar.gz usertarget-host:/data/docker-images/如果只是几台机器之间临时传scp也够用。注意传输完成后在目标机器上核对 md5md5sum -c hadoop-master-20250601.tar.gz.md5集群环境记得多节点镜像一起传放在同一个目录方便统一管理。3. 目标机器上导入镜像、启动容器、恢复集群3.1 docker load 加载镜像新机器上先确认 Docker 环境正常。如果还没装 DockerWindows 上用 Docker DesktopLinux 上用对应发行版的 docker-ce 包装好能跑docker ps就行。加载镜像docker load -i hadoop-master-20250601.tar.gz或者用管道方式docker load hadoop-master-20250601.tar.gz区别不大。加载完确认镜像已经出现docker images多节点的镜像也需要逐个 load。3.2 启动容器的核心参数不能漏这是整个迁移过程中最容易被忽略、也是最容易出问题的环节。很多人导入镜像后随手执行docker run -d --name hadoop-master hadoop-master:20250601结果容器起来了但 Hadoop 服务根本没法正常注册DataNode、NodeManager 全都连不上 NameNode。原因就是启动参数丢了。Hadoop 配置里面大量使用主机名比如core-site.xml里的fs.defaultFShdfs://master:9000yarn-site.xml里的yarn.resourcemanager.hostnamemaster。如果容器启动时没有显式指定--hostname master新容器的主机名是随机生成的NameNode 和 DataNode 对不上整个集群就散了。正确的启动命令大致是docker run -d \ --name hadoop-master \ --hostname master \ --network hadoop-net \ -p 9870:9870 \ -p 8088:8088 \ -p 9864:9864 \ -p 8042:8042 \ -p 9000:9000 \ -p 8032:8032 \ -p 8030:8030 \ -p 8031:8031 \ -p 8033:8033 \ hadoop-master:20250601各个端口作用如下端口服务说明9870NameNode Web UIHDFS 管理界面8088ResourceManager Web UIYARN 管理界面9864DataNode Web UI查看数据节点状态8042NodeManager Web UI查看节点管理状态9000HDFS RPC客户端读写 HDFS 用的端口8030/8031/8032/8033YARN RPCResourceManager 相关通信端口如果你用了自定义网络hadoop-net在新机器上要先创建同名网络docker network create hadoop-net然后启动容器时指定--network hadoop-net。如果用默认 bridge 网络容器重启后 IP 会变主机名解析有时会出问题所以自定义网络更稳。提示如果之前是用-v挂载了数据卷启动时也要把同样的挂载参数带上否则容器里的数据目录是空的NameNode 会找不到元数据。3.3 进入容器启动 SSH 并拉起 Hadoop 服务容器启动后先确认容器是活着还是直接退出了docker ps -a状态应该是 Up。如果已经 Exited说明启动命令有问题参考第 4 章排查。进入容器docker exec -it hadoop-master bash先看下基础环境是否完整java -version echo $HADOOP_HOME service ssh status如果 SSH 没启动手动启动service ssh start然后检查 NameNode 的数据目录是否还在ls -l $HADOOP_HOME/hdfs/name/current这一步很关键。如果目录里有VERSION、edits_inprogress_*这类文件说明元数据完整可以放心启动。如果目录是空的说明 NameNode 从来没有格式化过或者数据在 volume 里没挂载上来这时候贸然启动会报错。确认没问题后启动服务start-dfs.sh start-yarn.sh执行jps查看进程jps伪分布式模式下应该能看到 NameNode、SecondaryNameNode、ResourceManager、DataNode、NodeManager 这几个进程。浏览器访问http://localhost:9870和http://localhost:8088确认 Web UI 能打开并且 DataNode、NodeManager 都注册成功。最后验证 HDFS 数据完整性hdfs dfs -ls /之前 HDFS 里的文件如果都在说明迁移成功。3.4 单节点伪分布式与多节点集群的恢复差异如果你之前搭建的是单节点伪分布式那到这里就结束了。但如果你之前是 master slave 的集群恢复工作要多几步。整个集群的容器都导入后需要保证所有容器在同一个 Docker 网络里/etc/hosts里能互相解析主机名master 到每个 slave 的 SSH 免密配置还在启动顺序尽量和原来一样先启动 master再启动 slave最后在 master 上执行start-dfs.sh和start-yarn.sh。如果 SSH 免密失效一般是因为从容器把/root/.ssh或home 目录里的密钥弄丢了。重新配置一次即可ssh-keygen -t rsa -P -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys然后把公钥分发到 slave 节点。4. 导出导入之后的那些坑我基本都踩过4.1 import 后容器起不来服务也不自动拉起现象用docker export导出、docker import导入后执行docker run容器秒退或者容器能起来但进去了 SSH 没启动、Hadoop 进程一个都没有。原因export 丢掉了 Dockerfile 里的 ENTRYPOINT 和 CMD容器启动时没有默认要执行的命令。Docker 容器必须有一个前台进程没有的话容器立即退出。解决方法如果已经用了 export/import 链路可以在docker run时手动指定启动命令。但我个人建议干脆别走这条路直接用 commit save load。你已经配置好的启动逻辑、SSH 服务、环境变量都会被保留不存在这个问题。4.2 hostname 变了DataNode 和 NodeManager 注册不上现象NameNode 进程起来了但 9870 端口页面里看不到 DataNode日志里大量UnknownHostException或者Retrying connect to server: master/...。原因Hadoop 配置里到处都是master这个主机名启动容器时没有--hostname master导致主机名和配置对不上。解决方法删掉容器重新用正确的启动命令创建docker rm -f hadoop-master docker run -d --name hadoop-master --hostname master ... hadoop-master:20250601如果改起来太麻烦也可以进入容器修改core-site.xml、hdfs-site.xml、yarn-site.xml里的主机名配置但这样容易漏不如直接一开始用--hostname固定。4.3 端口映射不全Web UI 打不开或者功能残缺现象http://localhost:9870能打开但点击 DataNode 的链接打不开或者 YARN 页面里点 NodeManager 的日志链接是坏的。原因启动容器时只映射了 9870 和 8088其他端口没有暴露。解决方法删掉容器重新启动把 DataNode、NodeManager 的端口也映射出来。参考 3.2 节的完整命令。如果是本机测试图省事可以用--network host容器直接复用宿主机网络不需要做端口映射。但多容器情况下端口冲突风险极高不建议集群环境使用。4.4 误格式化 NameNode直接把集群数据搞没了现象迁移后启动 HDFSDataNode 报 clusterID 不匹配或者 NameNode 起不来。有人一慌就执行hdfs namenode -format结果数据全没了。原因NameNode 和 DataNode 的 clusterID 不一致一般是因为数据目录里的current/VERSION文件丢了或者目录路径变了。format 会重新初始化 NameNode 的元数据和已有 DataNode 的 clusterID 对不上整个分布式文件系统的数据就废了。解决方法迁移前把$HADOOP_HOME/hdfs/name和$HADOOP_HOME/hdfs/data目录备份好。如果确实需要重新初始化先确认数据有没有备份。clusterID 不一致的一般处理是对比 name 和 data 目录下的 VERSION 文件手动改成一致而不是 format。重要提示HDFS 的 NameNode 元数据是整个集群的命根子。迁移过程中宁可多花时间备份也不要图快直接 format。4.5 数据明明在旧容器导出来之后新容器里没了现象旧容器里 HDFS 有数据迁移到新容器后hdfs dfs -ls /是空的或者看到的文件数量不对。原因数据根本不在容器可写层里而是放在了 Docker volume 或 bind mount 中。commit 和 export 都只处理容器文件系统不会包含 volume 数据。解决方法单独备份 volume。假设 volume 名叫hadoop-data在源机器上执行docker run --rm -v hadoop-data:/data -v $(pwd):/backup ubuntu tar czf /backup/hadoop-data.tar.gz -C /data .把备份文件传到目标机器然后创建同名 volume 并解压docker volume create hadoop-data docker run --rm -v hadoop-data:/data -v $(pwd):/backup ubuntu tar xzf /backup/hadoop-data.tar.gz -C /data注意容器内的 Hadoop 进程默认可能是用 hadoop 用户跑的解压后要确认权限正确docker run --rm -v hadoop-data:/data ubuntu chown -R hadoop:hadoop /data4.6 问题速查表问题典型现象排查方向解决方案容器秒退docker ps -a显示 Exited启动命令丢失用 commitsaveload手动指定 commandDataNode 注册不上9870 页面没有 DataNodehostname 不一致--hostname master启动Web UI 打不开端口无法访问端口映射缺失映射完整端口列表HDFS 数据丢失ls /为空数据在 volume 中单独备份/恢复 volumeNameNode 起不来日志报 clusterID 不一致元数据目录损坏恢复 name 目录禁止乱 formatSSH 免密失效master 无法 ssh slave密钥丢失重新生成并分发5. 更稳的做法把数据放到 volume 单独管理5.1 为什么 volume 比容器可写层更靠谱容器本身是易失的删掉容器可写层的数据通常也会一起消失。volume 是独立于容器生命周期存在的存储对象容器删除、镜像重建volume 里的数据都还在。对于 Hadoop 来说最值钱的是 NameNode 元数据和 DataNode 上的真实数据。如果这些数据写在容器可写层迁移时只能依赖 commit 打包容量大、迁移慢、清理麻烦。如果一开始就把 HDFS 数据目录挂到 volume 上迁移时镜像和数据可以分开处理镜像负责环境volume 负责数据逻辑清晰得多。5.2 迁移带 volume 的 Hadoop 容器的完整流程假设源机器上容器启动命令类似docker run -d \ --name hadoop-master \ --hostname master \ -v hadoop-namenode:/usr/local/hadoop/hdfs/name \ -v hadoop-datanode:/usr/local/hadoop/hdfs/data \ -p 9870:9870 \ -p 8088:8088 \ hadoop-master:20250601那么迁移步骤是先停服务保证数据一致docker commit生成环境镜像docker savegzip打包镜像单独用一次性容器备份两个 volume把镜像文件和 volume 备份传到目标机器docker load加载镜像创建同名 volume解压 volume 备份到对应目录用和源机器一致的挂载参数启动容器启动 Hadoop 服务并验证。到这里容器导出导入的整体流程就说完了。最后说一点个人感受。导出导入这个话题看起来不过是几条 docker 命令但真正决定环境能不能恢复成功的不是命令本身而是你对自己环境理解得够不够深。我前两次折腾都图省事用 export结果每次都在启动容器那一刻翻车后来老老实实走 commit save load再配合 volume 数据管理基本没有出过问题。你如果马上要换机器或者给别人交付环境建议按这个顺序走一遍能省掉大量排错时间。