Fedora 在服务器和桌面领域积累了足够的稳定性，但很多运维人员并不清楚它针对物联网场景做了专门优化。Fedora IoT 这个版本把系统根文件系统变成了只读的 OSTree 提交，配合原子化更新和健康检查，正好适合那些无人值守、网络波动频繁的边缘设备。如果你手头有树莓派、x86 工控机或者 ARM 网关，都可以直接刷入 Fedora IoT 镜像开始管理。接下来会从环境准备、系统更新、远程操作、容器部署几个角度展开。
Fedora IoT 镜像与基础环境搭建
Fedora IoT 的镜像和普通 Workstation 或 Server 版本不一样，它默认使用只读的根文件系统，所有系统级修改都通过 rpm-ostree 生成新的 OSTree 提交来完成。这种方式带来的好处是每次升级都像是一次全新的系统部署，不会因为残留配置文件或者半更新的包导致系统进入不一致状态。镜像下载后可以用 arm-image-installer 或者直接使用 dd 写入 SD 卡或磁盘。如果目标是 x86 设备，建议用 Fedora Media Writer 制作启动盘，安装过程中选择 IoT 版本即可。
首次启动后，系统会引导你设置主机名、网络和用户。默认情况下 root 账户不会开启 SSH 密码登录，你需要创建一个普通用户并把它加入 wheel 组，然后通过 sudo 提权。这么做是为了降低边缘设备被暴力破解的风险。网络配置推荐使用 nmcli 命令行工具，因为它能生成稳定的 systemd-networkd 配置，而且后续批量管理时也容易用脚本复制。例如执行 nmcli con add type ethernet con-name wan ifname enp1s0 ip4 192.168.1.100/24 gw4 192.168.1.1 可以快速固定 IP。如果设备需要连接 Wi-Fi，可以用 nmcli dev wifi connect "SSID" password "passphrase"。
Fedora IoT 默认启用了 firewalld 防火墙，建议只放行 SSH 和后续应用需要的端口。比如边缘节点上跑了 MQTT 服务，可以用 firewall-cmd --permanent --add-port=1883/tcp 然后 firewall-cmd --reload。另外系统时区、NTP 同步也要提前设置好，因为设备日志的时间戳会直接影响故障排查。使用 timedatectl set-timezone Asia/Shanghai 和 timedatectl set-ntp true 即可。这些基础配置做完后，建议先执行一次手动更新，让系统处于最新的 OSTree 提交状态。
原子化更新与 greenboot 健康检查
Fedora IoT 的更新机制和传统的 dnf update 完全不同，它依赖 rpm-ostree 工具。执行 rpm-ostree upgrade 时，系统不会在运行中的根文件系统上直接替换包，而是下载新包、生成一个新的 OSTree 提交，并在下次重启时切换过去。这意味着更新过程中设备始终保持运行，只有重启那一瞬间才会切换到新系统。如果新版启动失败，grub 菜单里还保留着旧版备份，可以手动回滚。更省心的是 rpm-ostree rollback 命令，一条指令就能回到上一个已知良好的状态。
单纯依靠 grub 手动回滚还不够智能，greenboot 就是为这个场景设计的。它是一套基于 systemd 的健康检查框架，在设备启动后会运行一系列自定义脚本，判断系统是否真正可用。比如你可以写一个脚本检查关键服务是否启动、网络接口是否拿到 IP、甚至调用某个 HTTP 接口验证应用是否响应。如果检查失败，greenboot 会自动回滚到上一个 OSTree 提交并重启，整个过程不需要人工介入。安装 greenboot 用 rpm-ostree install greenboot，然后重启生效。自定义检查脚本放在 /etc/greenboot/check/required.d/ 目录下，脚本返回非零退出码就表示失败。
#!/bin/bash # 检查容器运行状态 systemctl is-active --quiet podman-test-app if [ $? -ne 0 ]; then echo "test-app container is not running" exit 1 fi exit 0
上面的脚本只是一个最简单的示例，实际生产中可以扩展更多逻辑，比如检查数据库连接、磁盘读写速度或者传感器数据采集是否正常。greenboot 还支持 check/required.d 和 check/wanted.d 两个层级，前者失败会导致回滚，后者失败只记录日志不触发回滚。这样你可以设置一个严格的必需检查，再补充一些非致命的警告检查。对于无人值守的物联网设备来说，greenboot 的价值在于自动修复更新带来的意外问题，把人工现场维护的次数降到最低。
通过 Cockpit 与 Ansible 实现远程运维
远程管理几十台甚至上百台边缘设备时，不可能逐一 SSH 登录敲命令。Fedora IoT 默认可以启用 Cockpit 这个 Web 管理界面，它提供了直观的系统状态查看、日志检索、终端访问和存储管理功能。安装命令是 rpm-ostree install cockpit，安装后需要重启系统，然后执行 systemctl enable --now cockpit.socket。浏览器访问 https://设备IP:9090 就能看到登录页。Cockpit 的终端功能非常适合临时排查问题，但它更适合单台设备操作，批量管理还是要交给 Ansible。
Ansible 是无代理架构，只要边缘设备开启了 SSH 并且有 Python 环境，就能被控制端管理。你可以在管理机上维护一个 inventory 文件，把所有 Fedora IoT 设备的 IP、用户、密钥信息列出来。然后编写 playbook 来批量执行系统更新、配置文件下发、服务重启等任务。比如下面这个 playbook 会检查所有设备的 OSTree 版本，并返回当前部署的提交 ID。
---
- name: Check Fedora IoT OSTree version
hosts: edge_nodes
become: yes
tasks:
- name: Get current deployment
command: rpm-ostree status --json
register: ostree_status
- name: Show deployment info
debug:
msg: "{{ ostree_status.stdout | from_json | json_query('deployments[0].checksum') }}"
使用 Ansible 时要注意，Fedora IoT 的根文件系统是只读的，不能在 /etc 以外的位置随意写文件。配置管理应该遵循“系统状态写在 /etc，应用状态写在外置存储”的原则。对于需要修改系统级库文件的情况，必须通过 rpm-ostree install 或者 rpm-ostree usroverlay 临时开启可写层，但重启后 usroverlay 的修改会丢失。因此生产环境建议把自定义配置放在 /etc 下，应用数据挂载到独立的 /var 分区或外置存储，这样系统和数据就解耦了。
Podman 容器化应用部署与监控
Fedora IoT 并不预装 Docker，而是集成了 Podman 作为容器运行时。Podman 和 systemd 集成得更好，可以把容器作为 systemd 服务来管理，这样设备重启后容器能自动拉起。对于物联网应用来说，把传感器数据采集、边缘计算、消息转发等逻辑打包成容器，可以避免在只读系统上直接安装 Python 包或 Node 模块带来的麻烦。部署一个容器应用通常分两步：先用 podman run 验证运行正常，再用 podman generate systemd 生成服务单元文件。
# 运行一个测试容器 podman run -d --name edge-mqtt --network host \ -v /var/lib/edge-mqtt:/data:Z \ quay.io/example/edge-mqtt:latest # 生成 systemd 服务并启用 podman generate systemd --name edge-mqtt --files --new sudo mv container-edge-mqtt.service /etc/systemd/system/ sudo systemctl enable container-edge-mqtt.service sudo systemctl start container-edge-mqtt.service
注意上面的 quay.io/example/edge-mqtt:latest 只是示例镜像，实际使用时需要替换成你自己的容器仓库地址。如果设备无法访问公网容器仓库，可以考虑在内网搭建一个 registry，或者使用 podman save 和 podman load 离线导入镜像。另外容器日志默认会输出到 journald，可以用 journalctl -u container-edge-mqtt 查看，配合 Cockpit 的日志界面可以快速定位应用异常。
监控方面，Fedora IoT 本身可以通过 node_exporter 容器暴露 Prometheus 指标，边缘端的采集数据也可以由应用容器直接上报到中心端。如果设备规模不大，可以在管理机上部署一个 Prometheus 加 Grafana 来统一展示 CPU、内存、磁盘、网络流量以及容器运行状态。但要注意边缘设备的网络带宽有限，Prometheus 的拉取模式可能会占用较多上行流量，建议调整 scrape_interval 为 60 秒或更长，并开启指标过滤。除此之外，还可以使用 journald 的远程转发功能把日志集中到 loki 或 rsyslog 服务器，方便后续审计和告警。
最后强调一点，Fedora IoT 的只读根文件系统并不意味着无法做定制。所有系统级修改都可以通过 rpm-ostree 生成新的 OSTree 提交来固化，应用层则交给容器和 /etc 配置管理。把更新、回滚、健康检查、远程运维、容器部署这几块串联起来，你就得到了一套相对完整的物联网设备管理方案。对于长期运行在恶劣环境中的边缘节点来说，这套方案比传统的 Debian 或 Ubuntu 手动 apt 更新要可靠得多。