超级会员免费看
Puppet工具使用与问题排查指南（上）
RSpec - Puppet测试工具使用
在使用Puppet进行基础设施管理时，测试是确保配置正确的重要环节，RSpec - Puppet是一款强大的测试工具。
安装RSpec - Puppet
可以通过以下命令使用Puppet代理附带的Gem进行安装：
t@mylaptop $ sudo /opt/puppetlabs/puppet/bin/gem install rspec-puppet
也可以使用系统的Gem进行安装，但要注意不同版本的Ruby可能有不同的Gem行为，还可以使用如下命令：
puppet resource package rspec-puppet ensure=installed provider=gem
创建测试示例
以下是创建测试示例的详细步骤：
1.
定义
thing
类
：
class thing {
service {'thing':
ensure => 'running',
enable => true,
require => Package['thing'],
}
package {'thing':
ensure => 'installed'
}
file {'/etc/thing.conf':
content => 'fubar\n',
mode => '0644',
require => Package['thing'],
notify => Service['thing'],
}
}
-
创建
metadata.json文件 ：在模块的根目录下创建该文件，内容如下：
{
"name": "thomas - thing",
"version": "0.0.1",
"author": "Thomas Uphill",
"summary": "Does a thing",
"license": "Apache - 2.0",
"source": "https://github.com/uphillian/thomas - thing",
"project_page": "https://github.com/uphillian/thomas - thing",
"dependencies": [
{ "name":"puppetlabs/stdlib","version_requirement":">= 4.13.1 < 5.0.0" }
],
"data_provider": "hiera",
"description": "Useless module that should do a thing, it doesn't though."
}
- 初始化测试目录 ：运行以下命令：
t@mylaptop ~/puppet]$cd modules/thing
t@mylaptop ~/puppet/modules/thing $ rspec - puppet - init
运行后会创建一系列目录和文件，如下所示：
+ spec/
+ spec/classes/
+ spec/defines/
+ spec/functions/
+ spec/hosts/
+ spec/fixtures/
+ spec/fixtures/manifests/
+ spec/fixtures/modules/
+ spec/fixtures/modules/thing
+ spec/fixtures/manifests/site.pp
+ spec/spec_helper.rb
+ Rakefile
-
创建测试文件
thing_spec.rb：在spec/classes目录下创建该文件，内容如下：
require 'spec_helper'
describe 'thing' do
it { should create_class('thing') }
it { should contain_package('thing') }
it { should contain_service('thing').with('ensure' => 'running' ) }
it { should contain_file('/etc/things.conf') }
end
- 运行测试 ：
t@mylaptop $ rake
运行结果可能会出现失败，例如：
...F...F
Failures:
1) thing should contain File[/etc/things.conf]
Failure/Error: it { should contain_file('/etc/things.conf') }
expected that the catalogue would contain File[/etc/things.conf]
# ./spec/classes/thing_spec.rb:6:in `block (2 levels) in <top (required)>'
2) thing should contain File[/etc/things.conf]
Failure/Error: it { should contain_file('/etc/things.conf') }
expected that the catalogue would contain File[/etc/things.conf]
# ./spec/fixtures/modules/thing/spec/classes/thing_spec.rb:6:in `block (2 levels) in <top (required)>'
Finished in 1.04 seconds (files took 1.03 seconds to load)
8 examples, 2 failures
Failed examples:
rspec ./spec/classes/thing_spec.rb:6 # thing should contain File[/etc/things.conf]
rspec ./spec/fixtures/modules/thing/spec/classes/thing_spec.rb:6 # thing should contain File[/etc/things.conf]
这是因为测试中定义的文件路径
/etc/things.conf
与实际清单中的
/etc/thing.conf
不一致，修改
thing_spec.rb
文件中的路径为
/etc/thing.conf
，再次运行
rake
命令，测试应该就会通过。
RSpec - Puppet工作原理
-
rspec - puppet - init命令会创建一个用于存放测试程序的目录框架，我们主要关注spec/classes目录，每个类的测试文件都放在这里，文件名以被测试的类命名，如thing_spec.rb。 -
测试代码以
require 'spec_helper'开始，用于设置RSpec环境。 -
describe块用于标识要测试的类，将关于该类的断言列表包裹在do .. end块中。 - 断言是我们对类的期望，例如：
-
it { should create_class('thing') }：确保指定的类被创建。 -
it { should contain_package('thing') }：表示类中应该包含名为thing的包资源。 -
it { should contain_service('thing').with('ensure' => 'running' ) }：包含两个断言，一是类中包含thing服务，二是该服务的ensure属性值为running。 -
可以使用
with方法指定资源的属性和值，如it { should contain_file('/tmp/hello.txt').with('content' => "Hello, world\n", 'owner' => 'ubuntu', 'group' => 'ubuntu', 'mode' => '0644' ) }。
Puppet的Noop模式
在Puppet使用过程中，有时候我们需要在不实际执行操作的情况下了解Puppet的计划，这时可以使用Noop模式。
为什么使用Noop模式
- Puppet清单可能不会按预期工作，或者其他人的更改可能未被发现。
- 在将Puppet集成到现有基础设施时，不确定Puppet是否会更新配置文件或重启生产服务，使用Noop模式可以避免意外停机。
- 手动配置更改可能会被Puppet覆盖，使用Noop模式可以提前发现。
如何使用Noop模式
-
创建
noop.pp清单 ：
file {'/tmp/noop':
content => 'nothing',
mode => '0644',
}
-
使用
--noop开关运行puppet apply：
t@mylaptop.example.com $ puppet apply noop.pp --noop
运行结果会显示Puppet计划做什么，但不会实际执行，例如：
Notice: Compiled catalog for mylaptop.example.com.strangled.net in environment production in 0.02 seconds
Notice: /Stage[main]/Main/File[/tmp/noop]/ensure: current_value 'absent', should be 'file' (noop)
Notice: Class[Main]: Would have triggered 'refresh' from 1 event
Notice: Stage[main]: Would have triggered 'refresh' from 1 event
Notice: Applied catalog in 0.02 seconds
-
不使用
--noop选项运行puppet apply：
t@mylaptop.example.com $ puppet apply noop.pp
这时文件会被实际创建，结果如下：
Notice: Compiled catalog for mylaptop.example.com.strangled.net in environment production in 0.01 seconds
Notice: /Stage[main]/Main/File[/tmp/noop]/ensure: defined content as '{md5}3e47b75000b0924b6c9ba5759a7cf15d'
Notice: Applied catalog in 0.02 seconds
Noop模式工作原理
在Noop模式下，Puppet会执行正常操作的所有步骤，但不会对机器进行实际更改（例如
exec
资源不会运行），它会告知你原本会做什么，你可以将其与预期进行比较。
Noop模式的其他用途
- 作为简单的审计工具，检测自Puppet上次应用清单以来机器是否有更改。
-
结合
--debug开关可以查看Puppet在清单中考虑的每个资源的详细信息。 -
在运行Puppet主节点时，可以使用
--trace和--debug选项编译节点的目录，例如：
[root@puppet ~]# puppet master --compile cookbook.example.com --debug --trace --logdest /tmp/cookbook.log
命令输出日志记录
当使用
exec
资源在节点上运行命令时，Puppet会在命令返回非零退出状态时给出错误信息，但有时命令成功返回零退出状态却未达到预期效果，这时可以使用
logoutput
属性记录命令输出。
如何记录命令输出
-
定义
exec资源并设置logoutput参数 ：
exec { 'exec with output':
command => '/bin/cat /etc/hostname',
logoutput => true,
}
- 运行Puppet ：
t@mylaptop $ puppet apply exec.pp
运行结果会显示命令的输出，例如：
Notice: Compiled catalog for mylaptop.example.com in environment production in 0.05 seconds
Notice: /Stage[main]/Main/Exec[exec with output]/returns: mylaptop.example.com
Notice: /Stage[main]/Main/Exec[exec with output]/returns: executed successfully
Notice: Applied catalog in 0.02 seconds
logoutput
属性设置
| 设置值 | 说明 |
|---|---|
false
| 从不打印命令输出 |
on_failure
| 仅在命令失败时打印输出（默认设置） |
true
| 无论命令成功还是失败，总是打印输出 |
可以在
site.pp
文件中设置所有
exec
资源的
logoutput
默认值，例如：
Exec { logoutput => true, }
如果不想看到命令输出，可设置
logoutput => false
。
调试信息日志记录
在调试Puppet问题时，打印特定点的信息非常有用，Puppet的
notify
资源可以实现这一功能。
如何打印调试信息
在清单中想要调查的点定义
notify
资源，例如：
notify { 'Got this far!': }
当应用该资源时，Puppet会打印出信息：
notice: Got this far!
更多用法
-
可以在
notify语句中输出变量，例如：
notify {"operating system is ${facts['os']['name']}": }
Puppet会在打印时插入变量的值，如：
Notice: operating system is Fedora
-
可以像处理其他资源一样处理
notify调用，使用资源链确保其在失败资源之前或之后执行。例如，若exec资源failing exec失败，可以这样链一个notify资源：
notify{"failed exec on ${hostname}": }
-> exec {'failing exec':
command => "/bin/grep ${hostname} /etc/hosts",
logoutput => true,
}
如果不使用资源链或元参数（如
before
或
require
），则无法保证
notify
语句会在感兴趣的其他资源附近执行。
下面是一个简单的mermaid流程图，展示了使用RSpec - Puppet进行测试的基本流程：
graph TD;
A[安装RSpec - Puppet] --> B[定义测试类];
B --> C[创建metadata.json文件];
C --> D[初始化测试目录];
D --> E[创建测试文件];
E --> F[运行测试];
F --> G{测试是否通过};
G -- 否 --> H[修改测试文件];
H --> F;
G -- 是 --> I[完成测试];
Puppet工具使用与问题排查指南（下）
资源排序与调试
在Puppet中，资源的执行顺序可能与源文件中的顺序不同。当使用
notify
资源进行调试时，需要使用资源链来确保
notify
资源在感兴趣的资源之前或之后执行。
资源链示例
假设
exec
资源
failing exec
失败，我们可以使用资源链让
notify
资源在其之前执行：
notify{"failed exec on ${hostname}": }
-> exec {'failing exec':
command => "/bin/grep ${hostname} /etc/hosts",
logoutput => true,
}
如果想让
notify
资源在
failing exec
之后执行，可以使用
require
元参数：
notify { 'Resource X has been applied':
require => Exec['failing exec'],
}
但需要注意，如果
exec
资源失败，依赖它的
notify
资源将被跳过。例如：
notify {'failed exec failed': require => Exec['failing exec'] }
运行Puppet时，会看到如下结果：
t@mylaptop ~/puppet/manifests $ puppet apply fail.pp
...
Error: /bin/grepmylaptop /etc/hosts returned 1 instead of one of [0]
Error: /Stage[main]/Main/Exec[failing exec]/returns: change from notrun to 0 failed: /bin/grepmylaptop /etc/hosts returned 1 instead of one of [0]
Notice: /Stage[main]/Main/Notify[failed exec failed]: Dependency Exec[failing exec] has failures: true
Warning: /Stage[main]/Main/Notify[failed exec failed]: Skipping because of failed dependencies
Notice: Finished catalog run in 0.06 seconds
资源排序的重要性
资源排序不当可能导致调试信息不准确或无法获取。通过合理使用资源链和元参数，可以确保
notify
资源在合适的时机执行，帮助我们更好地调试问题。更多关于资源排序的信息可以参考相关文档。
生成报告
在使用Puppet管理基础设施时，生成报告可以帮助我们了解系统的状态和变化。虽然原文未详细介绍生成报告的具体步骤，但我们可以简单提及相关概念。
报告的作用
- 监控系统状态：了解资源的配置情况、服务的运行状态等。
- 发现问题：及时发现配置错误、资源冲突等问题。
- 合规性检查：确保系统符合相关标准和规定。
可能的报告类型
- 资源报告：显示系统中各种资源的配置和状态。
- 变更报告：记录资源的变更历史。
- 错误报告：汇总系统中出现的错误信息。
自动生成HTML文档
自动生成HTML文档可以帮助我们更好地理解和管理Puppet代码。虽然原文未给出具体实现方法，但我们可以推测其大致流程。
文档的作用
- 代码说明：对Puppet代码进行详细解释，方便团队成员理解。
- 知识传承：新成员可以通过文档快速了解系统的配置和管理方式。
- 合规性文档：满足相关合规性要求。
可能的实现方式
- 使用工具：如Puppet自带的工具或第三方工具。
- 脚本生成：编写脚本自动提取代码信息并生成HTML文档。
绘制依赖图
绘制依赖图可以直观地展示资源之间的依赖关系，帮助我们更好地理解和管理Puppet代码。同样，原文未详细介绍绘制依赖图的方法，我们可以简单说明其重要性。
依赖图的作用
- 理解代码结构：清晰地看到资源之间的依赖关系，便于代码维护。
- 发现潜在问题：如循环依赖等问题。
- 优化配置：根据依赖关系优化资源的配置和部署。
理解Puppet错误
在使用Puppet过程中，遇到错误是很常见的。理解错误信息可以帮助我们快速定位和解决问题。
错误信息分析
当Puppet出现错误时，会输出详细的错误信息，我们需要仔细分析这些信息。例如，在使用
exec
资源时，如果命令返回非零退出状态，会有如下错误信息：
Notice: /Stage[main]/Main/Exec[/bin/cat /tmp/missing]/returns: /bin/cat: /tmp/missing: No such file or directory
Error: /bin/cat /tmp/missing returned 1 instead of one of [0]
Error: /Stage[main]/Main/Exec[/bin/cat /tmp/missing]/returns: change from notrun to 0 failed: /bin/cat /tmp/missing returned 1 instead of one of [0]
从这些信息中，我们可以知道命令执行失败的原因是文件不存在。
调试技巧
-
使用
--debug开关：查看详细的调试信息。 -
使用
--trace选项（主节点）：编译节点目录时获取更多信息。
检查配置设置
检查配置设置可以确保Puppet按照我们的预期工作。
配置文件检查
Puppet的配置文件（如
puppet.conf
）包含了各种配置选项，我们需要检查这些选项是否正确。例如，在使用Noop模式时，可以在
puppet.conf
文件的
[agent]
或
[main]
部分添加
noop=true
。
资源默认值检查
可以通过设置资源默认值来统一管理资源的配置。例如，在
site.pp
文件中设置
Exec
资源的
logoutput
默认值：
Exec { logoutput => true, }
下面是一个mermaid流程图，展示了Puppet问题排查的基本流程：
graph TD;
A[发现问题] --> B[查看错误信息];
B --> C{是否能定位问题};
C -- 是 --> D[解决问题];
C -- 否 --> E[使用调试工具];
E --> F[分析调试信息];
F --> C;
D --> G[验证解决方案];
G --> H{问题是否解决};
H -- 否 --> A;
H -- 是 --> I[完成排查];
综上所述，在使用Puppet进行基础设施管理时，我们可以通过各种工具和方法来确保配置的正确性、监控系统状态、排查和解决问题。合理运用RSpec - Puppet进行测试、使用Noop模式进行预演、记录命令输出和调试信息等，都可以帮助我们更好地管理和维护系统。
扫一扫
931
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
