Using a support ticket service as my example SaaS solution, I’ve been demonstrating how anyone can take advantage of the tools offered by Amazon Web Services to take your idea from a business plan to a product that is available to your customers via the cloud. So far, we’ve worked through planning and design considerations, built an IaaS layer, and used AWS CloudFormation templates to create a highly available cluster. We’re now ready to start polishing the application.

The next step is to change the AWS CloudFormation template to automate the build of my support ticket service. I have a high-availability cluster, Drupal, an RDS database, firewall rules, a load balancer and so on. It’s a fantastic thing to achieve with a web UI and a few mouse clicks.

But it’s not fantastic enough. I must edit the CloudFormation template, to bring it closer to my needs, but first I have to know what’s in it and where I need to make the necessary modifications. Below, I’ll give you an overview of all the parts.

Polishing my service means entering developer territory

The service provided by the AWS CloudFormation Drupal template is not what I want. I am going to tweak that template here to make the needed changes. Unfortunately this means crossing into developer territory. I won’t make the whole journey, because developer territory is a desolate wasteland that is unpleasant to visit. I will cover enough to light the way.

A combination of Drupal modules

SaaS companies build their services. They don’t take white-label goods and stick their badge on. I will build my support ticket service using the Drupal Core CMS toolkit, a bunch of optional extras, and a lot of development time.

However, there are plenty of optional modules for Drupal that I can string together to cut down development time.

  • The support ticket service comes from the Support module. The Support module provides the business end of my service.
  • The monetizing mechanism comes from a set of Commerce modules. These handle the e-commerce side. Drupal Commerce is a big collection, with nearly twenty modules to install and many more supporting modules. These provide the framework for dealing with customers, tax, line items, payment, products and so on.
  • The control of this premium content is managed by Content Access module and other things, such as the Roles access control mechanism. These modules stick the commerce and support ticket parts together.

What’s in an AWS CloudFormation template

I can edit an AWS CloudFormation template file to suit my needs.

Click to enlarge.

First I must understand what a template is. Here’s a brief overview. For a more detailed description, see the AWS guide Bootstrapping Applications via AWS CloudFormation.

The little automatic gremlins that build CloudFormation take their instructions from a configuration file that looks a bit like this.

{
    "AWSTemplateFormatVersion" : "version date",
    "Description" : "Valid JSON strings up to 4K",
    "Parameters" : {
        keys and values
    },
    "Mappings" : {
        keys and values
    },
    "Resources" : {
        keys and values
    },
    "Outputs" : {
        keys and values
    }
}

This text, with its liberal sprinkling of curly braces, quotes and colons, is JSON (JavaScript Object Notation). JSON is popular with developers who don’t want the wordiness of XML but aren’t cool enough for YAML.

The keys and values line in the example above would look a bit like this in a real template file.

"S3Bucket" : {
   "Type" : "AWS::S3::Bucket",
   "Properties" : {
      "AccessControl" : "PublicRead",
      "WebsiteConfiguration" : {
         "IndexDocument" : "index.html",
         "ErrorDocument" : "error.html"
      }
   }
}

All that indented stuff is a load of nested key/value pairs. It’s complicated, and it’s only the tip of the iceberg. Template files are nerd heaven.

The Launch Config

The Resources section of the template file contains a sub-section called LaunchConfig. This section starts with this line.

“LaunchConfig”: {

The LaunchConfig section is 200 lines of cleverness. It has a list of files to install, download and create. It’s also got an entire bash script embedded in it.

I use the clustered Drupal template. You can see it here: Highly Available Web Server with Multi-AZ Amazon RDS database instance and using S3 for storing file content.

Later, I’ll be making a few changes to the LaunchConfig section of this template and create a cluster.

The embedded bash script

The bash script in the LaunchConfig section is located towards the bottom of the file. The script is about 60 lines long and looks like this.

"UserData"       : { "Fn::Base64" : { "Fn::Join" : ["", [
          "#!/bin/bash -v\n",
          "yum update -y aws-cfn-bootstrap\n",
...
...
...
         "# All is well so signal success\n",
          "/opt/aws/bin/cfn-signal -e 0 -r \"Drupal setup complete\" '", { "Ref" : "WaitHandle" }, "'\n"
 
        ]]}}

The job of this disturbing-looking template code is to put all those lines into a bash script.

A bash script is a collection of commands that does all sorts of things to the system. System administrators have been writing scripts for decades. This clever bash script edits the Apache web server configuration, lists all the new EC2 machines, sets up a basic Drupal site, and so on.

This script is copied to each new EC2 VM. It ends up in the directory /var/lib/cloud/data/scripts/. All the messages it produces end up in /var/log/cloud-init.log.

The EC2 machines’ files and directories

Distributing an application across many servers is tricky. You have to know what is copied, what is shared, and where it should all go.

Lots of files are duplicated across the machines. All the general code (Drupal Core) is copied to the web site directory on each new server (it’s in /var/www/html).

The S3 bucket

Some of the files are shared between machines. One bit of the file system is actually an AWS S3 (Simple Storage Service) bucket. This shared area is mounted on all three servers (on /var/www/html/sites/default/files). Some Drupal files will sit in this S3 bucket.

S3 buckets are usually used for web site static content, rather than executables, logs and other tricky files. This S3 bucket will hold customer file uploads. One customer uploads a file once, then all the web servers can respond to requests for this file.

Template backup

Don’t bother storing your new template on the web. You can give CloudFormation a URL to get your template file, but it only works with AWS S3 (Simple Storage Service). That’s where AWS stores its templates. That’s where your uploaded template gets stored. Developers who use a code repository like Github or Gitorious are out of luck.