Part 7: GitOps Pipelines

This is Part 7 of a multi-part, self-paced exercise.

What Will You Do¶

In this part, you will create a GitOps Pipeline to manage the lifecycle of an application. For simplicity, this part assumes the user has an account on Github and will fork the repository as a Public repository.

Estimated Time

Estimated time burden for this part is 15 minutes.

Step 1: Fork Repository¶

To setup a GitOps pipeline, you will need a Git repository. To help you get started, let us fork an existing repository.

Ensure you are logged into your GitHub.com account
Navigate to the public Git repository
Click on Fork repository
Select your account name to fork repo to

This will create a copy of the repository in your Git system (e.g. GitHub). An example is shown below.

Forked Git Repository

Step 2: Add Repository¶

In the desktop project, navigate to Integrations -> Repositories
Click on New Repositories
Provide a friendly name
Select Git for Type

New Repository

Provide the Git repo's Endpoint URL
Save

Git Endpoint

Note

It does not matter if your Github repo is public or private. If private, you need to provide access credentials.

Optionally,

Under Infrastructure -> Repositories, Click on validate for your repository
If you see a validation successful message, the controller is able to access the repository

Validate Repository

Step 3: Create Namespace¶

We need to create a namespace to deploy our workload via the GitOps pipeline

Navigate to Infrastructure -> Namespaces
Click on New Namespace
Provide a name, select wizard for type and Save
Under placement, select your cluster and publish the namespace

In the example below, we have created a namespace called "first" on our cluster.

Create Namespace

Step 4: Create Workload¶

Now, we are ready to create a workload based on k8s manifests in our Git repository and publish it to the namespace we just created.

Navigate to Applications -> Workloads
Click on New Workload and provide a friendly name
Select "Helm 3" for package type
Select "Pull files from repository" for Artifact Sync
Select "Git" for Repository Type
Select the namespace you created in the previous step and Select "Continue"

Create Workload

Step 5: Publish Workload¶

We are now ready to configure our workload by (a) specifying the Git repo and (b) selecting the cluster for placement.

Select the name of the repository created in the previous steps
Select "master for revision
Enter path for Helm file i.e. "Helm/webserver"
Enter path for the values file i.e. "Helm/webserver/values.yaml" and Select "Continue"

Configure Workload

Select your cluster for Placement Policy and Publish workload.

In a few seconds, the workload's k8s resource will become operational on your cluster.

Published Workload

Optionally, you can also verify the status of the resources using the zero trust kubectl channel. You should see something like the following

kubectl get po -n first

NAME                                   READY   STATUS    RESTARTS   AGE
test-helm-webserver-7874b96c7c-tzpqt   2/2     Running   0          10s

Step 6: GitOps Pipeline¶

In the previous step, we manually created a workload and deployed it to your cluster. Everytime you make a change to the manifests in your Git repo, you have to remember to republish the workload. With a GitOps pipeline, you can completely automate this ensuring that the workload on the clusters are "always kept reconciled" with changes made in the Git repository.

Navigate to GitOps -> Pipelines
Click on New pipeline and provide it a friendly name

Add Stage¶

A pipeline can have multiple stages, with completely different actions to model your desired workflows. In this exercise, we will test with a single stage pipeline.

Under Stages, add a new Stage
Provide a name for the stage
For Action, select "Deploy Workload"
For workload, select the workload you created in the previous step

New Stage

Add Trigger¶

A pipeline can be executed based on an "external trigger". In this exercise, we will configure a cron job based trigger that will periodically check your Git repository for modifications to the specified files.

Under Triggers, add a new Trigger and provide a friendly name
Select "Cron Job" for type
Select the name of the repository to monitor
Enter "master" for revision
Enter Path for the file in the Git repo to monitor for changes. In our case, "Helm/webserver/values.yaml"
Enter a cron expression specifying the frequency. In our case, "*****" to check the repository every minute.

New Trigger

Activate Pipeline¶

By default, newly created pipelines start life in a deactivated state.

Click on Activate to activate pipeline

Step 7: Update Git Repo¶

Now, you are ready to make changes in your Git repo and have the changes be picked up by the pipeline and reconciled to the clusters.

Navigate to the file "Git repo -> demo-apps -> Helm -> webserver -> values.yaml"
Update the "replicaCount" to a different number. For example, from 1 to 2
Commit the changes to the repository

Commit Git Changes

In a few seconds, the cron job based trigger will detect the changes and execute a pipeline job. In the example below, the pipeline took 22 seconds to reconcile the changes in the Git repository with the downstream clusters.

Pipeline Job

Step 8: Verify Updates on Cluster¶

Navigate to Infrastructure -> Cluster
Click on Kubectl and check the number of replicas.

In the example below, notice that the age of one of the pods is just 15 seconds. This was the additional replica added as part of the changes in the Git repo.

kubectl get po -n first

NAME                                   READY   STATUS    RESTARTS   AGE
test-helm-webserver-7874b96c7c-gslv4   2/2     Running   0          15s
test-helm-webserver-7874b96c7c-tzpqt   2/2     Running   0          142m

Recap¶

Congratulations! At this point, you have successfully created a workload and wrapped it with a GitOps pipeline for completely automated, hands off deployments.