企业官网建设流程全解析

手头有一套业务系统需要基于 Openclaw 2026.3.7 来跑，但现场环境是个物理隔离的内网，机器上连基础镜像源都访问不了。我花了两个晚上把整个部署链路捋顺，最终沉淀成一套可以直接照抄的 Docker 离线部署方案。从镜像准备、导出导入、私有仓库搭建到 Compose 编排和数据持久化，全部走了一遍，这篇就来完整记录这套方案的设计思路和踩坑过程。

先说清楚这套方案是给什么场景准备的：目标机器没有任何外网访问能力，可能是等保要求下的内网隔离环境，也可能是客户现场只有本地局域网。无论哪种情况，你手里通常只有一台能临时联网的“跳板机”或者自己电脑，所有需要用到的容器镜像、依赖组件，都得在联网机器上准备好之后，用物理拷贝的方式送进内网。Docker 离线部署就是解决这类问题的标准做法，核心只有三件事：打包、搬运、载入。但实际做的时候，光是把 Openclaw 2026.3.7 的镜像层依赖完整拉下来，就要面对镜像命名、平台架构、依赖服务、版本锁等一系列问题。

我在这套方案里走的是“离线镜像包 + Docker Compose + 内网私有仓库”的组合路线。单机导入适合临时部署，但如果你想在几台机器上重复部署，或者后续还要升级，那必须上私有仓库。接下来把每一步完整拆开讲，命令和配置都贴出来，你照着执行就行。

1. 离线部署的需求拆解与方案选型

1.1 离线部署到底要解决什么问题

很多人第一次做离线部署，以为就是把docker pull换成一个docker save和docker load就完事了。真到现场你会发现坑远比想象中多。首先，Openclaw 2026.3.7 作为一个完整的自动化编排框架，并不是只有一个镜像，它通常还依赖中间的数据库、缓存、消息队列等组件。也就是说，你要离线打包的不是“一个镜像”，而是一整棵镜像依赖树。

以我的环境为例，最终需要跑起来的服务有：Openclaw 主服务容器、数据库容器、缓存容器，另外还有一个内网镜像仓库容器。这些服务之间通过网络互相访问，如果镜像版本不匹配，应用起来之后可能会遇到接口协议对不上或者数据格式不兼容的问题。所以离线方案的第一步，就是在联网机器上把整套环境的镜像 Tag 版本统一固定下来，这个步骤管它叫版本锁定。

第二个要解决的问题是架构差异。现在多数服务器是 x86_64 架构，但有些内网机器可能是 ARM64 架构，比如信创环境下的国产 CPU 服务器。镜像如果不带 multi-arch 清单，你在 x86 机器上拉下来的镜像放到 ARM 机器上直接docker load，启动时大概率报exec format error。这个错误非常典型，排查起来也会绕很多弯路，后面我会讲怎么提前规避。

第三个问题才是搬运和导入。离线包用什么介质拷贝，U 盘、移动硬盘还是刻光盘？这取决于现场出入管理的严格程度。但不管用什么介质，离线包都不能只包含镜像文件本身，启动脚本、配置文件、初始化 SQL 或初始化脚本，这些统称交付物，都需要一并整理进去。我最后是把所有文件打包成一个自带目录结构的交付包，现场解压后按 README 执行三步命令就能完成部署。

1.2 三种常见离线部署方案对比

我在前期做选型的时候，对比过业内常用的三种离线部署方案，实测下来各有适用场景。

我这次选的是“离线镜像包 + 内网私有仓库 + Compose 编排”三合一的路线。单机直载方式虽然简单，但如果后续还要扩容机器，那就要重新拷贝一遍镜像。而且 Openclaw 2026.3.7 的镜像加起来好几个 GB，多台机器重复导一次非常浪费时间。架设一个本地 registry 之后，所有机器都从内网仓库拉取，docker 本身还会做本地缓存，遇到多节点扩容场景，效率和可靠性都高很多。

1.3 方案整体链路与文件流转设计

整套方案走完，数据流转路径是这样的：

第一步，在联网机器上安装与目标环境一致的 Docker 版本，然后按照依赖清单，逐个拉取 Openclaw 2026.3.7 及其依赖服务的镜像。

