Modernizing runtimes with Liberty

Move applications to Liberty runtime

• Introduction
• Application Overview
• Analysis
• Build
• Deploy

Run it yourself

• Deploy the solution on Red Hat OpenShift using Cloud Nativet Toolkit Pipelines
• Deploy the solution on Red Hat OpenShift using OpenShift Pipelines (Tekton)

Introduction

Application Overview

• Starting with the database, the application leverages two SQL-based databases running on IBM DB2.

• The application exposes its data model through an Enterprise JavaBean layer, named CustomerOrderServices. This components leverages the Java Persistence API to exposed the backend data model to calling services with minimal coding effort.

  • This build of the application uses JavaEE6 features for EJBs and JPA.

• The next tier of the application, named CustomerOrderServicesWeb, exposes the necessary business APIs via REST-based web services. This component leverages the JAX-RS libraries for creating Java-based REST services with minimal coding effort.

  • This build of the application is using JAX-RS 1.1 version of the respective capability.

• The application’s user interface is exposed through the CustomerOrderServicesWeb component as well, in the form of a Dojo Toolkit-based JavaScript application. Delivering the user interface and business APIs in the same component is one major inhibitor our migration strategy will help to alleviate in the long-term.

• Finally, there is an additional integration testing component, named CustomerOrderServicesTest that is built to quickly validate an application’s build and deployment to a given application server. This test component contains both JPA and JAX-RS-based tests.

How the Application was Modernized

Analysis

• Install IBM Cloud Transformation Advisor either in to a Kubernetes Cluster or locally

• Download and execute the Data Collector against the existing WebSphere ND runtime

• Upload the results of the data collection in to IBM Cloud Transformation Advisor and review the analysis. A screenshot of the analysis is shown below:

• In the case of the CustomerOrderServicesApp.ear application, IBM Cloud Transformation Advisor has determined that the migration to WebSphere Liberty on Private Cloud is of Moderate complexity and that there are two Severe Issues that have been detected.

• Drilling down in to Detailed Migration Analysis Report that is part of the application analysis, it is apparent that IBM Cloud Transformation Advisor has detected that there are issues with lookups for Enterprise JavaBeans and with accessing the Apache Wink APIs.

• Behavior change on lookups for Enterprise JavaBeans In Liberty, EJB components are not bound to a server root Java Naming and Directory Interface (JNDI) namespace as they are in WebSphere Application Server traditional. The fix for this is to change the three classes that use ejblocal to use the correct URL for Liberty

• The user of system provided Apache Wink APIs requires configuration To use system-provided third-party APIs in Liberty applications, you must configure the applications to include the APIs. In WebSphere Application Server traditional, these APIs are available without configuration. This is a configuration only change and can be achieved by using a classloader definition in the Liberty server.xml file.

• In summary, some minimal code changes are required to move this application to the WebSphere Liberty runtime and the decision was taken to proceed with these code changes.

Build

• Make the simple code changes required for the EJB lookups which were recommended by IBM Cloud Transformation Advisor. The three Java classes that should be modified to look up Enterprise JavaBeans differently are shown in the detailed analysis view of IBM Cloud Transformation Advisor:

• Below is an example of the code changes required for one of the three Java classes. The org.pwte.example.resources.CategoryResource.java is changed from using ejblocal on line 28 as shown below:

...
InitialContext().lookup("ejblocal:org.pwte.example.service.ProductSearchService");
...
Copy to clipboardCopied!

...
InitialContext().lookup("java:app/CustomerOrderServices/ProductSearchServiceImpl!org.pwte.example.service.ProductSearchService");
...
Copy to clipboardCopied!

• The WebSphere Liberty runtime configuration files server.xml, server.env and jvm.options were created from the templates provided by IBM Cloud Transformation Advisor. The final versions of files can be found here:

  • server.xml
  • server.env
  • jvm.options

• WebSphere Liberty was configured for application monitoring using Prometheus and the Prometheus JMX Exporter. This was necessary to integrate WebSphere Liberty with the Red Hat OpenShift monitoring framework.

• The Dockerfile required to build the immutable Docker Image containing the application and WebSphere Liberty was created from the template provided by IBM Cloud Transformation Advisor. The final file for use with Jenkins can be found here:

  • Dockerfile

• The final Dockerfile file for use with Tekton/OpenShift Pipelines can be found here:

  • Dockerfile

• The containerized application was tested locally before the code and configuration files were committed to the git repository

Deploy

• Deploy using Cloud Native Toolkit Pipelines
• Deploy using Tekton

Deploy using Cloud Native Toolkit Pipelines

• test: the application code is compiled and unit tests are executed using Maven before the static code is analyzed for quality using SonarQube.

• build: the container image for the application is created using buildah and pushed to the Image Registry in the local OpenShift cluster

• trivy-scan: the container image in the local Image Registry is scanned for vulnerabilities using Trivy

• deploy: deploy the application to the dev namespace

• health-check: validate the the application is functioning correctly in the dev namespace. Automated testing may occur at this step but is out of the scope of this solution.

• tag-release: create a new ‘release’ for the application in the Git repository

• img-release: tag and push the container image to the central Image Repository

• scan: scan the container image in the central Image Registry using IBM Vulnerability Advisor

• helm-release: package a helm release for the application and load it in to the central Artifact Repository Artifactory

• gitops: update the GitOps repository with the latest helm release information to trigger ArgoCD to deploy the application to the test namespace

Deploy using OpenShift Pipelines

• 1) A developer commits code to the application repository

• 2) A webhook starts a tekton pipeline running in the build project

• 3) A tekton task clones the application source code (4) from the application repository, uses Maven to compile and test the application before using buildah to create a Docker image which is pushed to the docker registry (5)

• 6) A tekton task deploys the application to the local namespace using the image from the docker registry (7)

  

Summary