工业视觉踩坑实录（八）：一场足球赛，让全西班牙的开发者连 Docker 都拉不了——我在工厂部署时学到的基础设施教训

摘要：2026年4月，西班牙因一场足球比赛的版权保护，Cloudflare触发IP屏蔽，导致整个西班牙的docker pull全面失败。这个HN当天最高分（639分）的事件，让我回想起了自己在工厂现场部署时遇到过的那些基础设施崩塌时刻。本文从这件事出发，聊聊工业视觉部署中经常被忽视的基础设施依赖问题，以及我踩过坑之后总结的应对方案。

关于作者

我接触视觉整整10年。

机器视觉、烟草、煤矿等行业都有深度开发经验。从硬件选型、算法开发、模型训练，到上位机开发及部署，都在一线磨过。

之前是多家公司人工智能团队的技术负责人。现在自己创业了，还在继续做视觉落地这件事。

---

作者说

搞工业视觉的兄弟们有没有经历过这种场景——

算法在实验室跑得好好的，部署到客户现场，环境一切就绪，信心满满地执行docker pull，然后……

超时。

再试一次，还是超时。

之前我一直觉得，部署环境出问题主要是硬件配置不够、驱动不兼容这些事。直到我看到HN上那个帖子，我才意识到，有些坑是你再怎么准备硬件也躲不过的。

---

一场足球赛干掉了全西班牙的Docker

事情是这样的。

4月中旬，西班牙有一场足球比赛，版权方为了防止盗播，通过Cloudflare对疑似侵权IP段进行了屏蔽。

听起来很正常对吧？版权保护嘛。

问题是，Cloudflare是Docker Hub的CDN服务商之一。

屏蔽策略一生效，整个西班牙访问Docker Hub的请求全部被拦截。不是某家公司、某个网络，是整个国家。

这意味着什么？

所有需要docker pull的开发者、CI/CD流水线、自动化部署脚本，全部趴窝。

你在巴塞罗那写代码，docker pull nginx，报错。

你在马德里跑CI，构建镜像那一步直接卡死。

你在某个工厂的机房里做灰度发布，拉不到新镜像，回滚都回不上去。

HN上这个帖子拿到了当天最高分——639分，248条评论。评论区里西班牙的开发者炸了锅，有人说自己的生产环境直接受影响，有人说排查了半天才定位到是CDN层面的问题。

坦率地讲，我第一反应是觉得好笑。

足球赛把Docker搞崩了，这什么魔幻剧情。

但笑完之后，我突然觉得后背发凉——因为这个场景，我在工厂部署时不是没遇到过。

---

我在工厂现场遇到的"基础设施地震"

那次甲方机房断网，我的部署全废了

去年在一家企业部署行为检测系统。

现场环境是这么配的：一台工控机跑算法推理，Docker容器化部署，镜像存在私有仓库里。私有仓库托管在阿里云上。当时觉得这个方案很稳——私有仓库、权限控制、版本管理，该有的都有。

部署当天，一切顺利。镜像拉下来了，容器启动了，算法跑起来了，精度也对。

第二天一早，甲方信息科打电话过来：“你们那个系统怎么起不来了？”

我远程一看，容器挂了。重新拉镜像，拉不到。

打电话问甲方信息科，他们说：“昨天晚上机房做了网络策略调整，现在所有对外访问都需要走代理。”

代理。代理。

你想想看，我部署的时候根本不知道他们有机房网络策略这回事。没有人告诉我，也没有文档。前一天好好的，第二天突然变了。

最后折腾了大半天，找甲方信息科开了白名单，才把镜像重新拉下来。

内网环境才是常态

搞过工业现场部署的兄弟应该都懂，很多工厂的网络环境跟互联网是隔绝的。

不是所有的甲方都有完善的内网镜像仓库。有的工厂连外网都不通，你把U盘插进去，发现工控机没有USB口（安全策略禁用了）。

有的工厂有内网，但速度只有10Mbps——拉一个几GB的镜像，要跑大半个小时。

有的工厂说可以联网，但防火墙规则三天两头变，今天能通的端口明天就不通了。

这种环境下，你如果还指望docker pull来解决部署问题，迟早要出事。

---

Docker只是冰山一角

回到西班牙那个事件，它暴露的其实是一个更深层的问题：我们对中心化基础设施的依赖，比我们以为的要严重得多。

Docker Hub被墙，你就拉不了镜像。

npm registry挂了，你的前端构建就过不了。

pip源不可用，你的Python环境就装不了依赖。

GitHub Actions宕机，你的CI/CD就停摆。

我在实际项目中遇到的不仅仅是Docker的问题。有一次在煤矿现场，甲方用的安全通信网关会定期清理DNS缓存，结果我的系统里有个微服务依赖的域名解析失败，服务间调用直接断了。

排查了三个小时。三个小时。

最后发现不是代码bug，不是网络故障，是DNS缓存过期后网关没有正确刷新。

类似的事情经历多了，我就开始重新思考部署方案。

---

我的应对方案：离线部署 + 本地冗余

方案一：镜像导出/导入

这是最简单粗暴但最可靠的方案。

# 在有网的环境导出镜像
docker save my-algorithm-image:v1.0 | gzip > algorithm-v1.0.tar.gz