第二步，将镜像逐个docker save成 tar 文件，并对每个 tar 生成 SHA256 校验值。然后附上编排用的 docker-compose.yml、环境变量示例、初始化脚本和部署说明文档，组成一个完整的交付包。

第三步，到目标现场后，先把交付包拷贝进内网，校验文件完整性，确认 docker 环境就绪，然后执行导入脚本把镜像docker load进去。接着启动 registry 容器，把镜像 push 到本地仓库。

第四步，在目标机器上编写并修改 Compose 文件，替换镜像地址为本地仓库地址，然后一键docker compose up -d启动整套服务。

这套链路做下来，后续再新增机器就非常简单了：目标机器只需要装好 Docker，配好本地仓库地址，然后一条docker compose pull && docker compose up -d就能完成部署。这也是我为什么强调私有仓库一定要搭的原因，后面的维护成本会指数级下降。

2. 动手前必读：版本锁定与环境准备

2.1 先整理一份完整的依赖清单

离线部署最忌讳的是到了现场才发现少了某个组件。所以要做的第一件事，就是在联网机器上把依赖关系理清楚。

我当时梳理 Openclaw 2026.3.7 部署依赖的时候，列了一个清单表，包含：

• Openclaw 主镜像，Tag 固定为 2026.3.7；
• 数据库组件（PostgreSQL 为主，某些场景也可能用 MySQL），版本需要和 Openclaw 官方默认依赖保持一致；
• 缓存组件，常见的是 Redis，主要给任务队列和缓存使用；
• 消息队列组件，如果有异步任务分发就大概率需要；
• 对象存储客户端组件，有些能力依赖 S3 兼容存储；
• 初始化脚本，包括建库脚本、默认配置注入脚本。

这个清单怎么确认？最可靠的方式是去查看 Openclaw 官方部署文档里写的 compose 示例，里面会把依赖服务的镜像版本写得清清楚楚。如果没有明确的版本要求，就用该版本发布时常用的稳定版本。锁定了版本之后，拉取命令就变得非常机械：

docker pull openclaw/openclaw:2026.3.7 docker pull postgres:16-alpine docker pull redis:7-alpine docker pull minio:latest

这里有个细节：如果你要把镜像送到离线环境长期使用，尽量别用latest标签。原因很简单，latest是一个浮动标签，镜像内容会随着上游更新而变化，你无法保证当前拉到的内容和未来拉到的是同一个版本。正确做法是固定到具体数字版本，比如minio:RELEASE.2024-xx-xxTxx-xx-xxZ这种带日期的 Tag，才能保证交付内容的确定性。

2.2 目标机 Docker 环境准备：离线安装 Docker 的两种方式

目标机器上没有 Docker 环境怎么办？这也是离线部署中非常常见的一环。解决方式有两种，我实测下来都比较靠谱。

第一种方式是使用静态二进制包。Docker 官方提供免安装二进制包，下载后解压即可用。这种方式不依赖系统包管理器，对操作系统版本兼容性最好，适合 Linux 各发行版。具体步骤如下：

# 在联网机器上下载 docker 静态包 # 类似 docker-xx.tgz，还需要带上 containerd、runc 等配套组件 # 拷贝到目标机器后解压 tar -xzf docker-xx.tgz cp docker/* /usr/local/bin/ # 配置 systemd 管理 Docker 服务 # 需要准备 docker.service 和 containerd.service 文件

但静态包方式会引入 systemd 服务文件的维护问题，需要自己写 service 文件，对不熟 systemd 的同学不太友好。第二种方式是准备 RPM 或 DEB 离线安装包，这是我最推荐的方式。在内网机器上离线安装 Docker 的步骤是：

# 在联网机器上，用 yumdownloader 或 apt-get download 拉取依赖包 yumdownloader --resolve docker-ce docker-ce-cli containerd.io # 把下载好的 rpm 文件全部拷贝到目标机器 # 在目标机器上执行 rpm -ivh *.rpm # 启动并设置开机自启动 systemctl enable --now docker

要注意的是，Docker 的 RPM 包之间存在依赖关系，所以必须用--resolve参数把所有依赖一起拉下来。如果漏了几个依赖包，安装时会报错提示缺哪个包，也没关系，回到联网机器上补拉就行。

2.3 统一版本标准：拉取到导出的规范化流程

