Continuous Delivery

Use Argo CD to continuously deliver application changes

In IBM Garage Method, one of the Develop practices is continuous delivery. The Developer Environment uses an Argo CD pipeline to automate continuous delivery.

What is continuous delivery

Continuous delivery is the DevOps approach of frequently making new versions of an application’s components available for deployment to a runtime environment. The process involves automation of the build and validation process and concludes with a new version of the application that is available for promotion to another environment.

Continuous delivery is closely related to continuous deployment. The distinction is:

Continuous delivery deploys an application when a user manually triggers deployment
Continuous deployment deploys an application automatically when it is ready

An application is ready for deployment when it passes a set of tests that prove it doesn’t contain any significant problems. These tests must be automated so that deployment can be automated. Until you have this set of automated tests and trust them sufficiently, stick with continuous delivery.

What is GitOps

GitOps is the operational pattern of using Git repositories as the source of truth for defining the configuration that makes up the desired state of the application. It uses Git repositories to declaratively represent the desired state of applications in deployment environments.

GitOps takes advantage of several Git features:

Git has an audit log of changes
Whole releases can be managed from a pull request
Git enables changes to be rolled back quickly if there is an issue with a new release

CI/CD integration

For the full end-to-end build and delivery process, both the CI and CD pipelines are required. For this to work, a Git repo is used to convey the configuration values. Within the Developer Environment, we have used certain naming conventions to streamline and simplify the untegration between the various components.

The naming components are:

app repo - The name of the Git repository for the application
git org - The name of the GitHub organization for the application’s repo
tag - The build version
chart version - The version of the Helm chart
region - The geographic location in IBM Cloud

The derived names are:

GitHub application path: github.com/{git org}/{app repo}
CI Pipeline name: {git org}.{app repo}
Docker image’s path: {region}.icr.io/{git org}/{app repo}:{tag} in the Image Registry
Helm chart’s path: generic-local/{git org}/{app repo}-{tag}-{chart version}.tgz in the Helm Repository
Dependencies filename: {app repo}/requirements.yaml in the GitOps repo
CD Pipeline name: {app repo}

What is Argo CD

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. The deployment environment is a Kubernetes cluster or namespace, which also works for an OpenShift cluster or project. Argo CD models a collection of applications as a project and uses a Git repository to store the project’s desired state. Each application is stored as a folder in the repository, and each deployment environment is stored as a branch in the repository.

Argo CD supports defining Kubernetes manifests in a number of ways:

helm charts
kustomize
ksonnet
jsonnet
plain directory of yaml/json manifests

Argo CD synchronizes the application state with the desired state defined in Git and automates the deployment of Kubernetes resources to ensure they match.

Configuring GitOps with Argo CD

You must have completed the Argo CD Setup before continuing.

Terminology:

Argo CD uses a number of terms to refer to the components

Application - A deployable unit
In the context of the Developer Environment, an application is one Helm chart that contains one container image that was produced by one CI pipeline. While Helm charts and images could certainly be combined to make more sophisticated applications in more advanced scenarios, we will be using this simple definition here.
Project - A collection of applications that make up a solution

Set up the GitOps repo

Argo CD uses a Git repo to express the desired state of the Kubernetes environment. The basic setup uses one repository to represent one project. Within that repository, each application that makes up the project will be described in its own folder. The repository will also contain a branch for each destination (i.e. cluster and namespace) into which we want to deploy the applications.

Create a new repo from the Argo CD Code Pattern
Clone the project to your machine
Create a branch for the environment (e.g. test to configure the values for deployment to the testing environment)
```
git checkout -b test
```
The repository contains a template Helm chart in the app-artifactory folder. Copy that folder and rename it to match one of the application names in your project, i.e. {app repo}.
The application name should match the repository name if the CI pipeline is going push changes to the CD pipeline.
Update Chart.yaml
- name - The name of the application, should match the folder from the previous step
Update requirements.yaml
- name - The name of Helm chart and Docker image, should match your Git repo name, i.e. {app repo}
- version - The version number of the Helm chart, i.e. {chart version}
- repository - The url to the Helm repository including the folder where the Helm charts are being stored, i.e. http://artifactory.{ingress subdomain}/artifactory/generic-local/
  The url of the Helm repository in Artifactory can be determined by following the steps described in Administrator Guide - Argo CD setup.
