diff --git a/data/workshop/exercise2.mdx b/data/workshop/exercise2.mdx index cda94b1..f4be9f7 100644 --- a/data/workshop/exercise2.mdx +++ b/data/workshop/exercise2.mdx @@ -9,7 +9,7 @@ summary: "Time to deploy your first app!" --- -Now that we have had a tour of the OpenShift web console to get familar, let's use the web console to deploy our first application. +Now that we have had a tour of the OpenShift web console to get familiar, let's use the web console to deploy our first application. Let’s start by doing the simplest thing possible - get a plain old Docker-formatted container image to run on OpenShift. This is incredibly simple to do. With OpenShift it can be done directly from the web console. @@ -36,7 +36,7 @@ In the **Image name** field enter the following: quay.io/openshiftroadshow/parksmap:latest ``` -Leave all other fields at their defaults (but take your time to scroll down and review each one to familarise yourself! πŸŽ“) +Leave all other fields at their defaults (but take your time to scroll down and review each one to familiarise yourself! πŸŽ“) Click **Create** to deploy the application. @@ -61,7 +61,7 @@ The **Resources** tab may be displayed by default. If so, click on the **Details | *Deploying the container image* | -> Note: A pod is the smallest deployable unit in Kubernetes and is effectively a grouping of one or more individual containers. Any containers deployed within a pod are guaranteed to run on the same machine. It is very common for pods in kubernetes to only hold a single container, although sometimes auxiliary services can be included as additional containers in a pod when we want them to run alongside our application. +> Note: A pod is the smallest deployable unit in Kubernetes and is effectively a grouping of one or more individual containers. Any containers deployed within a pod are guaranteed to run on the same machine. It is very common for pods in kubernetes to only hold a single container, although sometimes auxiliary services can be included as additional containers in a pod when we want them to run alongside our application container. ## 2.2 - Accessing the application @@ -93,7 +93,7 @@ Clicking the link you should now see the ParksMap application frontend πŸŽ‰ ## 2.3 - Checking application logs -If we deploy an application and something isn't working the way we expect, reviewing the application logs can often be helpful. OpenShift includes built in support features for reviewing application logs. +If we deploy an application and something isn't working the way we expect, reviewing the application logs can often be helpful. OpenShift includes built in support for reviewing application logs. Let's try it now for our ParksMap frontend. diff --git a/data/workshop/exercise3.mdx b/data/workshop/exercise3.mdx index 16b623a..c1bfb9b 100644 --- a/data/workshop/exercise3.mdx +++ b/data/workshop/exercise3.mdx @@ -89,7 +89,7 @@ Once the new pod is ready, repeat the steps from task `3.2` to crash one of the In the previous example we saw what happened when we intentionally crashed our application. Let's see what happens if we just outright delete one of our ParksMap applications two **Pods**. -For this step we'll use the `oc` command line utility to build some more familarity. +For this step we'll use the `oc` command line utility to build some more familiarity. Let's start by launching back into our web terminal now by clicking the terminal button in the top right hand corner and then clicking **Start** with our `userX` project selected. diff --git a/data/workshop/exercise4.mdx b/data/workshop/exercise4.mdx index 1219518..06f9ac5 100644 --- a/data/workshop/exercise4.mdx +++ b/data/workshop/exercise4.mdx @@ -25,7 +25,7 @@ Let's get started by deploying a **Helm chart** for the [Gitea](https://about.gi Start in the **+Add** view of the **Developer** perspective. -Scroll down and click **Helm chart**. OpenShift includes a visual catalog for any helm chart repositories your cluster has available, for this exercise we will search for **Gitea**. +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**. @@ -47,9 +47,9 @@ tlsRoute: true ## 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. Notice how the application is made up of two separate pods, the `gitea-db` database and the `gitea` frontend web server. +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 access the application. +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: @@ -69,3 +69,29 @@ Next, if we click on the overall gitea **Helm release** by clicking on the shade +## 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. + + +|![helm-upgrade](/ocp-app-delivery-workshop/static/images/helm-upgrade.gif) | +|:-------------------------------------------------------------------:| +| *Attempting a gitea helm upgrade* | + + + + + + diff --git a/public/static/images/helm-upgrade.gif b/public/static/images/helm-upgrade.gif new file mode 100644 index 0000000..578dec2 Binary files /dev/null and b/public/static/images/helm-upgrade.gif differ