A foray into Fargate – deploying a containerised Kiwi TCMS into AWS

Written by BookingLive’s Senior DevOps Engineer Harley Thorne

We at BookingLive pride ourselves on the stability and performance of our products. Our Enterprise and Connect products are delivered using the AWS cloud, and our internal tools are no different. Behind every great product is a fantastic testing function – so the deployment of a reliable and flexible test case management system is a no-brainer.

Kiwi is the leading open-source test case management system, which allows teams to be more organised, transparent and accountable. You can read more about the application here: https://kiwitcms.org/.

Having recently enhanced and invested in the DevOps and Cloud Infrastructure at BookingLive, we have used this opportunity to deploy Kiwi TCMS using the following technologies:

• Terraform
• AWS
• Docker

You can find the reference architecture below:

AWS

ECS

We strive to provide value in everything we do for our clients, which is why at BookingLive we are always trying to make use of the latest technologies, in order to deliver the most innovative solutions possible. We decided to deploy this solution to AWS ECS Fargate in a bid to keep costs low but automatically scale to performance and availability demands as required with as little infrastructure management overhead as possible – to make my life easier!

Terminology overload when moving into the wonderful world of containers is nothing new, and ECS is no different. We’ll summarise the ECS terminology below.

TASK:

A running container is referred to as a task in ECS.

TASK DEFINITIONS: 

A task definition does what it says on the tin. You define what you want to run, with what configuration. Here is what we configured in our task definition to deploy Kiwi TCMS:

• The Docker image
• CPU / Memory
• Environment variables
• Log configuration
• Volumes / Mount points
• Port mappings

SERVICE:

An ECS Service controls the ongoing running and maintenance of your tasks using the Service Scheduler. It enables you to configure the number of tasks you want to run (using a given task definition). It is also required in order to load balance the traffic to your tasks (for high availability).

CLUSTER:

An ECS Cluster.. you can think of it as the infrastructure deployed for you to run your services upon. Depending on your launch type, you may or may not have access to this infrastructure (more on that below).

LAUNCH TYPES: 

A launch type determines the type of infrastructure that you want your tasks and services to be hosted on. There are two launch types you can use with ECS, EC2 and Fargate. The former, EC2, essentially allows you to run your containers on EC2 provisioned infrastructure that you manage. There are positives to having that granular host-level access, namely flexibility and control, but the deployment of Kiwi was going to be simple enough that we didn’t need this kind of access. Therefore, we opted for Fargate. Fargate manages the infrastructure in the background, so you don’t need to worry about it. You just give it a container, and off you go!

RDS

We opted to host the database in RDS, for ease of maintenance for the most part. We won’t go into too much detail on this service, but essentially, we created a MySQL RDS instance using Terraform and then, using security groups, enabled the web tier to communicate with the database over port 3306 (as per the architecture diagram at the start of this article).

You can find more information on RDS here: https://aws.amazon.com/rds/

Kiwi Configuration

The documentation can be found here: https://kiwitcms.readthedocs.io/en/latest/installing_docker.html

We created our own copy of the Kiwi Docker image and pushed it to a private AWS ECR (Elastic Container Registry), for use in our ECS task definition. We did this as we wanted to configure SES (Simple Email Service) as the email backend:

Dockerfile:

local_settings.py:

Kiwi has made it so that the local_settings.py file will be read if it is present at the location we’ve moved it to.

As you can see in the local_settings.py, we opted to provide our configuration using environment variables to the running containers (passed in through the ECS task definition!). In the end, we passed in:

• KIWI_DB_HOST
  • The hostname of our RDS instance
• KIWI_DB_PORT
• KIWI_DB_NAME
• KIWI_DB_USER
• KIWI_DB_PASSWORD
• KIWI_DONT_ENFORCE_HTTPS
  • We set this as we are doing SSL offloading on the AWS Elastic Load Balancer, so we didn’t want SSL enforced at the application level.
• EMAIL_HOST
  • We set this to the region-specific endpoint of SES SMTP, email-smtp.eu-west-1.amazonaws.com.
• EMAIL_PORT
• DEFAULT_FROM_EMAIL
• AWS_ACCESS_KEY_ID
  • An IAM Access Key with permissions to push email to SES (Simple Email Service, in AWS).
• AWS_SECRET_ACCESS_KEY

Terraform

We use Terraform at BookingLive for all of our infrastructure deployments. Terraform enables you to deploy your infrastructure through code. From looking at the architecture diagram at the beginning of this blog, you can see a large number of AWS resources are required. There are also dependencies between many of the resources and details that need to be passed between them. This is why we created a Terraform module for this deployment. It allowed us to spin up the various components and then dynamically pass the values into the ECS Fargate components with ease. Not to mention that in the event of a disaster we will easily be able to rebuild the solution.

Unfortunately, the module is not genericised enough for public consumption, but if there is interest, let us know.
More info on Terraform can be found at: https://terraform.io.

If you would like to find out more about how BookingLive develop and create systems or more about the solutions it provides to the market please click the button below.