Multisite on AWS EC2

by

I’m working on a multi-site app targeted to run fully Amazon Web Services. Due to its nature, it will have significant traffic spikes, followed by long periods of low traffic, so the ability to scale EC2 instances is a must have.

So far the structure I have in mind is:

                                _____________________
                                Elastic Load Balancer
                                _____________________
                                          |
                                          V
                                _____________________
                          []   []   []   []   []   []   []
                                   Autoscaling EC2
                                With Dynamic Virtual
                                        Hosts
                                Global Business Logic
                                _____________________
                                /         |          \
                               /          |           \
                       Amazon RDS         S3        Site Views?
                      One Per Site       for      
                                     static files

Now, I have two questions:

  1. Where should I keep the site-specific “views” or “theme” files? Is S3 fast enough to handle these? Or should I really create new AMIs every time I need to tweak a particular site’s theme?
  2. Configuration Files. Since each site connects to a separate Database, they each need their own configuration files. Again, should I store these on S3, and all EC2 instances check S3 for updated configs every now and then?

I feel there is some missing link I’m not aware of. What I’ve mostly seen is people advising you create a new AMI, and shut down the current instances and replace them with new ones. This seems like a heavy burden, especially in a multi-site structure where those changes could be specific to only a single site. Is there a preferred method of handling these kinds of code changes?

Answer

  1. A technique that I am thinking of using is to build custom AMIs that upon start will download the necessary data to bootstrap itself. In your case you can keep your sites on S3 and download the files on boot. If you use CloudInit for Ubuntu or something similar for other distros then you can script installation of your site quite easily. I believe it only runs on first boot so rolling-termination of nodes should get the up-to-date version of the site going. In this case you won’t have to continuously update the AMIs.

  2. If you don’t have a configuration management system setup then it’s easy enough to keep a file on S3 with configuration you would need. As you grow Chef or Puppet may be better, but they take some time to learn. This file could be loaded the same way or triggered with a tool like Fabric or Capistrano.

Fabric and Capistrano can help you trigger smaller updates. If you reuse the CloudInit script you won’t have to code it twice. Both Fabric and Capistrano can integrate with the AWS API rather easily to allow dynamic querying of the running nodes so you won’t have to maintain the ever-changing server lists.

A tool for making AMIs that recently launched called Packer could be helpful to you as well. In my first attempt I was able to get a new AMI created in 30 minutes from starting the tutorial. It can also help make AMIs for multiple regions.

Attribution
Source : Link , Question Author : jpschroeder , Answer Author : Philip Cristiano

Leave a Comment