3. 边缘应用形态与部署单元

在 ctrlX AUTOMATION 的边缘设备上，“部署一个应用”并不只有一种含义。同一个功能，可能以 Docker 容器、ctrlX App、Snap、systemd 系统服务，甚至一段自行编译的二进制程序存在。它们都能在设备上运行，但安装方式、依赖边界、权限模型、升级路径和生命周期管理完全不同。如果混淆这些形态，就会出现“应用装上了却起不来”“升级后配置丢失”“权限不足访问不到实时总线”等典型问题。本节的目标，是建立一张清晰的“可部署产物边界图”，让你在拿到一个功能需求时，能判断它应该被封装成哪一种部署单元。

一、五种部署单元的定位

容器化应用（Docker/OCI 容器）是最通用的形态。它把应用代码、运行时、库依赖打包进镜像，通过容器运行时隔离运行。在 ctrlX 上，容器通常由 ctrlX Data Layer 或应用管理框架拉起，适合自带完整依赖、需要独立文件系统的服务，例如视觉推理、数据库、Web 后端。它的边界是镜像层：镜像内是应用自己的世界，镜像外通过端口、卷挂载和 Data Layer 与系统交互。

ctrlX App是 ctrlX 生态中的“一等公民”。它本质上是一个符合 ctrlX 应用规范的包，通常内部仍以容器或 Snap 承载，但额外提供了标准化的元数据、Data Layer 节点声明、Web UI 入口、许可证与授权信息。安装后它会出现在 ctrlX 的应用管理界面中，可被统一启停、升级和授权。判断标准很简单：如果这个功能需要被最终用户通过 ctrlX 界面看到、授权和运维，就应该做成 ctrlX App，而不是裸容器。

Snap是 Ubuntu 生态的通用打包格式，强调强隔离与自动更新。ctrlX OS 基于 Ubuntu 内核与 Snap 机制，因此部分系统级组件和第三方工具以 Snap 形式存在。Snap 的边界由 snapcraft.yaml 中的接口（interface）定义，例如需要访问串口、网络或 GPIO 时必须声明对应 plug。它适合需要严格沙箱、又希望获得自动更新能力的工具类应用。

系统服务（systemd service）是操作系统层面的常驻进程管理单元。它没有额外隔离，直接以指定用户身份运行在主机命名空间中，因此能访问设备节点、实时网络和底层硬件。适合设备驱动代理、看门狗、网络配置守护进程等必须贴近系统的功能。代价是：它与 OS 版本强耦合，升级 OS 时可能失效，且不具备应用商店式的分发能力。

自定义运行时指不经过上述任何封装、直接部署的可执行程序或脚本，例如交叉编译出的 ARM64 二进制、Python 脚本配合虚拟环境。它最灵活，但也最“裸”：依赖需自行解决，开机自启需自行配置，权限需自行处理。通常只用于原型验证或内部工具，不建议作为正式交付形态。

二、如何判断一个功能该用哪种形态

判断的核心不是“哪种更先进”，而是三个问题：它需要多深的硬件访问？它是否需要被统一运维和授权？它的依赖是否复杂到需要自带？

如果功能需要直接读写 /dev 下的设备节点、绑定实时网卡、或运行在中断上下文附近，系统服务或自定义运行时是唯一现实选择，因为容器和 Snap 的命名空间会挡住这些路径。反之，如果功能只是消费 Data Layer 中的数据、做算法推理或提供 Web 界面，容器化应用是默认答案。

如果这个功能要交付给客户、要在 ctrlX 商店或本地应用管理中呈现、要绑定许可证，那么无论内部是容器还是 Snap，外层都应封装为 ctrlX App。ctrlX App 的价值不在运行机制，而在“可被发现、可被授权、可被统一升级”的生态契约。

Snap 则适合那些“需要沙箱、又需要自动更新、且依赖 Ubuntu 生态工具链”的场景，例如某些诊断工具、协议转换器。它的接口声明是硬约束：没有声明 network 接口，就真的连不上网。

