Start working on exercise 6.

data/workshop/exercise5.mdx

@@ -19,7 +19,7 @@ With Operators you can stop treating an application as a collection␃of primiti
 
 
 
-## 4.1 - Deploying an operator
+## 5.1 - Deploying an operator
 
 Deploying an application via an **Operator** is generally a two step process. The first step is to deploy the **Operator** itself.
 
@@ -58,9 +58,9 @@ Click **Create**. In a minute or so you should see the Grafana operator installe
 </Zoom>
 
 
-## 4.2 - Deploying an operator driven application
+## 5.2 - Deploying an operator driven application
 
-With our Grafana operator now running it will be listening for the creation of a `grafana` custom resource. When one is detected the operator will deplioy the Grafana application according to the specifcation we supplied.
+With our Grafana operator now running it will be listening for the creation of a `grafana` custom resource. When one is detected the operator will deploy the Grafana application according to the specifcation we supplied.
 
 Let's switch over to the **Administrator** perspective for this next task to deploy our Grafana instance.
 
@@ -106,7 +106,7 @@ spec:
 </Zoom>
 
 
-## 4.3 Logging into the application
+## 5.3 Logging into the application
 
 While we are in the **Administrator** perspective of the web console let's take a look at a couple of sections to confirm our newly deployed Grafana application is running as expected.
 
@@ -130,7 +130,7 @@ Click the **Route** named `grafana-route` and open the url on the right hand sid
 Once the new tab opens we should be able to login to Grafana using the credentials we supplied in the previous step in the YAML configuration.
 
 <Zoom>
-|![grafana-route](/ocp-app-delivery-workshop/static/images/grafana-route.png) | 
+|![grafana-route](/ocp-app-delivery-workshop/static/images/grafana-route.gif) | 
 |:-------------------------------------------------------------------:|
 | *Confirming the grafana route is working*                           |
 </Zoom>

data/workshop/exercise6.mdx

@@ -0,0 +1,53 @@
+---
+title: Deploying an application from source
+exercise: 6
+date: '2023-12-07'
+tags: ['openshift','containers','kubernetes','s2i','shipwright']
+draft: false
+authors: ['default']
+summary: "Exploring alternative deployment approaches."
+---
+
+Often as a team supporting applications on OpenShift the decision of which deployment method to use will be out of your hands instead be determined by the vendor, organisation or team producing the application in question.
+
+However, for an interesting scenario let's explore the possibility of what we could do if there is no existing deployment tooling in place and all we are given is a codebase in a git repository.
+
+This is where the concept of **Source to Image** or "s2i" comes in. OpenShift has built in support for building container images using source code from an existing repository. This is accomplished using the [source-to-image](https://github.com/openshift/source-to-image) project.
+
+OpenShift runs the S2I process inside a special **Pod**, called a **Build Pod**, and thus builds are subject to quotas, limits, resource scheduling, and other aspects of OpenShift. A full discussion of S2I is beyond the scope of this class, but you can find more information about it in the [OpenShift S2I documentation](https://docs.openshift.com/container-platform/4.14/openshift_images/create-images.html). 
+
+
+## 6.1 - Starting a source to image build
+
+Deploying an application via an **Source to Image** is straightforward. Let's try it out.
+
+Start in the **+Add** view of the **Developer** perspective.
+
+Click **Import from Git** under the **Git Repository** tile.
+
+**Source to Image** supports a number of popular programming languages as the source. For this example we will use **Python**.
+
+Enter `https://github.com/openshift-roadshow/nationalparks-py.git` for the **Git Repo URL**.
+
+OpenShift will automatically guess the git server type and the programming language used by the source code. You will be now asked to select an **Import Strategy**.  You have three options:
+
+- Devfile: this will use Devfile v2 spec to create an application stack. The repo has to contain a file named `devfile.yaml` in the Devfile v2 format.
+
+- Dockerfile: this will create a Container image from an existing Dockerfile.
+
+- Builder Image: this will use a mechanism called Source-to-Image to create automatically a container image directly from the source code.
+
+Select **Builder Image** strategy as we are going to create the container image directly from the source code.
+
+Select **Python** as the **Builder Image** type and **Python 3.8-ubi8** as the **Builder Image Version**.
+
+Scroll down and under the **General** header click the **Application** drop down and select **Create application** entering **workshop** as the name.
+
+Scroll down reviewing the other options then click **Create**.
+
+<Zoom>
+|![s2i-build](/ocp-app-delivery-workshop/static/images/s2i-build.gif) | 
+|:-------------------------------------------------------------------:|
+| *Creating a source to image build in OpenShift*                     |
+</Zoom>
+