版本统一是这套方案里最容易被忽略的环节。我的习惯是，在联网机器上先建工作目录，把 Openclaw 2026.3.7 的依赖清单拆成文本文件，然后写一个拉取脚本。脚本里对每个镜像名和 Tag 做硬编码，不依赖手工输入，从源头避免拼写错误和版本漂移。

#!/bin/bash # pull-images.sh images=( "openclaw/openclaw:2026.3.7" "postgres:16-alpine" "redis:7-alpine" "minio:RELEASE.2024-05-10T01-41-38Z" ) for img in "${images[@]}"; do echo "Pulling $img ..." docker pull "$img" done

脚本执行完，再用docker images检查一遍所有镜像的仓库名和 Tag，和清单做对比。这里建议用docker inspect查看一下镜像创建时间和 Digest 值，Digest 是镜像内容的哈希，同一个 Tag 在不同时间里 Digest 可能完全不同。把 Digest 记进交付说明文档，现场docker load之后可以再次检查 Digest 是否一致，确保搬运过程中镜像内容没有变化或损坏。

这一步多花十分钟，后面能省掉很多查问题的功夫。

3. 核心实操：镜像打包、导入与私有仓库搭建

3.1 镜像导出与完整性校验

所有镜像拉好之后，开始导出。可以用一条命令批量导出，也可以逐个导出。我倾向于逐个导出加校验，因为如果打包后单个镜像文件损坏，只需重新导出这一个，不需要全部重来。

docker save openclaw/openclaw:2026.3.7 -o openclaw-2026.3.7.tar docker save postgres:16-alpine -o postgres-16-alpine.tar docker save redis:7-alpine -o redis-7-alpine.tar

导出完成后，立即对每个文件生成校验值：

sha256sum *.tar > checksums.txt cat checksums.txt

checksums.txt文件会随交付包一起带到现场，现场导入前先跑一遍校验：

sha256sum -c checksums.txt

如果输出OK就说明文件是完整的。这一步在 U 盘拷贝或者网络传输过程中经常发挥作用，因为大文件容易出现部分损坏。我遇到过一次 U 盘拷贝大文件完毕后在末尾扇区数据错漏，就是因为有了校验环节才在导入前及时发现，避免了一堆莫名其妙的启动故障。

3.2 目标机导入镜像的两种方式

目标机拿到离线镜像包后，导入方式取决于你后续是否搭建私有仓库。

如果你只是单机临时部署，直接 load 就行：

docker load -i openclaw-2026.3.7.tar docker load -i postgres-16-alpine.tar # 以此类推

但如果你像我一样要在内网搭一个私有仓库，那就不能只 load 了。必须先加载 registry 容器镜像，然后启动本地 registry，再把所有镜像重新打 Tag 并 push 到本地仓库。整个流程听着绕，其实逻辑很简单：先让内网有一台“镜像仓库服务器”，其他机器都向这个仓库要镜像。

先把 registry 镜像导入：

docker load -i registry-2.8.tar

然后启动 registry 容器：

docker run -d \ --name local-registry \ --restart=always \ -p 5000:5000 \ -v /opt/registry-data:/var/lib/registry \ registry:2.8

启动完成后，把其他镜像从本地环境导入，再打 Tag 推送到localhost:5000：

# 先 load docker load -i openclaw-2026.3.7.tar # 重新打 Tag 指向本地仓库地址 docker tag openclaw/openclaw:2026.3.7 localhost:5000/openclaw/openclaw:2026.3.7 # push 到本地 registry docker push localhost:5000/openclaw/openclaw:2026.3.7

对每个镜像执行同样的 Tag 和 Push 操作后，内网私有仓库就搭建完成，其他机器只要网络能访问到这台 registry，就可以直接 pull 了。

3.3 本地私有仓库的坑：非加密 HTTP 与自签证书

搭建 install registry 本身不难，难在让其他机器顺利从它拉取镜像。默认情况下 Docker 客户端只允许访问 HTTPS 的 registry，如果是 HTTP 就需要显式配置信任，否则会报http: server gave HTTP response to HTTPS client的错误。

要解决这个问题，需要在每台客户端机器的 Docker daemon 配置里声明这个仓库地址为 insecure registry：

# 编辑 /etc/docker/daemon.json，一般这个文件默认不存在 { "insecure-registries": ["registry.local:5000"] }

