LISA’11: Tech Sessions – Chef DevOps

Print Friendly, PDF & Email

Dimitri is a really nice guy! He’s laid back and chilled.Started off managing machines manually, the network grew to multiple machines managed by multiple admins. So they tried a few CMs and decided on Chef.

From a the configuration management workshop 2 years ago he was given the idea to just try out managing /etc/motd. So, he went to look for a recipe but one didn’t exist, so you do what any sane sysadmin would do and made one. He then rebooted. The system overwrote the config file. So, he devised a template that wrote out what the system expected to be there, using ohai, a standard chef tool, to probe the system for variable data which chef had setup ready to use in the template. In more advanced templates you can set locations so that the host class selects a more specific config. You can also do a selection based on a template variable comparison.

So, how does the data get into the files? Chef has roles with a JSON config format. The function name run_list contains the recipes that apply to the class. An included package from the base class attempted to install postfix which failed as chef attempted to install from the FreeBSD ports system. So Dimitri rewrote the package driver to look for tar ball installation instead.

Chef can set log output at any arbitrary time easily by just calling the Chef function for this. (Which we could do in bcfg2 easily! Just never thought of doing that!) You can nest roles and just call the parent instead of all the separate children.

With workflow integration, Chef gets installed automatically at bootstrap time and old systems get Chef added regardless of whether the whole system can be managed or not. The configuration spec is stored all under mercurial.