Deploying to the Cloud

 8

Deploying to the cloud

With our app fully ready for its first cloud native deployment, let’s package it up for deployment to our Kubernetes platform as a native image. We’ll use some OpenShift tooling to accomplish this, as outlined in the Quarkus - Deploying on Kubernetes Guide.

OpenShift is a commercially supported distribution of Kubernetes from Red Hat. The platform is also available as open source, in the form of OKD, the Origin Community Distribution of Kubernetes that powers Red Hat OpenShift.

Login to OpenShift

Although your Eclipse Che workspace is running on the Kubernetes cluster, it’s running with a default restricted Service Account that prevents you from creating most resource types. So we’ll log in with your workshop user. Click on Login to OpenShift, and enter your given credentials:

• Username: user10

• Password: openshift

Use the username and password you were assigned by the instructor.

You should see:

Login successful.

You have one project on this server: "user10-project"

Using project "user10-project".
Welcome! See 'oc help' to get started.

After you log in using Login to OpenShift, the terminal is no longer usable as a regular terminal. You can close the terminal window. You will still be logged in when you open more terminals later!

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

The login session might timeout after long periods of inactivity. If this happens, you’ll get messages like Error from server (Forbidden): xxxxx is forbidden: User "system:anonymous" cannot xxxxx. Simply login again!

Namespaces are a top level concept to help you organize your deployments and teams of developers. A namespace allows a community of users (or a user) to organize and manage their content in isolation from other communities. OpenShift projects provide additional functionality for managing Kubernetes namespaces.

For this scenario, a project has been created for you called user10-project. You will use this project to deploy your developed project in the next step.

Build and Deploy native image

Quarkus offers the ability to automatically generate OpenShift resources based on sane default and user supplied configuration. The OpenShift extension is actually a wrapper extension that brings together the kubernetes and container-image-s2i extensions with defaults so that it’s easier for the user to get started with Quarkus on OpenShift.

Add openshift extension via CodeReady Workspaces Terminal:

mvn -q quarkus:add-extension -Dextensions="openshift" -f $CHE_PROJECTS_ROOT/quarkus-workshop-m1m2-labs

you will see:

✅ Extension io.quarkus:quarkus-openshift has been installed

Next, add the following variables in src/main/resources/application.properties for 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.expose=true

	We are using self-signed certs in this simple example, so this simply says to the extension to trust them.
	Instructs the extension to deploy to OpenShift after the container image is built
	Instructs the extension to generate and create the OpenShift resources (like DeploymentConfig and Service) after building the container
	Instructs the extension to generate an OpenShift Route.

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

mvn clean package -Pnative -DskipTests -Dquarkus.package.uber-jar=false -f $CHE_PROJECTS_ROOT/quarkus-workshop-m1m2-labs

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 dc/people

dc in dc/people is shorthand for OpenShift’s DeploymentConfig object type. There are other shortcuts like bc for BuildConfig, svc for Kubernetes Services, and so on.

Wait for that command to report replication controller "people-1" 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

The above curl command constructs the URL to your running app on the cluster using the oc get route command.

You should see:

hello quarkus-on-openshift from people-1-9sgsm

Your hostname (the Kubernetes pod in which your app runs) name will be different from the above.

So now our app is deployed to OpenShift. You can also see it in the OpenShift Console. Login with your assigned username and password (e.g. user10/openshift):

Once logged in, click on the name of your project (user10-project):

Switch to the Developer Perspective using the upper-left drop-down:

This provides a developer-centric Topology view of applications deployed to the project. You can see the single people deployment that we just deployed earlier using the CLI:

Click on the circle to get details:

Click on the View Logs link to see the console output from the app:

This is the same output you saw earlier when you ran it "locally" with it’s super-fast startup time.

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. Click on the route link:

You can click on the route link to open up the default Quarkus page that’s packaged as part of our workshop application.

Connect MicroProfile health check

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 in CodeReady:

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

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.

Congratulations!

This step covered the deployment of a native Quarkus application on OpenShift. However, there is much more, and the integration with these cloud native platforms (through health checks, configuration management, and monitoring) has been tailored to make Quarkus applications execution very smooth.

This is the end of the Basic Quarkus Hands-On Lab. You can now continue with the Advanced Quarkus Hands-On Lab if your instructor has included that lab.