Skip to main content
Version: Release 24.3

Continuous Delivery Using Release and Argo CD

Before You Begin​

This how-to involves working with a variety of tools and technologies such as Digital.ai Release, Argo CD, Digital.ai Release templates as code (.xlr files), GitHub, Amazon EKS, AWS CLI, kubectl, and so on. You can perform this task by simply following the instructions. However, being familiar with these tools and technologies can help you considerably when you try this out in your test environment.

To know more about Amazon EKS and Argo CD, see:

What's the objective?​

The objective is to illustrate how to set up a continuous delivery (CD) pipeline—for deploying applications to a Kubernetes cluster—that leverages the Release Management and CD capabilities of Digital.ai Release and Argo CD respectively.

Once you have this setup in place, all you would be doing is pushing a code change to trigger a release job in the continuous delivery pipeline and have your application deployed to the dev environment, verify the deployment, and then trigger another release job for one of the qualified dev images and promote your application to the next environment such as uat or prod.

  • Though the Digital.ai Release's Argo CD plugin supports GitHub, GitLab, and BitBucket repositories, this how-to is built with the GitHub repository for illustrative purposes.
  • Though the Digital.ai Release's Argo CD plugin supports all the popular cloud platforms such as AWS, GKE, and so on, this how-to is built with Amazon EKS for illustrative purposes.

What do you need?​

This CD pipeline is built with:

  • Digital.ai Release as the CD orchestrator.

    Digital.ai Release 22.0 or later with the following plugins installed:

  • Argo CD as the CD tool of choice.

  • GitHub as the repository that hosts the helloworld application code and Kubernetes manifest files.

  • GitHub Actions as the CI tool to build the helloworld application.

  • Docker Hub as the docker image repository.

  • Amazon EKS as the Kubernetes cluster where the helloworld application is deployed.

CD Pipeline

Keep these handy:

  • Digital.ai Release credentials
  • GitHub credentials
  • Docker Hub credentials
  • AWS credentials
  • Argo CD credentials

What do you have?​

This how-to has been built with an example GitHub how-to repository that hosts the following:

How does it work?​

Here's a high-level overview of what you would do to set this up and what happens when you start the deployment process with a simple code commit/merge.

At the end of this exercise you would have:

  • forked the xebialabs-community/howto GitHub repository and cloned the same to your Digital.ai Release server.
  • installed and configured Digital.ai Release 22.0.0 (or later).
  • created and configured an Amazon EKS cluster.
  • installed and configured the AWS CLI and kubectl.
  • installed Argo CD on the EKS cluster.
  • connected Release and Argo CD servers.
  • created three namespaces—uat, dev, and prod—using AWS CLI/kubectl.

The continuous deployment process starts when you make a code change to your helloworld Springboot web application, create a new pull request, and merge your pull request.

Here's what the continuous delivery workflow does when you merge your changes.

  1. You—Start a release using the Initial Application Setup in Argo.xlr template to set up the application in Argo CD initially
  2. You—Make a code change, commit the changes, and merge your Springboot application's code changes to GitHub
  3. Continuous delivery pipeline—Triggers a new release in Digital.ai Release using the Continuous Delivery.xlr template—builds your application using GitHub Actions—creates a new Docker image—adds the new image to the Docker Hub repository—and deploys the helloworld application to the dev environment of the Kubernetes cluster using Argo CD
  4. You—Verify the deployments to the dev environment and pick one of the stable versions for promoting to uat or prod environments
  5. You—Start a new release in Digital.ai Release using the Environment Promotion.xlr template to promote your application to the next environment such as uat or prod
  6. Continuous delivery pipeline—Deploys the new application version to the uat or prod environment in Amazon EKS
  7. You—Verify the deployment and iterate the continuous release process

Here's a detailed step-by-step.

Step 1—Create an Amazon EKS Cluster​

Note: For illustrative purposes, this topic deals with Amazon EKS. You can have your cluster in other cloud platforms such as GKE too.

  1. Log on to your AWS account and gather the AWSAccessKeyId and AWSSecretKey.

    Create an access key if you do not have one already. For more information, see Managing access keys.

    Important: It is recommended to download and save the AWS access key file immediately after creating the access key as you cannot retrieve your Secret Access Key later.

  2. Create an Amazon EKS Cluster. For more information, see Creating an Amazon EKS cluster.

    While there are innumerable configurations possible for your EKS cluster, this topic assumes the EKS cluster is made up of:

    • A cluster with three nodes of instance type t2.medium
    • Three namespaces—uat, dev and prod. You may choose to create three separate EKS clusters instead of sharing the same cluster with three namespaces. To keep the setup simple, this topic deals with a single cluster with three namespaces.

  3. Gather the following information about your Amazon EKS cluster and keep them handy.

    • Your Amazon account's AWSAccessKeyId and AWSSecretKey
    • The AWS region code (for example, eu-west-2) that hosts the EKS cluster
    • The EKS cluster's name
    • The API server endpoint URL
    • The Certificate Authority (CA) cert

