From Solo to Zero: Migrating to Chef Client Local Mode

This kind of Chef Solo is still fine. (Stephen Lauck is lead guitarist in Midnight Chaser, and is also a Chef employee!)
This kind of Chef Solo is still fine. (Stephen Lauck, a Chef employee, is lead guitarist in Midnight Chaser.)

Chef Solo was the original Chef. Remember the bad old days before the Chef server existed as a product, and the only way to use Chef was to scp (or worse, ftp) giant tarballs of recipes & cookbooks from system to system?

Five years later, we not only have a robust & scalable Chef server, but we have a Chef client that can run in local mode in addition to client-server mode. Chef Client local mode emulates all the functionality of Chef Solo, so it’s finally time to send chef-solo to the rural sanctuary for retired command-line tools.

What Is Chef Zero?

In late 2012, Chef Zero was created as a lab exercise by Chef software engineer John Keiser. (The term “lab” might be a bit misleading for what actually happened, which is an entertaining story in its own right. Suffice it to say that Black Friday is good for software development activities here at Chef.)

Chef Zero is a full, in-memory, fast-start Chef server intended for development purposes; it persists no data to disk, nor does it have any authentication or authorization. Later, Chef Zero was rolled into Chef Client 11.8.0, thereby giving us Chef Client local mode, which you run with the --local-mode parameter to chef-client.

Local mode behaves exactly like Chef Solo except that, during a run, it starts up a local Chef Zero server bound to localhost, uploads all local cookbooks & recipes to it, runs Chef Client, and then terminates the Chef Zero server. The end user experience is identical to Solo.

Why Migrate from Solo to Local Mode?

If you’re still using Solo, there are a number of compelling reasons to move to Chef Client local mode.

  1. There are no more special flags or contortions required to get environments, roles, data bags, encrypted data bags, or search support in your run. Granted, some of these features (like search) aren’t that interesting if you’re not using Chef Client with a server.
  2. There are no special tools or plugins for knife required.
  3. You no longer have to write special conditionals in recipes to check for Solo mode and guard against client-server syntax. For instance, you can get rid of recipe code that looks like this:
    if Chef::Config[:solo]
      # do something
    else
      # do something else
    end

    This also makes testing your recipes easier, because you have one less code path to maintain. Test Kitchen already supports chef_zero as a provisioner; simply change chef_solo to chef_zero in your .kitchen.yml and you’re in business.

  4. Using chef_zero as a provisioner to Test Kitchen also allows you to make “fixture node objects” as test data in your tests, and thereby truly exercise any search(...) logic in your recipe-under-test.
  5. Chef Client local mode is an easier migration path to a client-server architecture if you later discover you want it. The main problem that Chef server solves is content distribution: how do I get all the Chef data like cookbooks, roles, environments, etc., to all my nodes without the aforementioned workflow of sending tarballs around?

Client-server mode also gives you many other compelling features, like:

  1. A bird’s eye view of your entire infrastructure from a beautiful GUI that includes run statistics and analytics
  2. Search across your entire infrastructure. For example, nodes can discover each other and dynamically adapt their state to respond to the state of other nodes. (The robots are winning!)
  3. Access to the world’s only software-as-a-service platform for configuration management, Hosted Enterprise Chef, if you don’t want to run your own Chef server

and many others.

Some customers go directly to the client-server mode, which is great; it remains our recommended, and most widely-deployed architecture. If you’re not quite ready, local mode meets your standalone needs while putting you on an easy migration path to client-server.

Although we have no immediate plans to deprecate Chef Solo, we will eventually remove it from Chef. Hopefully I’ve made the case for you to start switching your deployments at least from solo to local mode. And if you’re just starting to play with Chef, start with chef-apply, or local mode, rather than Solo.

Author Julian Dunn

Julian is a product manager at Chef & started his career at the company in professional services. His first experience with Chef was at SecondMarket, a New-York based alternative markets startup. He has fifteen years of systems administration & software development experience at outfits large and small across such diverse sectors as advertising, broadcasting, Internet security and construction. When he's not helping customers, he enjoys good craft beer, indie music, and writing biographies about himself in the third person.

  • zts

    Chef Client Local Mode is great, but it’s not a drop-in replacement if you are using the Ruby DSL for Roles or Environments (neither of which chef-zero supports). This is a step backwards from both Chef Client and Chef Solo. It’s a shame to have to choose between using local mode, and the ability to comment roles.

    • Getting that feature into local mode is a requirement for any eventual move to have chef-solo become a transparent chef-zero implementation.

      • zts

        Excellent news – thanks, Adam. If y’all want to split the difference and add YAML roles, that’d be fine too :)

    • Lamont Granquist

      As of this PR https://github.com/chef/chef/pull/4887, which should be in Chef 12.10.x (when it is released), running chef-client –local-mode supports the Ruby DSL for roles and other objects. There should be no need to choose between those any more.