Third Party Platform Support for Chef

Currently, users of Chef are limited to working with the platforms supported by the Chef core. But with the advancements of Target Mode, the story could change quickly. Learn about the idea of a “Platform Support Pack” and what it could mean for the future.

Supporting Platforms, Oldschool-style

A long time ago, meaning until mid-2019, the only way to support platforms not capable of running a Chef agent either due to their OS or their API, was to write custom resources and handle connections yourself. That meant including some HTTP helpers for remote APIs or even managing SSH connections to remote machines.

Naturally, this approach did not scale well. And while there have historically been projects to support Cisco Nexus ¹ or NetApp devices ², most of these projects got abandoned due to their extensive need for refactoring and maintenance.

Don’t get me wrong - it has been entirely possible to write and support such projects. Just the need to maintain both remote system functionality AND the connections made it very cumbersome.

Advent of Target Mode

Things changed by 2019, but not many people have noticed and taken action since then. As I wrote extensively about Target Mode and its development on this blog, I will just sum up the current capabilities in this article.

Rooted in Chef InSpec, a product which tests compliance of remote systems which never has been agent-based, an extensible framework called Train was developed. This framework provides an abstraction for any transmission of commands to remote systems and by default comes with support for SSH and WinRM. But being built around plugins and consuming third party Gems as well, it has been extended for other protocols as well. I admit of being guilty to have authored some of those myself (AWS Systems Manager, VMWare vCenter, Serial/USB, REST APIs and even Telnet - because why not?).

But Train is not used solely by InSpec anymore. In Chef Infra Client 15.1.36 it got included for some first resources. Knife bootstrap now can use it to add remote nodes to a Chef Infra Server. And since Chef Infra Client 16.6.14, you can also run Ohai remotely - and that’s automatically done if you use Chef Target Mode.

A downside is that the amount of Target Mode-capable resources is still low. Most of Chef’s built-in resources are heavily based on Ruby-code and as Target Mode cannot assume Ruby being available on the remote system, this rules out the bulk of ready-made functionality.

The Platform Support Pack concept

The limited support for Target Mode resources seems like a big problem, but in fact it is not. There is nothing holding people off from creating third-party packs just as back with Chef 14 - but with the benefit of not needing to manage the transport yourself. Only the “agent-less” management using standard resources currently is not possible.

To maybe give some people ideas, I am presenting something in this post which we have been calling “Platform Support Pack” (PSP) internally for some time.

In our lingo, a Platform Support Pack is a collection of resources which bridge the gap between the Chef Infra core and the platform a user wants to configure.

That means:

• dealing with connecting (Train)
• detecting the remote platform/OS (Ohai)
• collecting a remote inventory (Ohai)
• providing helper DSL functions (Chef/InSpec Libraries)
• configuration resources (Chef custom resources)
• testing resources (InSpec custom resources)

So it is basically a marketable name for an abstraction layer and not too different from the old cookbooks - just updated for Chef 17 and beyond.

All this can be packaged into a cookbook which then gets consumed by anybody who wants to work on the provided platform. From my personal experience, this works especially well if you create an abstract resource as a base for your consumables - dealing with transforming requests, interpreting responses and providing some helpers.

I did not yet try if the new Chef Compliance Phase works with Target Mode resources, though. If not, you would probably need to split off the platform-specific InSpec resources into a separate profile.

Summary

The PSP concept, if done right, can easily expand Chef support for remote devices into realms currently occupied by API-capable tools like Ansible or Terraform. While there are boundaries between Orchestration and Config Management tools, it makes sense to have some sort of overlap.

And who knows, with the Chef Hackathon currently running until October 25th, we might see some more work in this direction. I am curious how that will turn out.