Chef - Available Testing Frameworks - InSpec and ChefSpec

1 hour
  • 12 Learning Objectives

About this Hands-on Lab

In this lab, we will demonstrate an understanding of Chef Testing Frameworks by using InSpec and ChefSpec with ChefDK and then using Chef Kitchen.

First, we’ll install the ChefDK tools on a server and make sure that Docker is working. Then, we need to ensure that Git is installed and has some basic configuration. Next, we’ll see how much we know about local cookbook development by creating one that installs software and uses InSpec and ChefSpec.

At the end of this hands-on Lab, we will have installed ChefDK tools, configured it, and have a custom-developed cookbook that we’ve tested with Docker and Kitchen.

Learning Objectives

Successfully complete this lab by achieving the following learning objectives:

On the Provided Server, Install Version 2.4.17 of the ChefDK Tools
  1. We need to download the correct version of ChefDK, which is 2.4.17. In a command line, run:

  2. Now install it:

    sudo rpm -ivh chefdk-2.4.17-1.el7.x86_64.rpm
  3. Once it’s installed, we need to make sure Chef uses the correct system locations for things:

    echo 'eval "$(chef shell-init bash)"' >> ~/.bash_profile
    source ~/.bash_profile
  4. Now check to see if it worked with which ruby and we should see /opt/chefdk/embedded/bin/ruby get returned.

Install What docker-ce Requires on This Server
  1. We need Docker on our workstation so we will need to run the following commands:

    sudo yum-config-manager --add-repo 
    sudo yum-config-manager --setopt="docker-ce-stable.baseurl=" --save 
    sudo yum-config-manager --add-repo= 
    sudo rpm --import 
    sudo yum install -y container-selinux docker-ce
  2. Now, let’s start Docker and enable it to start on system boot:

    sudo systemctl start docker
    sudo systemctl enable docker
  3. We should also set your user to be able to use Docker without using the sudo command. Once we’ve done this, we have to log out and back in again:

    sudo usermod -aG docker $USER
  4. Use SSH to get back in again and check to make sure Docker is running:

    docker ps

    If we can do that without prefacing it with sudo, we’re ready to continue.

Install Git and Set Some Global Defaults for Our User, Email Address, and Editor

When we use Kitchen later in the lab, we need Git to be installed and set up with some basic information. These commands will make that happen.

  1. Install it:

    sudo yum -y install git
  2. Configure some Git basics like the username, email address, and a default text editor:

    git config --global "USERNAME"
    git config --global "YOUREMAIL@DOMAIN.COM"
    git config --global core.editor vim

    Note: We can use fake email information since we don’t actually use it for this lab. It just needs to be set or we will get errors later.

Install the Gem Required for Using Docker with the Test Kitchen
  1. Docker requires a gem for this all to work. Install it with this:

    gem install kitchen-docker
Update SELinux to Be Permissive
  1. To perform the tasks properly, you should change SELinux so that it is permissive:

    sudo setenforce permissive
  2. We should also edit /etc/selinux/config and change things to permissive there too:

    sudo vim /etc/selinux/config

    Change the SELINUX line from SELINUX=enforcing to SELINUX=permissive.

Create a Cookbook for Use with These Tasks, and Call It la_testing
  1. Create the cookbook with this command:

    chef generate cookbook la_testing
  2. Now, change to the newly created directory:

    cd la_testing
Edit Our kitchen.yml File
  1. Edit kitchen.yml:

    vim .kitchen.yml
  2. In the top section, replace vagrant with docker and add some things. When we’re done, that top section should look like this:

      name: docker
      privileged: true
      use_sudo: false

    Remember that this is YAML, so we need to make sure we have the right number of spaces in spots. Those lines under driver are all indented two spaces.

  3. Down in the provisioner section, we need to add a name and version. It should look like this when we’re done:

      name: chef_zero
      # You may wish to disable always updating cookbooks in CI or other testing environments.
      # For example:
      #   always_update_cookbooks: <%= !ENV['CI'] %>
      always_update_cookbooks: true
      product_name: "chef"
      product_version: "13.8.5"
  4. We’re on a CentOS machine so we need to get rid of ubuntu from the file. Just delete (or comment out) the line in the platforms section that reads:

      - name: ubuntu-16.04

