DRAFT Continuous Deployment With Jenkins and Amazon EKS Part 1
One of the requirements we run into frequently in the Charlotte market is that companies want to build and configure continuous deployment pipelines in Jenkins to run against Amazon ECS or Amazon EKS. This is the start of a series of articles that shows you how to do this for Amazon EKS with the help of Packer and Terraform.
I say a series of articles rather than a single article not because of the difficulty, but because of the number of moving parts. Since we’ll be doing this project from the ground up – minus a few assumptions about installed and available tools that we’ll go into in a moment – we realize that there are a fair number of pieces we’ll need to put together. In a corporate environment, many of these might already exist, but for our purposes we’ll be building it from the ground up.
In the rest of Part 1, we’ll go over what we’ll be building and the tools of the trade we’ll use to build it.
In Part 2 we’ll focus on being able to build and deploy our sample application. We’ll go over the sample application that we’ll be deploying, a simple Spring Boot application that we’ll make available on Github. We’ll also stand up a Jenkins server on a Docker instance. This image will also include a number of tools that Jenkins will need to build our application and Docker image. With this in place, we’ll configure our Jenkins server to build our docker image, and we’ll test it out locally for now using minikube.
In Part 3 we’ll give our application a new home using Amazon’s new EKS service – Elastic Container Service for Kubernetes.
The Tools We’ll Be Using
Two things can be said of software tools: First, there are a lot of them. Secondly, each one takes some time to learn to use at all, and more time to use well. Together these two considerations lead me to always prefer tools that will serve me well in a variety of different contexts. Here then are the choices that I’ve made for the article:
We’ll be using Packer to build our Docker images rather than Dockerfiles. Fair warning: I’m a bit of a Hashicorp fanboy, but with good reasons! In the case of Packer, their web site puts those reasons best:
Packer builds Docker containers without the use of Dockerfiles. By not using Dockerfiles, Packer is able to provision containers with portable scripts or configuration management systems that are not tied to Docker in any way. It also has a simple mental model: you provision containers much the same way you provision a normal virtualized or dedicated server.
I personally have used Packer to create Amazon AMI images, for example. And as they point out, you can use a variety of scripts or configuration management systems.
I used bash when configuring the AMI image that I mentioned above, but the configuration management tool we’ll be using is one that has recently grown to be my favorite choice for such work, Ansible. We’ll use Ansible both for configuring our application image and our Jenkins box. Ansible is powerful, clean, and relatively easy to learn
For configuring and launching our EKS cluster we’ll use another Hashicorp tool, Terraform. Why not Amazon’s CloudFormation – their native tool? Here again, our choices are guided partly by flexibility – Terraform enables us to target Amazon EKS, to be sure, but what if it turned out we later learn we can save our company tens of thousands annually by moving to GCP Kubernetes? Terraform allows us to target different cloud vendors or even set up Hybrid clouds, all from within the same tool.