Docker 19.03.9离线部署：本地yum源与镜像导入实战

简介面向需要在内网或离线环境部署容器服务的运维与开发人员这份docker19.03.9离线部署工具提供了完整的安装物料免去逐台机器联网拉取依赖的麻烦适合网络受限机房、内网生产环境或需要统一Docker版本的团队使用。压缩包约57.69MB共4个文件涵盖tgz格式的Docker二进制镜像、sh格式的自动化部署脚本、service格式的systemd服务单元以及tpl格式的配置模板各文件分工明确便于组合使用从镜像导入到服务注册均有对应文件承接。目前已有9041人学习或下载适合中初级运维人员参考也可作为生产环境批量部署时的基础物料。借助该工具读者能一次获得离线安装Docker 19.03.9所需的核心文件与配置入口既可用于新环境快速搭建也能在断网条件下完成版本统一交付减少手工配置出错的可能。1. 离线部署工具到底是什么一台没有外网的服务器怎么装docker19.03.9某台刚拆封的服务器放在机房没有外网yum源也指向内网空仓库开发却催着上线。你手里只有一个U盘要在上面装docker19.03.9。这个标题里的“离线部署工具”本质是把docker引擎的rpm包、依赖关系、业务镜像tar包、daemon配置和安装脚本提前打包成一套可以在内网复用的工具包。到了现场不是现场找包而是一条命令解决依赖安装、服务启动和镜像导入。适合做私有化交付、隔离机房实施、长期在离线环境维护容器的运维和集成工程师。核心难点不是拿到那个docker二进制文件而是让整套依赖和镜像完整陪跑。2. 版本选型与离线部署思路为什么离线包里固定是19.03.92.1 19.03.9在docker版本演进里的特殊位置在接触离线部署时我一般先问目标机器是什么系统、什么内核再决定带哪个版本。docker19.03.9是19.03系列的末尾修复版它对应时代的内核正好覆盖CentOS 7、Ubuntu 18.04这批存量系统。相比20.10及以后版本19.03对systemd版本、cgroup v2的适配压力更小相比更老的1.1319.03有了独立的containerd、较完整的镜像管理能力还能正常用docker-compose。很多存量业务镜像构建时就基于这一时期的docker部署工具选它迁移成功率最高。如果你把19.03.9和20.10拉一起对比会发现19.03.9更保守。20.10默认启用iptables-nft和新的nftables后端而有些机房的网络脚本还在写iptables-legacy升级后规则对不上。19.03.9就没这个负担。研究版本时我建议直接看官方changelog而不是只看博客19.03.9修复了多个容器逃逸类安全漏洞所以它既是功能稳定版也是生产安全底线。很多私有化项目对外交付清单里会写明docker 19.03.9不是随便填的。对比项1.1319.03.920.10内核要求低3.10推荐4.0containerd分离无有有nftables依赖低低默认iptables-nft存量镜像兼容差好较好生产存量占比小大中还有一项工作要提前做按下这套工具时第一件事不是下载rpm而是做一次环境探测。下面命令的输出是打包脚本的输入参数cat /etc/os-release uname -r getconf LONG_BIT把这段输出写进工具包的README后续部署脚本也能据此提前判断overlay2能不能用。这个习惯在后面避坑章节还会用到。2.2 离线部署工具的两个组成部分引擎安装与镜像导入一个可用的“docker19.03.9离线部署工具”至少要覆盖两块。第一块是docker引擎的安装。在你准备U盘之前要解决依赖docker-ce、docker-ce-cli、containerd.io这三个主包背后还有container-selinux、libnfnetlink、iptables、curl、tar等系统依赖。如果只带docker-ce一个rpm到现场安装时yum会不断报缺依赖你根本不知道后续还要U盘回去捡哪个包。所以工具里必须有一个完整的rpm依赖池。第二块是业务镜像导入。单项服务可以用docker save把镜像打包成tar部署时用docker load导回来。但工具不是只给一个镜像用的它可以把多个镜像tar包集中放在images目录部署脚本遍历导入。如果你用到私有镜像仓库工具还要顺便写好/etc/docker/daemon.json把data-root指向大分区避免默认路径被系统盘撑爆。镜像导入这条线上有一个很多人忽略的点docker save导出的tar包不带平台标识。如果你在x86构建机上save了一个镜像拿到arm目标机上load虽然tar包能解出来镜像但运行时会报exec format error。所以工具包里应该有一个platform.txt标注镜像构建平台部署时先核对该文件。这个习惯能省掉不少半夜现场救火的麻烦。2.3 为什么选择本地yum源而不是rpm -ivh很多第一次做离线部署的同事习惯把所有rpm放在一个目录里然后执行rpm -ivh *.rpm。这种做法不是不能用但非常容易翻车。rpm命令不会像yum那样自动解析依赖顺序比如container-selinux必须在docker-ce之前装而通配符展开后字母顺序不可控另外如果目标系统已有docker相关包rpm会直接报冲突。常见做法是用yumdownloader把依赖全部拉到一个目录再用createrepo生成repodata在目标机上把该目录声明为一个本地yum源最后执行yum install。这样依赖顺序、冲突检测都由yum处理现场报错少得多。要说明的是这套思路对RHEL系CentOS、Rocky等比较顺滑。Debian系原理类似只是换成apt和deb包。工具目录结构里可以预留debian分支但正文按CentOS 7讲因为19.03.9配合CentOS 7的案例最典型。还有一个小坑createrepo生成的repodata目录如果放在U盘里文件时间戳会有变化目标机yum makecache有时会报哈希不一致。我一般会在打包前删除repodata到目标机上现场重新createrepo一次反正createrepo已经封装成脚本里的一步。3. 构建离线部署工具包从一台可联网的构建机开始3.1 依赖包收集的最小命令在构建机上准备一个目录比如 /opt/docker19-offline。用yumdownloader把docker三个主包和所有依赖一次性拉下来mkdir -p /opt/docker19-offline/{rpms,images,config,scripts} yum install -y yum-utils yum-config-manager --add-repo docker官方stable源 yum makecache yumdownloader --resolve --destdir /opt/docker19-offline/rpms \ docker-ce-19.03.9 \ docker-ce-cli-19.03.9 \ containerd.io这个命令的逻辑是先通过yum-config-manager把docker官方stable源加入构建机让yum能解析docker相关包然后yumdownloader会读取依赖关系把主包和所有依赖rpm都下载到指定目录。参数--resolve是关键少了它yumdownloader只下载你点名的几个包不处理依赖。版本号后面可以带上.el7确保准确例如docker-ce-19.03.9-3.el7。containerd.io不要装太新的版本docker19.03.9对containerd 1.4.4以上可能存在兼容偏移。我一般固定使用和19.03同时期发布的containerd.io1.2.x最稳。3.2 组织目录结构完整工具包应该能让人不看文档也能猜到怎么用。我常用的目录组织如下目录/文件作用rpms/RHEL系rpm依赖池是本地yum源的根目录images/业务镜像tar包部署时遍历导入config/daemon.json、docker19-offline.reposcripts/install.sh、health.shplatform.txt记录构建平台、目标系统、内核要求README.md使用说明和构建记录这个结构不是拍脑袋它拆出了部署脚本能引用的每个输入rpm池是yum源images由load脚本遍历config由配置脚本拷贝scripts里是一键入口。部署时把整个目录拷贝到目标机的/opt/docker19-offline路径路径变了只会影响repo文件里的baseurl。依赖包收集完成后检查一下数量find /opt/docker19-offline/rpms -name *.rpm | wc -l如果rpm文件数量少于20个大概率没解析全。centos7下docker19.03.9的依赖树通常在30到50个rpm之间具体取决于构建机上已安装的包。3.3 编写一键部署脚本安装rpm、启动docker、导入镜像工具核心是scripts/install.sh。脚本要能处理系统检测、本地源配置、安装引擎、写daemon.json、导入镜像这几件事#!/bin/bash set -euo pipefail BASE_DIR/opt/docker19-offline # 判断系统来源只支持RHEL/CentOS系 source /etc/os-release if [[ $ID ! centos $ID ! rhel ]]; then echo 仅支持RHEL/CentOS系 exit 1 fi # 配置本地yum源 cat /etc/yum.repos.d/docker19-offline.repo EOF [docker19-offline] namedocker19-offline baseurlfile:///opt/docker19-offline/rpms gpgcheck0 enabled1 EOF yum clean all yum makecache # 安装docker引擎 yum install -y docker-ce docker-ce-cli containerd.io # 写入daemon.json mkdir -p /etc/docker cat /etc/docker/daemon.json EOF { data-root: /var/lib/docker, storage-driver: overlay2, log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 }, live-restore: true } EOF systemctl daemon-reload systemctl enable --now docker # 导入镜像 if ls ${BASE_DIR}/images/*.tar 1/dev/null 21; then for img in ${BASE_DIR}/images/*.tar; do echo docker load -i ${img} docker load -i ${img} done fi # 验证 docker version --format Server: {{.Server.Version}} docker images脚本里的set -euo pipefail保证中途出错就退出不会带着半截状态继续往下走。先配repo再yum install是为了让yum从本地rpm池解析依赖。daemon.json里的storage-driver先按overlay2设置如果内核不支持后面改成vfs。docker load失败可以反复执行不会重复占用空间所以脚本里没有专门做去重。参数说明log-opts里的max-size和max-file限制单容器日志不超过50MB最多保留3个文件live-restore让docker守护进程升级或重启时容器不退出。这两个配置在离线生产环境很实用能减少日志占盘和意外重启导致的业务中断。3.4 生成repodatacreaterepo的正确使用姿势本地yum源的目录不是直接扔给目标机就能用的yum需要repodata元数据。构建机上执行yum install -y createrepo cd /opt/docker19-offline createrepo rpmscreaterepo会生成rpms/repodata目录repo文件里baseurl指向的是rpms而不是外层目录。如果以后往rpms里新增了rpm必须重新createrepo否则yum只识别旧的repodata。目标机上不需要安装createrepo只需要yum本身就能读取元数据。这个动作应该作为打包前最后一步确保repodata和rpms里的实际内容一致。4. 离线安装的完整操作从U盘到目标服务器的执行步骤4.1 用本地yum仓库解决依赖createrepo与repo文件打包时把整个/opt/docker19-offline目录拷到U盘到目标机解压到/opt/docker19-offline。注意路径必须一致否则repo文件里的file:///路径失效。如果你非要把工具放到其他目录要么改repo文件要么用sed改路径sed -i s#file:///opt/docker19-offline/rpms#file:///data/docker19-offline/rpms# /etc/yum.repos.d/docker19-offline.repo另一个更稳妥的做法是写一个小脚本set_repo_path.sh接受目标路径作为参数自动修改repo文件。这样就不会出现现场手工编辑遗漏字符的问题。目标机上如果存在系统自带的extras源或其他docker源install.sh里的repo文件会和其他源共存。yum安装时有可能从其他源拉到一个更新的docker导致版本不是19.03.9。部署时我一般先把 /etc/yum.repos.d 下非系统必需的源移走或者只保留docker19-offline.repo。4.2 执行安装shell脚本的顺序和输出解读登录目标机进入scripts目录执行cd /opt/docker19-offline/scripts bash install.sh 21 | tee /tmp/docker-install.logtee到日志文件失败后能翻到具体错误行。正常输出会依次出现yum makecache的loading提示、Installed: docker-ce.x86_64 3:19.03.9-3.el7、Created symlink /etc/systemd/system/multi-user.target.wants/docker.service最后是docker version和镜像列表。如果中途失败先看第一个错误文本不要被后面一串报错带偏。注意不要用sh install.sh脚本里用了bash的特性sh不一定兼容。如果脚本执行到systemctl enable时报错常见原因是systemd版本太老或者当前环境不是systemd比如某些容器里没有systemd。这时只能手动执行dockerd或者在工具里另外准备一个docker.service文件放入/usr/lib/systemd/system。4.3 daemon.json配置与docker镜像导入验证daemon.json已经由脚本写入如果目标机上有多个镜像tar包脚本会遍历导入。导入完成后验证镜像数量docker images --format {{.Repository}}:{{.Tag}} | sort如果某个镜像load失败单独重试for f in /opt/docker19-offline/images/*.tar; do docker load -i $f || echo load failed: $f done大镜像建议提前分卷避免U盘文件系统不支持超过4GB的单文件。分卷和合并方式如下split -b 2G /data/images/big.tar /data/images/big.tar.part_ cat /data/images/big.tar.part_* /data/recover/big.tar docker load -i /data/recover/big.tar这里最容易被忽视的是data-root的空间。如果目标机/var/lib/docker所在分区不够docker load会执行到一半报no space left。所以部署前先执行df -h /var/lib/docker和df -i /var/lib/docker在第一次启动前就把daemon.json里的data-root改到数据盘。已经启动过再改需要先停docker否则原有容器数据会“消失”。5. 离线部署踩坑指南5个常见问题和排查方法5.1 现象yum install时报Err: docker-ce conflicts with podman-1.6.4原因是CentOS 8及部分带AppStream的机器预装了podman和buildah它们提供的docker兼容命令和docker-ce包冲突。解决办法是先卸载yum erase -y podman buildah如果担心影响系统自带的运行环境先备份rpm -qa | grep docker的输出再删。建议在install.sh开头加一段预检测检测到podman和buildah就自动清除避免每次现场手工输入。提示不要误删containerd包。系统如果预装了cri-o也要一起移除它同样会占住容器运行时路径。5.2 现象systemctl start docker失败journalctl -u docker里出现failed to mount overlay: operation not permitted原因是内核overlay模块未加载或者目标机是虚拟化老环境不支持overlay2SELinux放行策略不完整也会触发同样错误。先检查lsmod | grep overlay modprobe overlay如果modprobe之后依然失败直接把daemon.json里的storage-driver改成vfs重启docker。vfs性能差但兼容性最好适合临时救场。升级内核可以根治但离线升级内核风险很大一般不在部署当天做。5.3 现象docker load执行到一半报no space left or device原因是镜像tar包很大默认/var/lib/docker所在根分区不足或者inode耗尽。先用df -h和df -i确认分区、inode可用量。解决方法是把daemon.json里的data-root指向有足够空间的数据盘路径并确认目录存在且权限正确mkdir -p /data/docker cat /etc/docker/daemon.json EOF { data-root: /data/docker } EOF systemctl restart docker如果是已经在跑的docker改data-root前必须先把旧数据迁移或接受容器重建。所以我一直坚持在工具脚本里留一个环境变量DOCKER_DATA_ROOT安装前统一设置。5.4 现象本地yum源能列出但yum install提示需要某个依赖而repodata里找不到原因是构建机下载时系统源与目标机不一致或者createrepo在rpm目录有更新后没有重新执行也可能是某个rpm是noarch但依赖了架构相关包。回到构建机执行repotrack重新抓取完整依赖池repotrack docker-ce-19.03.9 -p /opt/docker19-offline/rpmsrepotrack比yumdownloader更彻底会把多架构候选也拉下来体积会明显变大。打包前最好在构建机上用干净最小系统跑一遍yum install验证确认不会再缺依赖。repotrack拉下来的无用包可以人工摘掉但“缺包现场翻车”比“包多占空间”代价高得多。5.5 现象docker启动成功docker version Server也正常但运行容器立即退出先看退出码。如果是标准初始化错误多半是容器平台不匹配。在目标机执行uname -m cat /opt/docker19-offline/platform.txt对比两边架构是否一致。另一种情况是时区不对镜像默认UTC日志时间和本地差8小时。解决方法是运行容器时挂载docker run -v /etc/localtime:/etc/localtime:ro --rm 镜像名 date如果这条命令能正常输出本地时间说明镜像本身没问题问题只在运行参数。6. 进阶把工具包升级成可复用的离线仓库一次性把docker装上只是起点更有价值的是让这个工具包变成可持续维护的离线仓库。做法很简单在rpms目录里按版本分子目录比如docker19.03.9和docker20.10.24共存repo文件里各配一个源。部署时用yum --enablerepo指定版本而不是直接yum install docker-ce避免源顺序影响版本选择。我还会在工具包里加一个health.sh部署结束后自动检查守护进程、版本、镜像数量把“执行成功”变成可量化的结果#!/bin/bash set -e systemctl is-active docker /dev/null 21 || { echo docker inactive; exit 1; } docker version --format {{.Server.Version}} | grep -q 19.03.9 || { echo version mismatch; exit 1; } count$(docker images -q | wc -l) echo loaded images: $count if [ $count -eq 0 ]; then echo no images loaded; exit 1; fi docker ps -a --filter statusexited | awk NR1 {print $NF} | head -20这个脚本的作用不是炫技而是给交付验收一个明确的退出码。系统检测、版本比对、镜像计数、退出容器列表全部排成一眼能看懂的检查项。以后新增rpm只需要重新createrepo然后把rpms目录同步到内网服务器不用再造一套工具。两年前我交付一个内网项目图省事没确认目标机内核结果overlay2起不来半夜在机房把storage-driver改成vfs保住了业务但性能被业务方盯了很久。那之后我养成了一个习惯打包前先输出uname -r和cat /etc/redhat-release到构建记录安装脚本里第一步就核对系统版本。很多翻车其实不是工具不行是版本和系统没对齐。希望帮到你。本文还有配套的精品资源点击获取