Skip to content. | Skip to navigation

Personal tools
Log in
Sections
You are here: Home Web Hosting Hosting Plone at Amazon How ONE/NW Got AWS Up and running

How ONE/NW Got AWS Up and running

 

From: Jon Baldivieso [mailto:jonb@onenw.org]
Sent: Wednesday, November 12, 2008 10:42 AM
To: Patrick Shaw
Cc: davidglick@onenw.org; Jesse Snyder; Patrick Tewson; David Averill
Subject: Re: Moving a site to Amazon Web Services and EC2

 

I believe David's already shared some of the upfront costs to ramping up with AWS, but fwiw, here is an outline (w/ funky formatting) of how we've structured this setup:

 

▼            Goals

          ▼  have a reusable generic Zope-hosting disk image that didn't have *any* server-specific data on it.

                •              including cron jobs, apache config, etc

          •    use a mounted EBS volume for persistent data

          •    make server restarts as easy as possible

          •    support multiple Zopes within their own production buildouts

▼            What we did

          ▼  created a 64-bit image (supports L and XL EC2 instances) with:

                ▼            basic dependencies

                      •        apache

                      •        python/PIL

                      •        svn

                      •        postfix

                •              a user account "zope"

                ▼            very basic apache config that

                      •        include ModProxy module and friends

                      •        told apache to also load all .cfg files from a specific location, which was going to be on our persistent volume

          ▼  set up an EBS volume to host all data and configuration

                •              /usr/local/zope (home dir for Zope user)

                ▼            we used extended buildout recipes to capture misc other configuration, which was all under version control

                      •        bc we like to have a history of how our configuration evolves so we can see how it's changed and roll back if needed

                      •        we can emulate the entire production environment locally, if needed

                •              we used conventions to locate each buildout's apache config and cron jobs within parts of the buildout

                ▼            we set up a shell script that we call after an EC2 system reboot and after we've remounted the EBS volume

                      •        searches convention-based paths for new cron entries to compile a new crontab

                      •        starts Apache (bc we're including configuration from the EBS, this can't happen in a more normal rc.d way)

                      ▼      searches each buildout dir for a ec2-init.sh script and calls it

                            •  create a dir on the non-persistent AMI to host the buildout's log dir, bc you pay for disk IO on EBS volumes. (we're not sure about either the performance implications nor the cost-savings for this.)

                            •  start up the relevant services for the buildout (we use the supervisor recipe, so that really just means starting up that buildout's supervisor daemon)

          ▼  we have a suite of shell scripts that do normal maintenance that isn't specific to this architecture

                •              apache log parsing (we log to the non-persistent part of the AMI but parse the logs using AWStats and store to the persistent area)

                •              zope data backup (repozo) and purge of old backups

                •              ZODB packing

                •              log rotation

                •              the main AWS-specific automated task is snapshotting the EBS volume to S3

 

 

Document Actions

Comments (0)

« February 2012 »
February
MoTuWeThFrSaSu
12345
6789101112
13141516171819
20212223242526
272829