无网络环境下基于Docker与Git的生产代码部署方案问询

我太懂这种无网环境下Docker部署的糟心感了——每次改点小代码都要要么重新构建整个大镜像传输，要么手动docker cp一堆文件，效率低还容易出错。结合我之前帮团队解决过的类似问题，给你几个实用的方案，按需选：

方案1：预构建镜像+离线导入导出（最常用的单机器方案） #

这是最直接的思路，把镜像在有网环境做好，再传到无网生产机：

• 在有网的开发/构建机器上，正常用Dockerfile构建项目镜像：docker build -t your-project:v1.0 .
• 把构建好的镜像导出成tar包：docker save -o your-project-v1.0.tar your-project:v1.0
• 通过跳板机把tar包传到无网生产机（比如用scp或者跳板机的文件传输工具）
• 在生产机上导入镜像：docker load -i your-project-v1.0.tar
• 之后就可以正常启动容器：docker run -d --name your-app your-project:v1.0

小改动优化：增量镜像导出 #

如果只是改了少量代码，不想导出整个大镜像，可以基于原有镜像做增量更新：

比如先在有网机器上启动一个临时容器，把修改的文件复制进去，再提交成新镜像：

# 基于旧版本镜像启动临时容器
docker run -d --name temp-container your-project:v1.0
# 把本地修改的文件复制到临时容器对应路径
docker cp ./src/modified-file.js temp-container:/app/src/
# 提交临时容器为新镜像
docker commit temp-container your-project:v1.1
# 导出新镜像
docker save -o your-project-v1.1.tar your-project:v1.1

这样导出的tar包只会包含改动的镜像层，体积小很多，传输更快。

方案2：搭建离线私有镜像仓库（适合多台生产机场景） #

如果你的生产环境有多台无网机器，每次传tar包到每台机器太麻烦，可以搭建一个离线私有仓库：

• 在有网机器上下载私有仓库的离线安装包（比如Harbor的离线包），传到跳板机再同步到生产集群的某台机器
• 在该机器上部署离线Harbor仓库（按照官方离线安装文档操作即可）
• 回到有网机器，把构建好的镜像先推送到本地临时仓库，或者直接用docker save导出后，导入到离线Harbor仓库
• 其他生产机器就可以直接从本地离线Harbor拉取镜像，不用再逐个传tar包

方案3：基于Git差异的自动化docker cp同步 #

如果不想频繁构建镜像，也可以用脚本自动化同步修改的文件：

• 在开发机上，用Git获取当前版本和上一次部署版本的差异文件：git diff --name-only last-deploy-commit HEAD > changed-files.txt
• 写一个批量同步脚本（结合跳板机的ssh/scp），自动把这些差异文件传到生产机，再复制到运行中的容器里：

#!/bin/bash
# 读取差异文件列表
while read file; do
  # 先传到跳板机
  scp "$file" jump-user@jump-machine:/tmp/
  # 从跳板机传到生产机
  ssh jump-user@jump-machine "scp /tmp/$file prod-user@prod-machine:/tmp/"
  # 复制到容器对应路径
  ssh prod-user@prod-machine "docker cp /tmp/$file your-app-container:/app/$file"
  # 清理临时文件
  ssh jump-user@jump-machine "rm /tmp/$file"
  ssh prod-user@prod-machine "rm /tmp/$file"
done < changed-files.txt

# 如果需要重启服务生效，执行下面的命令
ssh prod-user@prod-machine "docker restart your-app-container"

这个脚本可以帮你省去手动复制每个文件的麻烦，减少出错概率。

几个关键注意事项 #

• 确保开发机和生产机的Docker版本尽量一致，避免镜像导入时出现兼容性问题
• 提前把项目依赖的基础镜像（比如ubuntu:20.04、node:18）在有网机器上下载好，导出成tar包传到生产机导入，这样构建项目镜像时就不用拉取基础镜像了
• 写Dockerfile时，尽量把不变的依赖安装步骤放在前面，改动的代码放在后面，这样每次构建的镜像增量更小，导出的tar包体积也会更小

内容的提问来源于stack exchange，提问作者WesternGun