在很多項目中，我使用Vagrant和Puppet來獲得開發環境的副本。有時特別是在小型項目中，我經常需要做出改變，我重新設置了流浪盒，並且它失敗了！流浪環境的自動化測試

是否有可能使用持續集成測試Vagrant框？

我需要檢查框的規定沒有錯誤，並運行一些自定義測試，如打開一個網頁。

2017-07-15 SebTM

您可以在這裏問了幾個不同的事情。你能舉一個你想要做什麼的例子嗎？ –

我希望CI運行一個流浪漢，檢查退出代碼，然後它應該執行一些自定義測試，如調用網頁。 – SebTM

流浪VS其他選擇進行驗收測試

我細講之前，流浪絕對是接受本地測試，因爲它是超級容易安裝的選擇。然而，在CI環境下測試要困難得多，因爲你必須設置所有不同的部分才能正常工作（Ruby，Vagrant，Virtualbox等）。 Docker是一個不錯的選擇，因爲它是輕量級的，並且大量的CI工具都內置了基於Docker的測試（例如Travis，Gitlab CI，CircleCI）。

我會詳細介紹使用Docker的here。這並不完美，因爲容器不是真正的機器：你不能測試諸如sysctl或swap之類的東西。但是對於測試一個基本的Puppet模塊（包，配置文件服務）來說很好。

你有什麼就用它來測試你的木偶代碼兩個主要選擇：

燒杯rspec的

燒杯在木偶由發佈工程團隊寫入測試木偶企業堆棧的工具。後來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

然後，使用環境變量來選擇木偶版安裝調用測試等（它會默認爲木偶的最新版本和任何框你」 VE設置爲默認）：

$ 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'...

有大量的輸出（設置我的日誌詳細，但你可以把它只能說明失敗也有），但最終你會得到通過的測試：

這裏有一個燒杯rspec的答案我介紹了Serverfault：

https://serverfault.com/questions/807316/puppet-test-roles-in-control-repo-with-beaker-rspec

這裏的解釋燒杯的RSpec和木偶其他一些環節：

試驗廚房

試驗廚房實際上是一個廚師工具，但有人分叉它來支持木偶（和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

這裏有幾個不錯的鏈接sumarising：

來源

2017-07-16 19:35:49

流浪環境的自動化測試

回答

流浪VS其他選擇進行驗收測試

燒杯rspec的

試驗廚房

相關問題