Pacman App

In this section, we’re going to deploy a pacman application, developed in nodejs that will expose 2 main REST endpoints to the visualizer application (pacman web component that was deployed in the previous labs). The application will query for user stats and high scores information that is stored in a MongoAtlas database. This application will also provide an external access point, so that the URL provided can be directly used by the end user to play pacman game.

Application architecture

Background: Source-to-Image (S2I)

In a previous lab, we learned how to deploy a pre-existing image image. Now we will expand on that by learning how OpenShift builds container images using source code from an existing repository. This is accomplished using the Source-to-Image project.

Source-to-Image (S2I) is a open source project sponsored by Red Hat that has the following goal:

Source-to-image (S2I) is a tool for building reproducible container images. S2I
produces ready-to-run images by injecting source code into a container image and
assembling a new container image which incorporates the builder image and built
source. The result is then ready to use with docker run. S2I supports
incremental builds which re-use previously downloaded dependencies, previously
built artifacts, etc.

OpenShift is S2I-enabled and can use S2I as one of its build mechanisms (in addition to building container images from Dockerfiles, and "custom" builds).

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 either in the OpenShift S2I documentation or on GitHub. The only key concept you need to remember about S2I is that it’s magic.

Exercise: Creating a Pacman application

The backend service that we will be deploying as part of this exercise is called pacman which is a game,

Add to Project

Because the pacman component is a backend to serve data that our existing frontend (pacman) will consume, we are going to build it inside the existing project that we have been working with. To illustrate how you can interact with OpenShift via the CLI or the web console, we will deploy the pacman component using the web console.

Using Application Code on Git Server

OpenShift can work with any accessible Git repository. This could be GitHub, GitLab, or any other server that speaks Git. You can even register webhooks in your Git server to initiate OpenShift builds triggered by any update to the application code!

Pacman GitHub Repository

Later in the lab, we want you to make a code change and then rebuild your application. This is a fairly simple Spring framework Java application.

Build the Code on OpenShift

Similar to how we used +Add before with an existing image, we can do the same for specifying a source code repository. Since for this lab you have your own git repository, let’s use it with a simple Java S2I image.

In the Developer Perspective, click +Add in the left navigation, go to the Git Repository section and then choose From Git option.

Add to Project

The Import from Git workflow will guide you through the process of deploying your app based on a few selections.

Enter the following for Git Repo URL:

https://github.com/veniceofcode/pacman.git

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.

Click Edit Import Strategy.

Select 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 Build Image as we are going to create the container image from the source code, as discussed in the next section.

Select Import Strategy
You could also use Dockerfile, the repo contains a multi-stage Dockerfile. For this exercise, we want to show the Build Image feature.

Verify that Java has been selected as your Builder Image, and be sure to select version openjdk-11-ubi8 to have OpenJDK 11.

Scroll down to the General section. Add the following:

Application Name :

pacman

Name :

pacman

In Resources section, select Deployment.

If present, leave Pipeline section empty here as we will implement it in the next modules

Under Advanced Options, ensure Create a route to the application is checked here.

We are going to create another Secure Route, this time directly from this view.

Click Show advanced Routing options.

Leave all default options, go under Security section.

Check Secure Route option.

Under TLS termination, select Edge.

Scroll down and expand the Labels section to add 3 labels.

The name of the Application group:

app=pacman

Next the name of this deployment.

component=pacman

And finally, the role this component plays in the overall application.

role=ui

Click Create to submit.

Select Builder

To see the build logs, in Topology view, click the pacman entry, then click on View Logs in the Builds section of the Resources tab.

Pacman build

This is a nodejs based application that uses Maven as the build and dependency system. For this reason, the initial build will take a few minutes as Maven downloads all of the dependencies needed for the application. You can see all of this happening in real time!

From the command line, you can also see the Builds:

oc get builds
= ----

You'll see output like:

[.console-output]
[source,bash]

NAME TYPE FROM STATUS STARTED DURATION pacman-1 Source Git@1c647d5 Complete 2 days ago 58s

You can also view the build logs with the following command:

[.console-input]
[source,bash,subs="+attributes,macros+"]

oc logs -f builds/pacman-1

After the build has completed and successfully:

* The S2I process will push the resulting image to the internal OpenShift 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 RS will detect no *Pods* are running and will cause one to be deployed, as our default replica count is just 1.

In the end, 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:

[.console-output]
[source,bash]

NAME READY STATUS RESTARTS AGE pacman-1-tkid3 1/1 Running 3 2m pacman-1-build 0/1 Completed 0 3m pacman-57df75c46d-xltcs 1/1 Running 0 2h

If you look again at the web console, you will notice that, when you create the
application this way, OpenShift also creates a *Route* for you. You can see the
URL in the web console, or via the command line:

[.console-input]
[source,bash,subs="+attributes,macros+"]

oc get routes

image::101.png[Pacman Console 800,align="center"]

Where you should see something like the following:

[.console-output]
[source,bash,subs="+attributes,macros+"]

NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD pacman pacman-pacman.apps.maverick.lab.upshift.rdu2.redhat.com pacman 8080-tcp edge/Redirect None bash-4.4 ~ $

In the above example, the URL is:

[source,text,role="copypaste",subs="+attributes"]

https://pacman-%PROJECT%.%CLUSTER_SUBDOMAIN%

WARNING: If the Pod is Running and the application is not available, please wait till we connect it to the MongoAtlas in the cloud as we don't have a database. Yet.