ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Fleet 与声明式设备管理(DDM):Apple 设备管理新范式的入门与实现指南

Fleet 与声明式设备管理(DDM):Apple 设备管理新范式的入门与实现指南 Fleet 与声明式设备管理DDMApple 设备管理新范式的入门与实现指南【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet本文以 Fleet 开源仓库中的声明式设备管理Declarative Device ManagementDDM技术资料为主体讲解 DDM 的核心概念、与传统 MDM 的本质差异、三大支柱声明、状态通道、可扩展性以及支持的 Apple 平台并结合仓库源码揭示 Fleet 如何交付、验证 DDM 声明、在数据库中如何存储与追踪其状态帮助你在组织中以渐进方式落地 DDM。什么是声明式设备管理DDMDDM 改变了托管设置在 Apple 设备上的部署与强制执行方式。传统 MDM 是命令式imperative的服务器不断向设备下发命令、轮询状态、确认结果每一次管理动作都要经历多轮网络往返。而 DDM 采用声明式范式管理员只需描述设备的“期望状态”设备自行检查自身状态并与声明比对在本地完成合规调整无需持续轮询管理服务器。Apple 在 2021 年的 Worldwide Developer Conference 上推出了 DDM。从 Fleet 仓库的架构文档 DDM Architecture 可以看到DDM 被描述为“对 MDM 协议的声明式扩展旨在规避传统 MDM 命令常见的性能与扩展性问题”。该协议被添加到既有的 Apple 设备管理协议之上——从源码结构看DDM 会话本身是通过传统 MDM 的DeclarativeManagement命令发起的因此 DDM 协议天然包含当前 MDM 协议覆盖的全部偏好域向后兼容。这带来两个直接后果DDM 声明与 MDM 配置文件可以同时下发到同一台设备而不产生管理冲突组织可以渐进式采用 DDM在过渡期内声明与现有 MDM 配置文件并行运行再逐步将配置迁移为声明。DDM 如何改变设备管理传统 MDM 遵循反应式模式服务器驱动每一个动作。以安装应用为例服务器发送安装命令并等待每台设备的确认然后回头查询安装是否开始、接收进度更新继续这场“对话”直到确认所有设备完成任务。查合规状态、更新配置、采集设备信息每一次交互都要经过网络通信、服务器处理和多阶段的设备响应。当设备规模从几十台扩展到数千、上万台时一个 MDM 服务器每天可能要处理数百万个独立请求管理服务器与网络都承受巨大负载。DDM 的核心思路就是把维护合规状态的责任交还给设备本身设备收到描述配置应然状态的“声明declaration”后从此自行检查并做出调整服务器不再需要持续轮询。DDM 的三大支柱Apple 将 DDM 建立在三个协同工作的核心概念上1. Declarations声明定义设备策略声明是 DDM 的构建块分为四种类型Configurations配置与现有配置文件类似定义设置、限制和账户细节Assets资产配置所需的引用数据如凭证、证书一次定义、多处引用避免跨配置复制数据Activations激活将配置分组并附加条件谓词决定配置何时、对哪些上下文生效Management declarations管理声明向设备传达组织信息与管理服务器能力。这种灵活性让组织可以构建随设备上下文自适应的管理策略一个配置可被多个激活引用一个激活可包含多个配置。2. Status channel状态通道设备主动上报状态通道反转了状态通信的方向不再是服务器轮询设备而是设备在状态变化时主动上报。管理服务器订阅它关心的状态项如系统版本、设备类型、合规状态订阅后先收到一份初始状态报告此后设备只在订阅项真正变化时才发送更新——设备不需要每次 check-in 都重复报告“我的系统仍是 iOS 17.2”。状态项还可以用于激活谓词activation predicates设备从 iOS 16 升级到 iOS 17 后可立即判断是否需要激活那些要求 iOS 17 的配置。3. Extensibility可扩展性面向未来的管理Apple 持续更新操作系统并新增管理声明类型。DDM 通过设备与管理服务器之间的能力感知capability awareness处理这些变化设备升级到新系统后告知服务器它支持的新特性服务器也告知设备新可用的声明类型组织无需协调大规模升级即可采用新能力。支持的 Apple 平台与要求DDM 自 2021 年引入以来支持范围不断扩展平台最低版本iOS16 及以后所有注册类型iPadOS15 及以后所有注册类型macOS13 Ventura 及以后tvOS16 及以后watchOS10 及以后这些要求意味着 DDM 需要相对较新的操作系统。组织在规划迁移前应先清点设备库存确认目标设备的系统版本达标。DDM 带来的收益性能与可扩展性设备不再需要持续轮询管理服务器负载下降——管理 10,000 台设备的服务器在传统 MDM 下每天可能处理数百万次 check-in 请求而 DDM 下设备只在状态实际变化时通信网络流量减少设置的强制执行也因不等待轮询周期而更高效。IT 运维效率设备自行处理日常合规强制管理开销下降基于 JSON 的声明格式让配置更易于构建与维护。Fleet 中 DDM 的实现从配置到验证的完整生命周期Fleet 支持管理员向 macOS、iOS、iPadOS 设备直接下发 DDM 负载DDM 配置文件可以存放在 GitHub、GitLab、Bitbucket 等 Git 仓库中通过 GitOps 工作流 完成评审、追溯与回滚Fleet 的 osquery 能力则在 MDM/DDM 状态之上提供近实时的“双重校验”报告。下面结合仓库源码深入这条链路。管理 DDM 配置文件UI、API 与 GitOps与 Fleet 中的其他自定义设置一样DDM 配置文件关联到某个 fleet或 “Unassigned”并可以通过标签条件应用于目标主机。UI所有自定义设置位于 “Controls → OS settings → Custom settings” 页面。Apple 传统.mobileconfig文件、Apple DDM.json声明和 Windows.xml文件都可以在这里上传与管理。REST APIGET/POST/DELETE /api/latest/fleet/configuration_profiles列出、创建、删除配置文件含 DDM 声明、GET /api/latest/fleet/configuration_profiles/summaryfleet 级状态统计、GET /api/latest/fleet/configuration_profiles/{profile_uuid}/status单个配置的状态统计以及POST /api/latest/fleet/hosts/{host_id}/configuration_profiles/{profile_uuid}/resend向特定主机重发某个 DDM 配置文件。需注意批量重发端点/resend/batch不支持 DDM 声明只能走单主机重发。GitOps通过fleetctl gitops的 YAML 管理controls: macos_settings: custom_settings: - path: ../lib/macos-profile1.mobileconfig labels_exclude_any: - Macs on Sequoia - path: ../lib/macos-profile2.json labels_include_all: - Macs on Sonoma.json条目即 DDM 声明支持labels_include_all/labels_include_any/labels_exclude_any标签定向。gitops命令通过POST /api/latest/fleet/mdm/profiles/batch端点整体替换当前 fleet 的配置文件集合YAML 中存在的被更新或新增不存在的被移除。存储如何在数据库中区分声明与配置文件DDM 声明存储在mdm_apple_declarations表中主键为declaration_uuid。从源码 server/fleet/mdm.go 可以看到Fleet 通过在生成的 UUID 前加前缀来区分配置文件类型MDMAppleDeclarationUUIDPrefix d // DDM 声明 MDMAppleProfileUUIDPrefix a // Apple .mobileconfig 配置文件 MDMWindowsProfileUUIDPrefix w // Windows 配置文件 MDMAndroidProfileUUIDPrefix g // Android 配置文件因此只需拿到一个 UUID 就能判断它属于哪类配置文件、到哪张表去查。另外同一 fleet 内配置文件名称必须在跨平台、跨类型范围内唯一这一约束在 docs 架构文档 中有说明由于不同类型存储在不同表中无法用标准数据库约束实现。交付ReconcileAppleDeclarations 与 DeclarativeManagement 命令DDM 配置的交付由定时任务驱动。server/mdm/apple 中的声明协调逻辑ReconcileAppleDeclarations负责把 DDM 声明发生变更的主机标记为 “pending”然后入队一条DeclarativeManagementMDM 命令。关键在于DDM 协议构建在传统 MDM 协议之上必须通过DeclarativeManagement命令“点火”才能启动 DDM 会话——这与 WebSocket 需由标准 HTTP 请求发起类似。只对声明有变更的主机下发该命令是一种优化对无变化的主机下发只会得到“无需变更”的结果若把它们也标记为 pending 反而会让它们卡在该状态。此外该协调逻辑还处理host_mdm_apple_declarations表中的resync字段用于修复“安装 pending 但被标记为移除 pending”这类竞态安装会直接过渡到 verified既然能被标记为移除 pending说明它已经装上再标记该配置为需重同步确保删除场景下状态最终一致。完整的协议交互时序在 架构文档 的 mermaid 图中给出概要为服务器侧ReconcileAppleDeclarations定时任务运行入队DeclarativeManagement命令经 APNs 推送通知设备设备通过 MDM 协议 check-in接收DeclarativeManagement命令设备依次发起 DDM 消息tokens→declaration-items→declaration/activation/{id}→declaration/configuration/{id}服务器逐一响应设备发送status消息上报声明状态服务器据此将声明标记为 verified 或 failed。值得注意的是设备也会不定期自行发起DeclarativeManagement会话以确保与服务器同步——这正是“设备负责维护自身状态”理念的体现。验证DDM 端点消息如何被处理DDM 协议由 server/mdm/nanomdm 包处理该包通过 HTTP 回调到 Fleet 实现的DeclarativeManagement接口。Fleet 的实现位于 server/service/apple_mdm.go协议消息按请求中的Endpoint字段分派到不同处理函数全部消息会存入mdm_apple_declarative_requests表以供审计。源码中可见端点分派的分支结构case dm.Endpoint tokens: svc.logger.DebugContext(r.Context, received tokens request, scope, scope) ... case dm.Endpoint declaration-items: svc.logger.DebugContext(r.Context, received declaration-items request, scope, scope) ...各端点操作的具体含义tokens为整组待下发声明生成同步令牌synchronization token。令牌生成逻辑较复杂对主机的每条声明计算内容哈希再把所有声明的令牌排序按上传时间、UUID 稳定排序后拼接哈希得到全局令牌。该令牌与主机当前已应用变更的令牌比对决定主机是否需要接收声明——内容没变就不下发这是省流量的核心。declaration-items下发应安装声明的清单只携带各声明的单个令牌与激活令牌。Fleet 用“差集”实现删除某条声明不出现在清单中设备就会自行移除它。所有配置都会创建对应的 activation 以便应用。设备根据令牌比对出缺少的声明在后续步骤按需索取完整内容。declaration/configuration/{uuid}返回对应声明的完整 JSONFleet secrets 在此按需展开。declaration/activation/{uuid}返回对应 activation 的完整 JSON。activation 可用谓词条件化应用配置Fleet 当前发送的是无条件 activation。status接收主机上的 DDM 声明状态报告。声明有效则标记为 “verified”无效则 “failed”。据实现中的研究注释设备不会主动发送 “remove” 状态而是通过“该声明未出现在状态报告中”来检测删除。状态报告的端点按 Apple 规范还可携带动态设备状态如电池健康、证书变化Fleet 目前仅用它更新声明状态。除了 DDM 协议内的status消息Fleet 还会从传统DeclarativeManagement命令的响应中批量更新状态完成从 “pending” 到 “verifying” 或 “failed” 的初始过渡——相关逻辑可在 server/service/apple_mdm.go 中查看测试用例覆盖见 server/service/apple_mdm_ddm_test.go 与 server/service/integration_mdm_ddm_test.go。Fleet 对 DDM 的支持范围与限制理解这些边界对编写可用的声明很重要实现校验位于 server/fleet/apple_mdm.go 的声明验证逻辑中DDM 声明必须是 configuration 类型不能包含操作系统更新设置——OS 更新由 Fleet 的 “Controls → OS updates” 设置统一处理不能是需要 assets 的声明类型assets 当前不支持不能是 “status subscription” 类型支持标签定向include any / include all / exclude any支持Fleet secrets下发时展开为实际值支持以下 Fleet 变量$FLEET_VAR_HOST_HARDWARE_SERIAL、$FLEET_VAR_HOST_END_USER_IDP_USERNAME、$FLEET_VAR_HOST_END_USER_IDP_USERNAME_LOCAL_PART、$FLEET_VAR_HOST_END_USER_IDP_GROUPS、$FLEET_VAR_HOST_END_USER_IDP_DEPARTMENT、$FLEET_VAR_HOST_END_USER_IDP_FULL_NAME、$FLEET_VAR_HOST_UUID、$FLEET_VAR_HOST_PLATFORM系统/用户通道仅 macOS声明可通过 Fleet 专有顶层键PayloadScope选择下发到设备通道System默认或用户通道User。Fleet 在上传时解析并记录该通道但会保留在存储的raw_json中使声明可往返、内容哈希能反映通道变化只在服务给设备时剥除保证设备收到的仍是合法的 Apple DDM JSON。与遗留 MDM 共存及迁移规划DDM 的设计目标是与 MDM 共存而非取代。配置文件与 DDM 声明可同时存在于同一台设备组织可以把现有 MDM 配置文件原样保留也可以按需重写为 DDM 声明。当 MDM 配置文件与 DDM 声明包含相同设置时DDM 优先——这一优先级专门适用于软件更新配置与 App 管理。组织可以选择性迁移例如只把软件更新策略转为声明其余配置保留为传统配置文件。共存期可长可短Apple 意在扩展 DDM 能力的同时继续支持遗留 MDM 配置文件。迁移规划建议优先识别收益最大的策略。软件更新是好的起点——Apple 为更新构建了较强的 DDM 支持收益也最直接。选择起点后尽早规划测试方案使用能代表整个机队行为的试点组或预发环境避免一开始就影响全部终端用户如果管理方案支持用激活谓词定向到特定设备类型或系统版本。落地步骤检查设备库存确认设备满足操作系统版本要求选择一个简单且高影响的用例如软件更新强制执行作为首次实施向小型试点组部署并监控状态通道的报告根据早期结果逐步扩大到更大的设备组。度量成效部署后应将新旧方案对比度量。若方案支持状态通道可用其报告量化设备通信量的下降服务器指标会体现基础设施收益更低的 CPU 利用率、更小的内存消耗、更少的网络带宽控制执行的提速在报表中也会显现。常见问题Fleet 服务器部署在本地on-prem时能否下发 DDM 配置可以。Fleet 可部署在任何地方包括自有基础设施且始终完整支持 Apple 的 MDM 与 DDM 规范不存在“仅云端实例才支持 DDM”的限制。DDM 与遗留 MDM 配置文件冲突时怎么办Apple 通过优先级规则处理当配置文件与 DDM 声明包含相同设置时软件更新配置与 App 管理上 DDM 优先其他设置上Apple 会合并冲突策略并执行最严格的配置与传统 MDM 处理重叠设置的多个配置文件的方式类似。为什么我的 DDM 声明没有应用到设备排查三类常见原因一、确认设备系统版本支持所用声明类型二、确认设备在注册过程中成功启用了 DDM通过注册时的激活命令三、仔细检查激活谓词——只有关联的所有 activation 都求值为 true声明才会应用。从传统 MDM 迁移到 DDM 通常要多久时间取决于组织规模与复杂度。多数组织采取渐进方式先用一到两个月迁移软件更新再转向账户配置与安全策略。DDM 与遗留 MDM 的共存意味着没有强制时间线可以按组织的资源与风险承受能力快慢自行掌握。开始实施 DDM 的最简单方式是什么从小型试点组的软件更新强制执行开始——它收益立现且 Apple 支持度高。在 Fleet 中你可以在 Custom settings 页面直接上传 DDM JSON 声明或用 GitOps 仓库 fleetctl gitops管理并通过 API 的 status 端点与 osquery 实时查询双重监控声明的下发结果。参考资料Fleet DDM 架构文档DDM 生命周期、协议时序图、数据库细节与已知限制YAML 文件配置参考custom_settings等 GitOps YAML 结构说明server/service/apple_mdm.goDDM 端点消息处理与状态更新的核心实现server/fleet/mdm.go配置文件 UUID 前缀常量定义server/mdm/nanomdm/service/nanomdm/dm.goDDM 会话的 HTTP 调用封装server/service/integration_mdm_ddm_test.goDDM 集成的端到端测试【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表