改完配置后重启 Docker：

systemctl restart docker

这里有个实际操作中的经验之谈：不要直接写 IP 加端口，因为如果你后面想用 TLS 证书或者要迁移仓库地址，IP 写死会很痛苦。我建议给这台仓库机器设置一个内网固定域名，比如registry.local，然后在各机器的/etc/hosts里加一行解析。这样后续仓库迁移，只需要改 hosts 指向即可。

当然，如果你希望更规范一点，可以给 registry 配上自签名证书开启 HTTPS。证书签发步骤大概这样：

# 生成 CA 私钥和自签名证书（用 openssl） openssl req -newkey rsa:2048 -nodes -keyout domain.key -x509 -days 365 -out domain.crt

生成的证书需要放到 registry 容器挂载的证书目录，并且客户端要把domain.crt加入系统信任列表。这个方法更麻烦，且每台客户端都要拷贝证书。如果内网安全要求不高，我建议用insecure-registries配置就好，实测最省事。

3.4 Compose 编排与启动配置示例

镜像全部就绪后，最后用 Docker Compose 把整套服务编排起来。在 Openclaw 2026.3.7 的部署场景里，Compose 文件的好处是可以把服务依赖、网络关系、数据卷一次性声明清楚。我使用的编排结构类似这样：

version: "3.8" services: database: image: registry.local:5000/postgres:16-alpine restart: always environment: POSTGRES_DB: openclaw POSTGRES_USER: openclaw POSTGRES_PASSWORD: change-me volumes: - db_data:/var/lib/postgresql/data networks: - openclaw-net healthcheck: test: ["CMD-SHELL", "pg_isready -U openclaw"] interval: 10s timeout: 5s retries: 5 cache: image: registry.local:5000/redis:7-alpine restart: always networks: - openclaw-net openclaw: image: registry.local:5000/openclaw/openclaw:2026.3.7 restart: always depends_on: database: condition: service_healthy cache: condition: service_started ports: - "8080:8080" environment: DATABASE_URL: postgresql://openclaw:change-me@database:5432/openclaw CACHE_URL: redis://cache:6379/0 volumes: - openclaw_data:/app/data networks: - openclaw-net volumes: db_data: openclaw_data: networks: openclaw-net: driver: bridge

这个文件里每一个配置项都不是随便写的。restart: always保证容器在机器重启后自动拉起，避免现场机器断电重启后服务全挂的问题。healthcheck用于探测数据库是否真正就绪，避免应用启动时数据库还未初始化完成导致连接失败后异常退出。volumes把持久化数据挂到宿主机磁盘，防止容器删除后数据全部丢失。networks让服务之间通过容器名访问，环境变量里的主机名就是服务名，Compose 会自动做 DNS 解析。

在目标机器上执行启动命令：

docker compose up -d

接着再用docker compose ps看服务状态，如果所有容器都是Up状态，基本就部署成功了。

4. 数据持久化、自启动与后续升级

4.1 数据卷规划与备份还原

Openclaw 2026.3.7 跑起来之后，最需要关注的就是数据目录。Compose 里声明的两个数据卷db_data和openclaw_data，其中db_data存放数据库文件，openclaw_data存放应用生成的文件、日志和配置。数据卷的底层存储位置是 Docker 管理的，通常在这个路径：/var/lib/docker/volumes/。

日常备份不要直接去拷贝/var/lib/docker/volumes里面的目录，尤其是数据库数据卷。因为数据库有事务和缓存机制，运行时直接拷贝文件容易造成数据损坏。正确做法是用数据库自带工具做逻辑备份。

比如 PostgreSQL 容器可以这样备份：

docker exec -t <db-container> pg_dump -U openclaw openclaw > backup.sql

还原就反过来：

docker exec -i <db-container> psql -U openclaw openclaw < backup.sql

应用数据卷由于是文件操作，相对安全一点，但备份前最好还是把应用容器短暂停一下，保证文件状态一致。我习惯在凌晨低峰期做备份，先用docker compose stop openclaw停掉应用服务，然后直接 tar 打包openclaw_data卷内容，最后再启动服务。

4.2 容器自启动与健康检查

