在许多项目中，我使用Vagrant和Puppet来获得用于开发的实时环境的副本。 有时特别是在小型项目中，我经常需要进行更改，我重新配置了流浪盒，但它失败了！
是否有可能使用持续集成测试Vagrant框？
我需要检查该框没有错误，并运行一些自定义测试，如打开一个网页。
In many projects I use Vagrant with Puppet to have a copy of the live environment for development. Sometimes especially at small projects often I have to make a change, I re-provision the vagrant box and it fails!
Is there a possibility to test the Vagrant box using Continuous Integration?
I need to check that the box provisions without an error, and run some custom tests, such as opening a web page.
最满意答案
Vagrant与其他验收测试选择
在详细介绍之前，Vagrant绝对是本地验收测试的首选，因为它非常易于设置。 但是，在CI环境中进行测试要困难得多，因为您必须设置所有各种部分才能使其正常工作（Ruby，Vagrant，Virtualbox等）。 Docker是一个不错的选择，因为它很轻巧，而且很多CI工具都内置了基于Docker的测试（例如Travis，Gitlab CI，CircleCI）。
我在这里详细介绍如何使用Docker。 它并不完美，因为容器不是真正的机器：你无法测试像sysctl或swap这样的东西。 但它有利于测试基本的Puppet模块（包，配置文件服务）。
您有两个主要选择来测试您的Puppet代码：
烧杯的RSpec
Beaker是Puppet的Release Engineering团队编写的一个工具，用于测试Puppet Enterprise堆栈。 后来Beaker-rspec诞生了，为Puppet模块测试提供了更加类似rspec的体验。
您编写的验收测试如下所示：
require 'spec_helper_acceptance' describe 'cockpit class' do context 'default parameters' do # Using puppet_apply as a helper it 'should work idempotently with no errors' do pp = <<-EOS class { '::cockpit': } EOS # Run it twice and test for idempotency apply_manifest(pp, :catch_failures => true) apply_manifest(pp, :catch_changes => true) end describe package('cockpit') do it { is_expected.to be_installed } end describe service('cockpit') do # it { is_expected.to be_enabled } it { is_expected.to be_running } end context 'Cockpit should be running on the default port' do describe command('sleep 15 && echo "Give Cockpit time to start"') do its(:exit_status) { should eq 0 } end describe command('curl 0.0.0.0:9090/') do its(:stdout) { should match /Cockpit/ } end end end end然后针对选定的“管理程序”运行测试。 所以在你的情况下，这将是流浪汉，我假设使用Virtualbox。
您配置主机配置文件，如下所示：
HOSTS: centos-72-x64: roles: - master platform: el-7-x86_64 box: puppetlabs/centos-7.2-64-nocm hypervisor: vagrant CONFIG: type: foss然后使用环境变量调用测试以选择要安装的Puppet版本等（它将默认为Puppet的最新版本以及您设置为默认的任何框）：
$ PUPPET_INSTALL_VERSION="1.5.2" PUPPET_INSTALL_TYPE=agent BEAKER_set="centos-7-x64" bundle exec rake acceptance /Users/petersouter/.rbenv/versions/2.3.3/bin/ruby -I/Users/petersouter/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.4/lib:/Users/petersouter/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rspec-support-3.5.0/lib /Users/petersouter/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.4/exe/rspec spec/acceptance /Users/petersouter/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/beaker-rspec-5.3.0/lib/beaker-rspec/helpers/serverspec.rb:43: warning: already initialized constant Module::VALID_OPTIONS_KEYS /Users/petersouter/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/specinfra-2.67.2/lib/specinfra/configuration.rb:4: warning: previous definition of VALID_OPTIONS_KEYS was here Beaker::Hypervisor, found some vagrant boxes to create ==> centos-72-x64: VM not created. Moving on... Bringing machine 'centos-72-x64' up with 'virtualbox' provider... ==> centos-72-x64: Importing base box 'puppetlabs/centos-7.2-64-nocm'...有很多输出（我将我的日志设置为详细，但你也可以让它只在失败时显示），但最终你会得到一个通过测试：
以下是我在Serverfault上给出的Beaker-rspec的答案：
https://serverfault.com/questions/807316/puppet-test-roles-in-control-repo-with-beaker-rspec以下是解释Beaker-rspec和Puppet的其他一些链接：
http://razorconsulting.com.au/setting-up-puppet-module-testing-from-scratch-part-ii-beaker-for-module-testing.html https://simp-project.atlassian.net/wiki/display/SD/Debugging+Acceptance+Tests+Using+Beaker测试厨房
test-kitchen实际上是一个Chef工具，但有人将它分叉以支持Puppet（和Ansible）。 我没有这方面的经验，但基本上它以一种非常类似的方式工作：你设置一个配置来测试，比如一个Vagrant盒子，然后以spec文件的形式编写测试：
require 'serverspec' include Serverspec::Helper::Exec include Serverspec::Helper::DetectOS RSpec.configure do |c| c.before :all do c.path = '/sbin:/usr/sbin' end end describe package('ntp') do it { should be_installed } end describe service('ntp') do it { should be_running } end这里有一些很好的链接：
https://www.cedric-meury.ch/2016/10/test-driven-infrastructure-with-puppet-docker-test-kitchen-and-serverspec-yury-tsarev-gooddata/ http://ehaselwanter.com/en/blog/2014/05/08/using-test-kitchen-with-puppet/Vagrant vs other choices for acceptance testing
Before I go into detail, Vagrant is definitely the choice for acceptance testing locally as it's super easy to setup. However, it's much harder to test in a CI environment, because you have to setup all the various pieces to get it working (Ruby, Vagrant, Virtualbox etc). Docker is a good choice as it's lightweight, and plenty of CI Tooling have Docker based testing built in (eg. Travis, Gitlab CI, CircleCI).
I go into detail here about using Docker. It's not perfect, as a container isn't a real machine: you can't test things like sysctl, or swap. But it's good for testing a basic Puppet module (package, config file service).
You have a two main choices on what to use to test your Puppet code:
Beaker-rspec
Beaker is a tool written by the Release Engineering team at Puppet to test the Puppet Enterprise stack. Later Beaker-rspec was born, to give a more rspec-like experience with Puppet module testing.
You write acceptance tests that look like this:
require 'spec_helper_acceptance' describe 'cockpit class' do context 'default parameters' do # Using puppet_apply as a helper it 'should work idempotently with no errors' do pp = <<-EOS class { '::cockpit': } EOS # Run it twice and test for idempotency apply_manifest(pp, :catch_failures => true) apply_manifest(pp, :catch_changes => true) end describe package('cockpit') do it { is_expected.to be_installed } end describe service('cockpit') do # it { is_expected.to be_enabled } it { is_expected.to be_running } end context 'Cockpit should be running on the default port' do describe command('sleep 15 && echo "Give Cockpit time to start"') do its(:exit_status) { should eq 0 } end describe command('curl 0.0.0.0:9090/') do its(:stdout) { should match /Cockpit/ } end end end endThen you run the tests against a chosen "hypervisor". So in your case that would be vagrant, I'm assuming using Virtualbox.
You configure a host config file like so:
HOSTS: centos-72-x64: roles: - master platform: el-7-x86_64 box: puppetlabs/centos-7.2-64-nocm hypervisor: vagrant CONFIG: type: fossThen invoke the test using environment variables to chose Puppet version to install and such (it will default to the latest release of Puppet and whatever box you've set as default):
$ PUPPET_INSTALL_VERSION="1.5.2" PUPPET_INSTALL_TYPE=agent BEAKER_set="centos-7-x64" bundle exec rake acceptance /Users/petersouter/.rbenv/versions/2.3.3/bin/ruby -I/Users/petersouter/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.4/lib:/Users/petersouter/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rspec-support-3.5.0/lib /Users/petersouter/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.4/exe/rspec spec/acceptance /Users/petersouter/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/beaker-rspec-5.3.0/lib/beaker-rspec/helpers/serverspec.rb:43: warning: already initialized constant Module::VALID_OPTIONS_KEYS /Users/petersouter/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/specinfra-2.67.2/lib/specinfra/configuration.rb:4: warning: previous definition of VALID_OPTIONS_KEYS was here Beaker::Hypervisor, found some vagrant boxes to create ==> centos-72-x64: VM not created. Moving on... Bringing machine 'centos-72-x64' up with 'virtualbox' provider... ==> centos-72-x64: Importing base box 'puppetlabs/centos-7.2-64-nocm'...There's a lot of output (I set my logs to verbose, but you can make it only show on failure also), but eventually you get a passing test:
Here's an answer on Beaker-rspec I gave on Serverfault:
https://serverfault.com/questions/807316/puppet-test-roles-in-control-repo-with-beaker-rspecHere's some other links explaining Beaker-rspec and Puppet:
https://alexharv074.github.io/2016/05/13/setting-up-puppet-module-testing-from-scratch-part-ii-beaker-for-module-testing.html https://simp-project.atlassian.net/wiki/display/SD/Debugging+Acceptance+Tests+Using+BeakerTest-kitchen
test-kitchen is actually a Chef tool, but someone forked it to support Puppet (and Ansible). I haven't had as much experience with this, but essentially it works in a very similar way: you set up a configuration to test against, such as a Vagrant box, then write tests in the form of spec files:
require 'serverspec' include Serverspec::Helper::Exec include Serverspec::Helper::DetectOS RSpec.configure do |c| c.before :all do c.path = '/sbin:/usr/sbin' end end describe package('ntp') do it { should be_installed } end describe service('ntp') do it { should be_running } endHere's a few good links sumarising:
https://www.cedric-meury.ch/2016/10/test-driven-infrastructure-with-puppet-docker-test-kitchen-and-serverspec-yury-tsarev-gooddata/ http://ehaselwanter.com/en/blog/2014/05/08/using-test-kitchen-with-puppet/更多推荐
发布评论