Archives For aws

In my previous post I weighed up the benefits and limitations of Amazon’s Elastic Beanstalk hosting environment for Magento and took a very vague look at the costs. In this post I will run through the actual setup of a very basic Magento install ‘in the cloud‘ and the process of deploying changes. The goal for this initial setup is to keep everything bone stock as possible, we want minimal maintenance effort and an automated environment.

If we have some time at the end, we’ll do some stress testing of the platform to see how it handles customers. Benchmarks will have to wait, stay tuned.

The Tools

For this tutorial we’ll be working in a linux environment. I used a small EC2 server with the AWS default Linux AMI as the setup box, it’s nice and fast being on the same network as the Beanstalk platform. Make sure you have the following installed.

  • AWS EB tools, and the getting started guide
  • git, sudo yum install git
  • ruby, sudo yum install ruby
  • python 2.7, sudo yum install python27 – this one is a bit of a pain on the AWS default Linux AMI, you’ll need to hack in explicit use of the 2.7 binary in the AWS scripts. Or, heaven forbid, set it up properly and compile from source…

Once you have those in place, you should be ready to get Magento and the Beanstalk environment setup.
Continue Reading…

In this post I’m going to introduce Amazon’s Elastic Beanstalk PHP environment as a platform for Magento. In particular I’ll cover the mechanics and economics of hosting Magento, along with it’s benefits and limitations as a platform. The goal here is to create an auto-pilot environment providing high availability and scalability.

But first, the background. With World Wide Access, we’ve always run our own EC2 instances, ELBs, database servers and memcached. We scale up the instance sizes or counts manually when required. When we started using AWS (in 2008) Elastic Beanstalk was not yet on the scene so we had no choice but to do it that way. But now we do have a choice and, thanks to some downtime in the last week, I’m prompted to gather some thoughts on a migration to a fully auto-pilot set-up. This post is my notes on Elastic Beanstalk and Magento with git for deployment. I’ll add a more detailed setup guide and some benchmarks in a future post – this one will be a bit more abstract, so go make yourself a cuppa.

About the Amazon’s Elastic Beanstalk

Beanstalk brings together various parts of Amazon’s infrastructure: AWS servers, scaling, load balancing and high availability, to give your applications an automated environment to run in with flexible server sizes and instance counts that make growing easy. You can do all the things Elastic Beanstalk does, by combining the separate parts yourself, but this is much easier, trust me.
Continue Reading…

In this post I’ll run through the quick steps required to update your AWS Auto-Scaling group to use a new EC2 AMI. This post builds on the guide covered in my earlier post on setting up an Auto scaling group for an elastic load balancer, which in turn was built on the WordPress clustering guide. You could say this is part 3 in a rather long-running series.

There’s not much too this process thankfully.

Step 1: Create your new AMI

The easiest way I have found to do this is actually via the EC2 console. All I do is start a new instance on my current AMI, log into it and make any changes required (install/update packages etc) and then from the EC2 console, select the instance.

You don’t often need to log into the slave nodes, so if you need a refresher on how to do it, this command is all you should need:

ssh -i path/to/your/key.pem user@your-public-ip-of-the-node.compute-1.amazonaws.com

Continue Reading…

I’ve had a fun & games sort of day working through this Magento SSL offload on Amazon’s ELB and I thought it’d be worth documenting what’s involved, in the process I’ll give some steps to get it working and explain what the new (since version 1.6.2) Offloader header config option is for and how it helps.

Background

Firstly, a bit of background – if you just want the quick fix, skip right to it. The Internet can beam magically onto your computer screen one of two ways: http and https. http means the things you see everyone else can see too, the content is unencrypted and sent from the server to your computer. If you’re at a wifi hotspot, what you do online is being broadcast to everyone around you. Conversely, an https connection means the content is securely encrypted, and the endpoint server you are connecting to, is probably who they say they are. So we want https in public places, or when financial or personal information is involved – and if we’re paranoid, we want it all the time.
Continue Reading…

Back in June last year I wrote about creating a WordPress cluster on Amazon’s EC2. In this post I’ll run through a couple of the problems with that cluster, I’ve experienced, and how I solved them with Amazon’s Auto Scaling service.

The problems with the cluster

A couple of things were not ideal with the cluster that I’ve been putting up with for far too long but finally set aside some time this afternoon to fix.

1) The price of micro-sized spot instances spikes, to crazy prices, sometimes.
This has meant that although the price of micro instances while they’re running is cheap, when the price spikes they all die off and leave the cluster vulnerable. Unfortunately to set up auto-scaling in combination with spot-priced micro instances would require coding up a hybrid solution with shell scripts, and although I enjoy tinkering with this setup, I can’t justify that much effort when an out-of-the-box solution exists, Auto Scaling.
Continue Reading…