Welcome to Multiarch EKS Springboot Deployment Pipeline with CDK

Overview

AWS Graviton 2(using ARM) provides up to 40% better price performance over comparable current generation x86-based instances for a wide variety of workloads.

A hybrid ARM & AMD deployment takes advantage of the Graviton instances, at the same time lowers risks to migrate from AMD to ARM in one shot.

In this sample, you will build a java springboot application on a hybrid ARM & AMD EKS cluster. You will use the same source code to trigger an automatic deployment pipeline, build on both ARM and AMD. The whole setup is based on AWS Cloud Development Kit(CDK).

Architecture diagram

springboot application backend walk through

End users send request to a public application load balancer(ALB).
ALB send request to AWS load balancer ingress in EKS cluster. The EKS cluster contains 2 managed node groups, one with AMD instances, the other with Graviton 2 (ARM) instances.
AWS load balancer ingress route requests to the springboot application service. Springboot application service contains pods running on both AMD and ARM nodes.
Springboot pods talks to RDS Aurora, Elasticache Redis and generate the response.

deployment pipeline walk through

Devops users commit code to AWS CodeCommit.
The code commit triggers AWS CodePipeline, starting with a build phase. Build phase has 2 tasks running on AWS CodeBuild in parallel, one is on AMD instance to compile source code and build the AMD docker image, the other is on Graviton 2 instance to build the ARM docker image. They both push the docker image to ECR at the end of the task.
When both tasks in build phase succeeds, a post build phase is triggered. The post buid task creates a docker manifest on top of the ARM and AMD docker images. The manifest alias will route to ARM or AMD docker image based on the architecture of the requester.
The post build task commits the manifest to ECR.
The post build task runs kubectl to apply kubernetes config changes, update springboot service image to the newly created manifest alias.
Springboot service picks up the config change, pods download the image matching the architecture of their hosting nodes, via the manifest alias.

Run the Pipeline

Prerequisite

Install cdk Follow the prerequisites and install guidance. CDK will be used to deploy the application backend and deployment pipeline stacks.
Dockerhub account and access token Access token can be created in dockerhub. The username and token will be used to pull images from dockerhub during code build phase.
Install kubectl Follow the instructions. kubectl will be used to communicate with the ESK cluster.

Step by step guidance

Create Systems Manager Parameter Store in the console

Search system manager in services
Click Parameter Store in the left panel
Prepare your dockerhub username and access token
Click Create to create a new parameter, input Name as /springboot-multiarch/dockerhub/username and Value as your dockerhub username
Leave the others as default and click Create Parameter
Click Create to create a new parameter, input Name as /springboot-multiarch/dockerhub/password and Value as your dockerhub access token
Leave the others as default and click Create Parameter

Checkout the code, deploy both springboot application backend and deployment pipeline on AWS via CDK

# Checkout the code
git clone https://github.com/aws-samples/multiarch-eks-springboot-deployment-pipeline-with-cdk.git

# Prepare env
cd multiarch-eks-springboot-deployment-pipeline-with-cdk/cdk
python3 -m venv .env

# Run cdk to deploy both springboot application backend and deployment pipeline
# Please make sure CodeBuild ARM support(https://aws.amazon.com/codebuild/pricing/) 
# is available in the chosen region 
# e.g. ./bootstrap.sh 12345678 us-east-1
./bootstrap.sh {AWS ACCOUNT ID} {REGION}

# Make a note of CDK outputs
# i.e.
# backend.EKSConfigCommandxxxx
# pipeline.CodeCommitOutput

Commit code to codecommit to trigger the pipeline

# Checkout the new codecommit respository created by CDK in step 2
# i.e. value of pipeline.CodeCommitOutput
#   (make sure you are in the same filepath as in step 2 where you checkout the code)
#   e.g. 
#   ~/environment/multiarch-eks-springboot-deployment-pipeline-with-cdk/cdk (main) $ cd ../..
#   ~/environment $
git clone https://git-codecommit.{REGION}.amazonaws.com/v1/repos/springboot-multiarch test

# Copy source code to the new codecommit repository
cd test
cp -r ../multiarch-eks-springboot-deployment-pipeline-with-cdk/* .

# Commit source code to trigger deployment pipeline
git add *
git commit -m "trigger commit"
git push

Get application load balancer(ALB) address and visit

# Config kubectl to connect to the EKS cluster created by CDK in step 2
# Check CDK output backend.EKSConfigCommandxxxx
# e.g. aws eks update-kubeconfig --name {EKS CLUSTER NAME} --region {REGION} --role-arn {EKS MASTER IAM ROLE}

# get ALB address from kubernetes cluster
kubectl describe ingress | grep Address 
# e.g. Address:          k8s-default-springbo-cd123ab45c-98765432.{REGION}.elb.amazonaws.com

Expected results

Visit the ALB address output from step 4 in the last section. NOTE: You need to wait for about 1 minute before ALB is successfully provisioned.
Confirm browser shows the content similar to:

{"RDS Test":"passed","Node Name":"ip-10-xx-xxx-xx.ap-northeast-1.compute.internal","Redis Test":"passed"}

Refresh the page several times to observe the Node Name switch. The nodes are running AMD and ARM (graviton) correspondingly.

Cleanup

cd cdk
./cleanup.sh {AWS ACCOUNT ID} {REGION}

Security

See CONTRIBUTING for more information.

License

This library is licensed under the MIT-0 License. See the LICENSE file.

sinasojoodi/multiarch-eks-springboot-deployment-pipeline-with-cdk