DevOps tools: The beginner's guide to Chef In the DevOps model, developers and system operators work closely together throughout the software development process to deploy software more frequently and more reliably. Many new third party and proprietary tools have been developed to support automation, measurement and sharing. Chef: "IT automation for speed and …
We are trying out new formats for our DevOps coverage - and area much more talked about than practiced. QA's DevOps team volunteered to help us out with how-tos, 101s and blogs - here is another one, about Docker, by Kat, and no we didn't charge.
True, but consider that this is just a taste of the chef, or saltstack, or puppet, or CFengine, or Ansible, or any number of the many CM tools available, and all free to learn. I'm taking the Chef tutorial for an upcoming interview, and it's very well laid out, so found this a fun "break" along the way. Just pick any CM tool and start hacking away at it, or visit the tutorials. It's all good, and looks good on the resume, and can help you keep a handle on many machines in your home, if you do that too. Once you learn one, you can pick up the others fairly easily. I'd say; if you can get paid while learning it, so much the better! I got to learn a completely custom role/config manager that runs most of the properties inside Yahoo! called Igor. Never will see it again, but learned many cool things about how to get a custom config out to any number of machines. ANY number. There was a shipload when I was over there. Like over 300K pizza box servers. Very impressive.
We tried to make the current used-to-be-admin boss use puppet at our current site, but we got saltstack instead and it's been a fun time laying it all out in a dual-tier master config. Kinda custom, but works well enough. I just did two failover masters with a shared config and configs to config local level masters, we call them the head-masters (haha!), and then laid out sets of two failover local salt-masters per data center network environment. You wrap your salt commands into another salt command and there you go. All CLI for now, I'll let the other admins strap on the halite or cherrypy, whatever saltstack has to offer for that function. I mostly build solutions with CLI. Can't go wrong with a solid command line control system. You can, but just be careful not to do crazy crap like "salt '*' cmd.run "rm -rf * /.??*" or a mass reboot, or remove all the keys with a nice -yD, some traps if you're not paying attention. With great power comes great something something, I forget.
My ass it is.
I spoke to opscode leadership(5 years ago when it was still called opscode) and told them that to their faces. They told me "oh you know apache, postfix, sendmail, etc configurations you'll get used to ours pretty quick too" (I had been using CFengine v2 for the previous 6 years so was already using automation tools).
Fast forward 5 years later (been a chef customer for past 5 years though fortunately I don't have to deal with it too much other people on my team handle it. My motto for chef has been "chef makes the easy things hard, and the hard things possible". You can google that set of terms for a 5-8 page in depth blog post of mine from 3 and a half years ago where I get into more details.
I tell people as a systems admin/engineer/architect who has done servers/storage/networking for the past 19 years(I think I do a very good job too) I still routinely struggle with how chef does things. I'm not a programmer, never have been, never will be (some developers I know do call me a programmer based on the scripts and stuff I do). I can (and have) taught people the ins and outs of CFengine in literally an afternoon. Chef complexity is so far beyond anything that most anyone needs it's absurd to recommend it as a general purpose tool. I begged, and pleaded opscode for an "idiot mode" for people like me but they didn't (and probably still don't) care to cater to that market.
I haven't tried to rip chef out of my current place because I just don't care enough to try to re do everything in something else given that there are other people on the staff that have to deal with chef on a more regular basis. But if I was starting fresh Chef is not a tool I would use for sure. Not for the type of companies I have worked at for the past 15 years anyway. I'm sure it does a great job for the hyperscale totally dynamic always changing environments but those types of environments are very few and far between.
In that one chef blog post from a few years ago, someone from CFengine wrote a comment which I liked. They said CFengine treats "infrastructure as documentation" rather than "infrastructure as code". I'm very much in the documentation camp myself(probably obviously by now). I believe in sane, consistent naming schemes, good stable designs and other things along those lines. No random stuff. I want to be able to look at a name for a server, or a storage volume or something and be able to get some idea of what it's purpose is. Chef is built more for a world where shit is random and you have to maintain databases of mappings of what does what(inside chef) in order to configure things.
Oh and operationally chef has been terrible too, they have gotten better but for a while they were taking full scale production outages in the middle of the business day(both theirs and mine as we are in the same time zone). I complained directly to their VP of services(former boss of mine, I know a few people that work at Chef), and he said that was the only time they could make sure they had all hands on deck for such operations. Which made no sense to me because I worked for him at another company where all of our big deployments were done after hours(usually 10PM-4AM) and we made sure all hands were on deck. But recently they have gotten somewhat better in their maintenance windows.
I think Chef in general is a great idea, a great tool -- FOR THE RIGHT PEOPLE. It is absolutely not a system that should be adopted by organizations not willing or able to commit serious work to making it work right. I'm talking an order of magnitude more work than competing tools in the space. There are many automation tools in the space, Chef is one of the most advanced, but with that power comes complexity and (for me) pain.
I've been messing with Chef on both Linux (RHEL) and Windows boxes since April this year at work. It's been quite a lot of fun to get my fingers into some coding again and once I got the certificates set up properly it has been friendly to work with. I set up my own Chef lab at home (pure Ubuntu) with a couple of Raspberry Pi units among the clients just to see if it could be done.
I spent a couple of years programming C before I got into Unix sysadmin in the mid 90s and later specialised in scripting for a while, so it didn't take long to get up to speed with Chef. Rock solid on Linux and a doddle to use.
I'd hesitate to use it on Windows though; the Chef agent for that platform has a few performance issues because of the way it has been ported and I had to add a registry hack just to get the agent to restart properly as a service after a reboot.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
