A Test Kitchen Provisioner for Puppet
Ruby Puppet
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
lib bump version Aug 12, 2018
spec ci Aug 12, 2018
.gitignore Ignore /bundle directory Sep 9, 2015
.rspec Initial commit of unit testing framework Jun 16, 2015
.rubocop.yml ci Dec 13, 2017
.travis.yml ci Aug 12, 2018
CHANGELOG.md prep for release 3.2.0 Oct 19, 2017
Gemfile ci Dec 13, 2017
README.md template docs Dec 13, 2017
Rakefile Adds rake tasks to make releasing this gem easier Sep 1, 2017
TESTING.md support facter files Nov 11, 2015
kitchen-puppet.gemspec ci Dec 13, 2017
provisioner_options.md add r10k support Jun 27, 2018

README.md

Kitchen Puppet

Gem Version Gem Downloads Build Status

kitchen-puppet

A Test Kitchen Provisioner for Puppet

The providers supports both puppet apply and puppet agent clients and puppet bolt.

The PuppetApply provider works by passing the puppet repository based on attributes in .kitchen.yml & calling puppet apply.

The PuppetAgent provider works by passing the puppetmaster and other attributes in .kitchen.yml & calling puppet agent.

The PuppetBolt provider works by passing the puppet bolt commands based on attributes in .kitchen.yml & calling puppet bolt.

This provider has been tested against the Ubuntu 1604 and Centos 7 boxes running in docker and vagrant/virtualbox.

Template

Template project for using kitchen for puppet development:

https://github.com/scoopex/puppet-kitchen_template

Resources

