运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载导读Salt 为 syslog-ng 日志服务提供了一对配套的执行模块与状态模块执行模块 salt/modules/syslog_ng.py 负责生成配置、校验语法、查询版本/模块/统计信息以及启动、停止、重载服务状态模块 salt/states/syslog_ng.py 则把上述能力包装为可在 SLS 中直接使用的状态。本文基于 syslog-ng 官方使用教程 与该模块源码、单元测试完整讲解如何从 YAML 描述生成 syslog-ng 配置包括 source、destination、filter、parser、rewrite、template、log 路径与 junction 分支如何用module.run编排初始化步骤以及如何通过config_test、version、modules、stats等命令对实例进行诊断——读完即可在 Salt 环境中落地一套「配置即代码」的 syslog-ng 管理方案。模块定位与适用场景syslog-ng 是通用的日志采集与转发守护进程Salt 的 syslog_ng 模块salt.modules.syslog_ng提供如下能力对应源码中的公开函数生成配置config、write_version、write_config、set_config_file、set_binary_path、set_parameters诊断查询config_test语法检查、version版本号、modules可用模块、stats运行统计、get_config_file服务控制start、stop、reload_通过__func_alias__对外暴露为reload模块声明模块 docstring说明了关键背景syslog-ng 可以通过包管理器或源码方式安装当从源码安装时syslog-ng与syslog-ng-ctl两个二进制不在PATH中用户需要用syslog_ng.set_binary_path指定 sbin 目录用syslog_ng.set_config_file指定配置文件位置否则模块会使用默认配置路径/etc/syslog-ng.conf模块源码中的模块级常量__SYSLOG_NG_CONFIG_FILE。模块仅依赖cmd支持所有平台salt/modules/syslog_ng.py模块头部:platform: all。值得注意的是执行模块中若干函数config、set_binary_path、set_config_file、start、stop、reload_、write_config、write_version的 docstring 都注明「intended to be used from the state module / from states」即它们的典型用法是经由状态模块或module.run调用而不是直接在命令行单独执行从源码结构看这些函数返回的是带name、result、changes、comment字段的状态字典_format_state_result天然适配 Salt 的状态执行模型。配置生成机制从 YAML 到 syslog-ng 语法的配置树config函数是整个生成能力的核心。它接收一个name语句 ID 或statement_type.id形式和一份已解析的 YAML 结构config通过_build_config_tree构建内存中的配置树再经_render_configuration渲染为 syslog-ng 的文本语法salt/modules/syslog_ng.py#L644-L675。从源码看配置树由一组职责分明的类构成salt/modules/syslog_ng.py#L92-L398它们与 syslog-ng 配置语法逐层对应类对应语法元素典型实例Statement/NamedStatement/UnnamedStatement语句statementsource s_local {...};、log {...};、options {...};GivenStatement原样输出的文本片段配置注释、已有配置片段Option语句内部的一个选项file(...)、tcp(...)、udp(...)SimpleParameter/TypedParameter选项的参数/var/log/messages、ip(127.0.0.1)SimpleParameterValue/TypedParameterValue带类型参数的取值ip(0.0.0.0)中的0.0.0.0、tls(key_file(...) cert_file(...))Argument类型参数的最内层取值key_file的值渲染时由Buildable.build递归调用子对象的build方法配合模块级的_INDENT/_INDENT_STEP4 空格缩进生成层级缩进文本。例如source s_localhost { tcp(ip(127.0.0.1), port(1233)); };的缩进即由此产生。模块内部的 YAML 解析路径_parse_statement→_create_and_add_option→_create_and_add_parameters→_parse_typed_parameter/_parse_typed_parameter_typed_value对配置做了三类识别_is_reference值为字符串的{type: id}形式解析为对已定义语句的引用如source: s_localhost_is_inline_definition值为列表的单键字典解析为内联匿名语句如destination: [file: [...]]_is_junction键为junction的字典按 channel 拆分为多个分支_add_junction。_is_statement_unnamed把log、channel、junction、options判定为无名语句渲染时不带 ID其余语句source、destination、filter、parser、rewrite、template等则为具名语句。测试如何验证生成逻辑仓库中的单元测试tests/unit/states/test_syslog_ng.py逐一对各类语句的生成结果做了断言例如test_generate_source_config验证file(...)源码生成、test_generate_log_config验证带 junction/channel 的 log 路径、test_generate_short_form_statement验证source.s_gsoc短形式test_generate_given_config验证config.id形式的原样文本输出。此外 tests/pytests/unit/modules/test_syslog_ng.py 用 Mock 模拟cmd.run_all验证version对syslog-ng -V首行syslog-ng 3.6.0alpha0的版本解析、modules对Available-Modules行的提取、config_test对--syntax-only [--cfgfile...]参数拼装以及指定 sbin 目录时会把该目录追加进PATH环境变量_run_command_in_extended_path。状态与执行函数参考syslog_ng.config生成语句config(name, config, writeTrue)要求两个参数nameSalt 文档的 ID或statement类型.id形式config解析后的 YAML 结构write可选为True时写入配置文件否则只返回生成结果。writeTrue时会调用_write_config以追加模式写入__SYSLOG_NG_CONFIG_FILE默认/etc/syslog-ng.conf在 test 模式下__opts__[test]为真只返回注释说明将写入的内容而不落盘。返回字典中changes.new携带新生成的配置文本。CLI 直接调用示例模块 docstring 给出salt * syslog_ng.config names_local config[{tcp:[{ip:127.0.0.1},{port:1233}]}]初始化函数set_binary_path、set_config_file、set_parameters、write_versionset_binary_path(name)设置syslog-ng与syslog-ng-ctl二进制所在目录。包管理器安装时无需调用源码安装时必用例如salt * syslog_ng.set_binary_path name/usr/sbin。set_config_file(name)设置配置文件路径例如salt * syslog_ng.set_config_file name/etc/syslog-ng。注意模块默认值就是/etc/syslog-ng.conf且源码演示示例中混用了目录与文件两种写法实操时应以完整文件路径为准。get_config_file()返回当前配置的配置文件路径。set_parameters(versionNone, binary_pathNone, config_fileNone)一次完成上述设置其中version参数会调用_determine_config_version从syslog-ng -V输出中解析出形如3.6的大版本号并写入配置。write_version(name)删除旧的配置文件、重建新文件写入version: name行并前置一行 Salt 生成的头部注释#Generated by Salt on 时间戳__SALT_GENERATED_CONFIG_HEADER。它依赖_write_config的追加写与os.remove实现「先清空再重建」。服务控制start、stop、reloadstart(...)带完整参数列表user、group、chroot、caps、no_caps、pidfile、enable_core、fd_limit、verbose、debug、trace、yydebug、persist_file、control、worker_threads通过_add_cli_param/_add_boolean_cli_param拼装 CLI 参数最后总是附加--cfgfile__SYSLOG_NG_CONFIG_FILE若设置了二进制路径则以os.path.join(__SYSLOG_NG_BINARY_PATH, syslog-ng)作为命令。测试test_started_state_generate_valid_cli_command验证了started(userjoe, groupusers, enable_coreTrue)生成的命令以syslog-ng --userjoe --groupusers --enable-core --cfgfile/etc/syslog-ng.conf结尾。返回结果中changes.new为完整命令行。stop(nameNone)用ps.pgrep(patternsyslog-ng)找 PID再用ps.pkill(syslog-ng)结束进程未运行时报Syslog-ng is not running。reload_(name)执行syslog-ng-ctl reload设置了二进制路径时用该目录下的syslog-ng-ctlretcode 0视为成功。模块 docstring 明确提示如果目标系统上有 Salt 的 service 模块可用服务启停应优先使用 service 模块这些函数是 service 模块不可用时的替代方案。诊断函数config_test、version、modules、statsconfig_test(syslog_ng_sbin_dirNone, cfgfileNone)以syslog-ng --syntax-only [--cfgfilefile]对配置文件做语法检查返回retcode/stdout/stderr字典。可用于部署前校验生成的配置。version(syslog_ng_sbin_dirNone)解析syslog-ng -V输出第一行格式如syslog-ng 3.6.0alpha0取第二个字段作为版本号返回。modules(syslog_ng_sbin_dirNone)同样读取syslog-ng -V输出提取Available-Modules行后的模块列表测试样例为syslogformat,json-plugin,basicfuncs,...等逗号分隔串。stats(syslog_ng_sbin_dirNone)执行syslog-ng-ctl stats返回统计输出测试样例展示了SourceName;SourceId;...分号分隔的统计表格包含各 source/destination 的 processed 计数。这些函数均通过_run_command→__salt__cmd.run_all执行并捕获CommandExecutionError返回retcode-1。当传入syslog_ng_sbin_dir时会临时把该目录并入PATH_run_command_in_extended_path。状态模块用法状态模块salt/states/syslog_ng.py是对执行模块的薄封装提供四个状态函数syslog_ng.config(name, config, writeTrue)生成配置语句syslog_ng.stopped(nameNone)停止 syslog-ngsyslog_ng.started(...)按参数启动 syslog-ngsyslog_ng.reloaded(name)重载配置。状态模块 docstring 说明service 模块不可用的系统才需要started/stopped/reloaded配置生成能力则始终可用。完整的配置生成细节见 syslog-ng 使用教程下文即其核心内容。YAML 配置语法详解语句的两种声明形式syslog_ng.config要求name与config两个参数name决定生成的语句名config持有 YAML 结构。以下两种形式等价短形式ID 中直接带类型前缀source.s_localhost: syslog_ng.config: - config: - tcp: - ip: 127.0.0.1 - port: 1233长形式config 中显式声明类型s_localhost: syslog_ng.config: - config: source: - tcp: - ip: 127.0.0.1 - port: 1233短形式需要更少输入二者生成完全相同的配置文本。配置内容用列表与字典组合表达从源码解析逻辑看列表中的每个字典项都会被_create_and_add_option展开为语句内的一个Option。引号规则YAML 与生成配置之间存在引号转义约定教程原文的规则若生成的配置中需要string双引号YAML 中应写string若生成的配置中需要string单引号YAML 中应写string。例如文件路径- file: /var/log/apache/access.log生成结果中的写法因「简单参数 vs 类型参数」而异见下文示例作为简单参数时保留引号成为/var/log/apache/access.log作为类型参数值如ip(...)的值时引号由_is_simple_type判定、按值类型直接输出。字符串yes、no等也会按此规则输出。完整实战示例端到端生成配置教程给出了一个完整的 SLS 示例覆盖初始化、全局选项、source/destination/log 与注释写入# 设置配置文件位置 set_location: module.run: - name: syslog_ng.set_config_file - m_name: /home/tibi/install/syslog-ng/etc/syslog-ng.conf # syslog-ng 与 syslog-ng-ctl 二进制所在目录若已在 PATH 中则无需此项 set_bin_path: module.run: - name: syslog_ng.set_binary_path - m_name: /home/tibi/install/syslog-ng/sbin # 写入文件头几行同时清空原有内容 write_version: module.run: - name: syslog_ng.write_version - m_name: 3.6 # 更短的写法一次设置上述变量 set_variables: module.run: - name: syslog_ng.set_parameters - version: 3.6 - binary_path: /home/tibi/install/syslog-ng/sbin - config_file: /home/tibi/install/syslog-ng/etc/syslog-ng.conf # 全局选项 options.global_options: syslog_ng.config: - config: - time_reap: 30 - mark_freq: 10 - keep_hostname: yes source.s_localhost: syslog_ng.config: - config: - tcp: - ip: 127.0.0.1 - port: 1233 destination.d_log_server: syslog_ng.config: - config: - tcp: - 127.0.0.1 - port: 1234 log.l_log_to_central_server: syslog_ng.config: - config: - source: s_localhost - destination: d_log_server some_comment: module.run: - name: syslog_ng.write_config - config: | # Multi line # comment # 另一种写法把注释/已有片段作为 config 语句 config.other_comment_form: syslog_ng.config: - config: | # Multi line # comment执行后生成的文件教程原文含 Salt 生成头部与版本行#Generated by Salt on 2014-08-18 00:11:11 version: 3.6 options { time_reap( 30 ); mark_freq( 10 ); keep_hostname( yes ); }; source s_localhost { tcp( ip( 127.0.0.1 ), port( 1233 ) ); }; destination d_log_server { tcp( 127.0.0.1, port( 1234 ) ); }; log { source( s_localhost ); destination( d_log_server ); }; # Multi line # comment # Multi line # comment注意几点实现细节log语句是无名语句l_log_to_central_server这类 ID 只相当于注释source/destination的引用写法source: s_localhost被_is_reference识别并渲染为source(s_localhost);。注释写入有两种途径module.run调write_config追加原样文本或config.name形式走GivenStatement_build_config_tree对type_ config分支直接以原样字符串构建。从_write_config的实现看配置以追加模式写入因此典型的初始化流程是先用write_version清空重建再逐条追加各语句。更多语句生成示例含源码解析佐证以下示例取自教程的 Examples 章节同时对应 tests/unit/states/test_syslog_ng.py 中的测试用例可对照验证。简单 sourcefile目标配置source s_tail { file( /var/log/apache/access.log, follow_freq(1), flags(no-parse, validate-utf8) ); };对应 YAML三种等价写法之一s_tail: syslog_ng.config: - config: source: - file: - file: /var/log/apache/access.log - follow_freq: 1 - flags: - no-parse - validate-utf8复杂 sourcetcp ip/port/flagss_gsoc2014: syslog_ng.config: - config: source: - tcp: - ip: 0.0.0.0 - port: 1234 - flags: no-parse生成source s_gsoc2014 { tcp( ip(0.0.0.0), port(1234), flags(no-parse) ); };filterf_json: syslog_ng.config: - config: filter: - match: - json:生成filter f_json { match( json: ); };templatet_demo_filetemplate: syslog_ng.config: - config: template: - template: - $ISODATE $HOST $MSG\n - template_escape: - no生成template t_demo_filetemplate { template( $ISODATE $HOST $MSG ); template_escape( no ); };rewriter_set_message_to_MESSAGE: syslog_ng.config: - config: rewrite: - set: - ${.json.message} - value: $MESSAGE生成rewrite r_set_message_to_MESSAGE { set( ${.json.message}, value($MESSAGE) ); };全局 optionsglobal_options: syslog_ng.config: - config: options: - time_reap: 30 - mark_freq: 10 - keep_hostname: yes生成options { time_reap(30); mark_freq(10); keep_hostname(yes); };log 路径与 junction 分支这是最能体现 YAML 表达力的例子——把分支日志处理JSON 与非 JSON 分流表达为junctionchannel每个 channel 内再组合 filter/parser/rewrite/destinationl_gsoc2014: syslog_ng.config: - config: log: - source: s_gsoc2014 - junction: - channel: - filter: f_json - parser: p_json - rewrite: r_set_json_tag - rewrite: r_set_message_to_MESSAGE - destination: - file: - /tmp/json-input.log - template: t_gsoc2014 - flags: final - channel: - filter: f_not_json - parser: - syslog-parser: [] - rewrite: r_set_syslog_tag - flags: final - destination: - file: - /tmp/all.log - template: t_gsoc2014对应生成的目标配置log { source(s_gsoc2014); junction { channel { filter(f_json); parser(p_json); rewrite(r_set_json_tag); rewrite(r_set_message_to_MESSAGE); destination { file( /tmp/json-input.log, template(t_gsoc2014) ); }; flags(final); }; channel { filter(f_not_json); parser { syslog-parser( ); }; rewrite(r_set_syslog_tag); flags(final); }; }; destination { file( /tmp/all.log, template(t_gsoc2014) ); }; };该示例与测试用例LOG_1_CONFIG/test_generate_log_config完全对应源码中_parse_log_statement逐项判定引用source: s_gsoc2014、junction键为junction、内联定义值为列表的键如destination下的file空值列表syslog-parser: []则渲染为空参数选项。版本与二进制路径的处理细节从源码可以确认几个易踩坑的行为set_parameters的version参数并不会直接使用传入值而是调用_determine_config_version(__SYSLOG_NG_BINARY_PATH)重新解析syslog-ng -V输出统计前两个.出现的位置截取主版本号如3.6失败则取前 3 个字符。因此若二进制路径未设置且syslog-ng不在PATH中version解析可能失败——设置参数时务必保证路径正确。start在设置了二进制路径时拼接__SYSLOG_NG_BINARY_PATH/syslog-ng未设置时直接使用syslog-ng两种情况下__opts__[test]都为真时只返回「将要启动的命令」而不真正执行。所有命令均以python_shellFalse执行避免 shell 注入自定义环境变量中PATH会经过salt.utils.stringutils.to_str与salt.utils.data.decode规范化。小结一套可落地的 syslog-ng 管理方案综合教程、执行模块与状态模块源码以及两类单元测试可以总结出推荐的落地顺序用module.runsyslog_ng.set_parameters或分别set_binary_pathset_config_file初始化二进制路径与配置文件用module.runsyslog_ng.write_version清空旧配置并写入version头依次用syslog_ng.config状态形式或短/长 YAML 两种写法生成options、source、destination、filter、parser、rewrite、template、log含 junction/channel等语句用syslog_ng.write_config或config.name追加注释与既有片段部署前用syslog_ng.config_test做语法校验用syslog_ng.version/modules/stats诊断实例用syslog_ng.reloaded/started/stopped控制服务生命周期系统有 service 模块时优先用 service。该模块把 syslog-ng 复杂的文本语法抽象为 YAML 数据驱动同时保留了「原样文本」逃生通道config语句与GivenStatement既适合全量模板化也适合渐进式迁移存量配置。需要进一步阅读的仓库资源包括执行模块源码、状态模块源码、官方使用教程、状态单元测试、执行模块单元测试。赞分享运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载相关推荐Salt 执行模块 npm 完全指南用 SaltStack 自动化管理 NPM 包的生命周期Salt 执行模块 npm 完全指南用 SaltStack 自动化管理 NPM 包的生命周期 本指南围绕 Salt 执行模块 npm 源码位于 salt/m运维配置管理后端Salt 之 win_pki 执行模块基于 PowerShell PKI 的 Windows 证书全生命周期管理Salt 之 win_pki 执行模块基于 PowerShell PKI 的 Windows 证书全生命周期管理 导读 salt.modules.win_pk运维配置管理后端Salt Windows 服务管理完全指南win_service 执行模块与 service 状态编排实战Salt Windows 服务管理完全指南win_service 执行模块与 service 状态编排实战 导读 Windows 服务Services是运维配置管理后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考