Posts tagged with "aws"

In the first post on how we moved our application to Docker on AWS, I described the reason for us to do it, and how we set up the servers. This post describes how we’ve organized the different Docker containers.

Container Setup On AWS

Our setup on AWS looks like this:

We use an EC2 load balancer to route traffic to our web hosts. This is an easy way to setup clustering, but you should be aware that EC2 does not allow for any alternative route or html page if no hosts are available. This means that if all instances are down for some reason, the only thing shown is a blank page. This has been a long standing feature request which for some reason hasn’t been implemented yet.

Last fall, we moved the Qwaya Facebook ads tool from a single host on Rackspace to a clustered Docker based environment on AWS. This is the first blog post of hopefully more that I’m writing to remember what we did. I’ve planned two more posts, one on how we handle CI and one on container orchestration.

Why Docker?

The task at hand was not “Move to docker”, it was “get out of single host hosting”. The old deployment consisted of some quite complicated Fabric scripts that was run from an arbitrary developers laptop. The source code repository did not match the deployment setup, so there was a lot of remote copy commands running around. I know that this is a very common way of deploying applications, but it brings a number of problems. For example, there are no build artifacts, making repeatable builds harder, and if the build fails halfway in you will have a broken system.

At Qwaya we run our servers in AWS. We build our own base AMI’s in order to ensure a stable base infrastructure and to be able to quickly launch new servers when needed.

We have a few AMI’s arranged as described in the image below:

• The base image holds all the packages we want installed on all hosts, it sets up docker, logspout logging to Papertrail and [Datadog][datadog] monitoring.
• The Web and Worker images holds different systemd files for different parts of our application.
• We use Buildkite for building and deploying, which uses a bring-your-own technique for build servers. We have two kinds, one for building and one for deploying.

While we really should have our configs in something like Consul, we’re not there at the moment. In order to limit the number of AMI rebuilds, we try to place configs in cloud-init to limit rebuilds.