134 lines
6.7 KiB
Plaintext
134 lines
6.7 KiB
Plaintext
---
|
|
title: Deploying an application via helm chart
|
|
exercise: 4
|
|
date: '2023-12-06'
|
|
tags: ['openshift','containers','kubernetes','deployments','autoscaling']
|
|
draft: false
|
|
authors: ['default']
|
|
summary: "Exploring alternative deployment approaches."
|
|
---
|
|
|
|
In **Exercise 2** we deployed our ParksMap application in the most simplistic way. Just throwing an individual container image at the cluster via the web console and letting OpenShift automate everything else for us.
|
|
|
|
With more complex applications comes the need to more finely customise the details of our application **Deployments** along with any other associated resources the application requires.
|
|
|
|
Enter the [**Helm**](https://www.redhat.com/en/topics/devops/what-is-helm) project, which can package up our application resources and distribute them as something called a **Helm chart**.
|
|
|
|
In simple terms, a **Helm chart** is basically a directory containing a collection of YAML template files, which is zipped into an archive. However the `helm` command line utility has a lot of additional features and is good for customising and overriding specific values in our application templates when we deploy them onto our cluster as well as easily deploying, upgrading or rolling back our application.
|
|
|
|
|
|
## 4.1 - Deploying a helm chart via the web console
|
|
|
|
It is common for organisations that produce and ship applications to provide their applications to organisations as a **Helm chart**.
|
|
|
|
Let's get started by deploying a **Helm chart** for the [Gitea](https://about.gitea.com) application which is a git oriented devops platform similar to GitHub or GitLab.
|
|
|
|
Start in the **+Add** view of the **Developer** perspective.
|
|
|
|
Scroll down and click the **Helm chart** tile. OpenShift includes a visual catalog for any helm chart repositories your cluster has available, for this exercise we will search for **Gitea**.
|
|
|
|
Click on the search result and click **Create**.
|
|
|
|
In the YAML configuration window enter the following, substituting `userX` with your assigned user and then click **Create** once more.
|
|
|
|
```yaml
|
|
db:
|
|
password: userX
|
|
hostname: userX-gitea.apps.<clusterdomain>
|
|
tlsRoute: true
|
|
```
|
|
|
|
<Zoom>
|
|
| |
|
|
|:-------------------------------------------------------------------:|
|
|
| *Gitea application deployment via helm chart* |
|
|
</Zoom>
|
|
|
|
|
|
## 4.2 - Examine deployed application
|
|
|
|
Returning to the **Topology** view of the **Developer** perspective you will now see the Gitea application being deployed in your `userX` project (this can take a few minutes to complete). Notice how the application is made up of two separate pods, the `gitea-db` database and the `gitea` frontend web server.
|
|
|
|
Once your gitea pods are both running open the **Route** for the `gitea` web frontend and confirm you can see the application web interface.
|
|
|
|
Next, if we click on the overall gitea **Helm release** by clicking on the shaded box surrounding our two Gitea pods we can see the full list of resources deployed by this helm chart, which in addition to the two running pods includes the following:
|
|
|
|
- 1 **ConfigMap**
|
|
- 1 **ImageStream**
|
|
- 2 **PersistentVolumeClaims**
|
|
- 1 **Route**
|
|
- 1 **Secret**
|
|
- 2 **Services**
|
|
|
|
> Note: Feel free to try out a `oc explain <resource>` command in your web terminal to learn more about each of the resource types mentioned above, for example `oc explain service`.
|
|
|
|
<Zoom>
|
|
| |
|
|
|:-------------------------------------------------------------------:|
|
|
| *Gitea helm release resources created* |
|
|
</Zoom>
|
|
|
|
|
|
## 4.3 - Upgrade helm chart
|
|
|
|
If we want to make a change to the configuration of our Gitea application we can perform a `helm upgrade`. OpenShift has built in support to perform helm upgrades through the web console.
|
|
|
|
Start in the **Helm** view of the **Developer** perspective.
|
|
|
|
In the **Helm Releases** tab you should see one release called `gitea`.
|
|
|
|
Click the three dot menu to the right hand side of the that helm release and click **Upgrade**.
|
|
|
|
Now let's intentionally modify the `hostname:` field in the yaml configuration to `hostname: bogushostname.example.com` and click **Upgrade**.
|
|
|
|
We will be returned to the **Helm releases** view. Notice how the release status is now Failed (due to our bogus configuration), however the previous release of the application is still running. OpenShift has validated the helm release, determined the updates will not work, and prevented the release from proceeding.
|
|
|
|
From here it is trivial to perform a **Rollback** to remove our misconfigured update. We'll do that in the next step.
|
|
|
|
<Zoom>
|
|
| |
|
|
|:-------------------------------------------------------------------:|
|
|
| *Attempting a gitea helm upgrade* |
|
|
</Zoom>
|
|
|
|
|
|
## 4.4 - Rollback to a previous helm release
|
|
|
|
Our previous helm upgrade for the Gitea application didn't succeed due to the misconfiguration we supplied. **Helm** has features for rolling back to a previous release through the `helm rollback` command line interface. OpenShift has made this even easier by adding native support for interactive rollbacks in the OpenShift web console so let's give that a go now.
|
|
|
|
Start in the **Helm** view of the **Developer** perspective.
|
|
|
|
In the **Helm Releases** tab you should see one release called `gitea`.
|
|
|
|
Click the three dot menu to the right hand side of the that helm release and click **Rollback**.
|
|
|
|
Select the radio button for revision `1` which should be showing a status of `Deployed`, then click **Rollback**.
|
|
|
|
<Zoom>
|
|
| |
|
|
|:-------------------------------------------------------------------:|
|
|
| *Rolling back to a previous gitea helm release* |
|
|
</Zoom>
|
|
|
|
|
|
## 4.5 - Deleting an application deployed via helm
|
|
|
|
Along with upgrades and rollbacks **Helm** also makes deleting deployed applications (along with all of their associated resources) straightforward.
|
|
|
|
Before we move on to exercise 5 let's delete the gitea application.
|
|
|
|
Start in the **Helm** view of the **Developer** perspective.
|
|
|
|
In the **Helm Releases** tab you should see one release called `gitea`.
|
|
|
|
Click the three dot menu to the right hand side of the that helm release and click **Delete Helm Release**.
|
|
|
|
Enter the `gitea` confirmation at the prompt and click **Delete**. If you now return to the **Topology** view you will see the gitea application deleting.
|
|
|
|
<Zoom>
|
|
| |
|
|
|:-------------------------------------------------------------------:|
|
|
| *Deleting the gitea application helm release* |
|
|
</Zoom>
|
|
|