1. 从手动到自动为什么我最终选择了Puppet干了七八年运维前几年我一直觉得“自动化配置管理”是个伪命题。服务器数量少的时候手动SSH上去改改配置文件、装装包几分钟搞定何必折腾什么自动化工具直到有一次一个线上环境因为某台机器的Nginx配置被人手动改过导致负载均衡策略失效排查了整整一个下午才定位到问题。那次事故之后我开始认真审视配置管理这件事。Puppet是我接触的第一款配置管理工具也是目前团队里跑得最稳的一套方案。它的核心逻辑其实不复杂你用一种叫Manifest的描述性语言把“服务器应该长什么样”写清楚Puppet负责把机器拉到那个状态。跟Shell脚本最大的区别在于Shell脚本是“过程式”的——你先执行A再执行B中间任何一步出错都可能留下烂摊子而Puppet是“声明式”的——你只描述最终状态它自己决定怎么达到而且反复执行结果一致这就是所谓的幂等性。这篇文章适合谁看如果你手里管着十几台以上的服务器经常因为配置不一致、环境漂移、手动操作失误而头疼那Puppet值得你花时间研究。如果你只是管一两台机器说实话Ansible可能更轻量但Puppet的思想依然值得了解。我会从架构设计、核心概念、实操步骤、常见坑几个维度展开尽量把我在实际项目中踩过的坑和总结的经验都倒出来。2. Puppet的核心架构与关键概念拆解2.1 Agent/Master架构到底怎么选Puppet有两种运行模式一种是Agent/Master模式一种是单机模式也叫Masterless。很多人一开始纠结选哪个我的建议是先搞清楚你的规模。Agent/Master模式下所有被管理的机器上跑一个Puppet Agent进程定期默认30分钟向Puppet Master发起请求拉取自己的Catalog可以理解为该机器的配置清单然后在本地执行。Master端集中存放所有Manifest和模块。这种模式适合机器数量多、需要集中管控的场景缺点是Master可能成为单点需要做高可用。单机模式则是把Manifest直接放在被管理机器上用puppet apply命令本地执行。没有Master没有证书认证部署简单适合机器数量少或者临时环境。我早期做测试环境就是用单机模式后来机器上了50台之后才切到Agent/Master。注意Agent/Master模式下证书认证是第一个拦路虎。Agent第一次连接Master时会请求证书Master需要手动或自动签发。如果证书没签Agent会一直卡在等待状态日志里能看到“Waiting for certificate”之类的提示。2.2 Manifest、Resource、Class、Module的关系这四个概念是Puppet的骨架必须搞清楚。Resource是最小配置单元。比如一个文件、一个用户、一个服务、一个软件包都是Resource。每个Resource有类型type、标题title和一堆属性attribute。举个例子file { /etc/nginx/nginx.conf: ensure file, owner root, group root, mode 0644, content template(nginx/nginx.conf.erb), }这段代码声明了一个文件资源Puppet会确保这个文件存在、属主属组正确、权限正确、内容来自指定模板。如果文件已经存在且内容一致Puppet什么都不做——这就是幂等性。Manifest就是包含一个或多个Resource的文件后缀是.pp。Class是把相关Resource打包在一起的容器可以理解成编程里的函数。Module是Class、文件、模板、事实Facts的集合有固定的目录结构。实际项目中我们几乎不会把所有东西写在一个Manifest里而是按功能拆成Module比如nginx模块、mysql模块、users模块。2.3 目录结构长什么样一个标准的Module目录结构是这样的nginx/ ├── manifests/ │ ├── init.pp │ ├── config.pp │ └── service.pp ├── templates/ │ └── nginx.conf.erb ├── files/ │ └── nginx.repo ├── tests/ │ └── init.pp └── metadata.jsonmanifests/init.pp是入口文件里面定义的Class名字必须和模块名一致。templates放ERB模板files放静态文件。这个结构不是随便定的Puppet的自动加载机制依赖它。你如果把文件放错位置Puppet会报“Could not find template”之类的错误。3. 从零搭建一套可用的Puppet环境3.1 安装与基础配置假设我们用两台机器做演示一台Master主机名puppet-master一台Agent主机名puppet-agent。操作系统以常见的Linux发行版为例。Master端安装# 添加官方仓库以某主流发行版为例 rpm -Uvh https://yum.puppet.com/puppet7-release-el-7.noarch.rpm yum install -y puppetserverAgent端安装rpm -Uvh https://yum.puppet.com/puppet7-release-el-7.noarch.rpm yum install -y puppet-agent安装完成后Master端需要调整一下JVM内存默认2G对小型环境够用但如果模块多了会吃紧。编辑/etc/sysconfig/puppetserver把JAVA_ARGS里的-Xms和-Xmx调到合适值我一般设成2G和4G。启动Mastersystemctl enable puppetserver systemctl start puppetserverAgent端编辑/etc/puppetlabs/puppet/puppet.conf在[agent]段加上server puppet-master然后启动Agentsystemctl enable puppet systemctl start puppet3.2 证书签发第一道坎Agent启动后会自动向Master请求证书。在Master上执行puppetserver ca list --all你会看到Agent的证书请求状态是requested。签发puppetserver ca sign --certname puppet-agent签发成功后Agent端再执行一次puppet agent -t就能正常拉取Catalog了。如果Agent一直没反应检查Agent端的/var/log/puppetlabs/puppet/puppet.log常见问题是时间不同步导致证书验证失败或者防火墙挡了8140端口。实操心得生产环境建议开启自动签发但一定要配合autosign策略比如只允许特定域名后缀的机器自动签。手动签发在机器多的时候会疯掉。3.3 写第一个Manifest并应用在Master的/etc/puppetlabs/code/environments/production/manifests/目录下创建site.ppnode puppet-agent { file { /tmp/hello-puppet.txt: ensure file, content This file is managed by Puppet.\n, mode 0644, } }Agent端执行puppet agent -t然后去/tmp下看应该多了个hello-puppet.txt。再执行一次puppet agent -tPuppet会报告“Applied catalog in X seconds”但不会重复创建文件因为状态已经一致了。这个简单的例子展示了Puppet的核心工作流定义状态、应用、验证幂等性。实际项目中我们会把site.pp作为入口里面用include引入各个模块的Class。4. 实战用Puppet管理Nginx和用户账户4.1 编写Nginx模块先创建模块目录cd /etc/puppetlabs/code/environments/production/modules mkdir -p nginx/{manifests,templates,files}manifests/init.ppclass nginx { package { nginx: ensure installed, } file { /etc/nginx/nginx.conf: ensure file, owner root, group root, mode 0644, content template(nginx/nginx.conf.erb), require Package[nginx], notify Service[nginx], } service { nginx: ensure running, enable true, subscribe File[/etc/nginx/nginx.conf], } }这里有几个关键点require确保包先装再改配置notify和subscribe确保配置变更后服务重启。这两个元参数是Puppet里控制执行顺序和触发动作的核心用好了能避免很多“配置改了但服务没重载”的问题。templates/nginx.conf.erb里可以用ERB语法动态生成配置比如根据Facts里的CPU核数设置worker_processesworker_processes % processors[count] %;processors是Puppet自动收集的Fact不需要额外配置。4.2 批量管理用户账户用户管理是配置管理里最常见的需求之一。假设我们要确保一批运维账户存在且SSH公钥正确。class users { $ops_users [alice, bob, carol] $ops_users.each |String $user| { user { $user: ensure present, shell /bin/bash, managehome true, } file { /home/${user}/.ssh: ensure directory, owner $user, group $user, mode 0700, require User[$user], } file { /home/${user}/.ssh/authorized_keys: ensure file, owner $user, group $user, mode 0600, content file(users/${user}_authorized_keys), require File[/home/${user}/.ssh], } } }然后在files/目录下放对应的公钥文件。这样新增一个用户只需要改$ops_users数组加一个公钥文件跑一次Puppet就搞定。注意managehome true会创建家目录但如果家目录已经存在且里面有数据Puppet不会删除。不过如果你不小心把ensure设成absentPuppet会连家目录一起删掉这个操作不可逆生产环境一定要小心。4.3 用Hiera做数据分离把数据硬编码在Manifest里不是好习惯。Puppet提供了Hiera来做数据与代码分离。配置hiera.yamlversion: 5 defaults: datadir: data data_hash: yaml_data hierarchy: - name: Per-node data path: nodes/%{trusted.certname}.yaml - name: Common data path: common.yaml然后在data/common.yaml里定义nginx::worker_processes: 4 users::ops_users: - alice - bob - carolManifest里用lookup函数读取$ops_users lookup(users::ops_users, Array[String], first, [])这样做的好处是不同环境、不同节点的数据可以分层覆盖代码逻辑不用动。比如测试环境的Nginx worker数设小一点生产环境设大一点只改数据文件就行。5. 常见问题与排查技巧实录5.1 排查思路速查表现象可能原因排查命令Agent卡在等待证书证书未签发puppetserver ca list --allCatalog编译失败Manifest语法错误puppet parser validate xxx.pp配置未生效依赖关系缺失puppet agent -t --debug服务未重启notify/subscribe未配检查Resource的元参数模板渲染报错ERB变量不存在puppet apply --test本地测试执行超时Master内存不足检查/var/log/puppetlabs/puppetserver/puppetserver.log5.2 几个我踩过的坑坑一Resource标题重复。同一个Manifest里不能有两个相同类型且相同标题的Resource。比如你写了两个file { /etc/hosts: }Puppet会直接报错。解决办法是用不同的标题或者用ensure present的数组形式。坑二执行顺序不一定是书写顺序。Puppet默认不保证Resource按你写的顺序执行除非你用require、before、notify、subscribe这些元参数显式指定。我早期写了一个装包、改配置、起服务的Manifest结果服务先起来了配置还没改导致服务启动失败。后来全部加上依赖关系才稳定。坑三Facts收集不全。有些自定义Fact需要额外装facter插件或者用external facts。如果Manifest里引用了不存在的Fact编译会报错。建议在模板里用fact之前先用facter -p确认一下。坑四环境隔离没做好。Puppet默认有production环境但你可以创建testing、staging等环境。不同环境的代码目录是独立的。我见过有人直接在production里改代码结果所有机器立刻生效出了事故回滚都来不及。正确做法是在测试环境验证通过后再合并到生产。5.3 性能优化的小技巧Master端如果管理几百台机器Catalog编译会成为瓶颈。几个优化方向一是开启environment_timeout缓存避免每次请求都重新编译二是用puppetdb做事实存储和查询减少Agent端的Facts传输量三是把不常变的模块拆成静态Catalog减少编译开销。Agent端可以调整runinterval默认30分钟。如果机器多可以错开执行时间避免同时向Master发起请求造成尖峰。在puppet.conf里加splay true和splaylimit 300让Agent在30分钟间隔内随机延迟最多5分钟再执行。6. 从Puppet出发配置管理的进阶思路Puppet解决了“机器状态一致性”的问题但它不是银弹。实际项目中我通常会把Puppet和CI/CD流水线结合起来代码合并到主分支后自动触发Puppet环境更新再通过puppet job或者bolt做批量任务编排。这样从代码提交到机器生效全程不需要人工登录服务器。另外Puppet的测试也很重要。puppet-lint做语法检查rspec-puppet做单元测试beaker做集成测试。我一般要求团队里每个模块至少要有puppet-lint通过核心模块要有rspec覆盖。这些工具在CI里跑一遍能挡掉大部分低级错误。如果你刚开始接触配置管理我的建议是不要一上来就追求大而全。先从一个简单的模块开始比如统一/etc/hosts或者管理NTP服务跑通整个流程理解Agent/Master的交互、证书签发、Catalog编译这些基础环节。等这套跑顺了再逐步把更多服务纳入管理。一口吃不成胖子配置管理这件事稳比快重要。最后分享一个我个人的习惯每次改完Manifest先在本地用puppet apply --noop跑一遍看看Puppet打算做什么变更。--noop是“干跑”模式不会真正修改系统但会告诉你哪些Resource会发生变化。这个习惯帮我避免了好几次误操作尤其是涉及删除文件或停止服务的场景。