ContributorsIn the Manage a node with Chef server module, you built a basic web server configuration. As part of the process, you set up a Chef server, brought up a node to manage, and bootstrapped your node.
The bootstrap process installed the Chef tools on your node, pulled the latest cookbooks from the Chef server, and performed an initial chef-client run on your node. After the bootstrap process completed, you made small changes to your web server cookbook and applied those changes to your node. The overall process looks like this:
- Write a small amount of Chef code that expresses some new policy or feature.
- Upload your code to the Chef server.
- Run
chef-client to apply the updated policy on your node. - Log in to your node and manually verify that it's configured as you expect.
- Repeat the process.
In Manage a node with Chef server, you applied a change to your web configuration that failed on your node. Imagine your node represented a piece of your production infrastructure. How could you detect the failure before the change reached production?
Although many teams first verify changes on test infrastructure before applying those changes to production, you can quickly experiment with new features and test configuration changes on temporary test instances using Test Kitchen.
Test Kitchen runs your infrastructure code in an isolated environment that resembles your production environment. With Test Kitchen, you continue to write your Chef code from your workstation, but instead of uploading your code to the Chef server and applying it to a node, Test Kitchen applies your code to a temporary environment, such as a virtual machine on your workstation or a cloud or container instance.
We consider using a temporary environment to be local development, no matter where that environment is located. With local development, you can iterate faster and correct mistakes earlier in the development process. Once you've written and verified your code locally, you can upload your cookbooks to the Chef server, bootstrap your node, and run chef-client on your node.
Local development shifts the development workflow to one that focuses on correcting mistakes earlier in the development process, before you apply your changes to production systems. In this workflow, you:
- Write a small amount of Chef code that expresses some new policy or feature.
- Verify your change on local test instances.
- Upload your code to the Chef server.
- Run
chef-client to apply the updated policy on your node. - Repeat the process.
Compare this diagram with the previous one. You see that the verification step occurs earlier in the process, before you upload changes to the Chef server and run chef-client on your node.
Another benefit to using Test Kitchen is that the operating system of your virtual environment doesn't need to match your workstation's. So even though you're configuring CentOS, your workstation can run macOS, Windows, or Linux.
In this module, you'll use Test Kitchen to apply the web server configuration you built in the Manage a node with Chef server module on local test instances. You'll also see how Test Kitchen enables you to experiment and correct mistakes earlier in the development process.
- Test configuration
This module was last tested on 27 April 2018 using this configuration:
- A workstation running Ubuntu 16.04, Chef Development Kit 2.5.3 (ChefDK is a precursor to Chef Workstation).
- CentOS 7 instances on Google Compute Engine, Chef client 14.0.202.
Although we recommend the latest software versions, the output you see may vary depending on your environment and the software versions you use.
