Make Me A Sandwich

A collection of recipes for creating servers suitable for Rails, Node, & Clojure apps.

Motivation

Operating systems and the software packages they provide are always changing, being updated, being tweaked. Your application is always changing, growing, expanding. Provisioning a server to host your software is a "rubber-meets-road" experience that bridges these two moving targets together. In other words, a provisioning event this month could be very different than a provisioning event next month.

Instead of having a hard-coded and difficult to change provisioning recipe with all the parts hidden (i.e. Chef or Puppet), let's expose the ingredients. Let's cook like people really cook -- adapting the recipe to what you've got at hand, the time you've got, and the folks who are coming to dinner.

Easily generate boilerplate scripts for every provisioning event. The old provision script is mostly for historical purposes anyway. Don't try to run it in a year. It's not going to work.

....

• servers are cheap to provision now giving cloud services
• instead of maintaining servers for long periods of time, we should periodically just provision new servers
• it's better to provision a new server from scratch than make lots of little config changes; then you can just hot-swap from the old to the new with a DNS change

Goals

• A simple-to-run, idempotent script for Ubuntu installation and another for CentOS.
• Generate boilerplate scripts that are designed to be easily updated by the developer.
• Generate boilerplate scripts that are designed to be thrown away and regenerated for each provisioning event.
• Don't try to abstract away from Ubuntu & CentOS like Chef & Puppet do.
• No requirement of Ruby, so no Capistrano. [can I stick to this?]
• Only require Bash. [in the generated boilerplate scripts, but what about the file generation?]

Other Goals, not sure

• Would really like a way to cd to a Rails/Lein app and run a command to generate a ./bootstrap directory based on the requested arch. (Don't want to use Rails generators in case of a Clojure/Node app.)

Design Principles

• each component should be isolated in its own install function

• each install function should be idempotent (safely called again and again)

• always install the development headers in each component's recipe

• this idempotency is to aid debugging and installation and is NOT to be used as a system upgrade mechanism

• but, system updates should be backported to this script

• IDEA: basically the app exists in its own little world, delegating all OS-specific installation/configuration details to a #{APP}/bootstrap directory and its scripts within it. The directory and its scripts are generated by make_me_a_sandwhich.

Expected Workflow

• start with a Rails, Lein, or Node app
• copy the ubuntu or centos directory from make_me_a_sandwich to your projects ./provision directory
• cd ./provision
• tweak the script if necessary, commenting/uncommenting components from the bootstrap_webapp function
• sudo ./bootstrap.sh
• If there are failures, tweak the script as necessary and rerun sudo ./bootstrap.sh
• Once everything is installed, add your provision directory to git

[workflow for a later provisioning event]

Recommendations

I highly recommend some virtual machine technology that supports snapshotting so you can roll back to a known, pristine state. I personally use VMWare Fusion on my Macintosh.

Thoughts

I'm thinking I might have to use a text-generator like ERB to really make this work. That would obviously require Ruby. Hmmm...

Thinking about Apache

• there are basically two approaches here, either bootstrap.sh installs a config, or
• boostrap.sh just points to a config that lives in your (presumably) Rails app; however... the problem there is that even if you want it live in your Rails app, bootstrap.sh (or some mechanism of it) needs to generate it, since it's based on the version of Ruby/Passenger you install (or not) and the certs you use/generate... starting to think we need to NOT check the config into the app but let bootstrap.sh deal with it. MORE THINKING: Yes, I'm pretty convinced that the *.conf file is an artifact of bootstrap.sh, and should live in the #{APP}/bootstrap directory, not in any other config directory