[chef] Re: Chef Server vs. Not Guidance


Chronological Thread 
  • From: Charles Johnson < >
  • To:
  • Subject: [chef] Re: Chef Server vs. Not Guidance
  • Date: Wed, 05 Aug 2015 18:58:52 +0000

Usual disclaimer: I work for CHEF. YMMV. etc.

The Chef Server is a publishing platform. It contains APIs for publishing and consuming particular data structures, and tools for securing and managing that published data. It also contains an artifact server for cookbooks. 

Humans and clients all publish data. Humans tend to publish policies and code, clients tend to publish data about the nodes in the infrastructure. All actors tend to consume the data set in most models.

The most useful thing about this platform, to me, is that if you set the clients to run on a scheduled basis, then every node in your infrastructure becomes an autonomous actor. Each of those autonomous actors becomes the SOA for its own configuration, because the client manages its own node object, and humans just modify policy by publishing run_lists on individual nodes or via roles, and publish updated cookbooks. Essentially the infrastructure starts to manage itself, and reacts to change that flows in via publishes to the Chef Server.

This enables some powerful, highly scalable workflows that just aren't possible when you're manually firing off ad-hoc config runs on nodes. But that said: Some people are never comfortable with this model, because it removes the central observer/controller from the equation. No longer do I weird REAL ULTIMATE POWER! No longer does my workstation reach out, poke hosts, and tell them to "Dance, monkey, dance!" Instead I publish policy & code, and trust that the nodes in my infrastructure will configure themselves accordingly, within the allowed timeframe. As a sysadmin who had to wrap his head around Chef, it took me a long time to grok and embrace this model, because it was so very different from the way that I was used to interacting with the world. At first it felt like giving up control, but as my experience grew I realized I was gaining a lot more than I ever gave up.

(I'm intentionally leaving aside the "roles/environments good or bad?" conversation here, as I don't see it as critical to the Chef Server workflow, and you can go either way really.)

What a Chef Server is:
- A publishing platform that gives you a defined API for distributing policy and code to chef clients.
- An easy way to distribute change through your distributed system, when coupled with daemonized chef-client runs.
- A searchable point-in-time database of information about your infrastructure.

What a Chef Server isn't:
- A centralized controller for Chef. Out of the box, it's just a searchable publishing platform for point-in-time data about your infrastructure, with no history.
- A source code repository: It is an artifact repository. Source code lives in SCM.
- A canonical source of truth: Your truth lives in source control, and on the configuration of the nodes themselves. Humans report that truth to the Chef Server from SCM, and nodes report that truth to the Chef Server from Chef Client.

Hope that helps you with your decision!

--Charles



Archive powered by MHonArc 2.6.16.

§