Editor’s Note: ChefConf 2018 ‘How We Did It’ Series
Welcome to final entry in our How We Did It series based on demos from the ChefConf 2018 Product Vision & Announcements keynote presentation. Today, Seth Thomas, Software Development Engineer on our Workstation team, will show us the newest project from Chef, Chef Workstation, and walk us through how that unikitten got from his local workstation to the servers we showed off on stage (and how you can do the same!). In case you missed it, review part one and part two of this series.
We’ve heard loud and clear that our community has needed an easier way to get started with Chef. The Chef Development Kit (ChefDK) has always provided a robust library of tools that we’ve optimized for quality pipelines and scaling throughout, but this has had the side effect of requiring new users to familiarize themselves with the fundamentals of developing Chef code before they can start tackling simple use cases. To this end, we’ve introduced Chef Workstation which, as per this RFC, will be supplanting ChefDK in the near future. Initially, Chef Workstation will contain all the features that already exist in the ChefDK, in addition to extra tooling aimed at providing newcomers with easier workflows for simple configuration tasks. Before Chef Workstation can supplant the ChefDK, we want to be sure that we optimize the user experience of each individual tool and make them more cohesive as a unified workflow. The use case we’ll be looking at today is based on my live demonstration from our Product Vision & Announcements keynote at ChefConf 2018. We’re also pleased to announce that we’ve included the code from this demo in the chef-workstation repository in the examples subfolder so you can easily follow along with today’s blog post.
The first new component of Chef Workstation is a utility called chef-run. This tool was created out of the desire to run ad-hoc tasks using chef resources, recipes, or cookbooks without the typical overhead of having to first use knife boostrap to connect your infrastructure to a Chef Server. Instead, chef-run allows you to run those ad-hoc tasks against any systems accessible via SSH or WinRM without requiring you to first configure a Chef Server or pre-install our agent on those machines. To that end, let us construct a use case to highlight the benefits of this new tool.
Let us pretend I am a fairly new member of an operations team who has received a helpdesk ticket. The request is to help create an environment for one of the web teams to test a prototype landing page using nginx. Another member of the team has already provisioned 3 servers for me so all we need to do is apply some configuration.
Download instructions and getting started guides are available at: https://chef.sh
To get started, all I need to is to download this single package. Chef Workstation comes with everything I need to get started with Chef.
First, let’s try running a Chef resource by itself which is functionality we’ve not exposed previously:
chef-run rhel-01 package ntp action=install
As you can see, we’re passing the target, which can be referenced by hostname (above) or IP address, the Resource type of package, the package name ntp and the action install. When we run this command, Chef will detect the running operating system and use the appropriate installation command without us having to concern ourselves with the details of OS-specific utilities like apt, yum, or zypper.
More complex tasks are often handled by Chef Cookbooks, which allow us to collect multiple resources into recipes, which in turn handle the end-to-end configuration of a multi-step installation process. In this case, I’ve been provided with a simple cookbook for setting up nginx called deploy_website. Let’s run the command to remotely deploy this ad-hoc like:
chef-run rhel-01 deploy_website
It’s worth noting that cookbooks often contain multiple recipes for different aspects of a configuration tasks, but most contain a default recipe for the most common use case. The above example is functionally equivalent to running either of the following:
chef-run rhel-01 deploy_website::default
OR
chef-run rhel-01 /path/to/cookbooks/deploy_website/default.rb
The above example is useful, but where this gets really interesting is when we run this against multiple servers like:
chef-run rhel-01,rhel-02,rhel-03 deploy_website
Since our servers follow a predictable naming convention, we can even simplify the above command by specifying a range of servers. The below example will take the exact same action, but without our needing to specify each server individually.
chef-run rhel-0[1:3] deploy_website
If you’d like to follow along with the examples detailed in this post, the deploy_website cookbook can be found in the chef-workstation project on Github. We’re excited to see how you use Chef Workstation to start configuring your environments as you embark on your Continuous Automation journey!
chef-runtoday!chef-run uses Policyfiles to apply configurations. To learn more, our Policyfiles Guided Tour can give you an overview of how this tool works.