99 lines
4.8 KiB
Plaintext
99 lines
4.8 KiB
Plaintext
---
|
||
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>
|
||
| |
|
||
|:-------------------------------------------------------------------:|
|
||
| *Creating a source to image build in OpenShift* |
|
||
</Zoom>
|
||
|
||
|
||
## 6.2 - Monitoring the build
|
||
|
||
To see the build logs, in **Topology** view of the **Developer** perspective, click the nationalparks python icon, then click on **View Logs** in the **Builds** section of the **Resources** tab.
|
||
|
||
Based on the application’s language, the build process will be different. However, the initial build will take a few minutes as the dependencies are downloaded. You can see all of this happening in real time!
|
||
|
||
From the `oc` command line utility, you can also see **Builds**, let's open our **Web Terminal** back up and take a look:
|
||
|
||
```bash
|
||
oc get builds
|
||
```
|
||
|
||
You will see output similar to the example below:
|
||
|
||
```bash
|
||
NAME TYPE FROM STATUS STARTED DURATION
|
||
nationalparks-py-git-1 Source Git@f87895b Complete 7 minutes ago 48s
|
||
```
|
||
|
||
Let's also take a look at the logs from the `oc` command line with:
|
||
|
||
```bash
|
||
oc logs -f builds/nationalparks-py-git-1
|
||
```
|
||
|
||
After the build has completed and successfully:
|
||
|
||
- The S2I process will push the resulting image to the internal OpenShift image registry.
|
||
|
||
- The Deployment (D) will detect that the image has changed, and this will cause a new deployment to happen.
|
||
|
||
- A ReplicaSet (RS) will be spawned for this new deployment.
|
||
|
||
- The ReplicaSet will detect no Pods are running and will cause one to be deployed, as our default replica count is just 1.
|
||
|
||
To conclude, when issuing the `oc get pods` command, you will see that the build **Pod** has finished (exited) and that an application **Pod** is in a ready and running state.
|
||
|
||
|
||
## 6.3 - Bonus objective: Podman
|
||
|
||
If you have time, take a while to understand how [Podman](https://developers.redhat.com/articles/2022/05/02/podman-basics-resources-beginners-and-experts) can be used to build container images on your device outside of an OpenShift cluster.
|
||
|
||
|
||
Well done, you've finished exercise 6! 🎉
|