post image is me making the Druplicon creepy af.

Once More Unto The Cloud

Before we can start Elastic Beanstalkizing our Drupal multi-site install, we have to take a couple minutes to sit back, fill a glass, and figure out exactly what we're going to be building. Since this is The Cloud, remember to grab your score cards boys and girls: It's time to play Buzzword Bingo!

First, a bit of a warning: There's a lot more than what I'm going to describe here, like creating VPCs and subnets and NATs and everything else responsible cloud wranglers do, but that stuff's all boring and well covered elsewhere. Just remember: Goofus creates all his AWS resources manually, Gallant uses CloudFormation.

The base Drupal install is going to be basically exactly what we already have (in fact, I just used the same build job in Jenkins with a slightly different promotion job, but we'll get there): A little nothing site with the most ghetto theme around whose sole purpose is to wrangle sites/all/modules and is the only one on which we enable Update (configured to check all projects, not just the active ones, so we don't get never ending spam). Whether you're doing multi-site or stand-alone, it's still Drupal, so we know we're going to need to build something LAMPish or, as you should start thinking of it: LAPMish.

The reason for the inversion is Linux, Apache, and PHP are going to be coming from over here, and MySQL is going to live over there. We'll call his house RDS and, when we move him in, we're going to make a note of the name we gave the CloudFormation stack we used to create him. We should also make sure his template has two outputs, one named RDSHostname and another named RDSPort, but we'll get to those later.

For L, A, and P, we're going to turn to the oddly-named Elastic Beanstalk. The TL;DR for this thing (insofar as we're using it tonight) is it calls websites "Applications" and it deploys "versions" of them in to "environments." Basically, every environment is an autoscaling group whose instances are rigged to deploy whatever version of your application using a specified solution stack (for which I just choose the latest Amazon Linux with the biggest PHP number because I'm a scrub). Sounds easy, doesn't it? Drupal is our application, so we just make a version and go, right?

Wrong. During periods of high traffic, our application could possibly wind up running on 3 or 4 instances which may sound pretty sweet, but presents a problem: What about any content we'd we'd created? MySQL's around so that's fine, but EC2 instances are ephemeral so we'd need a way to keep those pesky files from spiralling off in to the abyss. It would also be nice if it could also save us repetitive, expensive tasks such as generating CSS/JS aggregations and their pre-gzipped (because we do that, right?) counterparts. Bonus points if it gave us a way to manage those files externally because, sometimes, you just gotta. Pan left, enter S3.

Now, I'm sure you're envisioning aws syncing or using a library to do something, but, as before, we're going to be using yet another RioFS fork (YaRF) to mount the content bucket as a directory on the local filesystem. Normally we'd be done here, but Drupal has one more type of "super content" to consider: Its concept of "sites".

Since the end goal is for Drupal to have zero knowledge of any domain it's hosting (thus saving us having to re-deploy the application when we update a site), we're going to be using another S3 mount. The site deploy jobs really didn't change much: The mechanism to set database credentials still uses the username and password you set, only it uses the RDSHostname output from the database stack we set in the CloudFormation template that created our environment (because we're Gallant, not Goofus).

I don't know about you folks, but that sounds like the start of one hell of a good plan right there, so what do you say we throw Amazon a few bucks and get this thing built?