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 Windows Server, your workstation can run macOS, Windows, or Linux.
| Generally speaking, your workstation can run macOS, Windows, or Linux. However, when you run Test Kitchen with Hyper-V, you need to run a version of Windows that supports Hyper-V as your workstation. |
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 with this configuration:
- A workstation running Windows 10 on VMware Fusion, Chef Development Kit 1.2.22.
- Windows Server 2012 R2 instances on Microsoft Hyper-V, Chef client 12.19.36.