Install

  1. install the latest Ruby on your workstations (for windows see https://rubyinstaller.org/downloads/)

  2. From a Command prompt:

  • gem install librarian-puppet
  • gem install test-kitchen (or gem install test-kitchen -v 1.16.0 if using ruby version less than 2.3)
  • gem install kitchen-puppet

Requirements

It is recommended to have a metadata.json file of your puppet module. It is used by kitchen-puppet to configure the module path. The puppet docs describe (https://docs.puppetlabs.com/puppet/latest/reference/modules_publishing.html#write-a-metadatajson-file) how to create one.

You'll need a driver box without a chef installation so puppet can be installed. Puppet have one at http://puppet-vagrant-boxes.puppetlabs.com/ubuntu-server-12042-x64-vbox4210-nocm.box or http://puppet-vagrant-boxes.puppetlabs.com/centos-65-x64-virtualbox-nocm.box.

For PuppetAgent a server with a puppet master is required that can resolve the hostname ip address of the server. The server must also be able to resolve the hostname ip address of the puppet master.

You can also use the PuppetApply driver with a docker container, provided the necessary box requirements to install puppet are included inside the container. The easiest way to do this is to supply Kitchen-Docker with a custom dockerfile to install the needed dependencies for puppet installation.

Windows Support

There is windows/winrm support, currently not all functionality is supported.

  • require_chef_for_busser: false (it is possible to call rspec over winrm to run the tests)
  • resolve_with_librarian_puppet: false (librarian-puppet is not working on windows server)

Sample Puppet Repositories

Using Environments

In the root directory for your puppet repository:

Create a .kitchen.yml, much like one the described above:

    ---
    driver:
      name: vagrant

    provisioner:
      name: puppet_apply
      puppet_environment: dev
# the puppet environmnt files can be in this repository
      puppet_environment_config_path: environment/dev/environment.conf
      manifests_path:  environment/dev/manifests
      modules_path: environment/dev/modules_mycompany
# or external to this repository as long as they are accessible
#     puppet_environment_config_path: /my_environments/dev/environment.conf
#     manifests_path:                 /my_environments/dev/manifests
#     modules_path:                   /my_environments/dev/modules_mycompany
      hiera_data_path: /repository/puppet_repo/hieradata

    platforms:
    - name: nocm_ubuntu-12.04
      driver_plugin: vagrant
      driver_config:
        box: nocm_ubuntu-12.04
        box_url: http://puppet-vagrant-boxes.puppetlabs.com/ubuntu-server-12042-x64-vbox4210-nocm.box

    suites:
     - name: default

Sample Puppet Repositories

Test-Kitchen Serverspec

To run the verify step with the test-kitchen serverspec setup your puppet repository as follows:

In the root directory for your puppet repository:

Create a .kitchen.yml, much like one the described above:

    ---
    driver:
      name: vagrant

    provisioner:
      name: puppet_apply
      manifests_path: /repository/puppet_repo/manifests
      modules_path: /repository/puppet_repo/modules-mycompany
      hiera_data_path: /repository/puppet_repo/hieradata

    platforms:
    - name: nocm_ubuntu-12.04
      driver_plugin: vagrant
      driver_config:
        box: nocm_ubuntu-12.04
        box_url: http://puppet-vagrant-boxes.puppetlabs.com/ubuntu-server-12042-x64-vbox4210-nocm.box

    suites:
     - name: default

Then for serverspec:

  mkdir -p test/integration/default/serverspec/localhost
  echo "require 'serverspec'" >> test/integration/default/serverspec/spec_helper.rb
  echo "set :backend, :exec" >> test/integration/default/serverspec/spec_helper.rb

Create your serverspec tests in test/integration/default/serverspec/localhost/xxxxxx_spec.rb:

  require 'spec_helper'

  if os[:family] == 'ubuntu'
        describe '/etc/lsb-release' do
          it "exists" do
              expect(file('/etc/lsb-release')).to be_file
          end
        end
  end

  if os[:family] == 'redhat'
    describe '/etc/redhat-release' do
      it "exists" do
          expect(file('/etc/redhat-release')).to be_file
      end
    end
  end

Test-Kitchen Beaker

test-kitchen normally uses tests setup in test/integration/.... directory. Beaker format puts the tests with the spec/acceptance directory in the puppet repository and the spec_helper.rb under the spec directory which is more logical.

For examples see:

To implement this with test-kitchen setup the puppet repository with:

  • the spec files with the spec/acceptance directory.

  • the spec_helper in the spec folder.

  • install kitchen-verifier-serverspec on your workstation i.e. 'gem install kitchen-verifier-serverspec'

See examples:

.
+-- spec
¦   +-- acceptance
¦   ¦   +-- mariadb_spec.rb
¦   ¦   +-- nginx_spec.rb
¦   ¦
    +-- spec_helper.rb

In the root directory for your puppet repository create a .kitchen.yml with

  • a verifier of 'serverspec'
  • a pattern parameter with the spec tests to run
verifier:
  name: serverspec

suites:
  - name: base
    verifier:
      patterns:
      - modules/mycompany_base/spec/acceptance/base_spec.rb

See kitchen-verifier-serverspec

hiera_writer_files option

Allows creation of arbitrary YAML files in the target instance's hieradata/ dir in test-kitchen configuration (eg kitchen.yml). Like setting chef attributes in kitchen.yml, except for Hiera YAML files.

set hiera_writer_files in kitchen.yml

---
driver:
  name: vagrant

provisioner:
  name: puppet_apply
  manifests_path: /repository/puppet_repo/manifests
  modules_path: /repository/puppet_repo/modules-mycompany
  hiera_data_path: /repository/puppet_repo/hieradata
  hiera_writer_files:
    - datacenter/vagrant.yaml:
        logstash_servers: []
        hosts:
          10.1.2.3:
          - puppet
          - puppetdb

platforms:
- name: nocm_ubuntu-12.04
  driver_plugin: vagrant
  driver_config:
    box: nocm_ubuntu-12.04
    box_url: http://puppet-vagrant-boxes.puppetlabs.com/ubuntu-server-12042-x64-vbox4210-nocm.box

suites:
 - name: default

The above configuration will result in the creation of a file on the guest named ${hieradata}/datacenter/vagrant.yaml containing:

---
logstash_servers: []
  hosts:
    10.1.2.3:
    - puppet
    - puppetdb

It will overwrite any existing Hiera YAML files with the same name (on the guest), not merge.

Provisioner Options

Please see the Provisioner Options (https://github.com/neillturner/kitchen-puppet/blob/master/provisioner_options.md).

Contributing

To contribute to the repository, please follow the Fork / PR model:

  1. Fork The Repository
  2. Work on epic changes
  3. Write tests for your changes, see TESTING
  4. Update Documentation
  5. Commit
  6. Push
  7. Create PR
  8. Profit(?)