GitLab Runner, ECR & EKS Guide: Deploy on AWS in 15 Minutes

Continuous Integration and Continuous Deployment (CI/CD) are integral components of modern software development, enabling teams to deliver high-quality software faster and more reliably. GitLab Runner plays a crucial role in automating these processes, allowing developers to seamlessly build, test, and deploy their applications. In this blog, we'll explore the architecture of a CI/CD pipeline using GitLab Runner, with a focus on sending Docker images to ECR AWS (Elastic Container Registry and deploying them to an Amazon EKS AWS (Elastic Kubernetes Service) cluster.

Prerequisites of GitLab Runner:

You have an ECR registry. If you have not, go to AWS ECR console and create a registry.
You have a running AWS EKS cluster. If you have not, go to EKS console and create a cluster with at least 2 worker nodes.
You have enable shared Runner in your GitLab registry.

GitLab Runner CI/CD variables:

In GitLab, CI/CD configuration is consolidated within a singular file known as .gitlab-ci.yml. GitLab offers two repository types: public and private. For security reasons easy to understand, it is not recommended to let sensitive information such as password, API key, etc. in your versioned files GitLab Runner Docker Image AWS ECR AWS EKS Manifest File content. To address this concern, GitLab provides a solution through the web interface, allowing users to define CI/CD variables that can be referenced within the .gitlab-ci.yml file.

Define following variables in your GitLab CI/CD variables.

AWS_ACCESS_KEY_ID = “your aws access key”
AWS_SECRET_ACCESS_KEY = “your aws secret access key”
AWS_REGION = “your aws region”
REPOSITORY_URI = “your aws ecr repository url”

CI/CD Pipeline Overview:

The CI/CD pipeline we'll discuss involves multiple stages, each executed automatically by GitLab Runner whenever changes are pushed to the source code repository. The key stages include:

Build-and-Push-Docker-Image-in-ECR AWS Stage:

GitLab Runner detects changes in the repository and triggers the build-and-push-dockerimage-in-ecr stage. This stage involves compiling code and building a Docker image. Once the Docker image is built successfully, it needs to be stored in a container registry. In this case, we'll use AWS ECR. GitLab Runner pushes the Docker image to the specified ECR repository.

Deploy GitLab Runner to EKS AWS Stage:

After the Docker image is available in ECR, the deployment stage begins. GitLab Runner deploys the application to an EKS cluster using Kubernetes manifests

Create a deployment.yml file in your Gitlab repository and paste below code in it.

				
					---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: simple-helloworld-app
spec:
 replicas: 1
 selector:
 matchLabels:
 app: simple-helloworld-app
 template:
 metadata:
 labels:
 app: simple-helloworld-app
 spec:
 containers:
 - name: simple-helloworld-app
 image: 737971166371.dkr.ecr.us-east-1.amazonaws.com/nodejshelloworld:latest
 ports:
 - containerPort: 3000

Create a service.yml file in your Gitlab repository and paste below code in it.

				
					---
apiVersion: v1
kind: Service
metadata:
 name: node-app-service
spec:
 selector:
 app: simple-helloworld-app
 ports:
 - protocol: TCP
 port: 80
 targetPort: 3000
 type: LoadBalancer

Pipeline Configuration:

Dive into the configuration files that define the CI/CD pipeline in GitLab.
Create a .gitlab-ci.yml file in your Gitlab repository and paste below code in it.
This YAML file defines the pipeline stages, jobs, and their configurations. Below is a simplified example:

				
					stages:
 - build-and-push-docker-image-in-ecr
 - deploy_to_eks
variables:
 # Define your variables here, such as DockerHub credentials
 AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
 AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
 AWS_DEFAULT_REGION: ${AWS_REGION}
 ECR_REPOSITORY_URI: ${REPOSITORY_URI}
 IMAGE_NAME: "nodejs-helloworld"
 TAG: "latest"
 IMAGE_FULL_NAME: $IMAGE_NAME:$TAG
 CLUSTER_NAME: "mycluster"
build-and-push-docker-image-in-ecr:
 stage: build-and-push-docker-image-in-ecr
 image: docker:24.0.6
 services:
 - docker:24.0.6-dind

 before_script:
 - apk add --no-cache curl python3 py3-pip
 - pip3 install awscli
 - aws --version

 script:
 - docker build --tag $ECR_REPOSITORY_URI/$IMAGE_FULL_NAME .
 - aws ecr get-login-password | docker login --username AWS --password-stdin
$ECR_REPOSITORY_URI
 - docker push $ECR_REPOSITORY_URI/$IMAGE_FULL_NAME
deploy_to_eks:
 image:
 name: matshareyourscript/aws-helm-kubectl
 stage: deploy_to_eks
 before_script:
 - apk add --no-cache curl python3 py3-pip
 - pip3 install awscli
 script:
 - aws eks update-kubeconfig --region $AWS_DEFAULT_REGION --name $CLUSTER_NAME
 - kubectl create namespace deployment
 - kubectl apply -f deployment.yml -n deployment
 - kubectl apply -f service.yml -n deployment

Explanation:

1- Stages: Defines the sequential stages of the pipeline.
2- Variables: Placeholder for sensitive information like AWS credentials, ECR repository details, etc.
3- Before_script: Executes commands before each job, setting up the environment and configuring necessary tools.
4- Build-and-push-docker-image-in-ecr: Compiles code, builds the Docker image and Pushes the Docker image to AWS ECR using AWS CLI commands.
5- Deploy_to_eks: Applies Kubernetes manifests to deploy the application on the EKS clus

Conclusion:

By leveraging GitLab Runner and AWS services like ECR and EKS, you can establish a robust CI/CD pipeline for your containerized applications. This automation ensures that changes are thoroughly tested and seamlessly deployed, allowing your team to focus on building innovative features and delivering value to users.

Deploy on AWS in Minutes: GitLab Runner, ECR & EKS Guide

Posted By

Syed Muhammad Kashif