DevOps is quite the field today. You’ve got Vagrant (and recently released Packer), Chef, Puppet, Jenkins, and more buzzing around … and if you’re a developer who didn’t have to provision their own machines from the get-go, chances are a lot of it looks like jibberish (at least, that’s the case for me). Here’s a little primer on what what in devops for the non-devop (?)
Well, this wouldn’t be very useful if we don’t establish what we’re talking about when we talk about DevOps, eh? DevOps is the intersection of development and operations. That means that the space between people writing applications and the people making sure those applications are running on severs is getting smaller. Operations people are getting better and better at making developers’ lives easier and (hopefully) more developers are learning more about operations, rather them being “that person with the pager.”
Part of bringing development and operations closer is to make sure “but it worked in development!” is never, ever said (or well, hopefully :). By using virtual machines, a developer’s environment can closely, or nearly exactly, mimic the production environment where the code will be shipped.
I think of this as “when was the last time you hosted your application on a Macbook Pro?” If you aren’t virtualizing your environment close(r) to production, you will find disparities and things that become harder because you must maintain separate systems.
Vagrant is the long time hotness in devops; it was released in 2010 and evolved from a Ruby gem to a downloadable tool to help people make virtualization easier. I really liked the author’s Tao of Vagrant post, which explains the philosophy of Vagrant quite well.
Chef/Puppet/Salt Stack/Configuration management
Ops School’s article on configuration management is quite quality, but for the “huh?” version, I’d summarize configuration management as such — these are tools that make it easier to put together a set of rules/processes for bringing up your system (configuring it). Chef’s analogies fit quite well — you write recipes, and those recipes (ex. to install Apache) are put in cookbooks, and so on. Chef and Puppet are both Ruby-based systems (although it’s not rocket science Ruby by any means), and Salt Stack is Python-based.
There’s a lot more to devops and well, ops, than listed here. Continuous deployment, build processes (ex. Jenkins, Buildbot).
And of course, the not-secret reason for this post is to ask for help — I’m learning this stuff myself (and was completely spoiled by the awesome ops team when I was working at Paperless Post) and would love to hear what resources you all use to get better at ops. Ops School is great, but it has a lot of ground to cover (know Ops? Contribute!).
What do you use to level up your Ops knowledge? Use the comments!
My friend Vanessa Hurst recommended Web Operations: Keeping the Data On Time to learn about DevOps:
@pamasaur love! Single greatest #devops book I’ve found is Web Operations by @allspaw & @jesserobbins ft @xaprb http://t.co/2K4rnTJah8
— Vanessa Hurst (@DBNess) July 2, 2013
2 Replies to “Getting started learning (dev)ops”
Funny, I’m in a similar boat right now. If you’re provisioning your first server, learn the fundamentals first. ‘Web Application Architecture’ by Shklar does a fantastic job explaining what a server is supposed to accomplish and why (Or seems to. I’m only halfway through). If you’ve already got that under your belt, set up a server manually or with a shell script. I would almost recommend a shell script so you have a record of everything that you want to accomplish. Then and only then, play with Chef or Puppet or whatever. That’s my plan anyhow.
I’ve thought about that — it feels a lot like I’m trying to start on step 3, when I haven’t completed steps 1 or 2. Any chance you have that book to loan on Kindle? 😀