Fleet 现代端点管理用 GitOps 将设备配置作为代码来治理【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet现代终端设备数量庞大、分布广泛、系统各异传统的控制台点击式click-ops管理已难以支撑跨 macOS、Windows、Linux 的大规模设备治理。本指南围绕 Fleet 的 GitOps 实践讲解如何把设备配置定义成版本化、可评审、可回滚的 YAML 代码借助fleetctl命令与 CI/CD 流水线实现自动化下发与持续合规。读完本文你将掌握设备即代码Devices as Code的核心思想、Fleet GitOps 仓库的结构与核心 YAML 区块、fleetctl gitops的实际用法以及如何用策略与自动化闭环检测和修复配置漂移。传统设备管理为何失效现代设备集群device fleets规模大、分布广、持续变化。员工在家庭、办公室和移动环境中工作IT 团队必须跨多个操作系统管理数千台设备。而传统工具是为一个更简单的世界设计的它们依赖手工工作流、集中式网络和 GUI 驱动的管理。原白皮书 articles/modern-endpoint-management-managing-devices-as-code.md 列出了传统模式最常见的四类问题企业网络之外的设备可见性有限远程与移动设备难以被集中监控手工更新无法在大规模集群上扩展逐台点击操作的成本随设备数线性增长影子 IT 与过时清单造成安全缺口未被纳管的设备成为攻击面合规报告与审计准备缓慢需要从分散的控制台日志中重建变更历史。这些挑战使 IT 团队难以在设备集群上维持安全性与一致性。问题的根源在于传统管理是反应式的——先出现问题再逐一修补。新范式将设备作为代码管理现代基础设施早已在用代码管理。服务器、网络、云环境都被定义为受版本控制的配置文件。同样的思路如今也适用于设备管理借助基础设施即代码Infrastructure as Code与 GitOpsIT 团队把设备配置定义在代码中、存储在 Git 仓库里通过拉取请求Pull Request评审变更再自动应用到整个设备集群。这种做法的四个核心收益原文档要点设备配置的单一事实来源single source of truth一切期望状态都收敛在 Git 仓库每次变更都有完整版本历史谁改的、何时改的、改了什么、为什么改一目了然自动化部署与回滚合并即生效一条git revert即可回退有问题的变更安全策略的持续强制策略不依赖人工抽查而是按固定节奏自动比对与执行。团队从出了问题再反应转向定义期望状态让自动化去强制它。这正是 Fleet GitOps 工作流的设计哲学。Fleet 的 GitOps 参考文档开宗明义In Fleet, you can manage your devices as code在 Fleet 中你可以将设备作为代码管理见 docs/Configuration/yaml-files.md。GitOps 在设备管理中的角色从理念到四原则articles/the-gitops-idea.md 指出GitOps 是由软件技术实践者与分析师提出的一组工具和工作原则它将版本控制文件与自动化结合声明某个实体的期望状态。它不止于使用 Git 本身而是一整套工作方式。articles/gitops-for-device-management.md 进一步把 GitOps 概括为四个核心原则这些原则同样适用于设备管理原则在设备管理中的体现声明式配置Declarative configurationYAML 描述期望的最终状态而非达成步骤例如所有 macOS 主机必须开启 FileVault版本化状态Version-controlled state配置定义存放在 Git形成详尽变更历史可回溯、可审计自动化部署Automated deployment变更评审合并后由 CI/CD 或原生集成自动下发到目标设备组持续调和Continuous reconciliation策略按固定节奏比对设备实际状态与 Git 中的期望基线在审计周期之间发现并纠正漂移对 IT 团队而言这套工作流带来的实战优势非常具体配置以可评审文件形式存在可精确查看两个版本间的差异、谁批准了合并团队成员通过 PR 提出变更形成天然的评审门禁跨平台安全基线可以用同一套流程标准化落地灾备方面多数设备配置可从仓库内容重建而证书、令牌与注册状态存放在 Git 之外仍需单独的备份流程。快速上手用 fleetctl 生成 GitOps 起始仓库Fleet 为 GitOps 提供了开箱即用的工具链。快速开始的方式是安装fleetctl命令行工具然后运行fleetctl new该命令会生成一个完整的起始仓库starter repository其中包含 GitOps 所需的标准目录结构与示例文件。fleetctl new生成的模板说明见 cmd/fleetctl/fleetctl/templates/new/README.md。典型的 GitOps 仓库采用如下布局路径均相对仓库根目录default.yml # 全局配置All fleets fleets/ fleet-name.yml # 单个设备组fleet的配置 unassigned.yml # 未分配设备组的配置 lib/ labels/*.labels.yml # 标签定义可拆分为独立文件 policies/*.policies.yml # 策略定义 reports/*.reports.yml # 报告定义 *.mobileconfig / *.xml / *.json # 配置描述文件 *.sh / *.ps1 / *.py # 脚本 *.package.yml # 软件包定义这个仓库本身就是你的单一事实来源default.yml管理全局组织设置org_settingsfleets/下的文件管理具体设备组的设置settings与设备组专属资源lib/则存放可被多处引用的共享资源文件。核心命令fleetctl gitops将仓库中的声明式 YAML 应用到 Fleet 实例靠的是fleetctl gitops命令。它的实现位于 cmd/fleetctl/fleetctl/gitops.go其命令行定义UsageText: fleetctl gitops [options]支持以下关键参数参数环境变量说明-f必填可多次FILENAME要应用的 GitOps 配置文件一次运行可传多个文件每个文件用单独的-f指定--dry-runDRY_RUN只校验、不应用。PR 校验和 CI 预检的核心开关--delete-other-fleetsDELETE_OTHER_FLEETS删除配置中未出现的其他设备组原--delete-other-teams已更名见源码中的兼容处理--allow-unknown-keysALLOW_UNKNOWN_KEYS将未知 YAML 键降级为警告而不是报错失败实际调用示例# 校验仓库中的配置不真正应用 fleetctl gitops -f default.yml -f fleets/unassigned.yml --dry-run # 正式应用生产环境 fleetctl gitops -f default.yml -f fleets/fleet-name.yml从源码可以看到几个值得注意的行为约束-f必须显式指定-f must be specified不接受位置参数一次运行只允许一个全局配置文件unassigned.yml原no-team.yml在一个运行中只能出现一次且旧文件名会输出弃用提示。源码还实现了跨文件一致性校验例如如果任一文件启用了终端用户认证end user authentication则本次运行或服务端当前状态中必须存在完整配置的 IdP否则运行失败——这防止了部分应用导致 ADE 注册被锁定的问题对应 issue #43371 的修复。测试用例 cmd/fleetctl/fleetctl/gitops_test.go 中大量使用--dry-run验证各种 YAML 组合例如TestGitOpsBasicGlobalFree用runAppForTest(t, []string{gitops, -f, tmpFile.Name(), --dry-run})校验最小全局配置的合法性与幂等性。在 CI/CD 中运行PR 评审 自动部署fleetctl new生成的模板同时提供了 GitHub Actions 与 GitLab CI 的流水线配置让 GitOps 真正跑起来。核心逻辑详见模板 README推送新提交到默认分支时自动执行Apply latest configuration to Fleet工作流把合并后的配置应用到 Fleet针对拉取请求工作流只执行 dry-run验证配置合法性而不影响生产流水线运行前必须配置两个凭据FLEET_URLFleet 实例地址如https://organization.fleet.com和FLEET_API_TOKENGitOps 专用令牌在 GitHub 中配置为 Secrets、在 GitLab 中配置为 CI/CD VariablesGitLab 用户还可以创建定时流水线如每日 6AM UTC 的0 6 * * *即使没有新提交也能定期同步确保配置始终与仓库一致。这样每一次配置变更都经过提交 → PR 评审 → CI 校验dry-run→ 合并 → 自动应用的完整链路变更历史天然内建在 Git 提交记录与 PR 讨论中。把期望状态写成代码核心 YAML 区块Fleet GitOps 的能力核心在于一系列声明式 YAML 区块。下面按 docs/Configuration/yaml-files.md 的完整参考逐一介绍最常用的几个。labels设备分组与定向标签用于给设备分组支持dynamicSQL 查询自动匹配、manual手工指定主机和host_vitals按主机健康数据匹配三种成员类型可配置platform过滤darwin、windows、linux、ubuntu、centos# default.yml labels: - name: Arm64 platform: darwin description: macOS hosts on the Arm64 architecture query: SELECT 1 FROM system_info WHERE cpu_type LIKE arm64% OR cpu_type LIKE aarch64% label_membership_type: dynamic - name: C-Suite description: Hosts belonging to the C-Suite label_membership_type: manual hosts: - IR7M6ZGQJM - JMFWY8VZ09注意labels键的省略行为取决于Settings Integrations Change management中的 labels 例外开关。例外关闭时YAML 中未列出的既有标签会在下一次 GitOps 运行中被删除例外开启时标签改由 UI 管理YAML 中若出现labels键反而会导致运行失败。标签也可拆分为独立文件并用path:/paths:引用labels: - path: ./lib/labels-name.labels.yml - paths: ./lib/labels/*.ymlpolicies策略与自动修复策略是 GitOps 持续合规的引擎通过 osquery SQL 查询定义设备应该满足什么状态支持platform、critical、labels_include_any/labels_exclude_any定向等字段# fleets/fleet-name.yml policies: - name: macOS - Enable FileVault description: This policy checks if FileVault (disk encryption) is enabled. resolution: As an IT admin, turn on disk encryption in Fleet. query: SELECT 1 FROM filevault_status WHERE status FileVault is On.; platform: darwin critical: false labels_include_any: - Engineering - Customer Support策略与自动化联动是闭环修复的关键Fleet Premium 能力策略失败时可自动安装软件install_software支持自定义包路径、Fleet 维护应用 slug 或 SHA256 哈希或运行修复脚本run_script.pathpolicies: - name: macOS - Firefox installed platform: darwin query: SELECT 1 FROM apps WHERE bundle_identifier org.mozilla.firefox continuous_automations_enabled: true install_software: package_path: ./firefox.package.yml - name: macOS - Disable guest account platform: darwin query: SELECT 1 FROM managed_policies WHERE domaincom.apple.mcx AND username AND nameDisableGuestAccount AND CAST(value AS INT) 1; run_script: path: ./disable-guest-account.sh还有一类补丁策略patch policy将type设为patch并指定fleet_maintained_app_slug策略查询会随应用元数据自动更新设备未运行最新版本即判定失败配合install_software: true无论应用是否打开都自动修补或patch_when_closed: true仅在应用关闭时修补并自动重试即可实现自动化补丁管理。controls脚本、MDM 与系统更新controls区块集中管理脚本与设备管理MDM能力包括磁盘加密强制、各平台 OS 更新、配置文件下发、主机命名模板、安卓 MDM 开关等controls: scripts: - path: ../lib/macos-script.sh - paths: ../lib/scripts/*.sh # glob仅匹配 .sh/.py/.ps1 enable_disk_encryption: true macos_updates: minimum_version: 15.4.1 # 或 latest deadline: 2025-07-01 update_new_hosts: true apple_settings: configuration_profiles: - path: ../lib/macos/profiles/ddm.json labels_include_any: - Engineering windows_settings: configuration_profiles: - paths: ../lib/windows/profiles/*.xml各平台的更新参数都支持minimum_version具体版本号或latestdeadlineYYYY-MM-DD具体版本号时必填/deadline_days自动更新时必填的组合Windows 另有deadline_days与grace_period_days。配置文件支持labels_include_all/labels_include_any/labels_exclude_any三种定向方式未指定时面向全部主机。software软件分发software区块定义要安装的软件覆盖自定义包.pkg/.ipa/.msi/.exe/.deb/.rpm/.tar.gz 及脚本包、App Store / Play Store 应用app_store_idplatform与 Fleet 维护应用fleet_maintained_appsslug。支持self_service终端用户自助安装、labels_include_any定向、categories自助服务分类与setup_experience注册时安装等选项software: packages: - path: ../lib/software-name.package.yml self_service: true setup_experience: true app_store_apps: - app_store_id: 546505307 platform: ios auto_update_enabled: true auto_update_window_start: 00:00 auto_update_window_end: 04:00 fleet_maintained_apps: - slug: slack/darwin version: 4.47.65 self_service: true自定义包默认使用基于 ETag 的条件下载首次运行时缓存服务器 ETag后续运行发送If-None-Match服务端返回 304 即跳过下载以加速 GitOps 运行若服务器不支持 ETag可设置always_download: true强制每次重新下载。配合hash_sha256可做哈希锁定哈希一致则跳过下载、不一致则报错。org_settings全局组织设置org_settings管理全局组织级配置如 SSOsso_settings、主机过期host_expiry_settings、webhook 自动化webhook_settings、特征开关features、GitOps 模式本身gitops.gitops_mode_enabledrepository_url等org_settings: features: enable_host_users: true enable_software_inventory: true webhook_settings: failing_policies_webhook: enable_failing_policies_webhook: true destination_url: https://example.org/webhook_handler host_batch_size: 0path 与 paths文件引用两种方式scripts、configuration_profiles、labels、policies、reports均支持单文件与 glob 两种引用path:引用单个文件文件名不得包含*、?、[、{paths:接受 glob 通配模式批量匹配如../lib/windows/profiles/*.xml标签等选项会应用到所有匹配文件。所有路径都相对当前编辑的 YAML 文件所在目录解析注意与仓库根目录相对路径区分。同一条目不能同时指定path与paths。从点击操作到代码管理两种模式的对比把传统 GUI 管理与代码化管理并列来看对应原白皮书的核心对比主题维度手动 / GUI 驱动代码化 / GitOps变更记录分散在控制台审计日志常缺为什么Git 提交历史天然记录 who / when / what / why评审门禁无或依赖事后审批PR 评审内建于工作流回滚手动逐项还原git revert一键回退规模化随设备数线性增长声明式定义一次自动下发到全部目标合规证据审计前临时收集每次日常工作自动沉淀一致性依赖个人操作纪律声明式基线 持续调和强制需要说明的是GitOps 并不意味着放弃控制台。正如 articles/gitops-for-device-management.md 指出的控制台用于日常快速查看与临时调整而重大配置变更走版本控制Fleet 的 UI、REST API 与 GitOps 三种管理方式共享同一套配置语义UI 中可配置的内容同样能以 YAML 定义。漂移检测、审计与持续合规配置漂移configuration drift指设备实际状态偏离文档化基线是审计失败的高发原因。GitOps 通过两层机制应对合并前校验——CI 流水线对 PR 中的 YAML 做 dry-run提前拦截违反基线的变更部署后持续评估——策略按固定节奏在设备上运行比对实际状态与期望基线。当设备未通过策略时Fleet 可自动运行修复脚本或安装所需软件并重试而不是等待管理员人工排查从而在审计周期之间就闭环检测 → 修复。对合规团队Git 提交历史与 PR 批准链构成防篡改tamper-evident的变更记录每个提交记录了变更者、时间、具体内容与理由可同时支撑 SOC 2 的变更管理与逻辑访问控制、HIPAA 的访问与审计控制、FedRAMP 的配置基线与变更控制等要求一套证据覆盖多个框架。关于框架对照的完整分析可参考 articles/gitops-for-device-management.md。实战最佳实践与注意事项结合 docs/Configuration/yaml-files.md 末尾的 Tips 与源码实现以下几点直接影响生产可用性为 GitOps 创建专用 API 令牌使用fleetctl user create --api-only创建仅限 API 的用户这类用户能通过 GitOps 修改配置但不能访问 Fleet UI再在 UI 中分配 GitOps 角色与全局/设备组作用域。敏感值用环境变量注入YAML 中可引用$ENROLL_SECRET、$JIRA_API_TOKEN、$FLEET_SECRET_*等变量避免把令牌明文提交进仓库。GitOps 运行时会解析这些环境变量源码中的SaveEnvSecrets/GetGitOpsSecrets即负责此逻辑。未定义的设置会被重置或删除YAML 中未列出的设置项会恢复默认值或删除例如软件包。这意味着仓库必须是完整的期望状态而不是增量补丁。例外情况是host_expiry_settings与smtp_settings未定义时不会被重置。重命名设备组先改 UI 再改 YAML只改 YAML 会导致设备组被删除、主机变成 Unassigned 并丢失设置。运行前先 dry-run在 CI 中对每个 PR 执行fleetctl gitops --dry-run把配置错误拦截在合并之前正式应用前也可本地先跑一遍确认输出符合预期。结语从手工更新、GUI 点击、分散清单到声明式 YAML、Git 评审、自动调和设备管理正在经历与应用部署同样的基础设施即代码变革。Fleet 将这一范式原生内置fleetctl new生成起始仓库fleetctl gitops将声明式配置应用到跨平台设备集群策略引擎持续比对实际状态与期望基线并自动修复。设备配置从此像代码一样可评审、可回滚、可审计——这正是现代 IT 团队在大规模、多平台、强合规压力下规模化治理设备的路径。想深入了解每个 YAML 区块的全部可选参数可继续阅读 docs/Configuration/yaml-files.md想追查命令的底层实现与校验逻辑可研读 cmd/fleetctl/fleetctl/gitops.go 及其测试用例 cmd/fleetctl/fleetctl/gitops_test.go。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