容器自启动是离线部署现场很容易被忽视的一点。很多内网环境断电后需要人工去机房开机，如果 Docker 和容器没有配置好自启动，那就得一台台去手动敲命令。我的做法是在两个层面保障：

第一，Docker 服务本身开机自启：

systemctl enable docker

第二，每个容器都要设置restart: always，Windows 上叫策略，Linux 上就是容器配置里做声明。restart: always不光在机器重启后有用，容器进程异常退出时也会自动拉起，对业务稳定性有直接帮助。

健康检查则是通过 Compose 里的healthcheck配置。它让 Docker 能够识别容器是否真正可用，而不是仅仅看进程状态。比如数据库容器虽然启动了，但还没完成初始化，这时候 Openclaw 服务如果先跑起来，就会因为连不上数据库而反复重启失败。有了健康检查，depends_on配合condition: service_healthy就能确保依赖服务就绪后再启动。这个配置组合，强烈建议大家在离线部署时用起来。

4.3 升级与回滚：离线增量包的做法

Openclaw 2026.3.7 这套环境用了一段时间后，如果官方发布了新版本，比如 2026.3.8，那么离线环境同样可以升级。升级的思路和首次部署几乎一样，只是可以做成增量包。

增量包的制作流程：

第一步，在联网机器上拉取新版本的镜像，导出成增量 tar 文件。

第二步，把 tar 文件拷贝到内网，压缩包校验无误后docker load导入到 registry 所在机器。

第三步，重新打 Tag 并 push 到本地 registry。

第四步，修改 Compose 文件里 Openclaw 镜像的 Tag，从2026.3.7改成2026.3.8。

第五步，执行docker compose pull openclaw && docker compose up -d。这样只会重建标记为变化的服务，其他依赖服务不受影响。

如果升级后发现问题需要回滚，只要把 Compose 文件里的 Tag 改回2026.3.7，然后docker compose up -d，镜像在本地仍然存在，拉起过程很快。这就是固定 Tag 带来的好处，latest标签做不到这种精确回滚。

4.4 监控与日志：内网环境下的轻量方案

很多内网环境没有完善的监控系统，这时候最少必要做的两件事是磁盘空间监控和容器状态巡检。我习惯部署一个简单的定时脚本，每隔几分钟调用docker ps检查容器是否都在运行状态，如果发现异常就写日志并报警（内网如有邮件服务可以发告警）。

