把 OPC UA 连接到 Docker

开始之前

• 为 PKI 目录挂载持久卷。这就是本页的全部要点。
• 关于容器主机名和 ApplicationUri 的决定，因为两者的解析方式都与在笔记本电脑上不同。
• 从容器到各服务器 4840 端口的网络可达性，包括容器宿主机自身的任何主机防火墙。

配置方法

1. 把 PKI 目录挂载到具名卷上无论你的技术栈把它叫作 ./pki、安全配置存储路径还是证书管理器根文件夹：都要挂载它。容器的身份就在里面，必须能在重启后留存。
2. 显式设置 ApplicationUri不要让它默认取自随机的容器主机名。在配置中设定它，并确保证书 SAN 中出现同一个值作为 URI 条目。
3. 把每一个可达名称都放进证书 SAN容器的服务名、主机的 DNS 名，以及对端实际会连接的任何地址。客户端拿它所连接的 URL 与 SAN 比对，并不关心容器自认为叫什么。
4. 处理时间容器继承宿主机时钟。宿主机时钟偏移会让完全有效的证书出现证书时间校验失败，因此宿主机上的 NTP 是一项安全控制措施。
5. 在交付之前先验证重启场景启动容器，建立安全会话，重启容器，确认会话无需管理员改动信任列表即可重新建立。如果做不到，说明你的卷并没有挂载在你以为的位置。
6. 为服务器暴露正确的端口容器化的 OPC UA 服务器需要发布 4840 端口，而且它所通告的端点 URL 必须是客户端真正能访问到的地址，而不是容器的内部地址。

地址空间是什么样子

容器化不会改变地址空间。它改变的是身份和可达性：证书、ApplicationUri 和对外公布的端点 URL。这三者就是部署可用与令人困惑之间的全部差别。

陷阱

• PKI 卷未做持久化是容器化 OPC UA 最常见的失败原因。症状让人抓狂：先是能用，然后每次部署之后都失败，报出的证书错误看起来像是服务器端发生了变更。
• 一个在端点描述中公布自身容器内部主机名的容器化服务器，会给客户端一个它无法解析的 URL。请显式配置对外公布的主机名。
• 宿主机时钟偏移会产生看似证书内容问题的证书时间校验失败。在重新生成证书之前先检查时钟。
• 容器内的临时文件和中间文件没问题，但任何你需要保留的东西（证书、nodeset 导出、配置）都需要卷。
• 如果容器在编排器下频繁重启，每一次重启都是对每一台服务器的一次全新连接。请让启动错峰，否则你是在自己制造连接风暴。

从中获取 OEE 数据

没有直接关系：这属于部署管道。它对 OEE 的意义仅在于：每次部署都丢失信任的采集器会在可用率数据中留下缺口，而除非你单独记录采集器健康状态，否则采集缺口与停机无法区分。请在设备数据之外同时发布一个采集器在线信号。

最后核对日期 2026 年 9 月 7 日，对照 OPC UA 1.05.07。OPC UA Connect 是教育资源，与 OPC Foundation 无隶属关系。