Welcome back to the upgrading Chef Infra blog series!
Over the past weeks we’ve talked about why you should upgrade and how to upgrade your cookbooks for compatibility through the use of cookstyle. Your cookbooks are now ready to function with the newest Chef Infra versions.
After the chef-infra-client upgrade, we will see the following benefits:
Once you’ve updated your cookbooks, and ensured compatibility with Test Kitchen as outlined in our last blog, it’s time to start upgrading clients in your environments. Before starting any upgrade process, be sure to check out the upgrade considerations in our documentation. Now let’s dive in!
Upgrading something that potentially manages your entire infrastructure can appear as burdensome. While there are more automated ways of dealing with this task, it’s important to understand how we would approach it manually. The manual way of upgrading the chef-infra-client involves running a CLI command to upgrade on a node by node basis.
The following line would do the trick on *nix & MacOS:
curl -L https://chef.io/chef/install.sh | sudo bash
And here’s the Windows one-liner:
. { iwr -useb https://omnitruck.chef.io/install.ps1 } | iex; install
While having to SSH or WinRM into machines and upgrading via command-line is not extremely challenging, we can run into several problems:
For these very reasons, we’ve created the chef_client_updater cookbook, which does most of the heavy lifting for you.
Introducing the chef_client_updater.
The chef_client_updater allows you to upgrade your Chef Infra Client through a cookbook. This recommended approach leads to an easy to digest process which gives you the following benefits:
In general, binaries expect to be upgraded 1 minor release at a time. This is generally done so functionality remains throughout the upgrade process.
We’ve already taken care of functionality through the cookstyle/refactoring exercise, which means we can jump to whatever major version we desire.
Through the chef_client_updater we can simply pin the version of Chef Infra Client we want to migrate to and press play.
Your current Chef Infra consumption may translate to the challenge of having to upgrade hundreds or thousands of nodes. Thankfully Chef lives for Automation!
If you are already utilizing Chef Infra at that level of scale, then your nodes are probably already communicating with some version of the Chef Infra Server. By adding the chef_client_updater cookbook to your run-list and pushing it to the Chef Infra Server, your nodes will auto-upgrade the chef-client the next time they self-check for desired states.
This upgrade will only happen if the Chef Infra Client installed version doesn’t match your desired version. This means that the setup process only needs to happen once, and Chef Infra handles the rest.
The entire process is fairly fast and after you execute it once, you can apply it to whatever scale you want. Simply add the chef_client_updater as one of your dependencies and use the resource like so:
chef_client_updater 'Install latest Chef Infra Client 16.x' do
version '16'
end
Here’s a video of my colleague Ken Langdon performing a quick upgrade on his Windows machine:
Throughout the years Chef and the Chef Community have released several patterns of implementing Chef Infra. These patterns have tackled problems ranging from dependency handling to desired-state simplification. From the Berkshelf way to environment cookbooks and Policyfiles.
The Effortless Config pattern utilizes Policyfiles and Chef Habitat as the vehicle in which we deliver infrastructure. Why Chef Habitat? Habitat is a framework which allows one to “define, package, deliver” any project along with all of its dependencies, both immediate and transitive, in a consistent manner.
Organizations are complex and different teams might rely on different versions of chef-client. Some teams might be okay with their current setup for the time being, and might not be ready for any modifications just yet. Chef Habitat bundles the Chef Infra Client with configuration policy as a single artifact, where they can be promoted through release channels providing fine-grained control of where each version of client and policy should be in use.
With this approach, Policyfiles will still define your desired-state in an easy to read single-file definition and Habitat will be responsible for packaging the Policyfiles along with all the Chef Infra requirements (e.g. chef-infra-client, chef-scaffolding,etc.).
Why is this being brought up within the Chef upgrade blog series?
Effortless Config will create an immutable artifact out of your desired-state with a pinned chef-infra-client version.
Team X and Y can work with artifact A which uses an older version of Chef Infra, while Team Z works with the latest and greatest artifact B. Both teams could utilize the same pipeline without obstructing each other. This pattern erases any agent management problem that you might have previously encountered. The Effortless Config pattern also results in faster deployments/remediation at scale due to Habitat’s lightweight ability to continuously communicate with the artifact repository.
If you’re interested in learning more about the Effortless Config pattern, be sure to check out our documentation for details, caveats, and usage examples. We’ve also released a newly-redesigned Chef Infra course at Learn Chef that provides a detailed introduction to the pattern..
In our next post, we’ll have a look at applying the techniques we’ve learned for upgrading our cookbooks and clients at scale, with the new Upgrade Lab. Upgrade Lab provides a way to evaluate every cookbook and node on your Chef Infra Server to ensure a straightforward path to migrating everything to the latest and greatest kit.
In the meantime, be sure you check out some of the resources referenced in this post including:
As ever, if you’d like to upgrade, but could use assistance, be sure to contact us to see how we can help jumpstart your upgrade process!