Update values.yaml
- Replace <app-chart-name> with the name of application
- Provide configuration values specific to the Helm chart under the <app-chart-name> prefix
  Note: The Helm values will need to be prefixed with the Helm chart name that was provided in the previous step. For example, assuming the helm chart is message-logger, the values.yaml file would look like the following:
```
message-logger:
  replicaCount: 3
```
  Note: The specific values that should be configured are dependent on the Helm chart that is referenced in the requirements.yaml. For the Code Patterns, you can see those details and customize the chart by looking in the chart/{chart name} of the repository.
Repeat steps 4-7 for each application in the project

Register the git repo in Argo CD

Now that the repository has been created, we need to tell Argo CD where it is.

Get the Argo CD login information from the igc credentials CLI command
Note: You need to be logged into the cluster on the command-line for the CLI to access the cluster information.
Log in to Argo CD
Click on the gear icon on the left menu to access the Settings options
Select the Repositories option
Press either the Connect Repo using HTTPS or Connect Repo using SSH button at the top and provide the information for the Git repo

Create a project in Argo CD (Optional)

In Argo CD terms, each deployable component is an application and applications are grouped into projects. Projects are not required for Argo CD to be able to deploy applications, but it helps to organize applications and provide some restrictions on what can be done for applications that make up a project.

To create a project:

Log into Argo CD
Click on the gear icon on the left menu to access the Settings options
Select the Projects option
Press the New Project button at the top of the page
Specify the properties for the new project
- name - Provide the name for the project
- description - A brief description of the project
- source - Press Add source and pick the Git repository from the list that was added previously
- destinations
  - Add https://kubernetes.default.svc for the cluster url and test for the namespace
  - Add https://kubernetes.default.svc for the cluster url and staging for the namespace
- Press Create
Note: Initially, the only cluster that is available is the one in which Argo CD is - https://kubernetes.default.svc. By adding the two destinations we have allowed the project to be deployed to both the test and staging namespaces within the current cluster.

Add an application in Argo CD for each application component (Helm chart)

The last step in the process is to define the application(s) within Argo CD that should be managed. This consists of connecting the config within the Git repo to the cluster and namespace.

Log into Argo CD
Press New Application and provide the following values:
- application name - The name of the application. It is recommend to use the format of {namespace}-{image name}
- project - The project with which the application should be included
- sync-policy - The manner with which Argo CD will use to manage the deployed artifacts. Automatic is recommended
- repository url - The Git url where the configuration is stored
- revision - The branch where the configuration for this instance is stored
- path - The path within the repository where the application config is located (should be the application name)
- destination cluster - The cluster url for the deployment
- destination namespace - The namespace where the application should be deployed
Repeat that step for each application and each environment

Hook the CI pipeline to the CD pipeline

The last stage in the CI pipeline updates the version number in the requirements.yaml to the version of the helm chart that was just built. Through a couple naming conventions the only thing the pipeline needs in order to interact with the CD process is a Kubernetes secret named gitops-cd-secret that provides the details needed to connect to the git repo to push updates.

Fortunately, a CLI command provides a simple way to create a Kubernetes secret that contains git credentials.

Create the gitops-cd-secret:

Log into the cluster on the command-line.
Change the directory to the root of the Argo CD Code Pattern repo that was cloned previously.
Run igc git-secret gitops-repo -n dev-{initials} to create the secret. This command will prompt for the username, personal access token, and the branch to put in the secret.

What just happened?

The git-secret command creates a secret in a Kubernetes namespace containing the url, username, password, and branch information for a git repo. In the command above, we provided gitops-cd-secret for the secret name. (If that value is left off the secret name defaults to {git org}.{git repo}.) You can verify the secret was created by running:

kubectl get secrets/gitops-cd-secret -n dev-{initials} -o yaml

Note:

For the secret to be available to the CI pipeline, the secret needs to be created in the same namespace where the pipeline is running (e.g. dev-{initials}).
The value provided for branch is the one the pipeline will use to when committing changes to trigger the CD pipeline. test is the recommended value for the branch field.

Edit this page on GitHub