This is the third in a series of posts I'm making detailing my setting up a Puppet master/slave pair of servers on Linode. If you haven't seen them yet, go check out my first and second posts about my Puppet servers.
A few months ago, I published a post about using Puppet to manage infrastructure. As my company grows, I'm finding it more important to ensure that all of my servers are managed in a sane manner. To me, this includes ensuring that if one of my servers ever goes down, or the data center it's in gets smashed by a meteor, I could theoretically be back up and running just by migrating to another data center.
A couple of weeks ago, I published the first post in this thread about some problems I was having with the Peloton Bike in the house.
My roommates have a Peloton Bike in the house. It's a neat thing -- it's a stationary bike with a built-in computer (think large tablet) that basically streams live or pre-recorded Spin classes to your house. It's a great way for cyclists to stay in shape during the long winters, especially in Chicagoland, where I live. It is not, however, without its problems.
One of the best things to come out of the Continuous Delivery movement is the concept of infrastructure as code. This is the idea that you should treat your servers in the same manner that you treat the programs you write to put on those servers. In other words, you should be able to programmatically specify what type of operating system you want on your server, which packages should be installed, and how they should be configured. Further, all of that should be code, and it should be stored in your version control system and treated with the same rigor as you treat the other code you write.