# 拷贝到目标机器（U盘、移动硬盘、内网传输都行）
scp algorithm-v1.0.tar.gz user@factory-machine:/tmp/

# 在目标机器导入
docker load < algorithm-v1.0.tar.gz

这个方案的好处是完全不依赖网络。缺点是镜像文件大，几GB的tar.gz拷起来确实慢。

我一般会做两件事来优化：

1. 用多阶段构建缩小镜像体积
2. 只打包运行时依赖，不打包开发工具

一个典型的工业视觉算法镜像，优化前可能4-5GB，优化完能压到1-2GB。

方案二：私有仓库 + 定期同步

如果甲方有条件搭内网服务器，这是更好的方案。

我用的方案是Harbor，开源的，部署在内网。

# docker-compose.yml (简化版)
version: '3'
services:
  harbor:
    image: goharbor/harbor-arm:v2.10
    ports:
      - "8080:80"
      - "8443:443"
    environment:
      HARBOR_ADMIN_PASSWORD: <your-password>
    volumes:
      - /data/harbor:/data

关键是定期同步。我在办公室的CI/CD里加了一个定时任务，每天凌晨把最新镜像推送到一个中转服务器。到了现场部署的时候，从中转服务器同步到内网Harbor。

这样即使外网突然断了，内网仓库里至少有最近一次同步的镜像。

方案三：空气隔离环境

有些甲方的要求比较严格，需要完全断网部署（军工、能源、烟草行业的某些产线）。

这种情况下，我的做法是：

1. 在办公室准备好完整的部署包（镜像+配置+模型文件）
2. 打成一个tar包，通过安全渠道（甲方指定的U盘或安全传输系统）传到现场
3. 现场用一台跳板机做内网分发

配置文件里所有涉及外网地址的，全部改成内网地址：

# config.yaml
model:
  path: /opt/models/checkpoint.pt  # 本地路径，不走网络
registry:
  url: http://192.168.1.100:8080  # 内网仓库
logging:
  endpoint: http://192.168.1.101:9200  # 内网ELK

这一步特别重要。我之前犯过一个错误——在离线环境的配置文件里写了一个外网的地址，结果服务启动后一直尝试连接，超时重试超时重试，把日志塞满了，把性能也拖垮了。

不是bug，是配置问题。但排查起来比bug还烦人。

---

几条血泪教训

踩了这些坑之后，我给自己定了几个原则，每次部署前都会过一遍：

1. 永远假设网络会断。

这不是悲观，是工程实践。你假设网络永远畅通，那网络一断你就完了。你假设网络随时会断，你从一开始就会设计离线方案。

2. 部署包必须自包含。

镜像、配置、模型、依赖库，全部打包在一起。不要在部署的时候才去网上拉东西。甲方现场的网络环境是你控制不了的。

3. 配置文件和代码分离。

同一个镜像，在不同现场用不同的配置文件。IP地址、端口号、模型路径，全部通过配置文件注入，不要硬编码。这条听起来是常识，但我在别人的项目里见过太多硬编码的案例了。

4. 部署前先问甲方三个问题。

• 你们现场能不能联网？
• 联网的话，有没有防火墙/代理限制？
• 你们的网络策略会不会经常变？

这三个问题能帮你避开80%的部署坑。我之前每次都是到了现场才问，吃了不少苦头。现在养成习惯了，报价阶段就先问清楚。

5. 给自己留一条物理退路。

我会在工控机上预留一个USB口（如果甲方允许的话），或者提前配好一个通过串口/SSH访问的方式。万一网络全断了，至少还能手动操作。

有一次深夜12点，甲方产线出了问题，我的系统日志全存在内网ELK上，但网络断了连不上。最后是靠SSH串口登录进去，把日志拷到本地U盘带出来的。

如果当时没有留那个SSH入口，我就只能去现场了——而工厂在另一个省。

---

回到西班牙那个事件

说到底，那个足球赛导致Docker Hub不可用的事件，跟我们工业现场遇到的断网、防火墙策略变更、DNS过期是同一类问题。

基础设施不是你能控制的变量，但你可以控制自己依赖基础设施的方式。

云服务、CDN、容器仓库，这些东西让开发变得方便了，但也让部署变得脆弱了。你在办公室里docker pull一下就行，在工厂的机房里，这一步可能是你最大的噩梦。

我现在做部署方案的时候，第一个考虑的不是"怎么最快部署上去"，而是"如果所有外网都断了，这个系统还能不能跑"。

能做到这一点，你的部署方案才算及格。

---

最后说两句

搞工业现场的兄弟们，基础设施这件事，怎么说呢，真的值得认真对待。

不是说你一定要搞多复杂的方案，关键是意识到位——知道哪些环节可能出问题，提前准备好备选方案。

像文章开头那个西班牙事件，如果你在CI/CD里配置了多个镜像源（比如官方Hub + 阿里云镜像 + 自己的私有仓库），至少其中一个挂了你还有别的选择。

别等到半夜三点被电话叫醒，才想起来这件事。

*本文所有代码均为示意，核心思路可复现，具体参数需根据实际场景调整。

📎 相关专栏

• 工业视觉踩坑实录