三、一个具体的边界划分示例

假设我们要在 ctrlX CORE 上部署一个“振动监测与预警”功能。它包含三部分：高频采样驱动、FFT 特征计算、Web 看板与告警推送。

• 高频采样驱动：需要以 10 kHz 读取加速度传感器，直接访问 SPI/IEPE 接口，延迟敏感。→ 系统服务，以专用用户运行，绑定 CPU 核。
• FFT 特征计算：消费采样数据，输出特征值到 Data Layer，依赖 numpy/scipy。→ 容器化应用，镜像内固定 Python 与库版本，通过 Data Layer 读写。
• Web 看板与告警：提供 UI、配置告警阈值、推送邮件。→ 封装为 ctrlX App，内部是容器，声明 Data Layer 节点与 Web 入口，纳入应用管理。

这样划分后，升级 FFT 算法只需替换容器镜像，不影响驱动；调整告警界面只需升级 ctrlX App；而驱动作为系统服务，随 OS 版本一起验证，不随意变动。三者的边界清晰，互不越界。

四、部署单元的关键参数与观察点

在实际操作中，可以用以下字段快速核对一个部署单元的边界是否合理。下表给出的是示例性检查项，具体值需按项目实际填写。

部署单元	典型载体	硬件访问	升级方式	关键观察点
系统服务	systemd unit	直接	随 OS 或手动替换	systemctl status、journalctl 日志、CPU 亲和性
Snap	.snap 包	经接口声明	snap refresh 自动	snap connections、接口是否 connected
容器化应用	OCI 镜像	经卷/端口映射	替换镜像标签	docker ps、挂载卷、Data Layer 连接状态
ctrlX App	App 包（内含容器/Snap）	继承内部载体	应用管理界面统一升级	授权状态、Data Layer 节点是否注册、UI 是否可达
自定义运行时	二进制/脚本	直接	手动替换	依赖库是否存在、自启是否配置、权限是否正确

五、常见边界错误与排障方向

最常见的错误是“把需要硬件的功能塞进容器”。表现是容器启动正常，但打开设备节点时报 Permission denied 或 No such file。此时不要急着加 --privileged，而应先判断该功能是否本就不该容器化。若确实需要，应通过设备映射（--device）和最小权限组来开放，而不是全权限。

第二个常见错误是“把 ctrlX App 当成普通容器直接 docker run”。这样虽然进程能跑，但它不会出现在应用管理界面，Data Layer 节点不会自动注册，许可证也无法绑定。正确做法是通过 ctrlX 的应用安装接口或应用管理界面安装 App 包。

第三个错误是“Snap 接口未连接”。Snap 安装后接口默认可能是 disconnected 状态，需要 snap connect 手动连接，或在 snapcraft.yaml 中声明为默认连接。观察点是 snap connections <name> 的输出。

# 示例：查看某 Snap 的接口连接状态
snap connections vibration-monitor
# 输出中若 network 为 disconnected，则需：
sudo snap connect vibration-monitor:network

# 示例：查看系统服务运行状态与最近日志
systemctl status vibration-driver.service
journalctl -u vibration-driver.service -n 50 --no-pager

# 示例：查看容器挂载与 Data Layer 连接
docker inspect fft-service --format '{{json .Mounts}}'

这些命令的输出，正是判断“部署单元边界是否被正确设置”的直接依据。看到设备节点、接口状态、挂载卷和日志，就能定位问题出在封装层还是功能层。

六、小结：边界即契约

容器化应用、ctrlX App、Snap、系统服务与自定义运行时，不是五个可以随意替换的选项，而是五层不同强度的契约。容器约定“我自带依赖，只通过明确定义的接口交互”；ctrlX App 约定“我遵守生态规范，可被统一管理”；Snap 约定“我在沙箱内运行，通过接口申请权限”；系统服务约定“我贴近系统，随 OS 生命周期”；自定义运行时则几乎没有契约，一切自负。明确可部署产物的边界，本质上就是明确每一层契约的权责，让功能在正确的层级上稳定运行。