Deploying Kong to AWS Elastic Container Service with Terraform

Nick Doyle
3 min readJul 31, 2018

--

I’ll start out by saying that I don’t think this particular architecture is indicated in many instances; thesedays if thinking about building an API the first (and often best) first port of call will be AWS API Gateway or Google Cloud Endpoints.

The reasons I implemented this particular setup were not for an actual system - rather for fun and exercise in my dojo, and to try out a couple things I hadn’t worked with before — namely Kong, and ECS Service Discovery.

It had also been a while since I’d used Terraform, for sure a good weapon to keep sharp. In general I really like Terraform; it’s flexible, elegant, with good community support, and the now-standard support for distributed provisioners by locking+storing state in dynamodb+s3 is great — however in using it I came across the same issues that I (and others) have had in the past; the state getting out of sync or not always applying changes as expected. It wasn’t too bad for this project, but I think could get pretty painful with more complicated setups.

Architecture

Architecture for the project

Notably, access to sensitive areas (Database, Kong admin dashboard) is accessible only via SSH Bastion (and the Kong admin API is only available to the Kong dashboard container).

Kong is serving onlyplain HTTP, with SSL offloaded to the ALB.

Containers know about each other via ECS Service Discovery, which is currently only available in the following regions:

  • US East (N. Virginia) us-east-1
  • US East (Ohio) us-east-2
  • US West (N. California) us-west-1
  • US West (Oregon) us-west-2
  • EU (Ireland) eu-west-1

So e.g. when configuring Kong (automation of which was left in my backlog for the project — and probably there will remain :) one can route requests for “nyan.mydomain.con” to the nyancat web container at “nyan.ecs.local”. It’s a cool setup that leverages existing AWS parts (mainly route53) an removes the need for running your own service discovery.

Docker Images

There are 2 custom docker images used in the project, available on Docker Hub:

The Docker image for Kong with config in SSM parameter store is based on the standard Kong Alpine image, just using aws cli and jq to grab SSM parameters (their names specified in environment vars when launching the image), and use them for config.

The Docker image for Terraform with Kong provider preinstalled is just that. It’s intended to be used once Kong has been stood up, in order to configure the cluster via Terraform. The reason is to not require Terraform actually being installed on the provisioning instance itself — the task that shall I think remain in my backlog :)

Infra Code is here: https://bitbucket.org/nick_doyle/kong_aws_terraform/src/master/

Cost

Running Kong behind an ALB is never going to be cheaper than the pricing for straight ALB, but the excellent tool I used to draw the diagram, cloudcraft, gives a nifty breakdown so I’ll include it for interest.

Wrapping Up

I hope you enjoyed and learnt something. As always, I’d really like your feedback and thoughts below. Until next time!

--

--

Nick Doyle
Nick Doyle

Written by Nick Doyle

Cloud-Security-Agile, in Melbourne Australia, experience includes writing profanity-laced Perl, surprise Migrations, furious DB Admin and Motorcycle instructing

Responses (1)