Step 2—Install and Configure AWS CLI and kubectl​

See Install Kubernetes Tools.

Step 3-Install Argo CD​

See Install Argo CD.

Step 4—Create Amazon EKS Namespaces​

With AWS CLI and kubectl utilities installed and configured, let us now create three namespaces, uat, dev, and prod, on the EKS cluster.

Run the following commands to create three namespaces—uat, dev, and prod

kubectl create namespace uat
kubectl create namespace dev
kubectl create namespace prod

Step 5—Install the NGINX Ingress Controller​

The next step is to install an NGINX ingress controller to provide external access to the Kubernetes services in your Amazon EKS cluster.

For more information about installing the Bitnami/NGINX ingress controller, see INSTALL BITNAMI/NGINX. While this how-to uses the Bitnami/NGINX, you can install any other flavor of NGINX too.

Configure Domain Names for Your Amazon EKS Cluster Using Amazon Route 53​

This is required to map the IP addresses of your uat, dev and prod NGINX ingress controllers to fully qualified domain names (FQDNs). You must also map the IP address of the Argo CD's ingress controller to an FQDN.

You must choose four FQDNs, one each for the uat, dev, prod, and Argo CD ingress controllers and configure the domain name mapping for the ingress controllers using Amazon Route 53.

Let's use the following FQDNs for this tutorial.

  • Argo CD ingress controller's FQDN: argocddigitalai.xldevinfra.com
  • uat ingress controller's FQDN: uatdigitalai.xldevinfra.com
  • dev ingress controller's FQDN: devdigitalai.xldevinfra.com
  • prod ingress controller's FQDN: proddigitalai.xldevinfra.com

For more information about how to configure the FQDNs in Route 53, see Configuring Amazon Route 53 as your DNS service.

Step 6—Set Up Your Digital.ai Release Server and GitHub Actions​

  1. Log on to your Linux server as a root user.

  2. Install Digital.ai Release.

    Tip: If you want to install Release using Docker images:

  3. Start your Digital.ai Release server and log on.

  4. Install the following Release plugins.

  5. Fork the xebialabs-community/howto GitHub repository and clone it. Suppose you clone the repository to the your home directory (for example, /home/john).

  6. Go to the forked repository in GitHub and enable GitHub Actions for the forked repository.

  7. Edit the start-release.yml file and add values for the following variables and commit the changes.

    Here's an example:

    apiVersion: xl-release/v1
    kind: Release
    spec:
      name: Trigger Continuous Delivery
      template: <Release-folder-name>/Continuous Delivery # argocd/Continuous Delivery for example
      variables:
        ARGO_APP_NAME: "helloworld-dev" # The application name
        GIT_REPO_URL: "https://github.com/isaacsathish/howto.git" # The repo URL
        GIT_REPO_NAME: "howto" # The repo name
        LOCAL_GIT_CLONE_PATH: "/home/ubuntu/git-temp-dir" # The path to the folder on the Digital.ai Release server where the revision branch of the repo is cloned
        MANIFEST_PATH_IN_GIT: "argocd/helloworld-cd/dev" # The path of the folder that contains the deployment manifest file
        MANIFEST_FILE: "helloworld.yaml" # The deployment manifest file name
        NEW_TAG: PLACEHOLDER

  8. Connect Release to the GitHub and Argo CD servers.

    Tip: Use the Argo CD ingress controller's FQDN to connect Argo CD to Release.

Step 7—Add Secrets to GitHub​

  1. Go to Settings > Secrets of your forked GitHub repository and add the following secrets.

    • DOCKER_USER—your Docker Hub user name

    • DOCKER_PASSWORD—your Docker Hub password

    • DOCKER_REPO—your Docker Hub repository name

    • DOCKER_REGISTRY_HOST—Docker Hub host name—hub.docker.com, for example

    • XLR_USER—your Digital.ai Release user name

    • XLR_PASS—your Digital.ai Release password

    • XLR_URL—your Digital.ai Release URL (should be a publicly accessible FQDN)

    Important: The Release server must have public IP addresses assigned to it. If you are trying this out for testing purposes and if you run the Release server in your localhost (in the absence of public IPs), use utilities such as ngrok to create a tunnel to expose your localhost (port: 5516 for Release) to the internet.

