The blending of development and IT operations into a culture of shared goals and objectives — commonly referred to as DevOps — is a pipe dream for some and a nightmare for others. Where your organization falls in this cultural landscape may vary considerably from what others are doing.
Some resist change in themselves as much as they complain about the other side: Developers blast the systems team for slowness of the deployment process and the operations team complains about developers rushing to add features while compromising security and quality control. Entering into this fray in an attempt to help alleviate the chaos, Chef is an open-source automation tool — available in cloud-hosted and on-premises varieties — that helps turn IT configuration and infrastructure management into code. Embedded below is a quick Chef overview that will help get you up to speed on what Chef does.
Chef is essentially an automation tool. It uses the core components of a workstation and a server to create and run sets of instructions, called recipes and cookbooks, on target nodes. A recipe is a single file that contains one or more resources, and the instructions for that resource. A resource can be practically anything: A Windows service, a file, and even a PowerShell script. The instructions available for any particular resource are dependent on the resource type.
For instance, when working with a service you can stop the service, or set it to have a startup mode of “disabled”. When working with files you can create or delete a file, or you can specify the content or that file.
A cookbook is a collection of recipes, and includes a way of setting some code aside as a template resource. This way you can include a larger text file, HTML code or a PowerShell script as a resource. Once included into a cookbook, those scripts and code can be referenced my multiple recipes from within the cookbook.
Why not use PowerShell instead of Chef?
Great question. The answer is that Chef isn’t just for running PowerShell, it’s about automation. It’s being able to put the resources, such as a collection of scripts, together in the right order and the right amounts.
The analogy of a recipe is a good one. Everything happens in order, and in simple commands. The code you write for Chef isn’t just for defining what you do, but it orchestrates the configuration changes into a repeatable task list.
And nobody is telling you to stop writing PowerShell and start using Chef. If you’re already using PowerShell for deployments and system builds, you may be doing a lot of what Chef can do. But there are some good reasons to use Chef.
Management of heterogeneous environments is the most prominent. With Chef, you can easily expand your environment to include Windows servers in your Linux shop or vice-versa. Although the configuration files are not identical between the operating systems, the underlying principles are the same.
Chef and Desired State Configuration in PowerShell
Describing the configuration of your systems in code is something that might sound familiar to you, especially if you’ve been following some Petri.com articles on What’s New in PowerShell 5.0 and Desired State Configuration.
The concept is the same: We use a file to list the configuration items that we want to set, and then behind the scenes the framework breaks down those configuration items into bits and pieces and makes the changes required. We do specify the end result that we want, whether it’s complex or a simple example.txt file. But we do not specify the exact steps to get there. That is the role of the framework, to interpret your recipe into an end-result and then manage the system to make it match the configuration.
Differences between Chef and PowerShell
If you’ve been working with PowerShell for a long time, you’ll have to get used to the syntax of a different language.
All Chef recipes are Ruby files. This is not a bad thing since Ruby is not a particularly difficult language to learn. But just like using any new language, you’ve got the learning curve before you get the payoff of being able to fully utilize it.
I think if you’ve been getting into PowerShell it can be very helpful, anyway. For many people in the operations side of IT, especially Windows administrators, using code is still a developing skill and not something that they are entirely comfortable with. So if you’ve been getting your feet wet with PowerShell, then congratulations — you’re going to have an easier time describing your configuration steps with code, regardless of the language.
Getting Started with Chef
I recommend giving Chef a spin and seeing what it’s all about for yourself. Chef’s website has a great introduction that includes a VM with Chef already loaded onto it. It has everything that you need for creating a recipe, a cookbook, and using them to create and delete a file, modify its content, install IIS on a Windows server, and configure the IIS service.
The VM is created automatically and is ready to go in about three minutes and lasts for 24 hours. Since the exercises that go along with the VM only take about an hour or so to go through, you should have plenty of time to explore.
No matter the size of your organization, it pays to execute your roles in the most effective way possible. Turning a deployment from a manual process into a repeatable and standardized task should be one of your goals.
Chef is just one of the tools that systems engineers and administrators are using to do their job consistently and effectively. There are many others, so tell me in the comments below: Are you using Chef, or have you considered it? What are you using in your organization?