It takes a while to first learn Chef, even with http://learnchef.com. I'd like to get that time down. One of the big hurdles a new user encounters is the need for a server to do many important tasks. A second hurdle is a large amount of configuration and privileges the user needs.
I'd like to get learning Chef down to a 3-step, less than one minute experience of joy and success. And I don't want to do it by building special tools you only use when you're starting up; you should only be doing things that will stand you in good stead as you get more advanced.
Here's the 3-step of my dreams:
- Install chef omnibus (known 1-step install)
- Create a
cookbooks/startmeup/recipes/default.rb
recipe with a resource or two in it. chef-client startmeup
No setup besides the install. No configuration, no authentication, no server, no privileges. Pure recipes, up and running and getting value in no time.
This requires two things: first, we need a server (and I nominate chef-zero). We integrate chef-zero tightly (and invisibly!) with chef-client and knife. Yes, you need a server, and we'll GIVE you a server that you don't even know about. Second, we need users to be able to run chef-client by default WITHOUT root, which means changing some default configuration like repositories and caches to point to accessible places.
The command, again:
chef-client startmeup
- Don't require a server
The first thing we need is the option to start up a local chef-zero instance, pointed at the user's local repository. In this proposal, the chef_zero.enabled
option will accomplish this. chef_zero.port
allows you to decide what port (which defaults to 8889). When the chef-zero server is started, chef_server_url will be set, meaning all knife and chef-zero operations will proceed as normal. This should come with a command line option as well so that one can quickly switch between one's server and local mode.
A further enhancement would be to allow a range of ports to be specified, so that if one is taken, we will try to start up on the next one.
To avoid configuration, chef-zero needs to be the default when running in a local repository like the above, when no configuration file is specified.
Keys must not be required for Chef::REST (or invisibly supplied). When not supplied, requests will not be signed (and we let real servers return the requisite 401).
- Let normal users run chef-client by default
When users run Chef, by default it points to cookbooks and such in /var/chef/cookbooks
. This needs to change. If no configuration file is found, Chef should first detect if it is running in a repository (by looking for a cookbooks/ dir just underneath or above it in the path) and set the chef_repo_path to that.
Even with the location of cookbooks and other data fixed, Chef still has some operations that touch caches in /var/chef/cache and the like. If no configuration file is found, Chef should set the cache to /.cache.
- Make the command line accessible
When running chef-client
locally, it is convenient and intuitive to just type recipes out on the command line. We should allow non-named arguments, and treat them as an overriding run list.
It may also be useful to allow users to type filenames, so that tab completion comes into play, a la knife-essentials:
chef-client cookbooks/apache2
chef-client cookbooks/apache2/recipes/server.rb
cookbooks$ chef-client apache2
looking at this horrible Chef::Config[:solo] block in the postgres cookbook, it is also dealing with this mess of setting up random passwords on first install, which is another antipattern and should be put into (encrypted) data bags, and ideally the recipe should be much simpler and just let you DI whatever data source you like for the initial postgres password... every time I see these kinds of nightmares in the cookbooks, though, it doesn't make me want to shoot chef-solo it makes me want to shoot the whole misguided approach... okay, </rant>