后端前端企业应用运维网络安全【免费下载链接】fleetOpen device management项目地址https://gitcode.com/GitHub_Trending/fl/fleet点击查看免费下载GitOps 是一套工具与工作原则的组合把配置文件纳入版本控制并借助 CI/CD 与自动化能力持续将它们与目标系统的真实状态对齐。本文以 Fleet开源设备管理平台为例拆解 GitOps 的三大组件与四大收益并带你走一遍fleetctl new生成配置仓库 → 声明式 YAML → PR 评审 →fleetctl gitops自动应用的完整落地路径读完即可在自己的设备管理工作中应用 GitOps 思想。GitOps 是什么不止是 git而是一种思想GitOps是软件技术从业者与分析人员创造的一个术语用来描述一组工具和协作原则。把这些工具和原则组合起来应用就会得到强大的自动化工作流——它提供了一种让版本控制的配置文件持续与某个实体所声明的期望状态保持同步的方式。这里的实体可以是你想得到的任何能被修改的技术构造例如一份软件代码库code base一个装满云服务器的数据中心一个 Web 应用实际上任何能够通过命令、API 或 configuration-as-code配置即代码方式修改的技术对象都可以纳入 GitOps 的管辖范围。值得注意的是虽然 GitOps 的名字里带着 git但它远不止用 git 存文件这么简单它也不是一件拿来就能买的产品。GitOps 是一种思想——一套关于如何安全、可审计、自动化地变更系统状态的思维方式。正是这种思想让 Fleet 这样的设备管理平台能够以设备即代码devices as code的方式被管理。在 Fleet 中这套思想已经完整产品化官方文档 GitOps 配置参考 开篇就写道In Fleet, you can manage your devices as code.在 Fleet 中你可以把设备作为代码来管理。下面的内容就是围绕这句话展开的。GitOps 三大组件Git分布式版本控制与单一事实来源Git 是一个开源的、基于文本的分布式版本控制系统用于管理一组文件称为仓库 repository简称 repo的变更。Git 以命令行界面CLI二进制形式分发最初由 Linus Torvalds 于 2005 年前后创建用来追踪 Linux 项目的贡献。Git 的核心能力可以概括为几点非破坏性修改一个或多个贡献者可以反复向仓库添加、修改文件每次修改称为 commit都被保留可回溯的历史沿着提交历史时间线前后移动可以查看每个文件中每一次变更的内容任意版本可晋升文件历史中的任何一个版本都可以被提升为当前正确的版本——这就是回滚rollback能力的根基协作式审批对文件的工作通常通过一套审批系统协作完成。由此得到的产物是一个逻辑上由所有最新提交组成的仓库它代表系统的单一事实来源source of truth。谁改了什么、什么时候改的、为什么改全部有据可查。在 Fleet 的落地形态中这个事实来源就是由 fleetctl new 生成的 starter 仓库 或你自己搭建的 GitOps 配置仓库。仓库里放着default.yml全局配置、fleets/各团队/设备组配置、labels/、platforms/等目录全部以 YAML 声明式描述设备管理的期望状态。CI/CD小步快跑、持续交付CI/CD持续集成与持续交付/部署是一个概念极简单、力量却极大的实践假设一组贡献者能通过 git 之类的版本控制系统无摩擦地协作、不会互相覆盖彼此的工作那么理论上他们就能更快地工作、更频繁地提交并持续不断地交付。CI/CD 的精髓是偏爱小的、迭代式的、实时测试并快速推向生产的变更而不是持续数年、直到完美才肯发布的重构项目。这种思考方式对团队、产品与整个组织产生的影响不容低估——它把变更从一件高风险的大事拆解成一件件低风险的小事。自动化让已知良好的变更自动流向生产将 git 与 CI/CD 理念结合再借助 git 仓库管理平台如 GitHub Actions、GitLab CI/CD的自动化能力——自动合并变更、检查审批、运行验证与测试、最终把已知良好known-good的变更推送到目标生产系统——GitOps 就此诞生。自动化是 GitOps 的引擎任何脚本、任何代码、任何二进制都可以在云端几乎任意计算平台上运行。这正是 GitOps 工作流幕后魔法的来源。Fleet 的官方仓库里这个自动化引擎对应着fleetctl gitops命令实现见 cmd/fleetctl/fleetctl/gitops.go它被设计为Fleet 最佳实践 GitOps 工作流的载体fleetctl gitops [options]它常用的核心参数见 命令定义参数环境变量说明-f fileFILENAME必填。要应用的 GitOps 配置文件可多次使用-f传入多个文件--dry-runDRY_RUN只校验不应用用于 CI 中对 PR 的预检--delete-other-fleetsDELETE_OTHER_FLEETS删除不在 GitOps 配置中的其他 fleet团队别名--delete-other-teams--allow-unknown-keysALLOW_UNKNOWN_KEYS把未知 key 降级为警告而非报错GitOps 的四大收益GitOps 的广泛采用本身就是其价值的证明。以下是它最重要的几项通用收益收益一最小权限原则Principle of least privilege围绕 git 仓库建立护栏是刚需。Git 仓库管理平台允许所有贡献者创造价值同时支持指定 codeowners代码所有者——他们可以在破坏性提交造成问题之前将其拦下。这样生产系统的变更入口被收敛到一条受保护的管道上而不是散落在每个人手里的 UI 上。收益二协作与审计Collaboration and auditing由于提交到仓库的变更对其他贡献者可见GitOps 提供了 git 之外难以获得的协作机会仓库管理平台提供行内评论inline comments而 git 本身则对每一次变更记录改了什么、何时改的、谁改的。这套机制天生就是为发现与回滚而设计的——需要时随时可以把仓库恢复到之前的任意状态。在 Fleet 的设备管理场景里协作的载体就是 Pull Request。下面的截图展示了一个典型的 GitOps PR工程师从fedora-internal-ca分支向main提出变更所有检查包括 Apply latest configuration to Fleet 的 GitOps 应用检查通过后即可合并图源 managing-linux-desktops-with-gitops 系列文章图片收益三测试与验证Testing and validation在 Git 仓库管理平台的自动化 runner如 GitHub Actions、GitLab CI/CD上能做的事没有上限预部署检查、代码 lint、安全合规检查、组织标准检查……一切都可以在变更触达生产之前自动执行。能在 CI/CD runner 上执行校验正是 GitOps 背后的魔法。Fleet 的 CI 集成遵循这一模式在 PR 上运行fleetctl gitops --dry-run只验证不应用在合并到默认分支后运行正式应用。下面截图展示的是合并到main后触发的 Apply latest configuration to Fleet 工作流成功执行的结果图源 managing-linux-desktops-with-gitops 系列文章图片收益四信心与韧性Confidence and resilience强大的审计能力加上对任何系统的声明式控制应当带来修复问题与宕机所需工时的显著下降。因为维护 GitOps 系统中的代码比维护并监控一个图形界面GUI的状态要容易得多GitOps 还能降低目标系统的长期维护成本。Fleet 中的 GitOps 落地从思想到实践第一步用fleetctl new生成配置仓库Fleet 提供了开箱即用的起点。fleetctl new命令实现见 cmd/fleetctl/fleetctl/new.go会从内置模板生成一份 starter GitOps 仓库结构模板见 cmd/fleetctl/fleetctl/templates/new/fleetctl new --org-name 你的组织名 --dir it-and-security生成后的仓库包含对应 default.template.yml. ├── default.template.yml # 全局配置模板org_settings / mdm / controls 等 ├── fleets/ # 各 fleet团队/设备组的配置 ├── labels/ # 标签可用 path/paths 引用 └── platforms/ # 平台相关配置模板注释里还给出了关键提示org_settings.server_settings.server_url推荐写成$FLEET_URL通过仓库 secret 注入管理员 SSOsso_settings、设备端到端用户认证mdm.end_user_authentication等高级配置以注释形式给出示例取消注释即可启用。生成后README 会指导你完成后续三步在 GitHub 或 GitLab 上创建仓库并推送创建一个专用的 Fleet GitOps 用户并获取 API tokenfleetctl user create --name GitOps --email gitopsexample.com \ --password password --global-role gitops --api-only把FLEET_URL和FLEET_API_TOKEN配置为 GitHub secrets 或 GitLab CI/CD variables。提示fleetctl user create --api-only创建的是只能通过 API/GitOps 修改配置、无法登录 Fleet UI 的专用账号。若使用 Fleet Free 版请将该 API-only 用户的角色设为 global admin见 yaml-files.md Tips。第二步用声明式 YAML 描述设备期望状态GitOps 的核心是声明式配置系统期望状态被显式写成代码。在 Fleet 中这些是易于理解的 YAML 文件完整参考见 docs/Configuration/yaml-files.md主要支持labels、policies、reports、controls、software、org_settings等区块。一个含标签与策略的default.yml示例节选自 yaml-files.md 与 策略示例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 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 calendar_events_enabled: false conditional_access_enabled: true labels_include_any: - Engineering - Customer Support关键的声明式语义需要牢记详见 yaml-files.md 的 Tips重命名 fleet 时先在 UI 里改名再改 YAML——若只改 YAML该 fleet 会被删除其主机失去配置并变为 UnassignedYAML 中未定义的设置会被重置为默认值或删除例如软件包。这是 GitOps全量覆盖模式的特性配置文件就是完整状态labels、policies、reports、scripts、configuration_profiles支持path:单文件与paths:glob 通配两种引用方式路径总是相对于当前文件。还可以把策略做成补丁策略patch policyFleet Premium设置type: patch与fleet_maintained_app_slug策略查询会自动更新配合install_software/patch_when_closed可实现应用自动打补丁见 yaml-files.md 补丁策略。第三步通过 PR 评审让变更流向生产GitOps 之所以能防住周五下午手滑改坏 MDM这类事故靠的是把变更从一个人点几下界面改造成一个受评审的代码合并动作。典型流程详见 Preventing Mistakes with GitOps工程师从main切出分支修改 YAML例如给 Workstations fleet 设置 macOS 更新要求macos_updates: deadline: 2025-02-15 minimum_version: 15.4.1推送分支创建 Pull RequestCI 中运行fleetctl gitops --dry-run做只读校验团队成员评审、提出修改意见例如发现版本号尚不可用审批通过、合并到main触发正式应用工作流fleetctl gitops -f ...配置自动推送到生产出问题时回滚就是回退一次 git 提交。这里有一个非常典型的工程细节在 CI 的 PR 检查阶段使用--dry-run而合并到默认分支后执行真实应用。这与fleetctl gitops命令内部对 dry-run 的支持是一致的——在 gitops.go 中dry-run 模式下会校验重复的 enroll secret在 测试用例 里也有大量--dry-run场景的回归验证。第四步用 GitOps 模式锁住 UI防止两边打架当一部分人用 git 改配置、另一部分人习惯点 UI 时最怕的就是配置互相覆盖。Fleet 的解决方案是GitOps 模式GitOps mode详细介绍见 GitOps 模式指南开启后UI 中所有可由 GitOps 管理的功能变为只读UI 用户无法保存或编辑这些配置例如无法在 UI 中新建/编辑查询确保所有变更都走版本控制协议开启方式Settings Integrations Change management开启 GitOps 模式需要 Fleet Premium且必须填写一个合法的http(s)://仓库 URL服务端校验逻辑见 server/service/appconfig.go。下面截图展示了 GitOps 模式下查询编辑器中的 Save 按钮被禁用、并提示 Manage in YAML (GitOps mode enabled) 的实际界面图源 GitOps 模式文章例外Exceptions机制GitOps 模式允许你把 labels、software、enroll secrets 这三类资源豁免出 git 管理让它们继续在 UI 中维护。当某类资源被设为例外时该资源在 UI 中保持可编辑即使 GitOps 模式开启fleetctl gitops会保留现有这类资源未豁免时YAML 中省略 key 即删除它们若 YAML 中仍包含该资源的 keyfleetctl gitops会直接失败并提示移除 key 或禁用例外从机制上杜绝 UI 与 git 互相覆盖。Fleet 默认开启 enroll secrets 例外。例外机制对fleetctl gitops始终生效与 GitOps 模式是否开启无关。这一行为在源码中有清晰实现配置结构GitOpsConfig定义于 server/fleet/app.go包含GitopsModeEnabled、RepositoryURL与Exceptions{Labels, Software, Secrets}三个布尔字段客户端在DoGitOps入口处即做例外校验——当对应例外开启而 YAML 中又出现该 key 时返回带管理页面 URL 的明确报错见 server/service/client.go。从源码看fleetctl gitops的一次执行把以上实践落到命令本身一次fleetctl gitops执行在 gitops.go 中会依次完成可结合 集成测试 观察全流程参数与文件校验检查-f必填、文件名长度、no-team.yml/unassigned.yml二选一、不允许位置参数L106-L129许可证检查读取 AppConfig 并确认 license非 Premium 用户无法使用团队fleet配置L131-L142标签变更预计算computeLabelChanges提前算出每个文件的标签增删改检测同一标签被多个团队添加/删除等冲突并支持标签在团队间迁移computeLabelMovesL927-L971多文件编排全局配置default.yml类最先处理团队配置随后支持--delete-other-fleets清理多余团队逐文件应用调用DoGitOpsserver/service/client.go把spec.GitOps结构转换为各类 API 调用包括标签、策略、报告、MDM 控制、软件包等收尾删除标签等后置操作在应用完成后统一执行dry-run 模式以[!] gitops dry run succeeded收尾真实模式输出[!] gitops succeededL805-L809。这些设计让 PR 评审 → 合并 → 自动应用 的 GitOps 工作流在设备管理领域变得可靠、可审计、可回滚。文化与心态GitOps 改变的不只是技术正如 Fleet 设备管理工程师 Allen Houchins 在 What I have learned from managing devices with GitOps 中总结的GitOps 带来的收益远不止技术层面——它意味着声明式配置单一事实来源、减少配置漂移、随规模扩展、自动化简化部署与回滚自愈系统、回滚回退提交、安全与合规收益完整审计轨迹、职责分离、自动化校验、缩小攻击面、以及让跨职能团队说同一种语言。真正的 GitOps 采用还需要一场文化转变通过 PR 协作开发为变更建立自然的检查点留下谁要求了什么、为什么的清晰记录把代码评审作为质量门禁既防配置漂移也是老带新的绝佳机会自动化思维识别可自动化的手动流程持续打磨并以手动干预次数下降为 KPI文档即代码让文档与配置同居一库随系统演进保持新鲜持续学习文化事后复盘聚焦流程改进而非追责鼓励坦诚报告问题跨职能共担打破开发、运维、安全之间的筒仓让各方视角进入最终配置。总结GitOps 随时可用你不需要特殊的理由或产品今天就可以把 GitOps 思维应用到你的工作中——它可以被创造性地应用于几乎任何场景、任何技术领域。在设备管理领域Fleet 已经把它变成了一条完整的路径fleetctl new起步 → 声明式 YAML 定义状态 → PR 评审 CI 校验 →fleetctl gitops自动应用 → GitOps 模式锁住 UI 兜底。这套组合拳带来的是可观测、可回滚、可重复的设备管理工作流——把周五下午的灾难变成一条可审查的提交。想要继续深入仓库里还有两份配套资料值得一读Preventing Mistakes with GitOps完整工作流演练与 GitOps 模式指南UI 只读与例外机制详解。赞分享后端前端企业应用运维网络安全【免费下载链接】fleetOpen device management项目地址https://gitcode.com/GitHub_Trending/fl/fleet点击查看免费下载相关推荐Fleet 现代端点管理用 GitOps 将设备配置作为代码来治理Fleet 现代端点管理用 GitOps 将设备配置作为代码来治理 现代终端设备数量庞大、分布广泛、系统各异传统的控制台点击式click ops管理已难后端前端企业应用运维网络安全用 GitOps 管理设备集群来自 Fleet 的实践经验与配置指南用 GitOps 管理设备集群来自 Fleet 的实践经验与配置指南 导读 本文以 Fleet 开源设备管理平台为背景系统总结用 GitOps 方式管理设后端前端企业应用运维网络安全Fleet 开源设备管理平台深度解析从 MDM 到 GitOps 的统一设备管理与本地实战指南Fleet 开源设备管理平台深度解析从 MDM 到 GitOps 的统一设备管理与本地实战指南 Fleet 是一个面向拥有成百上千台计算机的 IT 与安全团队后端前端企业应用运维网络安全创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
