Using S2I to build and deploy our application

Time estimation: 30 mins.

There are multiple methods to deploy applications in OpenShift. Let's explore using the integrated Source-to-Image (S2I) builder. As mentioned in the concepts section, S2I is a tool for building reproducible, Docker-formatted container images.

What will you learn?

  • How to use S2I to deploy an application on a Red Hat OpenShift Service on AWS cluster

What do you need before starting?

  • Successfully deployed application on an OpenShift Service on AWS cluster

Before you start

Retrieve the login command

If you are not logged in via the CLI, click on the dropdown arrow next to your name in the top-right of the cluster console and select Copy Login Command.

Follow the instructions on step 1 of the Deployment section.

Fork the repository

In the next section we will trigger automated builds based on changes to the source code. In order to trigger S2I builds when you push code into your GitHub repo, you’ll need to set up the GitHub webhook. And in order to set up the webhook, you’ll first need to fork the application into your personal GitHub repository.

Click here to fork the repo.

Note: Going forward you will need to replace any reference to < username > in any of the URLs for commands with your own GitHub username.

Create a project

Create a new project for this part. Let's call it ostoy-s2i.

You can create a new project from the CLI by running the following command or using the OpenShift web console.

oc new-project ostoy-s2i

Steps to deploy OSToy imperatively using S2I

Add Secret to OpenShift

The example emulates a .env file and shows how easy it is to move these directly into an OpenShift environment. Files can even be renamed in the Secret. In your CLI enter the following command:

oc create -f https://raw.githubusercontent.com/<username>/ostoy/master/deployment/yaml/secret.yaml

Add ConfigMap to OpenShift

The example emulates an HAProxy config file, and is typically used for overriding default configurations in an OpenShift application. Files can even be renamed in the ConfigMap.

Enter the following into your CLI

oc create -f https://raw.githubusercontent.com/<username>/ostoy/master/deployment/yaml/configmap.yaml

Deploy the microservice

We deploy the microservice first to ensure that the SERVICE environment variables will be available from the UI application. --context-dir is used here only to build the application defined in the microservice directory in the Git repo. Using the app label allows us to ensure the UI application and microservice are both grouped in the OpenShift UI.

Enter the following into the CLI:

oc new-app https://github.com/<username>/ostoy \

    --context-dir=microservice \

    --name=ostoy-microservice \

    --labels=app=ostoy \

    --as-deployment-config=true

You will see a response like:

Creating resources with label app=ostoy ...
  imagestream "ostoy-microservice" created
  buildconfig "ostoy-microservice" created
  deploymentconfig "ostoy-microservice" created
  service "ostoy-microservice" created
Success
  Build scheduled, use 'oc logs -f bc/ostoy-microservice' to track its progress.
  Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
   'oc expose svc/ostoy-microservice'
  Run 'oc status' to view your app.

Check the status of the microservice

Before moving onto the next step we should check that the microservice was created and is running correctly. To do this run:

oc status

You will see a response like:

In project ostoy-s2i on server https://api.myroscluster.g14t.p1.openshiftapps.com:6443
svc/ostoy-microservice - 172.30.47.74:8080
  dc/ostoy-microservice deploys istag/ostoy-microservice:latest <-
    bc/ostoy-microservice source builds https://github.com/0kashi/ostoy on openshift/nodejs:14-ubi8 
    deployment #1 deployed 34 seconds ago - 1 pod

Wait until you see that it was successfully deployed. You can also check this through the web UI.

Deploy the front-end UI

The application has been architected to rely on several environment variables to define external settings. We will attach the previously created Secret and ConfigMap afterward, along with creating a PersistentVolume. Enter the following into the CLI:

oc new-app https://github.com/<username>/ostoy \
    --env=MICROSERVICE_NAME=OSTOY_MICROSERVICE \
    --as-deployment-config=true

You will see a response like:

Creating resources ...
  imagestream "ostoy" created
  buildconfig "ostoy" created
  deploymentconfig "ostoy" created
  service "ostoy" created
Success
  Build scheduled, use 'oc logs -f bc/ostoy' to track its progress.
  Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
   'oc expose svc/ostoy'
  Run 'oc status' to view your app.

Update the deployment

We need to update the deployment to use a Recreate deployment strategy (as opposed to the default of RollingUpdate) for consistent deployments with persistent volumes. The reasoning here is that the PV is backed by EBS, and as such, only supports the RWO method. If the deployment is updated without all existing pods being killed it may not be able to schedule a new pod and create a PVC for the PV as it's still bound to the existing pod. If you will be using EFS you do not have to change this.

oc patch dc/ostoy -p '{"spec": {"strategy": {"type": "Recreate"}}}'

Set a liveness probe

We need to create a liveness probe on the deployment to ensure the pod is restarted if something isn't healthy within the application. Enter the following into the CLI:

oc set probe dc/ostoy --liveness --get-url=http://:8080/health

Attach a Secret, ConfigMap, and PersistentVolume to the deployment

We are using the default paths defined in the application, but these paths can be overridden in the application via environment variables.

  • Attach a Secret.
oc set volume deploymentconfig ostoy --add \
  --secret-name=ostoy-secret \
  --mount-path=/var/secret
  • Attach a ConfigMap (using shorthand commands).
oc set volume dc ostoy --add \
  --configmap-name=ostoy-config \
  -m /var/config
  • Create and attach a PersistentVolume.
oc set volume dc ostoy --add \
  --type=pvc \
  --claim-size=1G \
  -m /var/demo_files

Expose the UI application as an OpenShift Route

Using the included TLS wildcard certificates, we can easily deploy this as an HTTPS application:

oc create route edge --service=ostoy --insecure-policy=Redirect

Browse to your application

Enter the following into your CLI:

python -m webbrowser "$(oc get route ostoy -o template --template='https://{{.spec.host}}')"

Or you can get the route for the application by using oc get route and copy/paste the route into your browser.

Get more support

More OpenShift resources