另外要特别提醒一个坑：容器产生的日志文件会一直往宿主机的/var/lib/docker/containers/<id>/*-json.log里写，长时间不清理会把磁盘打满。我见过不止一次因为日志文件把磁盘占满导致数据库写入失败的案例。解决办法是在 Compose 文件或者 Docker daemon 配置里限制日志大小：

{ "log-driver": "json-file", "log-opts": { "max-size": "50m", "max-file": "3" } }

配置好之后，重启 Docker 生效，这个参数会限制单个日志文件最大 50MB、最多保留 3 个文件，从源头上避免日志撑爆磁盘。

5. 常见问题与排查技巧实录

5.1 问题速查表

离线部署过程中遇到的问题，我把它们整理成一个速查表，基本覆盖了绝大多数场景：

5.2 典型案例：镜像命名不一致导致 Pull 失败

我在某次部署中遇到过一个问题：所有镜像都已经 load 进目标机器了，但 Compose 启动时仍然报pull access denied或者not found。排查过程花了不少时间，最后定位到原因：镜像的命名和 Tag 不一致。

具体来说，Compose 文件里写的镜像地址是registry.local:5000/openclaw/openclaw:2026.3.7，但当时内网 registry 上只有localhost:5000/openclaw/openclaw:2026.3.7这个 Tag。Docker 在 pull 时会根据 Compose 里的地址去仓库查找，仓库里没有对应 Tag 就会报错，哪怕本地已经有内容一模一样的镜像也没用。

这个问题的根因是：docker push到 registry 后，仓库里的镜像会被删掉或者改名，Compose 里引用地址必须严格按照 push 时的完整镜像名来写。所以我后来在交付文档里特别标注了镜像引用规范，必须保证 Compose 文件里的image字段和 push 时的完整镜像名完全一致，否则 pull 不到。

5.3 典型案例：磁盘空间不足与 Docker 数据目录迁移

内网服务器磁盘规划经常不按生产环境要求来，遇到过几次因为磁盘满导致部署失败的情况。这里给一个临时解决办法和长期方案。

临时办法，清理不再需要的镜像和容器：

docker image prune -a docker container prune

长期方案，是把 Docker 的数据目录迁移到大容量磁盘。默认数据目录是/var/lib/docker，迁移做法如下：

# 先停掉 Docker 服务 systemctl stop docker # 拷贝数据到新目录（比如 /data/docker） rsync -avz /var/lib/docker/ /data/docker/ # 修改 docker.service 配置，或者创建 /etc/docker/daemon.json # daemon.json 中添加 "data-root": "/data/docker" systemctl start docker

迁移完成之后，执行docker info检查Docker Root Dir是否变成新路径。注意，迁移前一定要确认新分区已经做好格式化并挂载，中途不能强制断电。数据卷的读写和底层存储路径密切相关，迁移完成后最好立即做一次备份验证，确保数据可读。

5.4 经典请求：自签名证书与非加密 HTTP 兼容问题

有次给一个新现场部署，客户端机器明明已经配置了insecure-registries指向内网仓库，但docker pull仍然报证书验证失败。后来发现是因为那台机器上已经存在一个旧的/etc/docker/daemon.json，文件里有一些老配置，我在修改时只是直接追加了几行内容，导致 JSON 格式非法，Docker 启动失败后自动回退到默认配置，insecure-registries根本没生效。

这类问题的排查思路其实很简单：改完配置后一定要先检查两个地方。

第一，docker info里能不能看到Registry Mirrors或Insecure Registries列表，如果看不到说明配置没生效。

第二，看 Docker 日志，journalctl -u docker或者直接看文件日志，确认 daemon 配置文件解析是否有报错。配置文件不合法会直接导致 Docker 拒绝启动。

除了insecure-registries，如果你用的是自签名证书方案，还要确认证书是否被客户端系统信任。有一些发行版需要执行update-ca-certificates刷新信任列表，如果漏了这一步，证书装好但仍然不受信任，连接还是会失败。

5.5 几个值得养成的操作习惯

做完整个 Openclaw 2026.3.7 的离线部署，我总结出几个对所有离线项目都通用的操作习惯。

第一，所有交付文件都要有目录结构和命名规范。我的交付包长这样：

delivery/ ├── images/ # 存放所有离线镜像 tar ├── scripts/ │ ├── load-images.sh # 导入镜像脚本 │ └── start-services.sh # 启动服务脚本 ├── config/ │ ├── docker-compose.yml # 编排文件 │ └── daemon.json # Docker 配置参考 └── README.md # 部署说明

这种目录结构让现场实施的人看一眼就知道接下来要做什么，避免文件散落各处造成混淆。

第二，每个 tar 文件都做校验，并且校验文件要随包一起走。实际上，很多现场没有内网没有外网，连时间同步可能都没有。如果镜像文件在校验环节就发现问题，早发现早解决，不要等导入后才发现不对劲。

第三，Compose 文件和环境变量建议拆开，参考示例里放environment直接写明文，到最后实施时手工改。更规范的做法是把密码和地址写进.env文件，Compose 启动时自动读取。这样既不把敏感信息写死在编排文件里，也方便不同现场快速调整。

6. 写到最后的一点个人体会

这次把 Openclaw 2026.3.7 整套环境从联网机器搬到隔离内网，给我的最大感受是：离线部署真正的难点从来不在 Docker 命令本身上，而是在于对整套依赖链路的把控。镜像之间的版本匹配、架构兼容、默认配置、数据持久化策略，随便一个环节做了简化处理，都会在现场变成排查问题的无底洞。

前期不厌其烦地把镜像列表、Digest 校验值、Compose 配置、脚本和文档都放进交付包里，现场实施的时间反而缩短到半小时以内。这就是把工作前置的价值。我见过很多实施人员到现场才开始拉镜像、试配置，最后要么因为拉不到包卡住，要么因为版本不兼容反复重来，体验差距非常大。

最后再分享一个小技巧：完成整套部署后，别急着撤离现场，留十分钟做一次容器重启演练，让现场人员实际操作一遍docker compose restart，确认重启后服务能正常恢复。如果连重启演练都顺利通过，那这套离线部署方案才算真正交付完成。这十几分钟，能换来后续大量问题的预防。