运维DevOpsIaC【免费下载链接】puppetServer automation framework and application项目地址https://gitcode.com/gh_mirrors/pu/puppet点击查看免费下载导读本文以仓库中 ext/README.md 为纲逐项解析 Puppet 源码树中ext/目录的职责这里存放的是打包 Puppet 与 puppet-agent 时在内部使用的各类平台支撑文件——包括各发行版的 init 脚本、systemd 单元文件、macOS launchd plist、Solaris SMF 服务清单、Windows 服务守护进程与辅助批处理脚本以及默认 Hiera 配置和打包元数据。读完本文你将掌握 Puppet agent 在 Debian/Ubuntu、RHEL/CentOS、SUSE、macOS、Solaris 与 Windows 六大平台上的服务注册与守护方式理解PUPPET_EXTRA_OPTS、DAEMON_OPTS、runinterval等关键配置注入点并能在日常运维中按需自定义 Puppet agent 的启动参数与运行策略。一、ext/目录总览一份面向打包者的支撑文件清单ext/目录本身不包含 Puppet 的核心业务逻辑它服务的对象是puppet 与 puppet-agent 两个项目的打包与安装过程。README 明确说明This directory contains files used internally when packaging puppet and puppet-agent。从仓库实际文件结构看ext/其内容可归纳为四类类别文件/目录服务平台用途服务管理systemd/puppet.service使用 systemd 的现代 Linux 发行版systemd 单元文件注册 puppet agent 守护进程debian/puppet.init、puppet.defaultDebian/Ubuntu 等 LSB init 体系init 脚本 默认参数文件redhat/client.init、client.sysconfigRHEL/CentOS 等 EL 系列SysV init 脚本 sysconfig 配置suse/client.initSUSE/SLES 系列兼容 LSB 的 init 脚本osx/puppet.plistmacOSlaunchd 任务属性列表solaris/smf/puppet.xml、puppetSolaris 11SMF 服务清单与方法脚本windows/service/daemon.rb、daemon.bat及若干.batWindowsWindows 服务守护进程与命令行辅助工具默认配置hiera/hiera.yaml所有平台安装到$codedir/environments/production的默认 Hiera 配置打包元数据build_defaults.yaml、project_data.yaml打包自动化构建目标、仓库地址、gem 打包文件清单等值得注意的细节是README 提到osx/puppet.plist使用$codedir作为默认 Hiera 配置的安装位置这与 Puppet 的目录环境directory environments机制相关——$codedir下的environments/production是生产环境的代码根目录Puppet 会在该目录下查找hiera.yaml完成层级数据配置。二、systemd 单元文件现代 Linux 上的服务注册方式ext/systemd/puppet.service 是使用 systemd 的发行版RHEL 7/CentOS 7、Debian 8/Ubuntu 16.04 等注册 Puppet agent 的标准单元文件。其核心内容如下[Unit] DescriptionPuppet agent Documentationman:puppet-agent(8) Wantsbasic.target Afterbasic.target network.target network-online.target [Service] EnvironmentFile-/etc/sysconfig/puppetagent EnvironmentFile-/etc/sysconfig/puppet EnvironmentFile-/etc/default/puppet ExecStart/opt/puppetlabs/puppet/bin/puppet agent $PUPPET_EXTRA_OPTS --no-daemonize ExecReload/bin/kill -HUP $MAINPID KillModeprocess [Install] WantedBymulti-user.target几个值得深入的关键点$PUPPET_EXTRA_OPTS环境变量注入ExecStart中引用了$PUPPET_EXTRA_OPTS它可以通过EnvironmentFile指定的三个配置文件注入——/etc/sysconfig/puppetagent、/etc/sysconfig/puppetEL 系习惯或/etc/default/puppetDebian 系习惯。EnvironmentFile前的-表示文件不存在时不报错兼容不同发行版习惯。例如在 ext/redhat/client.sysconfig 中就有示例注释#PUPPET_EXTRA_OPTS--waitforcert500。前台运行模式--no-daemonize让 puppet agent 以前台进程方式运行这是 systemd 管理守护进程的标准做法——由 systemd 接管进程生命周期而不是让进程自行 fork 到后台。优雅重载ExecReload/bin/kill -HUP $MAINPID通过向主进程发送HUP信号触发配置重载。KillModeprocess只终止主进程不级联杀死其子进程。单元文件头部还给出了一个非常实用的自定义示例——通过 drop-in 目录覆盖系统级限制如果要提高 puppet 的打开文件数上限如LimitNOFILE10000只需创建/etc/systemd/system/puppet.service.d/limits.conf并写入[Service] LimitNOFILE10000然后执行systemctl daemon-reload再通过systemctl show puppet | grep LimitNOFILE验证是否生效。这种 drop-in 机制可以保证自定义配置在软件包升级时不被覆盖。三、Debian 系LSB init 脚本与/etc/default/puppet3.1 init 脚本结构ext/debian/puppet.init 是一个符合 LSB 规范的 init 脚本面向不支持 systemd 的 Debian 系平台。其头部声明了服务依赖与运行级别# Provides: puppet # Required-Start: $network $named $remote_fs $syslog # Required-Stop: $network $named $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6脚本定义了几个关键变量DAEMON/opt/puppetlabs/puppet/bin/puppet指向 puppet-agent 安装路径下的二进制DAEMON_OPTS可在/etc/default/puppet中被覆盖PIDFILE/var/run/puppetlabs/agent.pidPID 文件位置。脚本启动时通过[ -r /etc/default/puppet ] . /etc/default/puppetsource 配置文件即 Debian 体系的默认参数文件。支持的命令包括start、stop、reload发送 HUP 信号触发重载、status、restart、force-reload、condrestart。启动逻辑使用start-stop-daemon以$NAME $DAEMON_OPTS即agent $DAEMON_OPTS方式拉起进程停止时先TERM等待 10 秒超时再KILL等待 5 秒--retry TERM/10/KILL/5保证优雅退出。3.2 默认参数文件ext/debian/puppet.default 内容极简是 init 脚本的默认参数注入点# Defaults for puppet - sourced by /etc/init.d/puppet # Startup options DAEMON_OPTS运维人员可以把额外的 agent 启动参数写入此处例如DAEMON_OPTS--waitforcert 300。这与 Red Hat 系的PUPPET_EXTRA_OPTS是同一设计思路参数文件与脚本分离保证升级不覆盖用户自定义。四、Red Hat 系SysV init 脚本与 sysconfig 配置ext/redhat/client.init 面向 EL 系列RHEL/CentOS且不使用 systemd 的平台。头部chkconfig: - 98 02表示默认不在任何运行级别启用由安装包自行决定优先级为启动 98、停止 02。脚本关键变量与 Debian 版类似但配置文件名不同[ -f /etc/sysconfig/puppet ] . /etc/sysconfig/puppetsource sysconfig 文件puppetd/opt/puppetlabs/puppet/bin/puppetPUPPET_OPTSagent 基础参数pidfile${piddir}/agent.pid其中piddir/var/run/puppetlabs。脚本额外提供了两个 Debian 版没有的命令once$puppetd ${PUPPET_OPTS} --onetime ${PUPPET_EXTRA_OPTS} $——执行一次性 agent 运行--onetime常用于手动触发一次配置应用并可追加额外参数genconfig$puppetd ${PUPPET_OPTS} ${PUPPET_EXTRA_OPTS} --genconfig——生成当前环境下的完整配置快照用于排查配置问题rotate向主进程发送USR2信号用于重新打开日志文件。配套的 ext/redhat/client.sysconfig 同样只含一个注释示例#PUPPET_EXTRA_OPTS--waitforcert500提示用户可在此注入 agent 额外参数如首次运行等待证书签发的超时时间。五、SUSE 系兼容 LSB 的 init 脚本ext/suse/client.init 由 Red Hat 脚本衍生而来头部保留了原作者信息并注明 Martin Vuk (SuSE support)但针对 SUSE 的rc体系做了适配使用/etc/rc.status提供的rc_reset、rc_status、rc_exit等函数维护服务状态码符合 LSB 返回值约定0 成功 / 1 一般错误 / 2 参数错误 / 3 未实现功能 / 4 权限不足 / 5 未安装 / 6 未配置Default-Start: 3 5——SUSE 传统上只在运行级别 3 和 5 启动服务启动使用startproc -f -w -p ${pidfile}并有一个防御逻辑若 pidfile 中的 PID 与pgrep -f $puppetd匹配则视为已在运行而不再重复启动停止使用killproc -QUIT重载通过killproc -HUP实现同样支持once命令$puppetd ${PUPPET_OPTS} --onetime ${PUPPET_EXTRA_OPTS} $。SUSE 版同样 source/etc/sysconfig/puppetPUPPET_EXTRA_OPTS注入机制与 Red Hat 完全一致。六、macOSlaunchd plistext/osx/puppet.plist 是 macOS 上注册 Puppet agent 的 launchd 属性列表。核心配置keyLabel/key stringpuppet/string keyKeepAlive/key true/ keyRunAtLoad/key true/ keyProgramArguments/key array string/opt/puppetlabs/bin/puppet/string stringagent/string string--verbose/string string--no-daemonize/string string--logdest/string stringconsole/string /array keyStandardErrorPath/key string/var/log/puppetlabs/puppet/puppet.log/string keyStandardOutPath/key string/var/log/puppetlabs/puppet/puppet.log/string要点解读RunAtLoadtrue表示加载即启动KeepAlivetrue表示进程异常退出后由 launchd 自动拉起——这与 systemd 单元的管理哲学一致同样使用--no-daemonize前台模式日志输出到console并被 launchd 重定向到/var/log/puppetlabs/puppet/puppet.logstdout 与 stderr 合并写入同一文件通过EnvironmentVariables预设LANGen_US.UTF-8保证日志与输出使用 UTF-8 编码避免本地化问题。七、Solaris 11SMF 服务清单与方法脚本Solaris 不使用 systemd/init而是采用 SMFService Management Facility。ext/solaris/smf/下有两个文件配合工作7.1 服务清单puppet.xmlext/solaris/smf/puppet.xml 声明了一个名为network/puppet的单实例服务包含四组依赖config-filepath 类型依赖file:///etc/puppetlabs/puppet/puppet.conf存在loopback、physicalservice 类型依赖网络回环与物理网络就绪fs-local依赖本地文件系统。启动/停止方法分别指向/lib/svc/method/puppet start与stoprefresh方法直接使用:kill发送默认信号刷新服务。注意清单中create_default_instance enabledfalse——默认实例不启用需要管理员显式启用服务。7.2 方法脚本puppetext/solaris/smf/puppet 是实际的启停逻辑startexec $PUPPET agent直接在前台执行 agentSMF 接管生命周期stop通过svcprop -p restarter/contract $SMF_FMRI获取进程契约 ID然后调用smf_kill_contract先发TERM30 秒内每 5 秒重试若仍未退出则升级为KILL——这是 SMF 标准的优雅停机流程。八、Windows服务守护进程与批处理辅助工具ext/windows/是 Windows 平台的支持文件集合包含服务实现与若干.bat快捷工具。8.1 服务守护进程service/daemon.rbext/windows/service/daemon.rb 是一个独立运行的 Ruby 程序继承自Puppet::Util::Windows::Daemon实现了完整的 Windows 服务生命周期service_init、service_main、service_stop、service_pause、service_resume、service_shutdown。它的核心运行循环值得展开run_thread Thread.new do while service.running? runinterval service.parse_runinterval(ruby_puppet_cmd) if service.state RUNNING or service.state IDLE pid Process.create( :command_line #{ruby_puppet_cmd} agent --onetime #{args}, :creation_flags CREATE_NEW_CONSOLE ).process_id end sleep(runinterval) end end即每隔runinterval秒执行一次puppet agent --onetime。其中parse_runinterval源码 daemon.rb通过执行puppet config --section agent --log_level notice print runinterval动态读取配置中的运行间隔若获取失败则回退到默认值1800 秒30 分钟支持--debug与--logtofile两个专属开关--logtofile时日志写入%ALLUSERSPROFILE%\PuppetLabs\puppet\var\log\windows.log否则写入 Windows 事件日志事件源 Puppetload_env在启动前注入PUPPET_DIR、SSL_CERT_DIR、SSL_CERT_FILE、OPENSSL_CONF、RUBYLIB、Path等环境变量确保子进程能找到 Ruby 与 Puppet 的完整运行环境。8.2 入口与辅助批处理ext/windows/service/daemon.bat调用environment.bat准备环境后执行ruby -rubygems %~dp0daemon.rb %*作为 Windows 服务的命令行入口ext/windows/puppet_interactive.batcall puppet.bat agent --test %*后PAUSE——手动以--test模式前台、verbose、一次性运行一次 agent适合交互式调试ext/windows/puppet_shell.bat设置 PATH 后执行ruby.exe -v用于在已配置的 Puppet 环境中打开一个可用的 Ruby 命令行ext/windows/run_puppet_interactive.bat通过elevate.exe以管理员权限启动puppet_interactive.bat解决 agent 运行所需的提权问题。九、默认 Hiera 配置安装到生产环境的hiera.yamlext/hiera/hiera.yaml 是打包时安装到$codedir/environments/production的默认 Hiera 5 配置用户安装后即可获得开箱即用的数据层级--- version: 5 defaults: # datadir: data # data_hash: yaml_data hierarchy: - name: Per-node data (yaml version) path: nodes/%{::trusted.certname}.yaml - name: Other YAML hierarchy levels paths: - common.yaml要点version: 5表明这是 Hiera 5 配置格式与 Puppet 4.9/5 及以上版本的现代层级数据查找机制对应默认层级为节点级优先、全局兜底先查nodes/certname.yaml使用trusted.certname事实定位每个节点的专属数据再查common.yaml作为通用默认值——这是 Puppet 官方推荐的分层数据布局defaults中的datadir默认值为与该hiera.yaml同目录下的data子目录即environment/data配置中保留注释供用户按需取消注释启用自定义datadir或切换data_hash后端配置文件注释提示用户指定datadir时必须确保目录存在否则层级查找会失败。十、打包元数据构建自动化与 gem 打包ext/目录还承载两份打包相关 YAML10.1build_defaults.yamlext/build_defaults.yaml 记录 puppetlabs 构建自动化的目标信息packager: puppetlabs pbuild_conf: /etc/pbuilderrc build_gem: TRUE build_dmg: FALSE sign_tar: FALSE yum_host: yum.puppetlabs.com yum_repo_path: /opt/repository/yum/ apt_signing_server: apt.puppetlabs.com apt_repo_url: http://apt.puppetlabs.com apt_repo_path: /opt/repository/incoming tar_host: downloads.puppetlabs.com nonfinal_gem_path: /opt/repository-nightlies/downloads/gems/puppet8-nightly它定义了发布渠道yum/apt 仓库地址与路径、构建目标是否构建 gem、dmg、签名 tar以及预发布nightlygem 的上传路径。被注释掉的final_mocks与cows字段则用于指定 EL 系 mock 构建目标与 Debian 系 cowbuilder 目标。10.2project_data.yamlext/project_data.yaml 用于打包 puppet gem 时的文件清单与文档选项project: puppet gem_rdoc_options: - --title - Puppet - Configuration Management - --main - README.md - --line-numbers files: - [A-Z]* - install.rb - bin - lib - conf - man - examples - ext - tasks - localesfiles字段列出了构建源码 tarball 时要打包进 gem 的路径集合其中ext赫然在列——这说明本文讨论的这些服务管理文件会随 gem/源码包一起发布供各平台打包者在安装阶段按需取用。gem_rdoc_options则控制 gem 文档生成时的标题、主文档页与是否显示行号。十一、贯穿各平台的统一设计模式纵观ext/下所有服务管理文件可以归纳出 Puppet 在各平台服务化上的四个一致性设计配置与脚本分离无论是 Debian 的/etc/default/puppet、Red Hat/SUSE 的/etc/sysconfig/puppet还是 systemd 的EnvironmentFile drop-in 目录都把用户可调参数与随包安装的脚本分离保证包升级不会覆盖本地自定义统一注入PUPPET_EXTRA_OPTS/DAEMON_OPTS各平台脚本都预留了向puppet agent命令行追加参数的通道常见用法如--waitforcert500控制首次证书签发等待时间前台运行 外部进程管理器systemd、launchd、SMF 与 Windows 服务四种场景均采用--no-daemonize或--onetime由外部管理器接管生命周期避免双守护优雅重载与停机重载统一走HUP信号ExecReload、killproc -HUP、start-stop-daemon --signal HUP停机则普遍采用先 TERM 后 KILL的梯度策略确保 agent 正在进行的 run 不被粗暴打断。十二、小结与进一步阅读ext/目录虽不直接承载 Puppet 的配置管理逻辑却是 Puppet 能在六大操作系统上以正规服务形态稳定运行的基石。从 systemd 单元文件到 Solaris SMF 契约、再到 Windows 事件日志集成每一份文件都对应一个明确的平台接入点。如果你需要深入验证文中所述机制可继续在仓库中阅读服务参数解析的源头lib/puppet/application/agent.rb--no-daemonize、--onetime、--waitforcert等参数的实现位置Windows 服务基类lib/puppet/util/windows/daemon.rbWindowsDaemon的状态机与信号处理运行间隔默认值runinterval的默认设置在 lib/puppet/defaults.rb 中定义Hiera 层级查找机制lib/hiera/scope.rb 与 lib/hiera/puppet_function.rb环境目录机制docs/ 下的文档与 lib/puppet/environments.rb。如需在本地部署验证可使用标准的 puppet-agent 安装流程然后对比各平台服务的启停命令如systemctl start puppet、service puppet start、launchctl load、svcadm enable puppet、sc start puppet即可直观感受ext/目录在各平台发挥的作用。赞分享运维DevOpsIaC【免费下载链接】puppetServer automation framework and application项目地址https://gitcode.com/gh_mirrors/pu/puppet点击查看免费下载相关推荐终极Switch手柄兼容指南零成本解锁全平台控制器终极Switch手柄兼容指南零成本解锁全平台控制器 你是否曾为Switch官方手柄的高昂价格而烦恼是否家中闲置着PS4、Xbox或Wii手柄却无法在Swit蓝牙嵌入式fpm 的 pleaserun 输入类型一条命令生成多平台服务管理包systemd / sysv / upstart / launchdfpm 的 pleaserun 输入类型一条命令生成多平台服务管理包systemd / sysv / upstart / launchd 本篇技术指南围绕开发工具fpm 与 pleaserun一条命令生成 systemd / upstart / launchd / sysv 多平台服务定义包fpm 与 pleaserun一条命令生成 systemd / upstart / launchd / sysv 多平台服务定义包 导读 本文讲解 FPM 内开发工具上一篇深度解密Sunshine游戏串流构建专业级自托管游戏服务器下一篇打造家庭游戏串流中心Sunshine自托管游戏串流完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
运维DevOpsIaC【免费下载链接】puppetServer automation framework and application项目地址https://gitcode.com/gh_mirrors/pu/puppet点击查看免费下载导读本文以仓库中 ext/README.md 为纲逐项解析 Puppet 源码树中ext/目录的职责这里存放的是打包 Puppet 与 puppet-agent 时在内部使用的各类平台支撑文件——包括各发行版的 init 脚本、systemd 单元文件、macOS launchd plist、Solaris SMF 服务清单、Windows 服务守护进程与辅助批处理脚本以及默认 Hiera 配置和打包元数据。读完本文你将掌握 Puppet agent 在 Debian/Ubuntu、RHEL/CentOS、SUSE、macOS、Solaris 与 Windows 六大平台上的服务注册与守护方式理解PUPPET_EXTRA_OPTS、DAEMON_OPTS、runinterval等关键配置注入点并能在日常运维中按需自定义 Puppet agent 的启动参数与运行策略。一、ext/目录总览一份面向打包者的支撑文件清单ext/目录本身不包含 Puppet 的核心业务逻辑它服务的对象是puppet 与 puppet-agent 两个项目的打包与安装过程。README 明确说明This directory contains files used internally when packaging puppet and puppet-agent。从仓库实际文件结构看ext/其内容可归纳为四类类别文件/目录服务平台用途服务管理systemd/puppet.service使用 systemd 的现代 Linux 发行版systemd 单元文件注册 puppet agent 守护进程debian/puppet.init、puppet.defaultDebian/Ubuntu 等 LSB init 体系init 脚本 默认参数文件redhat/client.init、client.sysconfigRHEL/CentOS 等 EL 系列SysV init 脚本 sysconfig 配置suse/client.initSUSE/SLES 系列兼容 LSB 的 init 脚本osx/puppet.plistmacOSlaunchd 任务属性列表solaris/smf/puppet.xml、puppetSolaris 11SMF 服务清单与方法脚本windows/service/daemon.rb、daemon.bat及若干.batWindowsWindows 服务守护进程与命令行辅助工具默认配置hiera/hiera.yaml所有平台安装到$codedir/environments/production的默认 Hiera 配置打包元数据build_defaults.yaml、project_data.yaml打包自动化构建目标、仓库地址、gem 打包文件清单等值得注意的细节是README 提到osx/puppet.plist使用$codedir作为默认 Hiera 配置的安装位置这与 Puppet 的目录环境directory environments机制相关——$codedir下的environments/production是生产环境的代码根目录Puppet 会在该目录下查找hiera.yaml完成层级数据配置。二、systemd 单元文件现代 Linux 上的服务注册方式ext/systemd/puppet.service 是使用 systemd 的发行版RHEL 7/CentOS 7、Debian 8/Ubuntu 16.04 等注册 Puppet agent 的标准单元文件。其核心内容如下[Unit] DescriptionPuppet agent Documentationman:puppet-agent(8) Wantsbasic.target Afterbasic.target network.target network-online.target [Service] EnvironmentFile-/etc/sysconfig/puppetagent EnvironmentFile-/etc/sysconfig/puppet EnvironmentFile-/etc/default/puppet ExecStart/opt/puppetlabs/puppet/bin/puppet agent $PUPPET_EXTRA_OPTS --no-daemonize ExecReload/bin/kill -HUP $MAINPID KillModeprocess [Install] WantedBymulti-user.target几个值得深入的关键点$PUPPET_EXTRA_OPTS环境变量注入ExecStart中引用了$PUPPET_EXTRA_OPTS它可以通过EnvironmentFile指定的三个配置文件注入——/etc/sysconfig/puppetagent、/etc/sysconfig/puppetEL 系习惯或/etc/default/puppetDebian 系习惯。EnvironmentFile前的-表示文件不存在时不报错兼容不同发行版习惯。例如在 ext/redhat/client.sysconfig 中就有示例注释#PUPPET_EXTRA_OPTS--waitforcert500。前台运行模式--no-daemonize让 puppet agent 以前台进程方式运行这是 systemd 管理守护进程的标准做法——由 systemd 接管进程生命周期而不是让进程自行 fork 到后台。优雅重载ExecReload/bin/kill -HUP $MAINPID通过向主进程发送HUP信号触发配置重载。KillModeprocess只终止主进程不级联杀死其子进程。单元文件头部还给出了一个非常实用的自定义示例——通过 drop-in 目录覆盖系统级限制如果要提高 puppet 的打开文件数上限如LimitNOFILE10000只需创建/etc/systemd/system/puppet.service.d/limits.conf并写入[Service] LimitNOFILE10000然后执行systemctl daemon-reload再通过systemctl show puppet | grep LimitNOFILE验证是否生效。这种 drop-in 机制可以保证自定义配置在软件包升级时不被覆盖。三、Debian 系LSB init 脚本与/etc/default/puppet3.1 init 脚本结构ext/debian/puppet.init 是一个符合 LSB 规范的 init 脚本面向不支持 systemd 的 Debian 系平台。其头部声明了服务依赖与运行级别# Provides: puppet # Required-Start: $network $named $remote_fs $syslog # Required-Stop: $network $named $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6脚本定义了几个关键变量DAEMON/opt/puppetlabs/puppet/bin/puppet指向 puppet-agent 安装路径下的二进制DAEMON_OPTS可在/etc/default/puppet中被覆盖PIDFILE/var/run/puppetlabs/agent.pidPID 文件位置。脚本启动时通过[ -r /etc/default/puppet ] . /etc/default/puppetsource 配置文件即 Debian 体系的默认参数文件。支持的命令包括start、stop、reload发送 HUP 信号触发重载、status、restart、force-reload、condrestart。启动逻辑使用start-stop-daemon以$NAME $DAEMON_OPTS即agent $DAEMON_OPTS方式拉起进程停止时先TERM等待 10 秒超时再KILL等待 5 秒--retry TERM/10/KILL/5保证优雅退出。3.2 默认参数文件ext/debian/puppet.default 内容极简是 init 脚本的默认参数注入点# Defaults for puppet - sourced by /etc/init.d/puppet # Startup options DAEMON_OPTS运维人员可以把额外的 agent 启动参数写入此处例如DAEMON_OPTS--waitforcert 300。这与 Red Hat 系的PUPPET_EXTRA_OPTS是同一设计思路参数文件与脚本分离保证升级不覆盖用户自定义。四、Red Hat 系SysV init 脚本与 sysconfig 配置ext/redhat/client.init 面向 EL 系列RHEL/CentOS且不使用 systemd 的平台。头部chkconfig: - 98 02表示默认不在任何运行级别启用由安装包自行决定优先级为启动 98、停止 02。脚本关键变量与 Debian 版类似但配置文件名不同[ -f /etc/sysconfig/puppet ] . /etc/sysconfig/puppetsource sysconfig 文件puppetd/opt/puppetlabs/puppet/bin/puppetPUPPET_OPTSagent 基础参数pidfile${piddir}/agent.pid其中piddir/var/run/puppetlabs。脚本额外提供了两个 Debian 版没有的命令once$puppetd ${PUPPET_OPTS} --onetime ${PUPPET_EXTRA_OPTS} $——执行一次性 agent 运行--onetime常用于手动触发一次配置应用并可追加额外参数genconfig$puppetd ${PUPPET_OPTS} ${PUPPET_EXTRA_OPTS} --genconfig——生成当前环境下的完整配置快照用于排查配置问题rotate向主进程发送USR2信号用于重新打开日志文件。配套的 ext/redhat/client.sysconfig 同样只含一个注释示例#PUPPET_EXTRA_OPTS--waitforcert500提示用户可在此注入 agent 额外参数如首次运行等待证书签发的超时时间。五、SUSE 系兼容 LSB 的 init 脚本ext/suse/client.init 由 Red Hat 脚本衍生而来头部保留了原作者信息并注明 Martin Vuk (SuSE support)但针对 SUSE 的rc体系做了适配使用/etc/rc.status提供的rc_reset、rc_status、rc_exit等函数维护服务状态码符合 LSB 返回值约定0 成功 / 1 一般错误 / 2 参数错误 / 3 未实现功能 / 4 权限不足 / 5 未安装 / 6 未配置Default-Start: 3 5——SUSE 传统上只在运行级别 3 和 5 启动服务启动使用startproc -f -w -p ${pidfile}并有一个防御逻辑若 pidfile 中的 PID 与pgrep -f $puppetd匹配则视为已在运行而不再重复启动停止使用killproc -QUIT重载通过killproc -HUP实现同样支持once命令$puppetd ${PUPPET_OPTS} --onetime ${PUPPET_EXTRA_OPTS} $。SUSE 版同样 source/etc/sysconfig/puppetPUPPET_EXTRA_OPTS注入机制与 Red Hat 完全一致。六、macOSlaunchd plistext/osx/puppet.plist 是 macOS 上注册 Puppet agent 的 launchd 属性列表。核心配置keyLabel/key stringpuppet/string keyKeepAlive/key true/ keyRunAtLoad/key true/ keyProgramArguments/key array string/opt/puppetlabs/bin/puppet/string stringagent/string string--verbose/string string--no-daemonize/string string--logdest/string stringconsole/string /array keyStandardErrorPath/key string/var/log/puppetlabs/puppet/puppet.log/string keyStandardOutPath/key string/var/log/puppetlabs/puppet/puppet.log/string要点解读RunAtLoadtrue表示加载即启动KeepAlivetrue表示进程异常退出后由 launchd 自动拉起——这与 systemd 单元的管理哲学一致同样使用--no-daemonize前台模式日志输出到console并被 launchd 重定向到/var/log/puppetlabs/puppet/puppet.logstdout 与 stderr 合并写入同一文件通过EnvironmentVariables预设LANGen_US.UTF-8保证日志与输出使用 UTF-8 编码避免本地化问题。七、Solaris 11SMF 服务清单与方法脚本Solaris 不使用 systemd/init而是采用 SMFService Management Facility。ext/solaris/smf/下有两个文件配合工作7.1 服务清单puppet.xmlext/solaris/smf/puppet.xml 声明了一个名为network/puppet的单实例服务包含四组依赖config-filepath 类型依赖file:///etc/puppetlabs/puppet/puppet.conf存在loopback、physicalservice 类型依赖网络回环与物理网络就绪fs-local依赖本地文件系统。启动/停止方法分别指向/lib/svc/method/puppet start与stoprefresh方法直接使用:kill发送默认信号刷新服务。注意清单中create_default_instance enabledfalse——默认实例不启用需要管理员显式启用服务。7.2 方法脚本puppetext/solaris/smf/puppet 是实际的启停逻辑startexec $PUPPET agent直接在前台执行 agentSMF 接管生命周期stop通过svcprop -p restarter/contract $SMF_FMRI获取进程契约 ID然后调用smf_kill_contract先发TERM30 秒内每 5 秒重试若仍未退出则升级为KILL——这是 SMF 标准的优雅停机流程。八、Windows服务守护进程与批处理辅助工具ext/windows/是 Windows 平台的支持文件集合包含服务实现与若干.bat快捷工具。8.1 服务守护进程service/daemon.rbext/windows/service/daemon.rb 是一个独立运行的 Ruby 程序继承自Puppet::Util::Windows::Daemon实现了完整的 Windows 服务生命周期service_init、service_main、service_stop、service_pause、service_resume、service_shutdown。它的核心运行循环值得展开run_thread Thread.new do while service.running? runinterval service.parse_runinterval(ruby_puppet_cmd) if service.state RUNNING or service.state IDLE pid Process.create( :command_line #{ruby_puppet_cmd} agent --onetime #{args}, :creation_flags CREATE_NEW_CONSOLE ).process_id end sleep(runinterval) end end即每隔runinterval秒执行一次puppet agent --onetime。其中parse_runinterval源码 daemon.rb通过执行puppet config --section agent --log_level notice print runinterval动态读取配置中的运行间隔若获取失败则回退到默认值1800 秒30 分钟支持--debug与--logtofile两个专属开关--logtofile时日志写入%ALLUSERSPROFILE%\PuppetLabs\puppet\var\log\windows.log否则写入 Windows 事件日志事件源 Puppetload_env在启动前注入PUPPET_DIR、SSL_CERT_DIR、SSL_CERT_FILE、OPENSSL_CONF、RUBYLIB、Path等环境变量确保子进程能找到 Ruby 与 Puppet 的完整运行环境。8.2 入口与辅助批处理ext/windows/service/daemon.bat调用environment.bat准备环境后执行ruby -rubygems %~dp0daemon.rb %*作为 Windows 服务的命令行入口ext/windows/puppet_interactive.batcall puppet.bat agent --test %*后PAUSE——手动以--test模式前台、verbose、一次性运行一次 agent适合交互式调试ext/windows/puppet_shell.bat设置 PATH 后执行ruby.exe -v用于在已配置的 Puppet 环境中打开一个可用的 Ruby 命令行ext/windows/run_puppet_interactive.bat通过elevate.exe以管理员权限启动puppet_interactive.bat解决 agent 运行所需的提权问题。九、默认 Hiera 配置安装到生产环境的hiera.yamlext/hiera/hiera.yaml 是打包时安装到$codedir/environments/production的默认 Hiera 5 配置用户安装后即可获得开箱即用的数据层级--- version: 5 defaults: # datadir: data # data_hash: yaml_data hierarchy: - name: Per-node data (yaml version) path: nodes/%{::trusted.certname}.yaml - name: Other YAML hierarchy levels paths: - common.yaml要点version: 5表明这是 Hiera 5 配置格式与 Puppet 4.9/5 及以上版本的现代层级数据查找机制对应默认层级为节点级优先、全局兜底先查nodes/certname.yaml使用trusted.certname事实定位每个节点的专属数据再查common.yaml作为通用默认值——这是 Puppet 官方推荐的分层数据布局defaults中的datadir默认值为与该hiera.yaml同目录下的data子目录即environment/data配置中保留注释供用户按需取消注释启用自定义datadir或切换data_hash后端配置文件注释提示用户指定datadir时必须确保目录存在否则层级查找会失败。十、打包元数据构建自动化与 gem 打包ext/目录还承载两份打包相关 YAML10.1build_defaults.yamlext/build_defaults.yaml 记录 puppetlabs 构建自动化的目标信息packager: puppetlabs pbuild_conf: /etc/pbuilderrc build_gem: TRUE build_dmg: FALSE sign_tar: FALSE yum_host: yum.puppetlabs.com yum_repo_path: /opt/repository/yum/ apt_signing_server: apt.puppetlabs.com apt_repo_url: http://apt.puppetlabs.com apt_repo_path: /opt/repository/incoming tar_host: downloads.puppetlabs.com nonfinal_gem_path: /opt/repository-nightlies/downloads/gems/puppet8-nightly它定义了发布渠道yum/apt 仓库地址与路径、构建目标是否构建 gem、dmg、签名 tar以及预发布nightlygem 的上传路径。被注释掉的final_mocks与cows字段则用于指定 EL 系 mock 构建目标与 Debian 系 cowbuilder 目标。10.2project_data.yamlext/project_data.yaml 用于打包 puppet gem 时的文件清单与文档选项project: puppet gem_rdoc_options: - --title - Puppet - Configuration Management - --main - README.md - --line-numbers files: - [A-Z]* - install.rb - bin - lib - conf - man - examples - ext - tasks - localesfiles字段列出了构建源码 tarball 时要打包进 gem 的路径集合其中ext赫然在列——这说明本文讨论的这些服务管理文件会随 gem/源码包一起发布供各平台打包者在安装阶段按需取用。gem_rdoc_options则控制 gem 文档生成时的标题、主文档页与是否显示行号。十一、贯穿各平台的统一设计模式纵观ext/下所有服务管理文件可以归纳出 Puppet 在各平台服务化上的四个一致性设计配置与脚本分离无论是 Debian 的/etc/default/puppet、Red Hat/SUSE 的/etc/sysconfig/puppet还是 systemd 的EnvironmentFile drop-in 目录都把用户可调参数与随包安装的脚本分离保证包升级不会覆盖本地自定义统一注入PUPPET_EXTRA_OPTS/DAEMON_OPTS各平台脚本都预留了向puppet agent命令行追加参数的通道常见用法如--waitforcert500控制首次证书签发等待时间前台运行 外部进程管理器systemd、launchd、SMF 与 Windows 服务四种场景均采用--no-daemonize或--onetime由外部管理器接管生命周期避免双守护优雅重载与停机重载统一走HUP信号ExecReload、killproc -HUP、start-stop-daemon --signal HUP停机则普遍采用先 TERM 后 KILL的梯度策略确保 agent 正在进行的 run 不被粗暴打断。十二、小结与进一步阅读ext/目录虽不直接承载 Puppet 的配置管理逻辑却是 Puppet 能在六大操作系统上以正规服务形态稳定运行的基石。从 systemd 单元文件到 Solaris SMF 契约、再到 Windows 事件日志集成每一份文件都对应一个明确的平台接入点。如果你需要深入验证文中所述机制可继续在仓库中阅读服务参数解析的源头lib/puppet/application/agent.rb--no-daemonize、--onetime、--waitforcert等参数的实现位置Windows 服务基类lib/puppet/util/windows/daemon.rbWindowsDaemon的状态机与信号处理运行间隔默认值runinterval的默认设置在 lib/puppet/defaults.rb 中定义Hiera 层级查找机制lib/hiera/scope.rb 与 lib/hiera/puppet_function.rb环境目录机制docs/ 下的文档与 lib/puppet/environments.rb。如需在本地部署验证可使用标准的 puppet-agent 安装流程然后对比各平台服务的启停命令如systemctl start puppet、service puppet start、launchctl load、svcadm enable puppet、sc start puppet即可直观感受ext/目录在各平台发挥的作用。赞分享运维DevOpsIaC【免费下载链接】puppetServer automation framework and application项目地址https://gitcode.com/gh_mirrors/pu/puppet点击查看免费下载相关推荐终极Switch手柄兼容指南零成本解锁全平台控制器终极Switch手柄兼容指南零成本解锁全平台控制器 你是否曾为Switch官方手柄的高昂价格而烦恼是否家中闲置着PS4、Xbox或Wii手柄却无法在Swit蓝牙嵌入式fpm 的 pleaserun 输入类型一条命令生成多平台服务管理包systemd / sysv / upstart / launchdfpm 的 pleaserun 输入类型一条命令生成多平台服务管理包systemd / sysv / upstart / launchd 本篇技术指南围绕开发工具fpm 与 pleaserun一条命令生成 systemd / upstart / launchd / sysv 多平台服务定义包fpm 与 pleaserun一条命令生成 systemd / upstart / launchd / sysv 多平台服务定义包 导读 本文讲解 FPM 内开发工具上一篇深度解密Sunshine游戏串流构建专业级自托管游戏服务器下一篇打造家庭游戏串流中心Sunshine自托管游戏串流完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
