Deploying Microservice App on K8s

Deploying Microservice App on K8s

Part 6: CI/CD

ยท

6 min read

This blog is Part 6 of the blog series it is recommended that you read the previous blogs before this one. Here is the Part 1 of the series.

In this blog, I will discuss the CI/CD design for the application and manifests related to it.

Clone the project repository-

CI/CD Design

We are using ArgoCD in our cluster, which is a K8s native CD tool.

You will have to make two private repositories. The first private repository will have the application source code, it will contain all files of the "Tasklist App" directory of the project repository which you have cloned. Along with the application source code, it will have a GitHub Actions workflow file.

The second private repository will contain all the K8s manifests like ConfigMap, Secrets, Deployment, Statefulset and other manifests. This repository will essentially contain every file of the "Manifests" directory of the project repository that you have cloned.

You can make these private repositories right away. You don't have to make the GitHub Actions file for the application's private repository. I will give you the GitHub Actions file in the later part of the blog series.

So CI/CD pipeline will work like this-

Argocd running in the AWS EKS cluster will constantly monitor the private repository of the manifests. Argocd will maintain the cluster exactly as defined in the manifests file of this repository.

Whenever you commit to the application's source code in the application's private repository. The GitHub Actions workflow will get triggered. This GitHub Actions workflow file will essentially do 2 things.

  1. It will do the CI (Continuous Integration) by building the application's image and pushing this application's new image to the AWS ECR Repository. It will tag the image in the AWS ECR repository with a unique hash value.

  2. When it has done the first task it will change the tag of Image in the manifest which resides in GitHub manifests's private repository. It will update the image tag with the same tag that it has attached to the Image which it has pushed to the AWS ECR repository.

As I said above, ArgoCD constantly monitors the manifests of the GitHub manifests's private repository and maintains the cluster exactly as described in those manifests. When the GitHub Actions has done its job, ArgoCD will notice the change in the Image tag in the manifest. When it notices this change, it will try and search for the Image with the same tag in the AWS ECR repository.

As GitHub Actions has already pushed the Image with the tag that is searched by ArgoCD in the AWS ECR repository, the image will be found by ArgoCD and then ArgoCD will deploy this Image on the cluster. Hence CI/CD will be completed.


There are certain manifests required to make ArgoCD do its job and in this section, I will discuss those manifests.

You will find the manifests I discussed below in the "Manifests" directory of the project.

argocd.yaml

This manifest will run ArgoCD manifest and we will configure ArgoCD here.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: argo-web-cd
  namespace: argocd
spec:
  project: default
  source:
    repoURL: "GitHub fined grained token to access this repository"
    targetRevision: main
    path: .
  destination:
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      selfHeal: true
      prune: true

In the metadata section, we name the ArgoCD application as argo-web-cd and it resides in the argocd namespace.

You can define projects in ArgoCD to group related applications together and manage them collectively with shared settings. The "default" project often serves as a catch-all for applications that don't belong to a more specific project. So in project field of manifest we specify "default".

In the source field, we paste our GitHub manifests' private repository URL and set targetRevision to "main". This targetRevision tells ArgoCD which of the GitHub branch to monitor, we have specified the main so it will monitor the main branch of Manifetsts's repository.

Next, we have the path field, path field is used to specify the directory or path within the repository that contains the Kubernetes manifests for the application. We have manifest in the root of the repository therefore we have specified "." there.

Next, we have the destination field, this field is used to specify the Kubernetes cluster where the ArgoCD application should be deployed.

The last field is syncPolicy, which is used to define the synchronization behavior of ArgoCD. In this field selfHeal is set to true which means that ArgoCD will automatically attempt to bring the application back to the desired state if any discrepancies are detected between the desired state (as defined in the GitHub manifests's private repository) and the actual state in the Kubernetes cluster.

Last we have the prune set to true, which means ArgoCD will delete resources from the cluster that are no longer specified in the Git repository.

You can read the ArgoCD doc related to this manifest here.

argo-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: argocd-secret
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  url:   "manifest repository url"
  password: "GitHub fined grained token to access this repository"
  username: not-used

This file is a K8s secret file, it will have the GitHub fine-grained personal access token of the GitHub manifests's private repository.

Since the manifests are stored in a private repository, ArgoCD will need to authenticate itself to the private repository to monitor it. Therefore we will store the token here.

In the metadata, we are naming this secret as argocd-secret and it will reside in the argocd namespace.

Next in the label, we are essentially defining the type of secret which means the secret is for a repository.

In the stringData field, you need to mention the URL of the GitHub manifests private repository.

Next is password field, here you have to paste the GitHub fined-grained personal access token. In the later part of the blog, I will give the tutorial to get this personal access token.

The username field typically represents the username or identifier required for authentication when accessing the specified repository. We have set this field to "not-used" which means the username is not utilized or required for authentication in the context of the manifest repository specified in the url field.

You can read ArgoCD secret here.


Get Fine-grained Personal Access Token for Private Manifest Repo

In your GitHub account go to settings option which you can see by clicking on your profile picture.

In the settings page go to the developer setting. In developer setting page go to "Personal access tokens" and click on "Fine-grained tokens". On your current page click on "Generate new token".

  • In the token creation page, enter a name for your token.

  • Enter the expiration date and a description.

  • Next, in the "Repository access" select "Only select repositories" and then click on "Select repositories" and then select your manifests's private repository.

  • Next, in the "Permissions" section select "Repository permissions" and then you need to give "Contents" feature to "Read and write" permissions. After this at last of the page click on "Generate token".

  • After this you will see your fine-grained personal access token, copy this token and paste into the argo-secret.yaml file.


Share the blog on socials and tag me on X and LinkedIn for the #buildinpublic initiative.

Follow me on X and LinkedIn

******Thank you for reading๐Ÿ˜๐Ÿ˜‡******

ย