Deploy to OpenShift

Execute the following command in the VS Code terminal:

oc login -u {user} -p {password} https://openshift.default.svc:443

You should see:

Login successful.

You have access to the following projects and can switch between them with 'oc project ':

  * user-{user}-devspaces
    user-{user}-quarkus

Using project "user-{user}-devspaces"

Using project "devspaces-{user}".

Congratulations, you are now authenticated to the OpenShift server via the CLI. We’ll use the prettier web console later on in this lab.

Add openshift extension via VS Code Terminal:

mvn quarkus:add-extension -Dextensions="openshift"

[INFO] [SUCCESS] ✅  Extension io.quarkus:quarkus-openshift has been installed

Next, add the following variables in src/main/resources/application.properties for deploying the application to OpenShift. native compilation using Mandrel builder image:

%prod.quarkus.kubernetes-client.trust-certs=true
%prod.quarkus.kubernetes.deploy=true
%prod.quarkus.kubernetes.deployment-target=openshift
%prod.quarkus.openshift.build-strategy=docker
%prod.quarkus.openshift.route.expose=true
%prod.quarkus.openshift.route.target-port=http
%prod.quarkus.openshift.route.tls.termination=edge
%prod.quarkus.openshift.route.tls.insecure-edge-termination-policy=Allow
quarkus.openshift.deployment-kind=Deployment
quarkus.container-image.group={user}-quarkus
quarkus.container-image.registry=image-registry.openshift-image-registry.svc:5000

Docker build strategy builds the artifacts (JAR files or a native executable) outside the OpenShift cluster, either locally or in a CI environment, and then provides them to the OpenShift build system together with a Dockerfile. The container is built inside the OpenShift cluster and provided as an image stream.

Rebuild and re-deploy the people application via running the following maven plugin in the VS Code Terminal:

oc project {user}-quarkus &&
mvn clean package -Pnative -DskipTests -Dquarkus.package.uber-jar=false

As you recall, the output of this process is a native Linux binary but also running Source-To-Image(S2I) build processor.

Wait for it to finish!. You should get a BUILD SUCCESS message at the end. Once that’s done, make sure it’s actually done rolling out:

oc rollout status -w deployment/people

Wait for that command to report deployment "people" successfully rolled out before continuing.

And now we can access using curl once again. In the Terminal, run this command to access the endpoint:

curl $(oc get route people -o=go-template --template='{{ .spec.host }}')/hello/greeting/quarkus-on-openshift

You should see:

hello quarkus-on-openshift

Now that your app is deployed to OpenShift you can also see it in the OpenShift Console. Login with {user}/{password}

Once logged in, you can view a list of your projects :

Select the {user}-quarkus project to view Overview of the project:

Click on Workloads → Topology navigation menu on the left to view the topology of your project.

You can see the single people deployment that we deployed earlier using the CLI:

Select the circle to get details:

Select the View Logs link to see the console output from the app:

Go back to the Topology view. Since this app is exposed to the world, a Route was created which you can access using the small arrow in the upper right of the circle. Select the route link:

This will open a new tab in your browser with the URL to your app, and append /hello endpoint to the end of the URL to access the endpoint.

Earlier you implemented a series of MicroProfile health checks. To make OpenShift aware of these available health checks and begin using them, run the following commands in a Terminal:

oc set probe deployment/people --readiness --initial-delay-seconds=5 --period-seconds=5 --failure-threshold=20 --get-url=http://:8080/q//health/ready && oc set probe deployment/people --liveness --initial-delay-seconds=5 --period-seconds=5 --failure-threshold=20  --get-url=http://:8080/q/health/live

You’ll see in the Topology view that the app is re-deployed with the new settings and the old app will be terminated soon after:

This configures both a readiness probe (is the app initialized and ready to serve requests?) and a liveness probe (is the app still up and ready to serve requests) with default timeouts. OpenShift will not route any traffic to pods that don’t respond successfully to these probes. By editing these, it will trigger a new deployment.

At this point, the probes will be accessed periodically to ensure the app is healthy.