Containerization has emerged as a game-changer for modern enterprises seeking unparalleled agility and efficiency. By containerizing JBoss EAP applications, businesses can seamlessly encapsulate their complex Java applications and their dependencies, enabling rapid deployment, scalability, and simplified management. This transformative approach empowers organizations to respond swiftly to evolving market demands, reduce deployment friction, and fully harness the exceptional performance and reliability that JBoss EAP is renowned for.

Deploying a JBoss EAP application on Kubernetes involves several steps, including containerizing the application and creating an image with a JBoss EAP instance. Red Hat OpenShift offers a comprehensive set of development tools that streamline the containerization of applications. With its "Source to Image" feature, OpenShift simplifies the process of building and deploying applications by allowing developers to directly push their source code to the platform, which then automatically builds the container image.

What about other Kubernetes flavors, like Amazon EKS?

In this blog, we will guide you through the process of containerizing a JBoss EAP application using Move2Kube UI tool, which simplifies the containerization process by analyzing the application and generating the necessary Kubernetes artifacts automatically. Additionally, we will demonstrate how to deploy the containerized application on Amazon EKS, a managed Kubernetes service offered by Amazon Web Services (AWS). Note that running JBoss EAP on Amazon EKS will not be as full-featured as running JBoss EAP on Red Hat OpenShift. For example, you can get a supported EAP operator to deploy and manage JBoss EAP applications on Openshift, with features like Transaction Recovery, High Availability, and Failover, to mention a few.

Let's get started and learn how to containerize and deploy a JBoss EAP application on EKS using Move2Kube UI tool.

Prerequisites:

These prerequisites are necessary to containerize your JBoss EAP application using Move2Kube UI tool and deploy it on Amazon EKS.

Build your JBoss EAP Application

For this example, we will use quickstart from the repository below. Clone this in your local machine, and create a zip file:

https://github.com/jboss-developer/jboss-eap-quickstarts/tree/7.4.x/kitchensink

$ zip -r kitchensink.zip kitchensink

 

Launch Move2Kube Tool via Container

Create Workspace and Project

Workspace: jboss-demo

Project: kitchensink-app

Figure 1 shows the UI view of Move2Kube application and workspace creation.

Figure 1:  Move2Kube UI running in a container and accessed via localhost

Scroll down and upload the zip folder containing the source files for the KitchenSink application (see Figure 2), then click “Start Planning.” This will generate a plan for the source files to be transformed into Kubernetes YAMLs.

Figure 2:  Click the Start Planning button to generate a transformation plan

Once the plan is generated, click “Start Transformation.” This will walk you through a questionnaire, and for this example, provide the following options:

Step 1: Start Transformation

Step 2: move2kube Transformer Selector: default

Step 3: move2kube.transformers.types: select all

Step 4: move2kube.services.[].enable: kitchensink

Step 5: move2kube.services."kitchensink".dockerfileType: no build stage

Step 6: move2kube.services."kitchensink".childModules."kitchensink".port: 8080

Step 7: move2kube.services."kitchensink".wartransformer: jboss

Step 8: move2kube.target.imageregistry.url: quay.io

Step 9: move2kube.target.imageregistry.namespace: kitchensink-app

Step 10: move2kube.target."default".clustertype: AWS-EKS

Step 11: move2kube.services."kitchensink"."8080".servicetype: Ingress

For the remaining questions, leave the default values and finish the transformation. This should create a zip file (Figure 3). Download the file.

Figure 3:  Zip file shown as output of planning step.

 

Explore Generated Artifacts

Open the downloaded folder in IDE/CLI and explore the generated artifacts (see Figure 4).

Figure 4:  Folder structure of the downloaded zip file.

The deploy directory contains deployment artifacts, YAMLs for each of the services that we have identified using Move2Kube plan file. It also contains various CI/CD templates and files, and we can pick and choose as needed, based on whether we use ArgoCD/Helm/Kustomize/Tekton tools.

The scripts directory contains scripts for building and pushing images into the preferred registry (in this case, quay.io). The source dir contains the dockerfile that will be used to build the container image; currently it shows for Wildfly binaries (see Figure 5).

Figure 5:  Docker file snapshot

These binaries can be replaced with JBoss EAP binaries for enterprise support from Redhat for the EAP applications (an example is available here).

Build, Push, and Deploy Application Container Image

If using Podman, run the build script as shown. Make sure source/kitchensink/dockerfile has the correct WAR file being copied.

$ cd scripts
$ ./buildimages.sh podman
$ podman images
REPOSITORY                                          TAG         IMAGE ID      CREATED        SIZE
localhost/kitchensink                               latest      7373c8d909b2

 

Now run the pushimage script to push the built image into quay.io (for this example). Make sure to log into the registry first. If choosing to specify any other registry, modify scripts/pushimages.sh.

$ ./pushimages.sh quay.io <> podman

 

Deploy the image in running EKS cluster using deploy/yamls/kitchensink-deployment.yaml
Make sure to check the YAML for the correct image name, including URL.

$ deploy/yamls  > kubectl create namespace jboss
namespace/jboss created
$ deploy/yamls  > kubectl create -f kitchensink-deployment.yaml -n jboss
deployment.apps/kitchensink created
$ kubectl get pods -n jboss
NAME                           READY   STATUS    RESTARTS   AGE
kitchensink-78b6668fcc-fmmwn   1/1     Running   0          17s
kitchensink-78b6668fcc-w2p96   1/1     Running   0          17s


$ deploy/yamls  > kubectl create -f kitchensink-service.yaml -n jboss
service/kitchensink created


$ deploy/yamls  > kubectl get service -n jboss                      
NAME          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
kitchensink   ClusterIP   10.100.143.162   <none>        8080/TCP   5s


$ deploy/yamls > kubectl create -f kitchensink-app-ingress.yaml

 

Make sure to check for annotations for the Amazon load balancer controller (refer to  the example here).

Test KitchenSink Application

Once the ingress is created, it might take a minute for the ingress URL to be available.

$ kubectl get ingress kitchensink-app
NAME              CLASS    HOSTS   ADDRESS                                                                  PORTS   AGE
kitchensink-app   <none>   *       k8s-default-kitchens-6ed7dc9438-1460104612.us-east-2.elb.amazonaws.com   80      14m

 

Open the browser and access the KitchenSink application (see Figure 6) at the above address and the suffix /kitchensink path.

Figure 6:  Running JBoss application accessible from OpenShift route.

Conclusion

We have explored the process of containerizing the KitchenSink application using the Move2Kube tool and generating the required Kubernetes artifacts and YAML files for deployment in an Amazon EKS cluster. This streamlined approach allows developers to efficiently package and deploy their JBoss EAP applications.

Both Move2Kube and OpenShift offer valuable solutions for containerization and deployment tasks. While Move2Kube focuses on the Kubernetes ecosystem, OpenShift provides a comprehensive platform with additional features and tools to further streamline the process.