离线安装Docker这件事我在好几个项目里都踩过完整的坑内网测试节点的部署、机房隔离区的容器环境搭建、还有一台连软件源都连不上的嵌入式开发板。每次看到有人在问Ubuntu离线怎么装Docker和Docker Compose我都想把一整套能直接用、不出岔子的步骤整理出来。这篇文章就按我实际动手的顺序来写从找包、传包、装包到配置daemon、搞定Compose插件最后再用一个真实的小项目验证环境。不管你是要给生产环境准备容器运行时还是只想在断网笔记本上搭个实验环境这套流程都能直接抄作业。1. 为什么需要离线安装Docker场景分析与整体思路1.1 哪些环境必须走离线安装很多人第一次接触Docker都是在能联网的开发机上一条apt install docker.io或者官方脚本搞定。但真实项目里尤其是企业级环境离线安装才是常态。我遇到过的情况大致有这几类第一类是等保和合规要求严格的内网区域。机器不能随便连外网甚至apt源也被限制到只能访问内网镜像这时候你没法在线拉Docker官方源只能提前准备好安装包带进去。第二类是局域网的边缘节点或者没有固定外网的机房网络质量差到连HTTPS下载都不稳定与其在线装到一半断掉不如一次性把包拿到手。第三类是开发板、ARM盒子这类嵌入式设备系统裁剪过没有包管理器源可以用只能手动搬运二进制或deb包。另外一个常见场景是Windows上用Docker Desktop“virtualization support not detected”这个报错经常把人卡住装了Docker Desktop却启动不了。这种问题多半是虚拟机平台设置或者BIOS里的虚拟化没开跟Ubuntu服务器上的原生Docker其实不是一回事。我见过不少同事为了绕开Docker Desktop干脆在VMware虚拟机里先装一个Ubuntu Server改成用原生Docker反而更干净。这个思路也适用于离线环境只要Ubuntu本机能装好docker-ce后面什么容器项目都好说。1.2 离线安装的两个核心思路deb包 vs 二进制包离线安装Docker主要有两种手法我建议先明确这一点再动手。方案A是deb包方案。在另一台能联网、并且配置好Docker官方apt源的Ubuntu机器上用apt download把docker-ce、docker-ce-cli、containerd.io等一组deb包全部拉下来传到离线机器上dpkg -i安装。这套方案的好处是systemd服务文件、默认配置路径、用户组这些都给你安排好了装完直接systemctl start docker最省事。方案B是二进制包方案。从Docker官方发布页下载docker-27.x.tgz这个静态二进制压缩包手动解压到/usr/bin然后自己写systemd unit文件或者用dockerd 启动。这种做法的优点是不依赖deb包管理机制对发行版的兼容性更强但缺点是所有配置都得自己来单元文件也要自己维护对小项目有点累赘。我的建议很简单只要目标机器是Ubuntu、Debian这类Debian系系统优先选方案A。只有当你目标系统是精简过的、没有dpkg环境或者你还需要把Docker搬到非Debian系系统时才考虑方案B。本文主流程按方案A展开但我会在Compose插件部分也把二进制方式讲清楚因为Compose插件的二进制放法在两种方案里是通用的。整体流程其实只有四步联网机器上准备安装包→把安装包传到离线机器→dpkg安装到一半处理依赖并配置daemon→安装Compose插件并验证。每一步都有坑我按顺序一个一个讲。2. 在有外网的机器上准备安装包版本、架构与下载2.1 下载前必须确定的三个参数准备安装包之前先别急着敲命令。三个参数必须确认清楚错了后面全部白干。第一个是Ubuntu的发行版代号。不同代号对应Docker官方源里的不同目录20.04是focal22.04是jammy24.04是noble。用lsb_release -a查看你的离线机器版本。我最近一次帮人装机用的就是Ubuntu 22.04 LTS代号jammy下面命令里我都用jammy举例。第二个是CPU架构。x86_64的机器在Docker源里叫amd64ARM开发板对应的包叫arm64。虽然现在笔记本基本都是x86_64但不少内网服务器是ARM架构的下载的时候一定要检查文件名里的amd64还是arm64别拿错了。第三个是Docker版本。Docker CE的版本号比较规范比如5:27.3.1-1~ubuntu.22.04~jammy这种格式。其中5:是Debian的epoch版本前缀中间27.3.1才是真正的Docker版本号。离线环境建议选当前稳定版里比较新但不追最新的那个版本图个稳定。我这次演示用的是Docker CE 27.3.1搭配containerd.io 1.7.24。还有一个容易被忽略的点Ubuntu官方仓库里也有Docker包名字叫docker.io但版本比较老而且不带Compose插件。如果你在离线机器上图省事去apt安装docker.io大概率会得到一份和现在Docker生态脱节的旧版本。所以离线安装一定认准Docker官方源的docker-ce。2.2 用apt download一次性拉取全套deb包准备安装包的机器需要先配置好Docker官方apt源。这步只要执行一遍Docker官方文档里的setup命令就行curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt update然后在联网机器上建一个干净的目录执行下载。我用的是锁定版本号的方式避免哪天源里更新了版本导致你机器上拿到的包和离线机器上装的不一致mkdir -p /tmp/docker-offline cd /tmp/docker-offline apt download docker-ce5:27.3.1-1~ubuntu.22.04~jammy apt download docker-ce-cli5:27.3.1-1~ubuntu.22.04~jammy apt download containerd.io1.7.24-1 apt download docker-buildx-plugin apt download docker-compose-plugin注意apt download会直接在当前目录生成deb文件不会安装它们。等命令跑完你会看到类似这样一组文件docker-ce_27.3.1-1~ubuntu.22.04~jammy_amd64.deb docker-ce-cli_27.3.1-1~ubuntu.22.04~jammy_amd64.deb containerd.io_1.7.24-1_amd64.deb docker-buildx-plugin_0.19.3-1~ubuntu.22.04~jammy_amd64.deb docker-compose-plugin_2.32.4-1~ubuntu.22.04~jammy_amd64.deb如果你不想锁定版本直接apt download docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin也行拿到的就是当前源里的最新稳定版。但后续离线机器上的依赖如果和这个版本不一致可能要额外补包所以我推荐锁定版本。下载完成后顺手校验一下文件的SHA256确保传输过程中没有损坏sha256sum *.deb拿到这些deb文件后你再决定用什么方式拷贝到离线机器。文件总大小一般在100MB到200MBU盘、内网共享目录、scp都很方便。2.3 二进制方式下载Docker Compose插件刚才的deb包里已经包含了docker-compose-plugin这个包安装后会自动把Compose插件放到/usr/libexec/docker/cli-plugins/docker-compose。这是我在离线环境最推荐的Compose安装方式因为它和Docker版本配套、路径规范、升级也方便。但有两个场景你会需要二进制方式一是你走的方案B用tar包方式装Docker二是你的目标机器架构特殊deb源里找不到匹配的Compose插件包。这时候可以直接从Docker Compose的GitHub Release页面下载对应架构的静态二进制文件。下载时认准命名规则比如x86_64机器wget https://github.com/docker/compose/releases/download/v2.32.4/docker-compose-linux-x86_64 chmod x docker-compose-linux-x86_64ARM机器就把x86_64换成aarch64。下载到的文件就是一个单一静态二进制后面放到指定目录就能被docker compose命令识别。这个文件一般几十MB同样需要拷贝到离线机器。这里有一个很容易踩的坑Compose插件二进制和Docker CLI主程序之间不是完全独立的新版本的Compose会要求对应的CLI版本不能太老。如果你Docker装的是27.x却把Compose v1的独立工具拿过来用运行起来会有一堆兼容问题。所以我现在一律推荐v2版本的Compose插件别再用docker-compose独立命令了。3. 离线安装Docker核心步骤传输、安装、配置3.1 把安装包传到离线机器U盘、scp、共享目录这一步本身不复杂但我要提醒三个实际问题。第一文件完整性。U盘拷贝或者网络传输时文件和配置都可能被截断。到了离线机器上先跑一遍sha256sum *.deb和你在联网机器上拿到的校验值比对。别信U盘里的文件一定没问题我吃过亏一次拷贝中两个deb包坏了导致dpkg装到一半突然报“包损坏”排查半天。第二路径一致性。建议在离线机器上也建一个/tmp/docker-offline目录把deb包和Compose二进制都放进去避免和系统的其他文件混在一起。后续dpkg时直接用通配符就能一次性处理。第三如果是通过scp或内网共享传输注意权限。普通用户拷进去的文件后面sudo命令都能读问题不大但如果是U盘挂载的部分系统默认对FAT32格式的U盘文件加挂载参数可能导致中文名乱码。安装包全是英文名通常还好不过我还是建议先复制到本地磁盘再安装不要直接dpkg U盘里的文件。3.2 dpkg安装与依赖处理实录文件到位后直接安装sudo dpkg -i ./*.deb理论上这五个deb包之间的依赖关系是齐全的dpkg会一次性把它们都装好。正常输出会依次提示Unpacking docker-ce ...、Setting up containerd.io ...这些信息。装完后立刻验证sudo systemctl status docker但实际上离线环境装deb十有八九会碰到依赖错误。最常见的报错长这样dpkg: dependency problems prevent configuration of docker-ce: docker-ce depends on docker-ce-cli; however: Package docker-ce-cli is not installed.如果遇到类似提示先别慌。重点看报错里缺的是哪个包。很多时候是因为你只拷了docker-ce忘了带上docker-ce-cli或者containerd.io版本太旧。把缺的包补齐再执行一次sudo dpkg -i ./*.deb即可。还有一类问题不是缺包而是系统底层库版本太老。比如containerd.io要求libseccomp2版本不低于2.4而Ubuntu 18.04或者部分精简系统的libseccomp2可能只有2.3。这种时候哪怕deb包全齐dpkg装完后一启动dockerd照样崩。解法是额外下载对应版本的libseccomp2 deb包一起安装或者用apt的fix机制sudo apt --fix-broken install注意离线环境执行apt --fix-broken install时如果依赖的包不在本地它还是试图去软件源下载。如果源不通这个命令就白跑。所以我的习惯是宁可下载前把依赖看清也不依赖fix工具。实际操作中Ubuntu 22.04和24.04自带的libseccomp2都是新版通常不会有这个问题。3.3 配置daemon.json并启动服务包装好之后先别急着用。Docker默认配置有几个小毛病日志文件会无限增长默认数据目录在系统盘容易占满还有普通用户需要sudo才能操作。这些都应该在启动服务之前就定好。创建/etc/docker/daemon.json内容用我这份基础配置{ data-root: /var/lib/docker, log-driver: json-file, log-opts: { max-size: 100m, max-file: 3 }, exec-opts: [native.cgroupdriversystemd], group: docker, registry-mirrors: [] }解释一下每个字段的用意。>sudo systemctl enable --now docker systemctl is-enabled docker # 输出 enabled 就说明自启没问题然后做两件事验证。第一看服务状态sudo systemctl status docker第二运行一次基础命令确认控制面正常sudo docker version sudo docker info如果你希望当前用户不用sudo直接使用docker命令把用户加进docker组重新登录一次就行sudo usermod -aG docker $USER这里我多说一句加docker组等同于把root权限交出去生产环境要谨慎。如果是共享机器哪怕是内网环境也别随便给普通账号加这个组。4. 离线安装Docker Compose插件的两种方式4.1 方式一用deb包安装docker-compose-plugin如果你第2章下载deb包时把docker-compose-plugin也一起下了这里就很简单在离线机器上cd /tmp/docker-offline sudo dpkg -i docker-compose-plugin_2.32.4-1~ubuntu.22.04~jammy_amd64.deb装完之后验证docker compose version如果输出类似Docker Compose version v2.32.4插件就已经被Docker CLI识别了。这个deb包安装时会自动把Compose插件放到/usr/libexec/docker/cli-plugins/docker-compose路径完全符合Docker CLI的查找规则。这也是我反复强调推荐deb方式的原因路径、权限、权限组都给你弄好了不用你手动再折腾。4.2 方式二二进制放到cli-plugins目录如果你走的是tar包方式或者只拿到了Compose的静态二进制文件那就需要自己把它放到Docker CLI能识别的位置。Docker CLI会依次查找这几个目录中的插件/usr/local/lib/docker/cli-plugins /usr/lib/docker/cli-plugins ~/.docker/cli-plugins前两个是系统级插件目录所有用户都能用最后一个是用户级目录只对当前用户生效。离线安装建议放系统级目录因为以后切换到其他用户也能正常使用sudo mkdir -p /usr/local/lib/docker/cli-plugins sudo cp docker-compose-linux-x86_64 /usr/local/lib/docker/cli-plugins/docker-compose sudo chmod x /usr/local/lib/docker/cli-plugins/docker-compose再验证一次docker compose version有一点必须注意插件的文件名必须严格叫docker-compose不能带其他后缀。如果你拷贝的时候写成docker-compose-linux-x86_64Docker CLI会认不出它。这是我实操中经常看到的问题也是“明明放了文件但docker compose命令不识别”的常见原因之一。4.3 部署一个Compose项目验证环境安装只是第一步我会习惯性地在离线机器上跑一个真实Compose项目确认整个链路是通的。这里我用一个简单的Redis主从示例也是很多团队会碰到的场景。先解释一下离线环境镜像怎么来。既然机器不能联网容器镜像就不能直接docker pull。需要在联网机器上先拉取镜像再导出成tar包带进离线机器导入# 在联网机器上执行 docker pull redis:7.4-alpine docker save redis:7.4-alpine -o /tmp/redis-7.4-alpine.tar然后把tar包拷贝到离线机器执行导入# 在离线机器上执行 docker load /tmp/redis-7.4-alpine.tar导入后可以用docker images确认镜像已经出现在本地。接下来写一个最简单的Compose文件演示主从结构version: 3.8 services: redis-master: image: redis:7.4-alpine container_name: redis-master command: [redis-server, --appendonly, yes] redis-slave: image: redis:7.4-alpine container_name: redis-slave command: [redis-server, --replicaof, redis-master, 6379] depends_on: - redis-master然后docker compose up -d docker compose ps如果两个容器状态都是runningUp并且能通过docker compose logs redis-slave看到主从同步日志那Docker和Compose的离线安装就算完整验证通过了。这里有个小细节Compose项目会自动创建一个以目录名命名的网络比如redis_default容器之间通过服务名互相访问。如果生产环境有多个Compose项目需要互相通信建议在Compose文件里用networks明确指定外部网络而不是依赖默认网络这能省下后面排障的时间。5. 常见问题与排查技巧实录5.1 服务启动不了journalctl与dockerd --debug离线环境装好Docker后最常见的事故就是服务起不来。sudo systemctl status docker显示failed或者直接报“Failed to connect to the Docker API”——先别急着重装按下面顺序排查。第一步看服务日志sudo journalctl -u docker --no-pager -n 80第二步如果日志信息不够直接用debug模式跑一下dockerd能把日志怼到屏幕上sudo dockerd --debug我在真实项目中遇到过两次dockerd起不来的情况原因都挺有代表性。一次是内网机器的iptables被安全策略禁掉了docker0网桥建不起来日志里会报Failed to allocate daemon network或者failed to create NAT chain。解法是联系运维确认iptables规则或者临时把daemon.json里iptables: false设置一下确认问题确实在防火墙策略。另一次是overlay2存储驱动和内核模块不匹配日志会报Storage driver overlay2 is not supported这种多半是内核版本太老换用vfs驱动可以临时跑起来但性能和镜像分层都会出问题最好还是升级内核。排查这些问题时journalctl -u docker是首选dockerd --debug是兜底手段两者配合能解决绝大部分启动问题。5.2 docker compose命令不识别unknown command很多人离线装完Docker后一执行docker compose ps就报docker: unknown command: docker compose这个报错的含义不是“Compose启动失败”而是Docker CLI压根没找到docker compose这个子命令。原因无外乎三种一是Compose插件没装。你在第2章没下载docker-compose-plugin或者没把二进制放进cli-plugins目录。解决就是按第4章重新补齐插件。二是插件路径不对。Docker CLI只会在固定几个目录里查找插件你把二进制放到了/opt/或者随便一个自定义目录它自然找不到。三是文件名不对。插件文件必须叫docker-compose而且要有执行权限。你可以用ls -l确认一下文件权限缺少x权限时Docker同样会忽略它。排查时可以执行docker info看输出里的Plugins区段如果没有列出compose说明插件没被加载。这个命令能帮你区分“插件没装”和“装了但没被识别”。5.3 离线拉不了镜像内网仓库与save/load离线环境里执行docker pull nginx失败是很正常的因为根本没有外网线路。有些人就在daemon.json里填了registry-mirrors配置公共镜像源结果发现压根没效果因为离线机器连源也访问不了。正确的做法分两种。如果内网有Harbor或者Nexus这类私有镜像仓库那就在daemon.json里把registry-mirrors改成本仓库的地址{ registry-mirrors: [https://harbor.internal.example.com] }然后docker pull就可以走内网仓库拉取镜像。如果连内网仓库也没有那就老老实实用save/load方式。在联网机器上docker save导出、拷贝、离线机器上docker load导入。这个方式适合一次部署但如果镜像很多要注意tar包体积。我建议在导出时把无关的tag清理掉用docker images --format确认一下哪些镜像真正需要别把几百MB的中间镜像也捎带导出来。5.4 避坑清单最后整理一份我长期积累的避坑表覆盖离线安装Docker全流程每一条都是我实际撞过的现象常见原因处理建议dpkg安装时报依赖问题漏装docker-ce-cli或containerd.io下载完整五个deb包重新dpkgdockerd启动失败日志显示网络相关错误iptables被安全策略限制检查iptables规则临时关闭iptables开关验证docker: unknown command: docker compose没装Compose插件或路径/文件名不对按第4章补齐插件并确认文件权限普通用户执行docker命令权限不足用户不在docker组sudo usermod -aG docker $USER重新登录容器内网络不通docker0网桥冲突或防火墙拦截ip addr show docker0确认网桥检查防火墙规则离线机器docker pull失败网络不通或镜像仓库配置错误用save/load方式导入或配置内网仓库地址Windows虚拟机里想跑Docker Desktop报virtualization support not detected宿主机的嵌套虚拟化未开启在VMware/BIOS中开启Intel VT-x/AMD-V并确认Windows Hypervisor平台已启用这些坑并不是每个项目都会遇到但只要你离线环境稍微特殊一点命中概率就不低。提前了解原因遇到问题就能少走弯路。我个人的体会是离线安装Docker这件事真正麻烦的不是敲命令而是准备工作做得够不够细。版本、架构、依赖、镜像每一项都要在联网机器上提前备齐。我自己现在有个习惯每次项目验收后会把整组deb包和常用镜像tar包归档到内网的一个公共目录里后续新机器要装的时候直接拿现成的包几分钟就能装好不用每次重新联网找资源。这个习惯也推荐给你离线环境最怕的就是临时缺一个包还要满世界找。