内网环境Docker离线部署：从引擎安装到业务运行的完整链路

接到一个在内网机房部署Docker环境的活儿第一反应是什么不是看docker run手册而是先把移动硬盘和U盘准备好。Docker内网离线部署这个事说起来不复杂但做起来全是细节装引擎要离线包镜像要提前导出来搬进去私有仓库要自己搭连系统依赖都得精打细算。本文把我自己折腾过多轮、从空内网到跑起业务服务的完整链路整理出来适合所有需要在隔离网络、无外网环境下手动搭建容器平台的工程师。先说清楚这个内容能解决什么问题。你手里的服务器不能上外网却要用Docker跑MySQL、Redis、Nginx甚至要部署一套大模型推理服务互联网上现成的教程百分之八十都用不了——因为它们默认你还能docker pull。离线部署要解决的就是“在没有互联网的情况下把整套容器运行环境、镜像、编排文件完整搬运进去并跑起来”。准备做这件事的运维、开发、测试同学这篇可以直接当操作手册用。1. 为什么内网环境绕不开Docker离线部署很多第一次搞内网部署的人会想既然没有外网直接用物理机装应用不行吗为什么非要Docker答案在于交付一致性和环境隔离。内网机房的系统版本五花八门有的CentOS 7有的统信UOS有的Ubuntu 20.04同一个应用在这台机器上能跑换一台机器就缺库、缺依赖、端口冲突够你排查好几个小时。把应用和它的运行环境一起打包成镜像就能绕开底层系统的差异——这是Docker离线部署最核心的价值。另一个关键点在于部署效率和回滚能力。内网环境里一台机器一套手工装法十台机器就是十种“意外”用容器镜像统一拉齐之后批量部署只是导入镜像、启动容器两个动作。后面要升级版本换一个镜像tag就行出了问题秒级回滚到上一个镜像。这些在互联网环境下是基本操作但在没有外网的机房必须提前把镜像准备妥当才能享受同样的便利。我接触过的离线项目场景包括军工科研单位的数据处理系统、电厂控制区的业务应用、企业内部研发网的开发环境、以及最近很热的大模型推理服务的本地化部署底层思路都是同一套把“在线准备、离线搬运”作为核心工作流。这套方法也完全适配当前流行的Docker安装教程、Docker Desktop离线安装包、Ollama离线安装包等场景本质都是在解决“没有外网也要有完整工具链”的问题。1.1 离线环境的三种真实形态第一种是纯内网物理机服务器直接放在隔离机房没有互联网出口也没有任何内网软件源U盘和移动硬盘是唯一的输入渠道。这种环境难度最高所有东西都要自己带进去包括操作系统的依赖包。第二种是有内网软件源的半隔离网络机器可以访问公司内部的Yum源、Apt源或Nexus仓库但访问不了公网。这种情况下Docker引擎的安装包可以从内网软件源拿到但容器镜像依然是个问题——没有公网镜像仓库docker pull等同废掉最常见的坑就是你配了加速器也没用镜像源本身在外网。第三种是隔离程度相对低的开发测试网允许少数跳板机访问外网但生产区完全隔离。通常做法是在跳板机上完成镜像拉取和打包再通过光盘、摆渡机或者人工拷贝把镜像文件传进生产区。这种模式最接近我下面要讲的实操流程工作中也最常见。判断自己属于哪种形态只需要做两件事第一检查目标机器能不能访问公网直接ping baidu.com试一下能通就不用继续看了第二查一下内网有没有提供软件源的地址有的话可以省掉打包系统依赖的功夫。摸清环境形态后面所有步骤才好落地。1.2 离线部署的整体链路整个离线部署可以拆成五步任何一步做不扎实都会在目标机上爆雷。第一步是在有网环境准备Docker引擎安装包RPM包或二进制包都行同时把依赖包一并收集第二步是拉取目标机器上需要的全部镜像做一遍瘦身和版本确认逐个docker save打成tar包第三步是把镜像搬运进内网这一步最简单也能暴露最多问题比如移动硬盘格式不兼容、镜像包太大传输中断第四步是在内网搭建镜像仓库把所有tar包推送到私有Registry或Harbor里后续机器从内网仓库拉取镜像第五步才是真正执行部署导入镜像或从仓库拉取再用docker compose把编排文件落到实际业务上。这条链路里有几个关键取舍。整个链路里最容易出问题的就是依赖收集和镜像版本锁定。依赖收不全Docker引擎装上就起不了镜像版本不锁定在线环境拉的和离线环境用的对不上业务数据格式一变就是事故。做离线部署所有环节都要有“锁定”意识——系统版本、内核版本、Docker版本、镜像tag全部锁定才能在离线环境里复现出和在线环境一致的效果。2. 动手前的三个判断版本、架构、依赖不要一上来就下载安装包先花十分钟做三件事确认CPU架构、确认操作系统版本、确认是否有已知依赖缺口。这三件事直接决定你下载什么文件、拷贝哪些依赖、安装的时候用什么参数。跳过这一步的我见过太多人在目标机上安装失败发现下载的包架构不对还得重新回有网环境折腾一遍。2.1 先确认CPU架构再决定下载什么包Docker引擎和镜像都是跟CPU架构强相关的。市面上主流的有x86_64也叫amd64、aarch64arm64、以及小众的armv7、ppc64le等。内网机房最常见的是x86_64但近期不少项目用到了国产化服务器或边缘设备比如飞腾、鲲鹏、RK3588开发板这些就是aarch64架构。用错了架构Docker可能装不上镜像即使导入了也启动不了报错通常长这样exec format error。判断架构非常简单一条命令搞定uname -m返回x86_64就按amd64准备返回aarch64就按arm64准备。下载Docker RPM包或二进制包时选对应架构版本即可。镜像同理拉镜像时注意选择multi-arch清单中对应平台的那个例如docker pull --platform linux/amd64或docker pull --platform linux/arm64不然传到内网大概率跑不起来。2.2 Docker版本选择的经验值离线部署一旦选定Docker版本后续升级成本极高因为升级意味着你要再走一遍“下载-搬运-安装-验证”流程。所以初始版本选择必须保守、稳定、经过验证。我个人的建议是能选官方稳定版就不选试验版能选社区广泛使用版本就不选太新的版本。打个比方Docker 20.10.x和24.0.x都是社区验证比较充分的版本兼容性好compose插件生态成熟。如果业务方没有特殊要求选这两个大版本里的最新小版本最稳。25.0之后新特性很多但和旧版内核、旧版systemd的兼容性有时候需要额外处理离线环境出了问题没法在线查资料稳定性优先。另外要考虑和compose的配套关系。新版本Docker内置了docker compose插件旧版本还需要单独安装docker-compose二进制。离线环境里少一个东西就多一次搬运建议优先采用内置compose插件的版本省掉一份依赖。2.3 内网物理机常见的依赖缺口Docker引擎本身依赖一些系统动态库和服务管理组件。CentOS 7这类老系统上常见缺口包括container-selinux、libseccomp、iptables等Ubuntu服务器上常见缺口是containerd运行时自带但缺少某些libltdl7之类的库。RPM方式安装时系统会告诉你是谁依赖缺了但离线环境读不了网络源所以必须提前把依赖包一起下载。二进制包安装是最省心的Docker官方提供静态编译的二进制包把docker、containerd、runc放到/usr/bin或/usr/local/bin就能跑不依赖于额外的系统库。代价是需要手动配置systemd服务文件。新手建议用RPM包加依赖包的方式系统包管理器能帮你管理版本和依赖关系遇到缺什么再单独解决。注意安装前最好先确认一下目标机内核版本uname -r。Docker需要内核版本不低于3.10且开启了必要的存储驱动和网络模块。内网机器有些是定制内核模块裁剪得厉害没确认就装后面起容器会报各种内核能力缺失的错误。这条我在多个国产化项目上踩过。2.4 离线环境的系统源镜像技巧如果目标内网有系统软件源事情简单一大半。比如CentOS内网如果有镜像源直接配置baseurl指向内网Yum仓库一条yum install -y docker-ce就能解决。这要求提前在在线环境把Docker的Yum仓库文件准备好拷入内网并且确保内网源里有docker-ce相关的包。如果没有内网Yum源我推荐一个土办法找一台和目标机器系统版本完全一致的在线机器用yumdownloader批量下载Docker相关RPM包及所有依赖。yumdownloader --resolve docker-ce docker-ce-cli containerd.io docker-compose-plugin--resolve参数会一并把所有依赖拉下来生成的RPM包全部拷进U盘带到内网rpm -ivh *.rpm按顺序安装即可。这个方法比逐个月上网查依赖列表高效得多也是我在离线部署实操中使用最多的准备方式。3. 没有互联网Docker引擎怎么装装Docker引擎是离线部署里第一个硬骨头。在线环境一条命令的事离线环境得把安装包、依赖、服务配置全部准备好。这一节直接给你两条可落地的路线RPM包安装和二进制包安装。看完你就知道哪种情况选哪条。3.1 用RPM包离线安装CentOS/RHEL路线在CentOS 7或兼容系统上推荐走RPM路线。在线机器上执行依赖下载把生成的一堆rpm包拷到内网机器进入存放rpm包的目录后执行rpm -ivh *.rpm --nodeps等等不建议直接用--nodeps这样会绕过依赖检查后面Docker可能起不来。正确做法是先不加参数直接执行让系统告诉你缺什么你就找什么实在找不齐依赖再考虑--nodeps装上然后手动补齐缺失库。依赖收集阶段的艰难之处在于containerd.io的RPM包特别大有几十MB到上百MBU盘拷贝时容易忽略它。装完后跑一下验证docker --version systemctl enable --now docker systemctl status dockerdocker --version有输出、systemctl status显示active (running)这一步就过了。如果镜像仓库也需要离线部署后面还有的忙但Docker引擎这块已经稳了。3.2 二进制包安装的兜底方案如果目标系统太老或者太特殊RPM包装不上就改用静态二进制包。在在线环境到Docker官网下载二进制压缩包解压后把文件复制到目标机的/usr/bin再手动建立systemd服务。这里给一个最小可用的systemd服务文件示例[Unit] DescriptionDocker Application Container Engine Afternetwork-online.target firewalld.service Wantsnetwork-online.target [Service] Typenotify ExecStart/usr/bin/dockerd ExecReload/bin/kill -s HUP $MAINPID LimitNOFILEinfinity LimitNPROCinfinity LimitCOREinfinity TasksMaxinfinity TimeoutStartSec0 Delegateyes KillModeprocess [Install] WantedBymulti-user.target把这个文件放到/etc/systemd/system/docker.service执行systemctl daemon-reload systemctl enable --now docker静态二进制方式还有个好处就是可以把它揉进一个基础镜像里配合某些特殊场景做动态构建。但日常部署就别这么搞了维护成本不成比例。二进制方式最大的坑是需要自己处理cgroup驱动Docker默认用systemd作为cgroup驱动如果目标机的systemd版本过老会报错此时需要把/etc/docker/daemon.json里的cgroupdriver: cgroupfs打开或加上去。3.3 装完必做的内核参数和开机启动配置Docker装好跑起来之后有四个设置必须检查不然部署时随时给你“惊喜”。第一个是IP转发内网容器要访问外网或彼此互通必须开启IPv4转发echo net.ipv4.ip_forward1 /etc/sysctl.conf sysctl -p第二个是防火墙。内网机器很多默认开firewalld或者ufwDocker的网桥和端口映射会被拦轻则容器之间不通重则外部完全访问不了服务。我的一般建议是先临时systemctl stop firewalld验证业务再决定是放行端口还是干脆禁用防火墙。第三个是配置daemon.json。虽然离线环境用不上加速器但建议在/etc/docker/daemon.json里把>{ data-root: /data/docker, storage-driver: overlay2, log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 }, registry-mirrors: [] }第四个是确认overlay2模块已加载。lsmod | grep overlay没有输出的话手动modprobe overlay一次再写入/etc/modules-load.d/里防止重启丢失。内网环境无法自动下载存储驱动这一步不做容器镜像的层文件落不了盘起容器会直接挂掉。实操心得安装完Docker之后先别急着导入业务镜像先拉一个hello-world等价操作——随便导入一个最小的busybox镜像跑一条docker run --rm busybox echo ok确认引擎从启动、镜像加载到容器执行整个链路都通再开始正式部署。出问题的时候可以把“Docker本身故障”和“业务配置故障”分离开来排查效率高很多。3.4 离线安装Docker Desktop的特殊之处如果内网目标不是服务器而是开发人员的Windows机器场景就切换成了Docker Desktop离线安装。Docker Desktop的离线包在官网可以下载安装时不需要全程连网但有几个事需要提前处理安装后首次启动要启用WSL2而WSL2的组件在离线环境经常缺失另外Docker Desktop启动时会检测Virtualization support not detected如果机器是物理机BIOS里没开虚拟化会直接报错。这种情况下要么进BIOS开虚拟化要么就用Docker Toolbox这类老方案——但后者已经很久不维护了能用但别指望技术支持。实际项目里我更推荐在Windows上装Linux虚拟机再走Linux离线部署路线比硬啃Docker Desktop省心得多。4. 镜像才是离线部署的主战场Docker引擎装好后真正的重头戏是镜像。内网环境没有互联网镜像仓库所有运行镜像都得自己带进去。集团级项目几十个服务就是几十个镜像每个动辄几百MB甚至几个GB管理不好就是一场灾难。这一节把镜像的拉取、导出、搬运、导入、投递全链路讲透。4.1 在能联网的机器上准备镜像准备镜像的第一步是确定清单。和业务方一条条对用到哪些中间件、哪些应用服务、各自的版本号、需要什么架构的镜像。我当时做一个数据平台项目清单有MySQL 8.0、Redis 6.2、Nginx、MinIO、Kafka、Zookeeper、业务后端三个镜像足足列了八行每一行都要标注版本tag线上用latest的坏习惯在这里必须改掉离线环境没有机会再拉一次新tag。拉镜像时建议加上--platform参数明确指定架构。两个原因第一很多公共镜像仓库的manifest是multi-arch的不带参数拉取会默认拉当前机器的架构可能跟内网目标机器不一致导出导入后才会暴露问题第二显式指定更可控后续给同事传阅镜像包时也能一眼看出架构。docker pull --platform linux/amd64 mysql:8.0 docker pull --platform linux/amd64 redis:6.2拉完后逐个验证一下镜像能不能正常启动跑一个最简单的启动命令、看日志、再删掉容器。这一步不要省——我发现过有镜像在公共仓库里就带脏数据或损坏层的离线后发现拉错了想换又得重新走一遍网络拷贝流程。验证阶段的成本最低传到内网再发现问题就麻烦了。4.2 镜像导出导入的两种姿势准备完镜像之后有两种搬运方式各有利弊。第一种是docker save打成tar包最直观适合镜像比较少、单台或少量机器部署的场景docker save -o mysql_8.0.tar mysql:8.0 docker save -o all_images.tar mysql:8.0 redis:6.2 nginx:1.24save会保留镜像完整历史层和元数据文件偏大但导入后就能直接run。压缩传输时注意用gzip能省不少移动硬盘空间docker save mysql:8.0 | gzip mysql_8.0.tar.gz到了内网机器上解压导入gunzip -c mysql_8.0.tar.gz | docker load docker images第二种方式是自建私有镜像仓库把镜像推到内网Registry里其他机器再从仓库docker pull。适合批量部署、多台机器复用的场景也是生产环境的标准做法。你只需要在有网环境把镜像保存为tar包传到内网的一台服务器上导入再docker tag和docker push到私有仓库即可。两个方案怎么选我的经验是机器数量少、镜像少、一次性部署就用save/load简单直接机器数量多、后续还要持续发布更新就必须上仓库。前者是打游击后者是建根据地内网系统一旦进入长期运维阶段仓库几乎是必选项。4.3 离线镜像仓库从Registry到Harbor内网搭建镜像仓库轻量选官方registry:2镜像直接跑一个容器docker run -d --name registry \ -p 5000:5000 \ -v /data/registry:/var/lib/registry \ --restartalways \ registry:2但生产级内网部署建议上Harbor因为它自带Web UI、项目隔离、镜像复制、垃圾回收这些功能多人协作时管理成本低太多。Harbor本身也可以容器化部署用它的在线安装包准备一份离线包再配合docker compose启动。它依赖的镜像也要提前准备好——harbor安装脚本里会自动加载harbor.tgz镜像包离线包本来就是为这种场景设计的。仓库起了之后把前面导入的镜像重新打tag推到私有仓库docker tag mysql:8.0 192.168.1.100:5000/library/mysql:8.0 docker push 192.168.1.100:5000/library/mysql:8.0这里有个内网特有的问题目标机器要能访问到仓库地址得保证网络通、端口开放、域名解析正确。如果仓库机器有防火墙记得放行5000端口或Harbor配置的对外端口。否则后面所有机器pull都会卡住那场面相当尴尬。4.4 私有仓库的HTTP证书问题内网环境很少给私有仓库配正规HTTPS证书默认Docker守护进程只认HTTPS直接pull HTTP仓库会报http: server gave HTTP response to HTTPS client。解决方式有两种。第一种是临时按IP信任修改目标机器的/etc/docker/daemon.json把这个仓库IP加到insecure-registries{ insecure-registries: [192.168.1.100:5000] }改完重启Docker生效systemctl daemon-reload systemctl restart docker第二种是正规做法为仓库域名生成自签名证书分发给所有客户端机器并把证书加入系统信任列表。这条更安全但操作步骤多内网小团队不强制要求。作为过渡可以把自签名证书装在Registry容器里客户端配置insecure-registries先跑通业务后面有安全审计需求再换证书体系。注意如果内网方案里还涉及证书自动部署这类需求比如给业务域名开通SSL证书要记得证书的私钥和签发流程尽量提前在在线环境准备好离线环境里的证书颁发机构可能压根访问不了。我经历过一个项目业务系统要配HTTPS内网又没法在线申请证书最后是把在线环境的证书文件直接导入并配置了自动续期脚本才把这个环节绕过去。5. 一次典型的内网应用部署实录前面讲了引擎安装和镜像准备这一节拿三个最常见的中间件举个例子MySQL 8.0、Redis主从、Nginx。这个组合几乎能代表大多数内网业务系统的基础底座实际部署时你可以把业务镜像替换成自己的流程完全一致。5.1 场景设定内网部署MySQL 8.0 Redis主从 Nginx假设目标机器是两台内网服务器操作系统CentOS 7.9CPU架构x86_64机器没有外网但已经有内网私有仓库192.168.1.100:5000Docker引擎也都装好了。我们的任务是在这两台机器上把MySQL、Redis主从、Nginx全部跑起来数据目录要持久化容器重启不能丢数据。开始之前先规划目录结构。我习惯把所有业务数据统一放在/data下每个服务一个子目录后面备份迁移都方便/data/ ├── mysql/ │ └── data/ ├── redis/ │ ├── master/ │ └── slave/ └── nginx/ ├── conf/ └── html/目录权限要先设置好MySQL容器内的mysql用户UID是999Redis容器内的redis用户UID是999如果不提前chown容器初始化数据目录时会报权限错误。这条细节最容易忽略等部署时才看到Permission denied再回来查浪费不少时间。5.2 镜像传输与导入的实操细节如果仓库已经就绪两台机器直接docker pull 192.168.1.100:5000/library/mysql:8.0即可。如果还没有仓库、机器也不多就直接用tar包搬运先在在线机器或中转机器上导出镜像传到一个移动硬盘docker save -o deploy_images.tar \ mysql:8.0 \ redis:6.2 \ nginx:1.24ls -lh deploy_images.tar看下文件大小如果超过4GB移动硬盘格式要注意。FAT32单文件最大4GB存不下这种大包必须格式化成exFAT或NTFS。走到这一步发现文件存不进去是最冤的失败。目标机上执行导入docker load -i deploy_images.tar导入后验证docker images | grep -E mysql|redis|nginx确认所有镜像tag都在再继续。批量导多个tar包时注意文件名别和已有镜像重名或冲突不然导入会静默跳过。5.3 compose编排文件的内网适配多容器部署我强烈建议用docker compose编排而不是一条条docker run。Compose文件本身就是部署文档版本管理也方便内网服务器上装一次compose插件后续业务更新只要改文件重启就行。下面是一份适用于内网环境的docker-compose.yml示例把MySQL、Redis主从、Nginx都编排进去version: 3.8 services: mysql: image: 192.168.1.100:5000/library/mysql:8.0 container_name: mysql restart: always environment: MYSQL_ROOT_PASSWORD: StrongPassword2024 TZ: Asia/Shanghai ports: - 3306:3306 volumes: - /data/mysql/data:/var/lib/mysql - /data/mysql/conf:/etc/mysql/conf.d command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_unicode_ci redis-master: image: 192.168.1.100:5000/library/redis:6.2 container_name: redis-master restart: always command: [redis-server, --requirepass, RedisPass2024, --appendonly, yes] ports: - 6379:6379 volumes: - /data/redis/master:/data redis-slave: image: 192.168.1.100:5000/library/redis:6.2 container_name: redis-slave restart: always depends_on: - redis-master command: [redis-server, --slaveof, redis-master, 6379, --masterauth, RedisPass2024] volumes: - /data/redis/slave:/data nginx: image: 192.168.1.100:5000/library/nginx:1.24 container_name: nginx restart: always ports: - 80:80 - 443:443 volumes: - /data/nginx/conf:/etc/nginx/conf.d - /data/nginx/html:/usr/share/nginx/html注意几个内网适配的细节。第一image字段最好直接写私有仓库地址这样后续如果同步到新机器docker compose pull能直接从内网仓库拉而不必手动tag。第二密码这类敏感信息在内网演示环境可以直接写在文件里方便排查但生产环境建议用.env文件加载或docker secret管理。第三redis-slave的depends_on只保证容器启动顺序不保证主库服务已经就绪如果主库初始化慢从库可能连不上然后不断重试——实际上Redis的从库逻辑就是失败会重试所以一般没问题但如果业务强依赖主从同步需要通过健康检查来做强依赖。执行部署docker compose up -d等几秒钟看状态docker compose ps再验证各服务日志是否正常docker logs mysql --tail 50 docker logs redis-master --tail 50MySQL第一次初始化要一分钟左右看到日志里出现ready for connections就说明正常。Redis主从看日志里MASTER - REPLICA sync started和MASTER - REPLICA sync completed两行关键字。5.4 业务配置文件的内网裁剪内网部署通常还要做配置文件裁剪两块最常见。一个是域名和IP的替换在线环境可能用的是公网域名内网要改成内网IP或者内网域名Nginx的proxy_pass、后端的数据库连接串都要统一改。另一个是第三方服务地址的替换很多系统会对接短信、OSS、地图服务这些公网依赖在内网全不可用要么改造为内网替代方案。比如我在一个GIS项目里在线环境用的是高德地图Web服务内网完全访问不了公网API最后把地图底图替换成了内网部署的天地图离线瓦片服务。这种改造必须在部署清单里提前列出来和业务方逐项确认而不是等镜像导进内网才发现服务不可用。做离线部署一定要有一个外部依赖清单把所有需要出网的调用列出来逐条评估替代方案这是内网部署验收的关键依据。5.5 批量部署时的镜像分发策略如果不止两台机器而是十台二十台逐个docker load -i tar会累死人。我的做法是分层先把镜像推到私有仓库然后在各机器上写一条脚本从内网仓库批量拉取并启动容器。#!/bin/bash IMAGES( 192.168.1.100:5000/library/mysql:8.0 192.168.1.100:5000/library/redis:6.2 192.168.1.100:5000/library/nginx:1.24 ) for img in ${IMAGES[]}; do docker pull $img done docker compose up -d这里有个很实际的加速技巧内网千兆网络下从私有仓库批量拉镜像的速度通常比U盘拷贝快得多而且不容易出错。所以只要内网条件允许建一个中央仓库都比移动硬盘逐台拷贝高效。离线部署不是不用仓库而是把仓库搬进内网来用。6. 常见问题排查与避坑实录离线部署的坑基本都集中在几个固定位置Docker起不来、镜像导入慢、启动报错、仓库不通。这一节把高频问题和排查思路整理成速查样式方便你现场照做。6.1 Docker服务起不来journalctl说找不到依赖这是离线环境第一高频问题。执行systemctl start docker之后立刻退出systemctl status docker显示failedjournalctl -u docker里提示缺少动态库或找不到某个文件。排查思路第一步先确认是不是依赖没装齐。RPM方式安装时rpm -qa | grep docker检查所有相关包是否到位常见的container-selinux缺失会导致dockerd直接起不来。第二步确认存储驱动对应内核模块是否加载前面提过overlay先modprobe。第三步看SELinux状态内网CentOS的SELinux如果是enforcing且容器运行时没有对应的selinux策略可能会拦截进程权限临时setenforce 0观察能恢复再考虑长期策略。实操心得离线环境排查Docker起不来的问题第一反应不该是改配置而是先strace dockerd或者看完整journal日志把报错信息完整拉出来再对着报错找解决方案。网上很多教程让人直接改daemon.json但有时候问题根本不在daemon配置上而是内核模块缺失乱改只会让问题更隐蔽。这点跟在线环境非常不一样在线环境大家习惯试错离线环境试错成本高每一步都要有依据。6.2 docker load慢还经常中断镜像包几十GB通过U盘或内网共享目录导入慢和中断都很常见。排查思路第一步确认tar包是否完整可以在在线环境用docker save时同时生成一个md5校验文件到内网导入前用md5sum -c比对。第二步确认磁盘空间df -h看存储挂载点docker load解包时临时占用的空间至少是镜像包体积的1.5倍磁盘不够会静默失败或加载到一半报奇怪错误。第三步如果经常中断可以分成多个tar包分别导入不要图省事一个包塞几十个镜像断了一次全部重来太亏了。6.3 镜像导入后一启动就报exec format error这个报错是架构不匹配的典型特征。在x86_64机器上导入arm64架构的镜像docker run时内核无法执行这个二进制格式的进程就会报exec format error。排查方式很简单用docker image inspect看镜像的Architecture字段是否和目标机器uname -m一致。原因通常是在有网环境拉镜像时没有显式指定--platform拉到了multi-arch清单里的其他架构。解决也简单回到有网环境重新拉对应架构镜像再重新导出导入。如果镜像本身是业务方打包的要跟对方确认他们构建基础镜像时用的架构是不是和目标机器一致。国产化服务器上这类问题特别常见飞腾和海光混用的话镜像要各备一份。6.4 从私有仓库pull镜像一直卡住或报错卡住先确认网络连通性telnet 192.168.1.100 5000或curl -I http://192.168.1.100:5000/v2/不通就查防火墙、查路由、查容器端口映射。通了但报HTTPS错误就是前面说的insecure-registries没配置或没重启Docker。报unauthorized就检查docker login的凭证Harbor项目权限没配好也会这样。还有一个容易被忽略的原因目标机器的DNS解析不到内网仓库域名。我遇到过用主机名访问仓库时卡住改成IP地址秒通的情况。内网DNS体系不健全是常态能用IP就用IP省事。6.5 容器启动后网络不通容器起来了但外部访问不了服务。排查顺序先docker compose ps看端口映射是否正常再ss -tlnp | grep 端口确认端口在宿主机上有没有监听再检查宿主机防火墙有没有放行对应端口最后看容器内部监听地址有些服务默认监听127.0.0.1不对外需要改配置监听0.0.0.0。如果容器间需要互相通信确认它们是否在同一个自定义网络里。Docker默认桥接网络里容器之间可以通过IP互通但通过容器名互访必须使用自定义网络。compose文件里默认创建的项目网络支持服务名互访这条在编排文件里就要设计好。7. 大模型与AI应用内网部署的扩展玩法内网离线部署最近几年最火的场景已经不只是传统中间件了大模型推理和AI工具链的本地化部署越来越普遍。热搜里的Ollama离线安装包、DeepSeek本地部署、Jetson Orin上跑YOLOv8本质上都是在走“模型文件搬运 Docker容器运行”这条路。7.1 Ollama与模型文件的离线准备Ollama这类推理工具的离线部署思路和Docker镜像几乎一样先在有网环境下载好安装包和模型文件再拷贝到内网。Ollama模型默认存储路径是~/.ollama/models你把整个目录搬到内网机器对应位置配置好OLLAMA_MODELS环境变量就直接可用不需要重新拉取。大模型动辄几十GB传输环节要提前确认磁盘空间和拷贝方式比Docker镜像更考验耐心。7.2 大模型服务的Docker化封装更规范的做法是把大模型推理服务也封装成Docker镜像。以DeepSeek这类开源模型的本地部署为例把模型文件、推理脚本、API服务全部打进镜像做成一个标准应用镜像推到内网仓库后业务方只要docker run就能拉起一个大模型API服务和跑MySQL没有本质区别。但要注意GPU环境的特殊处理。内网服务器如果有NVIDIA GPU要提前准备nvidia-container-toolkit的离线包并配置Docker识别GPU参数。这一点很多离线教程不提实际部署中发现Docker容器里用不了GPU推理速度跟CPU没区别那就不叫AI部署了。Jetson Orin这类ARM设备还要额外确认JetPack版本和容器运行时兼容性版本不匹配镜像根本起不来。7.3 模型分发和灰度更新内网大模型部署的独特之处在于模型更新频繁。在线环境直接从Hugging Face或ModelScope拉取新模型离线环境只能用“模型文件打包 导入 重启服务”的方式。如果公司有多台推理服务器我建议把模型文件单独存放在内网共享存储或对象存储上容器启动时挂载进去而不是打进镜像里。这样更新模型时只需替换共享存储里的模型文件不需要重新构建镜像或重新导入镜像操作成本和出错概率都大幅降低。这里有个和我踩过的坑相关的经验模型文件格式和运行时版本高度绑定比如GGUF文件的量化版本和Ollama版本不兼容启动后疯狂报错。离线环境没有网可查唯一办法是在有网环境把目标版本彻底验一遍再把验证过的组合拷贝进内网。这条原则适用于所有离线部署不止大模型。8. 工具选型与方案取舍的个人经验写了这么多最后聊聊工具选型和方案取舍。不同规模的部署适合的方案完全不一样没有“万能解法”只有“当前条件下最优解”。8.1 小规模部署用什么方案如果你只是三五台机器部署一套业务系统镜像不超过十个团队就一两个人维护最简单直接的方式就是save/load加docker compose。没必要上Harbor一个registry:2容器就够用甚至多台机器直接用tar包分发也没问题。这个配置下部署成本最低出问题也好排查适合大模型推理demo、研发测试环境、小型业务系统这类场景。8.2 中大规模部署用什么方案如果机器上了两位数镜像几百个多团队共用一套内网环境Harbor几乎是唯一选择。项目隔离、权限管理、镜像复制、垃圾回收这些功能在规模化之后都变成了刚需。配合一个统一的编排层比如内网部署一个轻量的持续发布工具从镜像构建到应用发布形成流水线运维成本才能压下来。这种体量的项目离线部署就不是一次性行为了而是需要长期维护的基础设施前期的仓库搭建和配置管理投入非常值得。8.3 分阶段演进比一步到位更现实我的建议是分阶段演进。第一阶段先用手动save/load把业务跑通第二阶段搭一个registry镜像仓库统一镜像存储第三阶段再上Harbor加Web UI和权限管理业务扩大之后配合引入持续部署能力。每一步都是在前一步验证过的基础上叠加风险和复杂度都在可控范围内。反过来一上来就上全套配置复杂、出问题也无从排查不利于项目推进。离线部署做到最后你会发现绝大多数问题的根源都是“准备不充分”。依赖没提前收齐、镜像没锁定版本、架构没核对、证书没准备、磁盘空间没算好——每一件事单看都不难但叠加在一起就容易翻车。所以做这套工作最重要的能力不是会敲多少命令而是“提前把事情想全”的习惯。我在实际项目中的体会是离线部署做完的那一刻业务跑起来的那种踏实感是在线部署给不了的。因为你知道这套系统不依赖任何外部因素断网、公共仓库故障、网络攻击都不影响它正常对外提供服务。这个确定性就是内网离线部署最值钱的地方。如果你正被类似的问题卡住按上面这套链路走一遍基本能顺下来如果遇到具体报错对照问题速查表逐项排除大概率也能找到方向。