Why doesn't chef use chef to set up their training modules?

Why doesn’t chef use chef to set up their training modules?

Shouldn’t it be as simple as download and install chefdk then

knife cookbook site install <module name>

It seems like that would be a good selling point as well as providing great examples.
It makes me wonder if chef is mature enough do such tasks.

-Frustrated with module setup

1 Like

I’m not sure quite what you’re asking here. If you’re referring to the modules on learn.chef.io, we use git because that’s exactly what the developer experience will be - you check the cookbook out of git, and then you work on it.
Using knife cookbook site install is almost never the correct thing to do when developing a cookbook, so we don’t teach that way.
If you’re referring to something else, please could you elaborate?

I am talking about something else. I’m not concerned where cookbooks are located. My point is, on learn.chef.io the student is instructed to:

  • change various settings

  • down load several software tools. docker and docker-compose for example

In order for the lesson to begin.

My question is why don’t we use chef to do those things? Chef is for configuring systems but in the lesson modules a lot of the configuration is done by hand. Which as we all know can become fragile.

It would seem that all the downloading and setting of system attributes should be in a chef recipe instead of a manual list of instructions.

For context, @KingAndrew asked a similar question on this Learn Chef page:


If I understood the question correctly, it was around why Chef Automate Pilot uses a Docker-based installation and not a Chef cookbook.

I offered my perspective on the thread, but perhaps others have insights to share.

@KingAndrew - reading the spirit of your question, indeed, getting set up for Chef development involves some setup. This includes installing the Chef DK and common ecosystem tools such as Git, Vagrant, and VirtualBox. In fact, we do point to projects such as chefdk_bootstrap that assist with the process.

However, we’ve found that most users prefer to manually set up their systems for Chef development and then gradually discover how Chef works and what it can do.

That said, if you have other specific examples that you think could benefit from an easier setup, we’d love to consider them. The best place to leave that feedback is on the specific Learn Chef pages in question.

I’d add that tool inception, while clever, doesn’t serve new users. When learning a new technology, slowly approaching the steps in familiar ways and avoiding having to troubleshoot the tool itself just to get started is avoided.

Could you automate the entire thing with Chef? Almost definitely but we’d also pay a support cost there that I can assure you wouldn’t be worth the trade-off. The goal here is learning the tool not necessarily showing off how clever it can be. Additionally, different systems have different security policies and quirks so running chef-client as root/superuser locally is incredibly risky and the last thing we want is for a learner to hose their machine with something clever.

There are more reasons here but mostly along those lines - no point in being clever if being clever results in more issues.

True the goal is to learn chef, inspec, and habitat. So manually installing other tools seems to me to be outside of that scope. I’ll drop it after this post but if there were recipes for installing those non-chef tools the lesson(module) could describe how it was done with the tools we are trying to learn.

That’s not a very good statement about your product. I’d make sure your marketing department doesn’t use that.


My latter point isn’t a slight at the tool, it’s covering the disparate state, security postures, and craziness that each developer workstation brings to the table. It’s a non-trivial problem and we have tried to sensibly pick a balance that works well for our users as well as us. I could go on for a while pointing out specific issues and instances where and how this could/would bite us but I’d ask that you trust that I/we’ve been doing this a while.

You’re welcome to disagree but please don’t read so much into statements as to try to twist them into something they are not. As someone who spends lots of time with new users of many backgrounds, whether it be teaching in person or in Slack/IRC, I do believe we’ve chosen the safest and least complected path for the bulk of our target audience for learn.chef.io.

Related: If Chef inception is something you’d like to see in a practical application, I just happen to have built something to do that for our demos, though it’s a lot more than just chef cookbooks https://github.com/chef-cft/wombat and https://github.com/chef-cft/bjc/

I’m gonna pile on a bit here. You might think that “installing tool X” is a simple thing that everyone could agree on, but it’s not. For example, “installing nginx” actually means all of these things, depending on who you talk to:

  • install the package from the OS distribution’s main repo
  • install the package from a different 3rd party repo, like EPEL, to get a newer version
  • I build packages myself and put them in my own repo
  • actually I want openresty so I can use lua
  • I live on the edge and compile it from source on master
  • I made a fork to apply a patch, compile it from my GitHub account
  • compile it from source at a specific git tag
  • compile it from source and change all the ./configure options
  • compile it from source and then compile a bunch of modules that need the header files
  • etc.

Chef can do all of these but it can’t read your mind to figure out which one you want. The same applies to dev tools on laptops–you could definitely standardize that kind of thing for your company and manage it with chef, but the authors of LearnChef can’t magically standardize it across the whole world.

I don’t think it is easy

that is my complaint. In order to run these chef training modules I’m having to install docker (which I’ve never used before) and all of these containers that are preconfigured and then when it doesn’t work I have to ask a chef user group why my docker container running nginx (which I’ve never used before) doesn’t accept my connection, (see my other post. please!) It kind of seems I’m in the wrong mailing list but I’m not because someone at chef configured that container.

You don’t have to. I’m trying to use tutorials (see the original question) that are dreamt up by someone at chef. So you can dictate what packages to use.

I don’t think it is easy, but if I was having trouble getting a recipe from the supermarket or git working I would be asking questions and learning about how to get chef to create the correct configuration and learning about chef all the while.

I understand all of your students have different configurations. If they were figuring out the details of those configurations here and folding those configurations back into the recipes via pull requests the world would be a better place. :slight_smile:

Then you would not have to read anyones mind. You could just help answer chef questions and the chef users would be learning the whole time.

I am of course a new chef user but the first few lines of chef most of us see is:
package ‘httpd’ do
and we are all thinking wow this is great!

Then when you get into more difficult configurations for the next lessons and it seems (at least to me) kind of weird that we have this great and powerful tool but we are told to do things (downloading and installing packages) the old way.


Unfortunately we cannot. Our tutorials apply across a wide variety of platforms and environments. And developers tend to be very picky and get cranky easily if you threaten to dump a whole bunch of global packages into their laptop. We would love to hear which steps you have trouble with though, so we can improve them in the future!

I see what you mean.