Chef Infra Client 19.4.46 介绍与选型指南

一、信息基准

• 查询日期：2026-10-18
• 版本依据：Chef 的核心开源组件是 Chef Infra Client，其源码仓库（github.com/chef/chef）Releases feed 显示最新版本 v19.4.46（更新时间 2026-10-14）。商业平台层为 Chef 360 Platform（Progress 旗下 chef.io 产品线），官方文档目前维护 1.0 至 1.7 的版本文档线（docs.chef.io 导航目录）。
• 许可现状（如实标注）：Chef 源码仓库标注 Apache-2.0；但官方许可页（docs.chef.io/licensing/）说明：使用 Chef 产品分发版前必须接受 Chef 最终用户许可协议（Chef EULA），且可能被要求添加许可密钥。开源源码与官方分发包采用不同许可口径，选型时需逐项确认。

二、软件概述

本文介绍的版本为 Chef Infra Client v19.4.46（2026-10-18 查询时的官方最新版）。

Chef 是基础设施自动化领域的老牌平台，现属 Progress 公司。其开源核心 Chef Infra Client 以"基础设施即代码"的方式管理服务器配置：把期望的系统状态写成 Cookbook（配方书）与 Recipe（食谱），由客户端在节点上周期性执行，将系统收敛到声明状态。围绕它还有 Chef Infra Server（策略与节点管理服务端）、Chef Workstation（开发工作站工具集）等组件。商业层 Chef 360 Platform 把基础设施管理、合规与作业编排统一到单一平台，提供 UI 驱动的自动化能力（官方产品页表述："Unify infrastructure, compliance, orchestration and more on one single platform"）。与 Ansible 等新锐相比，Chef 生态更偏重大规模、强工程化的配置管理，但学习门槛与许可口径的变化也更值得关注。

三、核心概念

3.1 资源（Resource）与配方（Recipe）

Resource 是 Chef 的最小抽象单元，每个资源声明"某项系统状态应当是什么"（如某个包已安装、某服务已启动），并保证幂等执行。Recipe 由一组资源按顺序组成，采用 Ruby DSL 编写。全部内置资源可在官方资源文档（docs.chef.io/resources/）查阅。

3.2 Cookbook

Cookbook 是 Recipe、属性、模板、文件等资产的分发单元，是 Chef 代码组织的最外层组织单元（逻辑上的"包"）。

3.3 客户端-服务器模式

Chef Infra Server 集中保存 Cookbook 与节点状态；节点上的 chef-client 定期拉取属于自己的策略并执行（称为 chef-client run 或 converge）；管理端用 knife 命令行工具与服务器交互。也支持无服务器的本地模式（local mode）直接在单机执行。

3.4 Ohai 事实采集

每次运行前，Ohai 采集节点的系统事实（操作系统、网络、内存等），作为属性供 Recipe 做条件判断。

3.5 Chef 360 Platform

商业平台层，在 Infra 之上提供节点纳管、作业编排、合规统一视图等企业能力；官方文档以独立版本线（1.0–1.7）演进。

四、功能特性

4.1 幂等资源模型

package、service、user、file、template、remote_file 等上百种内置资源覆盖常见系统管理任务，重复执行结果一致。

4.2 多平台支持

官方长期维护 Linux 各主流发行版与 Windows 的支持矩阵，适合异构混合环境。

4.3 合规即代码

与 InSpec 集成，在 chef-client run 的合规阶段执行安全基线扫描，把配置管理与合规审计放进同一套代码流程。

4.4 依赖与策略管理

支持 Policyfile 与 Berkshelf 管理 Cookbook 依赖，保证不同环境使用可复现的策略版本。

4.5 测试工具链

Test Kitchen 提供多平台沙箱验证，ChefSpec 支持对 Recipe 做单元测试，形成"测试先行"的基础设施代码工作流。

五、快速上手

以下最小示例引自官方资源文档的资源写法（docs.chef.io/resources/），表达"安装 nginx 并启动"的声明式配方：

# recipes/default.rb
package 'nginx'

service 'nginx' do
  action [:enable, :start]
end

在单机本地模式下验证该配方（无服务器路径，官方文档用法）：

chef-client --local-mode

说明：本地模式会在当前机器上执行 cookbooks 目录中的策略；生产环境则通常由 Chef Infra Server 或 Chef 360 平台统一下发。以上为官方文档所述流程，本文不做本地实测。

六、适用场景与限制

6.1 适用场景

• 大规模节点配置管理：数百上千台异构主机的持续配置收敛，Agent 模式适合长期漂移修正。
• 合规基线治理：结合 InSpec 把等保/CIS 基线写成代码并周期性校验。
• 多平台混合环境：Linux 与 Windows 并存、需统一管理 DSL 的组织。

6.2 限制

• 学习曲线陡峭：Ruby DSL 与客户端-服务器体系概念较多，上手成本高于 YAML 类工具。
• 许可口径需评估：源码 Apache-2.0，但官方分发包需接受 Chef EULA 并可能需要许可密钥；商业能力（Chef 360）为付费产品，商用前应完成法务与预算评估。
• 生态热度相对下降：社区注意力部分转向 Ansible 等工具，第三方 Cookbook 活跃度需按项目逐个确认。
• 单机小场景过重：几台机器的场景引入 Infra Server 体系并不划算。

七、同类选型对比

对比对象：Ansible（无代理、YAML）、Puppet（声明式 DSL、Agent 模式）、SaltStack（事件驱动、YAML+Jinja）。数据查询日期均为 2026-10-18，stars 取自 shields.io 徽章，最近发版取自 GitHub Releases feed。

选型建议：已有 Ruby 能力、追求强模型与合规代码化的超大规模环境，Chef 仍是可靠选择；团队追求低门槛与广泛社区生态，优先 Ansible；存量 Puppet/Salt 环境继续沿用即可，新项目不必单纯为"更现代"而迁移。

八、参考链接

1. Chef 官方文档：https://docs.chef.io/
2. 许可说明（Chef EULA 与许可密钥）：https://docs.chef.io/licensing/
3. 内置资源参考：https://docs.chef.io/resources/
4. Chef Workstation 文档：https://docs.chef.io/workstation/
5. GitHub 仓库（Chef Infra Client 源码）：https://github.com/chef/chef
6. Releases feed：https://github.com/chef/chef/releases.atom
7. Chef 360 Platform 产品页：https://www.chef.io/products/chef-360-platform
8. stars 数据徽章：https://img.shields.io/github/stars/chef/chef.svg