That’s it for kitchen.yml edits. Write and quit so that we can get back to the command prompt.

Edit the Default Recipe to Install net-tools and httpd
  1. Edit the default recipe:

    vim recipes/default.rb
  2. Add this to the end of the file:

    ['net-tools','httpd'].each do |pkg|
      package pkg do
       action :install
Update the InSpec Test to Test for net-tools and httpd
  1. Edit the InSpec test:

    vim test/smoke/default/default_test.rb
  2. At the end of this file, we need to add:

    ['net-tools','httpd'].each do |pkg|
      describe package(pkg) do
       it { should be_installed }
Update the ChefSpec Test, Removing Ubuntu Tests and Adding Tests for net-tools and httpd
  1. We’ve finished the InSpec portion of our tests. Now, let’s edit the ChefSpec test so that it does what we need it to:

    vim spec/unit/recipes/default_spec.rb
  2. Here, we want to remove any reference to Ubuntu tests. Let’s erase lines 10-22 (the whole first context section):

      context 'When all attributes are default, on Ubuntu 16.04' do
        let(:chef_run) do
          # for a complete list of available platforms and versions see:
          runner = 'ubuntu', version: '16.04')
        it 'converges successfully' do
          expect { chef_run }.to_not raise_error
  3. We should just have a CentOS section now. Let’s add our test to this (for net-tools and httpd). The whole section should look like this:

    describe 'la_testing::default' do
      context 'When all attributes are default, on CentOS 7.4.1708' do
        let(:chef_run) do
          # for a complete list of available platforms and versions see:
          runner = 'centos', version: '7.4.1708')
        it 'converges successfully' do
          expect { chef_run }.to_not raise_error
        it 'installs httpd' do
          expect(chef_run).to install_package('httpd')
        it 'installs net-tools' do
          expect(chef_run).to install_package('net-tools')
  4. Save this file and let’s run some tests!

Run the ChefSpec Test
  1. We’re going to run the ChefSpec test that we just altered with this command:

    chef exec rspec --color -fd

    If everything passes, we can move on.

Trust, but Verify, with Kitchen
  1. To test if this cookbook works, we’ll run:

    kitchen verify
  2. You may also notice, in the end of the output, that our InSpec test gets run. If that all looks good, we’re done. Clean up the mess with this:

    kitchen destroy

Additional Resources

We have several tasks that need to be completed:

  1. Set up the environment for use with the rest of the tasks by installing Chef, Docker, Git, and the Chef gem for Docker:
    • Install version 2.4.17 of the ChefDK tools.
    • Install Docker CE and all that it requires, start it up, then make it start at boot:
      • Modify our group membership so we don't need to run sudo all the time.
    • Install Git and configure a name, email, and default editor.
    • Install the gem allowing Kitchen and Docker to work together.
    • Set SELinux to allow us to work through the rest of the steps.
  2. Create a cookbook called la_testing.
  3. Modify the default .kitchen.yml to use Docker and CentOS 7.
  4. Update the default recipe to install Net Tools and Apache.
  5. Update the InSpec test to test Net Tools and Apache.
  6. Update the ChefSpec test to both remove Ubuntu tests and add tests for Net Tools and Apache.
  7. Run the tests for ChefSpec via the rspec command. Tests should pass.
  8. Use the correct kitchen command to test whether or not the cookbook will converge properly.
  9. If there are problems, fix them and test again.

If you need help with these tasks, please see the accompanying video or hands-on lab guide.

What are Hands-on Labs

Hands-on Labs are real environments created by industry experts to help you learn. These environments help you gain knowledge and experience, practice without compromising your system, test without risk, destroy without fear, and let you learn from your mistakes. Hands-on Labs: practice your skills before delivering in the real world.

Get Started
Who’s going to be learning?

How many seats do you need?

  • $499 USD per seat per year
  • Billed Annually
  • Renews in 12 months

Ready to accelerate learning?

For over 25 licenses, a member of our sales team will walk you through a custom tailored solution for your business.


Sign In
Welcome Back!

Psst…this one if you’ve been moved to ACG!