在边缘运行更多服务IoT-For-Beginners 实战——把 Azure Functions 等任意容器化工作负载部署到 IoT Edge 模块【免费下载链接】IoT-For-Beginners12 Weeks, 24 Lessons, IoT for All!项目地址: https://gitcode.com/GitHub_Trending/io/IoT-For-Beginners本篇文章基于 IoT-For-Beginners 仓库中4-manufacturing/lessons/3-run-fruit-detector-edge一课的课后作业assignment编写。该作业的核心命题是边缘计算并不只属于图像分类器——任何能被封装进容器的代码都可以部署到 IoT Edge 设备上运行其中包括以 Azure Functions 为代表的无服务器serverless代码。读完本文你将掌握边缘工作负载的通用部署模型、从镜像构建到部署清单deployment manifest的完整链路并能够把之前课程里用到的 Azure Functions 触发器改造成一个运行在 IoT Edge 上的模块。作业背景为什么边缘不只属于 AI 模型在课程正文中你已经完成了将水果品质检测器部署到边缘的完整流程把 Custom Vision 训练好的图像分类器导出为容器镜像推送到 Azure Container Registry再通过 IoT Edge 的部署清单下发到边缘设备。边缘计算Edge Computing的本质是把数据处理放在离数据产生地点最近的地方——即你自己的内部网络而不是云端。它带来速度、远程可用性、低成本、隐私与安全等多方面的收益同时也在弹性伸缩、冗余与维护上有所取舍详见 课程 README 的 Edge computing 一节。而本次作业要传递的关键思想是搬到边缘的对象并不局限于 ML 模型。作业原文translations/en/4-manufacturing/lessons/3-run-fruit-detector-edge/assignment.md指出能够在边缘运行的不只是图像分类器——任何可以打包进容器的东西都可以部署到 IoT Edge 设备上。以 Azure Functions 形式运行的无服务器代码例如你在之前课程中创建的触发器同样可以在容器中运行因此也可以在 IoT Edge 上运行。在 IoT-For-Beginners 课程的制造业Manufacturing模块中前几课4-manufacturing/lessons/2-check-fruit-from-device等用 Azure Functions 构建过基于 IoT 数据触发的工作流。本次作业就是要求把这些云端触发器改造成边缘模块体会同一份代码在云与边缘两种承载形态下的差异。Azure IoT Edge 的工作负载模型模块即容器要理解把 Functions 部署到边缘首先需要建立 Azure IoT Edge 的模块化心智模型。从 课程 README 的 Azure IoT Edge 一节可以提炼出以下核心概念工作负载Workloads指任何执行某种工作的服务——AI 模型、应用程序、无服务器函数都属于工作负载。模块Modules部署到 IoT Edge 上的软件统称为模块。IoT Edge 默认运行与 IoT Hub 通信的系统模块edgeAgent和edgeHub当你部署图像分类器时它是作为额外的业务模块被追加进去的。容器ContainersIoT Edge 从容器中运行代码。容器是自包含的应用程序与宿主机上的其他软件隔离运行通常只能通过暴露的端口对外提供服务。IoT Edge 与 IoT Hub 同源集成因此管理边缘设备与普通 IoT 设备使用同一套服务与安全体系。作业正是建立在这一模型之上既然图像分类器能作为容器模块部署那么 Azure Functions 打包成的容器同样能作为模块部署唯一的区别是模块内部运行的业务逻辑不同。这正是云训练、边缘推理/边缘执行混合架构的延伸——你可以在云端训练模型、构建函数然后把迭代产物通过 IoT Edge 下发到边缘设备部署链路示意展示了边缘设备与云的这种关系。前置基础完整的边缘部署流水线源自本课实战在动手改造 Functions 之前需要先掌握本课已经演练过的通用部署流水线。这条链路对任何容器化工作负载都适用是本次作业的方法论基础其各环节的详细命令与说明可在 课程 README 中找到注册边缘设备在 IoT Hub 中注册一个 edge-enabled 设备例如fruit-quality-detector-edgeaz iot hub device-identity create --edge-enabled \ --device-id fruit-quality-detector-edge \ --hub-name hub_name然后获取该设备的连接字符串配置运行时需要用到az iot hub device-identity connection-string show --device-id fruit-quality-detector-edge \ --output table \ --hub-name hub_name搭建边缘运行时IoT Edge 运行时只运行 Linux 容器。Raspberry Pi 可直接承载Windows 上需要在 Linux 虚拟机中安装macOS 用户可按 vm-iotedge.md 的指引在云端创建预装 IoT Edge 的 Linux 虚拟机az deployment group create配合官方edgeDeploy.json模板即可一键创建并完成设备连接。准备容器镜像镜像需要先构建、再推送到容器注册表Container RegistryIoT Edge 才能从注册表拉取。本课使用 Azure Container Registry# 创建注册表 az acr create --resource-group fruit-quality-detector \ --sku Basic \ --name Container registry name # 登录、开启 admin 模式并生成密码 az acr login --name Container registry name az acr update --admin-enabled true --name Container registry name az acr credential renew --password-name password --output table --name Container registry name # 在解压后的模型目录中构建并推送镜像ARM 设备用 linux/armhf其余用 linux/amd64 docker build --platform platform -t Container registry name.azurecr.io/classifier:v1 . docker push Container registry name.azurecr.io/classifier:v1编写部署清单并下发部署清单deployment manifest是一个 JSON 文档列出将部署到边缘设备的所有模块。仓库中提供了完整可用的样例 deployment.json其中registryCredentials段用于让边缘设备登录注册表拉取私有镜像systemModules段声明edgeAgent/edgeHubmodules段声明业务模块示例中的ImageClassifier。下发命令为az iot edge set-modules --device-id fruit-quality-detector-edge \ --content deployment.json \ --hub-name hub_name验证与调用SSH 登录边缘设备后用iotedge list查看模块运行状态、用iotedge logs ImageClassifier查看日志随后可通过curl --request POST http://IP地址或主机名/image --header Content-Type: image/png --data-binary 文件名直接调用容器内暴露的 REST 接口完成预测返回 JSON 中包含各标签的概率ripe/unripe。正是这条流水线让在边缘运行 Azure Functions成为可能——你只需要把流水线中的镜像内容从分类器换成函数应用。作业任务把 Azure Functions 应用部署为 IoT Edge 容器模块作业的明确指令是从之前课程中选择一课尝试把其中的 Azure Functions 应用放到 IoT Edge 容器中运行。官方文档中提供了《Tutorial: Deploy Azure Functions as IoT Edge modules》Azure Functions 作为 IoT Edge 模块部署教程其中使用了一个不同的 Functions 项目展示了完整的操作方式可以按此思路迁移到本课的fruit-quality-detector场景。结合本课已有流水线推荐的实施路径如下1. 选定并改造一个 Functions 项目从本课程的前置课时例如4-manufacturing/lessons/2-check-fruit-from-device中创建的触发型 Functions中选一个项目作为改造对象。要点是函数触发逻辑保持不变但承载方式从云端 Functions 服务变为边缘容器函数容器与 IoT Edge 设备上其他模块运行在同一内部网络IoT 设备上报的遥测如水果图像或传感器数据可以在本地就被函数模块消费而不必绕行公网到云端再回来若函数需要接收 IoT 设备的消息可通过部署清单中的$edgeHub路由如upstream: FROM /messages/* INTO $upstream将消息流转到对应模块。2. 构建函数容器镜像并推送到注册表函数应用需要被容器化在 Functions 项目根目录添加 Dockerfile构建运行环境、拷贝函数代码、声明暴露端口然后使用与分类器完全一致的方式构建与推送docker build --platform platform -t Container registry name.azurecr.io/functionmodule:v1 . docker push Container registry name.azurecr.io/functionmodule:v1若边缘设备是 Raspberry PiARMplatform使用linux/armhfx86 环境使用linux/amd64若在边缘设备本机构建可省略--platform默认当前平台Linux 下可能需要sudo。3. 编写函数模块的部署清单在 deployment.json 的基础上把modules段中的业务模块从ImageClassifier替换为你的函数模块。以本课样例清单为模板需要注意的字段包括配置段字段作用与取值说明$edgeAgent.properties.desired.runtimetype固定为docker$edgeAgent.properties.desired.runtime.settingsminDockerVersion最低 Docker 版本样例为v1.25$edgeAgent.properties.desired.runtime.settings.registryCredentialsusername/password/address容器注册表登录凭据与地址地址形如容器注册表名.azurecr.ioIoT Edge 设备凭此拉取私有镜像$edgeAgent.properties.desired.systemModulesedgeAgent/edgeHub系统模块镜像样例使用mcr.microsoft.com/azureiotedge-agent:1.1与azureiotedge-hub:1.1edgeHub通过createOptions暴露 5671/8883/443 端口$edgeAgent.properties.desired.modules业务模块自定义模块名settings.image指向注册表中的函数镜像createOptions中通过ExposedPorts/PortBindings把容器内端口如 80映射到宿主机$edgeHub.properties.desired.routesupstream消息路由规则FROM /messages/* INTO $upstream表示把消息发往上游IoT Hub$edgeHub.properties.desired.storeAndForwardConfigurationtimeToLiveSecs消息离线暂存时长样例为7200秒替换其中三处Container registry name一处位于业务模块的settings.image两处位于registryCredentials段并把registryCredentials中的密码替换为你az acr credential renew得到的PASSWORD值然后执行az iot edge set-modules --device-id fruit-quality-detector-edge \ --content deployment.json \ --hub-name hub_name4. 验证函数模块在边缘运行部署完成后SSH 进入边缘设备执行iotedge list应能看到函数模块与edgeAgent、edgeHub一起处于running状态再用iotedge logs 函数模块名观察函数运行时日志例如 Functions 主机启动、绑定就绪、触发器注册等输出。随后即可让 IoT 设备向该模块的本地端点发送数据验证触发器能否被真实的数据流激活。评价标准什么样的实现才算合格本次作业的评分标准Rubric是判断实现质量最直接的依据完整继承如下标准优秀Exemplary合格Adequate需改进Needs Improvement将 Azure Functions 应用部署到 IoT Edge成功将 Azure Functions 应用部署到 IoT Edge并配合 IoT 设备用 IoT 数据触发了一次触发器成功将 Functions 应用部署到 IoT Edge但触发器未能被激活无法将 Functions 应用部署到 IoT Edge从这一标准可以反推出验收的三个关键里程碑能部署函数容器镜像成功推送部署清单下发后模块进入running状态能连通IoT 设备与函数模块在同一网络可达数据能送达模块端点能触发真实 IoT 数据而非手动调用成功激活函数中的触发器逻辑——这是优秀档的分水岭。其中触发器未能激活是最常见的失败模式排查时建议依次检查部署清单中的路由配置$edgeHub.routes是否正确、函数模块的端口映射是否可访问、函数触发的绑定类型与消息格式是否匹配以及iotedge logs中是否有报错或绑定失败记录。成本与清理提示Azure Container Registry 与云端 VM 均为收费服务本课中创建的注册表并非免费。作业完成后应参照仓库根目录的 clean-up.md 清理相关资源如果使用 vm-iotedge.md 创建的边缘虚拟机建议设置定时自动关机az vm auto-shutdown并注意az vm stop与az vm deallocate在计费上的区别——只有 deallocate 才会释放计算资源分配边缘容器默认不提供公有云那样的 API 密钥保护如分类器示例中调用/image无需 Prediction-Key安全性需要在内部网络中按实际需求自行配置。边缘化的取舍与分类器一致的收益与代价把 Functions 搬到边缘与把分类器搬到边缘有着完全一致的收益与代价详见课程 README 的相关章节收益数据不出本地网络隐私性更强、可离线工作、时延更低云资源用量下降可降低成本代价模块与云端项目如 Custom Vision 的 Predictions 面板不再自动同步——被边缘模块处理的数据不会出现在云端统计中模型或函数的迭代更新需要另行设计收集与再训练/再部署机制。这正是作业背后真正想让你体会的工程权衡云与边缘不是二选一而是按需混用——在云端训练、构建与治理在边缘执行与响应。总结本作业把 IoT-For-Beginners 课程中边缘化的思想从 AI 模型推广到了所有容器化工作负载只要能把代码装进容器就能借助 Azure IoT Edge 的模块机制把它部署到边缘。你在此过程中复用的注册表、部署清单、路由与验证手段构成了一个可迁移的通用边缘部署框架未来无论是 Functions、消息处理器还是其他服务都可以按同一套流水线落地。评价标准中成功部署 → 触发激活的递进关系也提醒我们边缘化的终点不是跑起来而是让真实业务数据在本地闭环流转起来。【免费下载链接】IoT-For-Beginners12 Weeks, 24 Lessons, IoT for All!项目地址: https://gitcode.com/GitHub_Trending/io/IoT-For-Beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
