Amazon CloudFormation Second Look

02 Mar 2011 Amazon CloudFormation Second Look

Second look at Amazon CloudFormation

This is a follow-up post to my quick experiments in using the new Amazon CloudFormation service to quickly provision and deploy a full-on Redmine Project Management stack on the Amazon Cloud.

The main purpose of this post is to show how easy it was to modify the public “Redmine Stack” template that Amazon made available when CloudFormation was launched.

The good news

CloudFormation launched with pre-made templates for deploying Redmine based systems which was fantastic as it allowed me to deploy a quite sophisticated application stack while sitting in a local Starbucks.

The Redmine template automatically handled the following:

  • Launching the EC2 server with all the necessary software
  • Automatically creating a Mysql database in Amazon RDS
  • Automatically pointing the Redmine install at the RDS database
  • Automatic provisioning and assignment of an Elastic IP
  • Automatic setup of security groups for the RDS database and EC2 Server
  • And a few other things …

The bad news …

Issues caused by me

The dumbest thing I did was forget to alter the database passwords contained in the Redmine template. This meant that our MySQL database username and password was “admin” and “admin”. Doh!

The good news is that the Redmine template and CloudFormation limited the potential security damage. The fact is that thanks to the security groups that were set up automatically access to the MySQL database is not allowed from the internet. Access is allowed only from within AWS and only by someone presenting the proper cloud credentials. Still a dumb move and something I needed to change.

Issues with the Redmine CloudFormation template

Upon further reflection and looking at the Redmine template, I had a couple of issues and concerns with it — nothing technical, just concerns about how well it fit our needs and use cases.

Concerns:

  • The template does not install an SSH keypair into the EC2 server which means that no remote login access to the server is allowed. This is not cool for the use cases we envision
  • The template uses the Amazon RDS service for it’s MySQL database. This is probably overkill for our small use case and racks up costs by requiring the use of an $.11/hour RDS m1.small server instance in addition to the EC2 server we run the webserver on
  • The template automatically configures and provisions an Amazon Elastic Load Balancer interface to front-end our web server. This is about 10,000x times overkill for our little use case. We don’t need load balancing to the web server and we certainly don’t need to pay the extra traffic charges incurred by passing data through the load balancers
Obf redmine 004
Note the terminated server instance that has no SSH keypair!
It’s not fun having a server you can’t login to!

A perfect opportunity!

The issues I had with the premade Redmine template gave me a perfect excuse to dive into CloudFormation a bit more to see if I could actually customize and create my own CloudFormation Stack template.

Customizing the Redmine CloudFormation Template

Here are text versions of the CloudFormation Template files I’ll be talking about in this post:

I’ll try to graphically show the (simple) changes between the custom template I made based off of the original Redmine one…

In the pictures below, the original template text is on the right and the changes that I made are in the left column. If the pictures are not clear or all that readable they can be used as reference points for examining the JSON formatted templates linked above.

Obf redmine 002
Defining a new parameter for our SSH Keypair
Obf redmine 008
Change the default password to something other than ‘admin’
Obf redmine 009
Change the EC2 server default size down to a small t1.micro instance
Obf redmine 012
This is an important edit, here we pass in the name of our
SSH Keypair as an attribute to the EC2 Properties
Obf redmine 011
Deleting all mentions of the Elastic Load Balancer resource
Obf redmine 013
Replace the URL “output” from the stack which referred
to the load balancer hostname with one that just lists the elastic IP address

Impressions

I’m still impressed with CloudFormation and this customization effort only reinforced my view. Hacking up the JSON file that represents the Stack Template was straightforward and pretty easy to debug.

Obf redmine 001
Loading our new “Stack” is as simple as uploading the JSON formatted text file…
Obf redmine 003
Nice! We now have an SSH Keypair parameter and a t1.micro instance in our “Stack”

If you screw up your template you might have to squint your eyes a bit to see the error as it’s tiny and hidden in the Amazon console view:

Obf redmine 006
Can you see the error message?
Obf redmine 005
How about now?

Oops.

This is what you end up with when you screw up your “stack”. In this case I accidentally manually deleted an Elastic IP address that had been provisioned as part of an earlier CloudFormation stack deployment.

With the Elastic IP address gone, I’m completely unable to delete the old Stack from the CloudFormation management interface in the AWS Web Console. I suspect I’ll have to go into the support forums and either ask for help or more likely ask for one of the AWS engineers to manually delete the stack.

Click on the image for the full-size version.

Related Posts
Filter by
Post Page
Employee Posts Screencasts Featured News Presentations Events
Sort by

Amazon CloudFormation First Look

2011-02-25 14:42:19

22

Amazon VPC Deployment Screencast

2010-12-06 10:17:35

22

Grid Engine & Amazon EC2

I delivered the following presentation at the 2009 Sun HPC Workshop where
2009-09-09 09:10:43

22

No Comments

Post A Comment