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.
- 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
|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.
|Defining a new parameter for our SSH Keypair|
|Change the default password to something other than ‘admin’|
|Change the EC2 server default size down to a small t1.micro instance|
|This is an important edit, here we pass in the name of our
SSH Keypair as an attribute to the EC2 Properties
|Deleting all mentions of the Elastic Load Balancer resource|
|Replace the URL “output” from the stack which referred
to the load balancer hostname with one that just lists the elastic IP address
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.
|Loading our new “Stack” is as simple as uploading the JSON formatted text file…|
|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:
|Can you see the error message?|
|How about now?|
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.