CICD Pipeline for Amazon EKS using AWS Developer Tools and CDK

This pattern describes how to create a continuous integration and continuous delivery (CI/CD) pipeline that automatically creates the repo, builds a sample application and deploys to an existing Amazon Elastic Kubernetes Service (Amazon EKS) cluster on the Amazon Web Services (AWS) Cloud. This pattern uses a greeting application developed with a goLang.

You can use this pattern’s approach to build the code for a any application, package the application artifacts as a Docker image, security scan the image, and upload the image as a workload container on Amazon EKS. This pattern’s approach is useful if you want to migrate from a tightly coupled monolithic architecture to a microservices architecture.

Table Of Contents

Limitations
Requirements
Target Architecture
Tools
Code
Implementation
Best Practices
Troubleshooting
Related Resources
Additional information

Limitations

AWS CLI version 2 must be configured with the same IAM user that creates the Amazon EKS cluster because only they are authorized to add other IAM users, groups, or roles to the aws-auth ConfigMap
This approach doesn’t deploy containers to Amazon EKS clusters across multiple accounts, but this solution can be well extended to include cross AWS accounts deployments.
This pattern’s approach doesn’t implement container-specific logging and monitoring tools

Requirements

An Understanding of AWS CDK and usage.
An active AWS account.
AWS CDK CLI 2.0 +
A web browser that is supported for use with the AWS Management Console. (See the list of supported browsers)
AWS Command Line Interface (AWS CLI) version 2, installed and configured. For more information about this, see Installing, updating, and uninstalling the AWS CLI version 2 in the AWS CLI documentation.
AWS CLI version 2 must be configured with the same IAM user that creates the Amazon EKS cluster because only they are authorized to add other IAM users, groups, or roles to the aws-auth ConfigMap. For information and steps to configure AWS CLI, see Configuration basics in the AWS CLI documentation.
AWS Identity and Access Management (IAM) roles and permissions with full access to AWS CloudFormation. For more information about this, see Controlling access with IAM in the AWS CloudFormation documentation.
An existing Amazon EKS cluster, details of IAM role name and IAM role ARN of worker nodes in EKS Cluster.
Kubernetes Cluster Autoscaler, installed and configured in your Amazon EKS cluster. For more information about this, see Cluster Autoscaler in the Amazon EKS documentation.
Helm version 3.4.2 or later

Target Architecture

The diagram shows the following workflow:

User runs the CDK which automatically creates the Code Commit repo with a greeter goLang Application. Subsequent changes are made as Pull request. Users raise a pull request (PR) with their application code changes to base branch of an AWS CodeCommit repository.
The code push then triggers the AWS CodePipeline based on AWS Event rule configured.
AWS CodePipeline runs the build phase (continuous integration).
AWS CodeBuild builds the artifact, packages the artifact to a Docker image, scans the image for security vulnerabilities and stores the image in Amazon Elastic Container Registry (Amazon ECR).
After the continuous integration phases are complete, AWS CodePipeline enters the deployment phase (continuous delivery).
The Docker image is deployed to Amazon EKS as a container workload (pod) using Helm charts.
Emails Notifications of various phases within the AWS CodePipeline are sent to the users via Amazon SNS.

Tools

AWS CloudFormation – AWS CloudFormation is a service that helps you model and set up your AWS resources.
AWS CodeBuild – AWS CodeBuild is a fully managed build service in the cloud.
AWS CodeCommit – AWS CodeCommit is a version control service hosted that you can use to privately store and manage assets.
AWS CodePipeline – AWS CodePipeline is a continuous delivery service you can use to model, visualize, and automate the steps required to release your software.
Amazon SNS – Amazon Simple Notification Service (Amazon SNS) is a managed service that provides message delivery from publishers to subscribers, e.g: Email notifications, sms notifications
Amazon ECR – Amazon Elastic Container Registry (Amazon ECR) is an AWS managed container image registry service that is secure, scalable, and reliable.
Amazon EKS – Amazon Elastic Kubernetes Service (Amazon EKS) is a managed service that you can use to run Kubernetes on AWS without needing to install, operate, and maintain your own Kubernetes control plane or nodes.
AWS Identity and Access Management – AWS IAM is a web service that helps you securely control access to AWS resources.
Helm – Helm helps you manage Kubernetes applications.

Code

The code for this pattern is available on GitHub, in the EKS-CICD repository. Documentation for each files and folder are mentioned in README.md which is available in GitHub code

Implementation

Setup your environment

Git can be downloaded here
To pull down the repo via ssh, run
- git clone https://github.com/kalyansundars/EKS-CICD.git
- This creates a folder named eks-cicd
- Run cd eks-cicd
- Open config/pipleline-config.ts and update the following values:
  - ServiceName – Name of the service to be created
  - RepositoryName – Name of the CodeCommit Repo Name to be created
  - ECRRepositoryName – Name of the ECR Repo to store built images
  - HelmReleaseName – Name of the helm release
  - Namespace – Namespace name of the EKS Cluster
  - Clustername – Name of the EKS Cluster to be used (Pre-existing)

{    
    serviceName: 'eks-cicd',
    sourceStage: {
        repositoryName: 'microservice'
    },
    buildStage: {
        ecrRepositoryName: 'microservice',
    },
    deployStage: {
        helmReleaseName: 'microservice-chart',
        namespace: 'default',
        clusterName: 'eks-cicd-aws'
    },
    environment: 'dev'  
}

If this is your first time running CDK, ensure you bootstrap the environment with cdk bootstrap. AWS Credentials for CDK can be provided through environment variables or an AWS CLI profile.

Installation

Login to Linux instance where the code is cloned and node environment is setup
Execute the following command to create the CDK stack that creates the necessary resources for clean up

$cdk synth
$cdk deploy

Verification

Verification of Stack creation
- Login to AWS console
- Navigate to cloudformation Service
- Look for name “eks-cicd"
- Verify stack creation under “resources” tab
Verify Code Repo/Pipeline
- Login to AWS console
- Open AWS Code Commit to verify the code repository creation
- Open AWS Code Pipeline to verify code pipeline creation
Execute
- Navigate to code commit repo and make a change to the go application and commit the changes
- This change will in turn trigger the code pipeline and the application gets built and image is pushed to ECR Repo
- Once the above step is done, container gets created in EKS based on the ECR Repo image and gets applied via helm
- Navigate to EKS Cluster to verify the new pod creation
Clean Up
- To tear down the solution, run
- cdk destroy
- This should remove all nested stacks. In the AWS CloudFormation console verify AmiCleanUpStack is no longer present in the region in which it was deployed.

Best Practices

https://docs.aws.amazon.com/cdk/v2/guide/best-practices.html cdk8s is using the same programming paradigm as CDK and both share similar best practices
https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-push.html

Troubleshooting

Issue	Solution
Code Build, Code Pipeline execution errors	User can check Amazon Cloudwatch logs for Code Build, Code Pipeline execution errors.

Related Resources

Additional information

Addition configuration such as tag information for resources created can be added on to the config file.

Credits: Abhay Diwan, Co-Author, AWS; Dipen Desai, Co-Author, AWS