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.

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 "echo" 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 "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"

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

Configure Workload

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

Published Workload

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

New Stage

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

New Trigger

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

Webhook in GitHub

Activate Pipeline¶

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

Click on Activate to activate pipeline

Activated 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"

Git Commit

Navigate to your GitOps pipeline and click on it
You should see something like the following

Successful Pipeline Job

Click on the Job ID to view additional details
You should see something like the following

Job Details

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".