Setup

This is Part 1 of a multi-part, self-paced quick start exercise.

What Will You Do

In part 1, you will perform a one-time configuration of a k8s YAML workload, test deployment to a cluster and automate deployments using a GitOps pipeline.

• Fork a Git repository
• Create a workload and deploy a k8s yaml workload to your cluster
• Create a GitOps pipeline to automate this workload's deployments

Once this part is complete, in subsequent parts, you will update the k8s YAML file to test and experience various "deployment patterns".

Estimated Time
Estimated time burden for this part is 15 minutes.

Step 1: Fork 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 shown below.

Step 2: Add Repository

• In the desktop project, navigate to Integrations -> Repositories

• Click on New Repositories

• Provide a friendly name

• Select Git for Type

• Provide the Git repo's Endpoint URL

• Save

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

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 "echo" on our cluster.

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 "k8s YAML" 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"

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 k8s file i.e. ""

• Select your cluster for Placement Policy and Publish workload. In a few seconds, the workload's k8s resources will become operational on your cluster.

You can also verify the status of the k8s resources using the zero trust kubectl channel.

• Click on Debug
• Click on Kubectl
• Type the following Kubectl command

kubectl get po -n echo

You should see something like the following

NAME                         READY   STATUS    RESTARTS   AGE
echo-blue-558b67ffd6-4xmjt   1/1     Running   0          3h17m

Step 6: GitOps Pipeline

In the previous step, we manually created and deployed a workload to your cluster. Everytime you make a change to the manifest in your Git repo, you have to remember to republish the workload i.e. the changes will "not be picked up and reconciled automatically".

With a GitOps pipeline, you can completely automate this. The GitOps pipeline will ensure that the workload on the clusters are "always kept reconciled" with desired specifications in the Git repository.

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

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 simple, single stage pipeline.

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

Add Trigger

A pipeline can be executed based on an "external trigger". For example, changes to the manifests in your Git repository. In this exercise, we will configure a trigger that will receive a webhook notification when specific files in your Git repository are modified.

• Under Triggers, add a new Trigger and provide a friendly name
• Select "Webhook" for type
• Select the name of the repository to monitor e.g. "gitops"
• Enter "master" for revision
• Enter the path for the file in the Git repo to monitor for changes. In our case, "K8sYaml/echo.yaml" and Save

You will now be presented with the webhook configuration details that you need to copy/paste to your GitHub repository. Once you complete this step, the GitOps pipeline will be configured to receive webhook notifications whenever the file "echo.yaml" is updated in the Git repository.

Webhook in GitHub

• Navigate to your GitHub repository -> Settings -> Webhooks
• Click "Add webhook"
• Copy/Paste the "Payload URL" and "Secret" from the previous step
• Add webhook

Activate Pipeline

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

• Click on Activate to activate pipeline

Step 7: Test GitOps Pipeline

We are now ready to verify whether we have configured our setup properly.

• Navigate to your Git repo -> Code -> K8sYaml -> echo.yaml

• Edit File

• Update the replicas from "1" to "2"

• Provide a Git commit message e.g. "Replicas from 1 to 2"

• Click on "Commit Changes"

• Navigate to your GitOps pipeline and click on it

• You should see something like the following

• Click on the Job ID to view additional details

• You should see something like the following

Notice that the Message in the trigger is identical to what you typed in when you performed the "Git Commit" operation. Optionally, use the zero trust kubectl channel to verify if the changes have been reconciled to the cluster.

kubectl get po -n echo

You should see something like the following. Note that the number of replicas has been increased from "1" to "2".

NAME                         READY   STATUS    RESTARTS   AGE
echo-blue-558b67ffd6-4xmjt   1/1     Running   0          15m
echo-blue-558b67ffd6-fv5l9   1/1     Running   0          3m

Step 8: Access Application

Let us now test if we are able to reach our application using the LoadBalancer service.

• Using kubectl, retrieve the LoadBalancer's IP address
• The "External-IP" is where we will access our application
• Copy the "External-IP"

kubectl get svc -n echo

NAME   TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
echo   LoadBalancer   10.0.122.112   40.118.212.71   80:32505/TCP   1h

• Open Terminal/Command Prompt
• Copy the following command, enter the External-IP and execute it. This will execute cURL against the configured IP every second.

while true; do sleep 1; curl http://<External-IP from above>;done

You should see something like the following

Blue
Blue
...etc

Recap

In this part, you successfully configured, setup and tested a GitOps pipeline to ensure that changes made to your k8s manifests are automatically reconciled with the target clusters. You are now ready to move to subsequent parts of the exercise to start testing the various "deployment patterns".