Step 8—Import the Digital.ai Release Templates​

  1. See Import a Release Template and import the three Release templates from the xebialabs-community/howto GitHub repository.

  2. Once imported, you must open the tasks in these templates and add/select values for fields such as the GitHub server name, Argo CD server name and project name, and so on.

    task set up

Step 9—Initial Application Configuration in Argo CD​

Use the Initial Application Setup in Argo.xlr release to configure the application's source code repo in Argo CD and deploy the application initially.

initial Setup

This Release contains tasks to:

  1. Add a repository connection to Argo CD.
  2. Create a project in Argo CD.
  3. Create an Argo CD Application.
  4. Sync the created application (in Kubernetes to the definition in GitHub).
  5. Get the Sync Status.

When you run this release, it is going to ask you for inputs such as the Git Repository URL that has the Kubernetes deployment manifest files, the path of the manifest file in the repository, the application name and project name.

Enter Values

Enter these values and start the Release. The application will be set up in Argo CD.

Run this release for all the three environments, dev, uat, and prod by changing the values appropriately for the MANIFEST_PATH_IN_GIT, ARGO_APP_NAME, and KUBE_NAMESPACE fields.

Here's an example set of values for the three environment variables:

dev

  • GIT_REPO_URL : forked repo url (for example, https://github.com/isaacsatish/howto.git)
  • MANIFEST_PATH_IN_GIT : argocd/helloworld-cd/dev
  • ARGO_PROJECT_NAME : helloworld
  • ARGO_APP_NAME : helloworld-dev
  • KUBE_SERVER_URL : https://kubernetes.default.svc
  • KUBE_NAMESPACE : dev

uat

  • GIT_REPO_URL : forked repo url (for example, https://github.com/isaacsatish/howto.git)
  • MANIFEST_PATH_IN_GIT : argocd/helloworld-cd/uat
  • ARGO_PROJECT_NAME : helloworld
  • ARGO_APP_NAME : helloworld-uat
  • KUBE_SERVER_URL : https://kubernetes.default.svc
  • KUBE_NAMESPACE : uat

prod

  • GIT_REPO_URL : forked repo url (for example, https://github.com/isaacsatish/howto.git)
  • MANIFEST_PATH_IN_GIT : argocd/helloworld-cd/prod
  • ARGO_PROJECT_NAME : helloworld
  • ARGO_APP_NAME : helloworld-prod
  • KUBE_SERVER_URL : https://kubernetes.default.svc
  • KUBE_NAMESPACE : prod

Step 10—Continuous Delivery​

Use the Continuous Delivery.xlr release to continuously deploy the helloworld application to the dev environment of the Kubernetes cluster.

CD

This release contains tasks to:

  1. Create a revision branch in the repository with manifest files.
  2. Clone the revision branch locally.
  3. Update the new image in the kubernetes manifest file.
  4. Commit and push the change.
  5. Create a pull request.
  6. Approve the pull request.
  7. Merge the pull request.
  8. Sync the application.
  9. Get the Sync Status.

Now, whenever a code change is merged into the master branch of the helloworld application's source code repository, the source code is built and tested and wrappred into a docker image and pushed to the docker hub repository. Then a new revision branch is created and cloned, the application is built and wrapped as a docker image, and the image is deployed to the target kubernetes environment, which in this case is the dev environment, all through the Release template run.

Step 11—Environment Promotion​

Use the Environment Promotion.xlr release to manually deploy an image of the helloworld application to the uat or prod environment of the Kubernetes cluster.

promotion

  • This release is similar to the Continuous Delivery release discussed in Step 10.

  • The difference is that this release is triggered manually whenever you have an image that's ready to be deployed to the uat or prod environments.

  • The path of the manifest file to be updated determines the environment to which the image is promoted.

  • Run this release, enter the values, and start the Release.

    env promotion

  • Note that the:

    • CONTAINER_NAME variable takes the following values from the deployment manifest files:
      • uat—helloworld-uat-container
      • prod—helloworld-prod-container
    • NEW_TAG variable takes the commit tag (SHA) of the image

The image will be deployed to the desired environment, which can be uat or prod in this case.