A while back we published a post detailing how a microservices application can be built using WildFly Swarm and Netflix OSS. WildFly is a lightweight, flexible, feature rich, Java EE 7 compatible application server which is the foundation for JBoss EAP 7, Red Hat’s commercial Java EE server offering. JBoss EAP 7.0 Beta was released in the beginning of this year and a few weeks ago it also became available on OpenShift in order to easily build JBoss EAP 7.0 based applications running in containers.

 

The full list of new JBoss EAP 7.0 features are detailed in the release note. A highlight of the new capabilities follows:

  • Support for Java EE 7 and Java SE 8
  • Optimized for container and cloud deployments
  • Upgrade support featuring interoperability
  • Enhanced administration and management

In this post, we will rebuild the same microservices application based on JBoss EAP 7.0 and Netflix OSS and deploy on OpenShift.

The JBoss EAP 7.0 image on OpenShift supports Source-to-Image (S2I) functionality in OpenShift which removes the need for building the Docker images for our services separately. OpenShift can directly clone the code from the github repository, build and package the service, create a Docker image containing the service deployed on JBoss EAP 7.0, push the new image into the integrated image repository and finally run the resulting container.

Refactoring the Services for JBoss EAP 7.0 Beta

image00

In order to refactor the demo microservices application to use JBoss EAP 7.0 Beta, a few minor changes needs to be made in the Maven configuration. The first change is to update the WildFly version to what the based version for JBoss EAP 7.0:

<version.wildfly-swarm>1.0.2.Final</version.wildfly-swarm>

The JBoss EAP 7.0 image on OpenShift does not have any root application deployed. By renaming the service artifact to ROOT.WAR during the packaging, the service will be deployed as the root application and will be accessible under the root context. By default, JBoss EAP 7.0 image uses the “openshift” Maven profile to build and package the application. You can take advantage of this profile to make sure the target package is renamed only when it’s run by JBoss EAP 7.0 image.

openshift

maven-war-plugin
2.6

${project.basedir}/deployments
ROOT

 

OpenShift Template

In order to simplify deployment of the entire microservices application, you can also adjust the OpenShift template used for orchestrating the services. Instead of building the Docker images for each service separating and instructing OpenShift to pull the images from the local Docker repository, you can create a BuildConfig for each service that uses JBoss EAP 7 Source-to-Image (S2I) and automatically packages and builds the application as a Docker image before pushing it into the integrated OpenShift image repository. You also need to create an ImageStream that keeps track of images built for each service.

- apiVersion: v1
kind: ImageStream
metadata:
labels:
application: eap7-microservices-example
name: employee-app
- apiVersion: v1
kind: BuildConfig
metadata:
labels:
application: eap7-microservices-example
name: employee-app
spec:
output:
to:
kind: ImageStreamTag
name: employee-app:latest
source:
contextDir: employee-service
git:
ref: eap7
uri: https://github.com/siamaksade/wildfly-swarm-hystrix-example.git
type: Git
strategy:
sourceStrategy:
forcePull: true
from:
kind: ImageStreamTag
name: jboss-eap70-openshift:1.3-Beta
namespace: openshift
type: Source
triggers:
- github:
secret: Yx9viFu9zBxcGmdN
type: GitHub
- generic:
secret: Yx9viFu9zBxcGmdN
type: Generic
- imageChange: {}
type: ImageChange
- type: ConfigChange

The source section of above configuration states where to find the source code for the service which is referring to the github repo and branch hosting the code. The trigger section describes when the Docker image should be rebuilt and push to the registry. The above configuration specifies the following events to trigger an service rebuild:

  • Webhooks: for triggering builds whenever a git commit takes place on the git repo
  • Base image change: to rebuild whenever the base image for this service gets updated. In other words, if a new version of JBoss EAP 7.0 image is released (jboss-eap70-openshift:1.3-Beta), OpenShift will automatically rebuild the service based on the new image. This feature is particularly useful when new patches and security fixes are released for base images.
  • Config change: to rebuild when there is a new build configuration for this service and in future versions, when the build configuration gets updated. An example of such a change would be defining new environment variable or changing the repository branch hosting the source code.

 

For further details on BuildConfig configuration refer to OpenShift documentation.

 

Now that you have the build configured, you can modify the deployment config to launch the JBoss EAP 7.0 Beta-based service container:

- apiVersion: v1
kind: DeploymentConfig
metadata:
labels:
application: eap7-microservices-example
name: employee-app
spec:
replicas: 1
selector:
deploymentConfig: employee-app
strategy:
type: Recreate
template:
metadata:
labels:
application: eap7-microservices-example
deploymentConfig: employee-app
name: employee-app
spec:
containers:
- env:
- name: OPENSHIFT_KUBE_PING_LABELS
value: application=employee-app
- name: OPENSHIFT_KUBE_PING_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: MQ_CLUSTER_PASSWORD
value: O5sHf97QEliXXcVv
- name: JGROUPS_CLUSTER_PASSWORD
value: O5sHf97QEliXXcVv
- name: JAVA_OPTS_APPEND
value: -Xms512m -Xmx512m
image: employee-app
imagePullPolicy: Always
livenessProbe:
exec:
command:
- /bin/bash
- -c
- /opt/eap/bin/livenessProbe.sh
name: employee-app
ports:
- containerPort: 8778
name: jolokia
protocol: TCP
- containerPort: 8080
name: http
protocol: TCP
- containerPort: 8888
name: ping
protocol: TCP
readinessProbe:
exec:
command:
- /bin/bash
- -c
- /opt/eap/bin/readinessProbe.sh
terminationGracePeriodSeconds: 60
triggers:
- imageChangeParams:
automatic: true
containerNames:
- employee-app
from:
kind: ImageStream
name: employee-app
type: ImageChange
- type: ConfigChange

Similar to build configuration, the above defines a set of trigger to instruct OpenShift to automatically redeploy the service based on certain events:

  • Image change: when a new version of the service image is available in the registry
  • Config change: when changes are detected to the replication controller of this service

 

Combination of build and deployment configuration as stated above, enables automatic build and deployment of the service container whenever changes are committed to the service git repo and also whenever the new version of JBoss EAP 7.0 Beta image is made available to OpenShift.

 

The complete template after refactoring is available on github.

Deploying on OpenShift

Taking advantage of JBoss EAP 7.0 image and a template, deploying the complete microservices application on OpenShift becomes significantly simplified.

 

Since Netflix Turbine makes API calls to OpenShift in order to discover data endpoints for aggregation, the service account used by the Turbine container to make API calls needs to have read access to cluster. Run the following command as an OpenShift cluster admin user to give sufficient privileges to the service account:

$ oadm policy add-cluster-role-to-user cluster-reader system:serviceaccount:eap7:default

Now create a new project for the microservices application:

$ oc new-project eap7 --display-name="JBoss EAP 7.0 Microservices"

The ImageStream for JBoss EAP 7 should be installed on OpenShift, if it’s not already done before. These ImageStreams are normally installed in the openshift namespace. In order to create the ImageStream run the following:

$ oc create -f https://raw.githubusercontent.com/jboss-openshift/application-templates/master/jboss-image-streams.json -n openshift

You can also install the ImageStreams in your own namespace (project) for example if you don’t have sufficient access to modify the openshift namespace:

$ oc create -f https://raw.githubusercontent.com/jboss-openshift/application-templates/master/jboss-image-streams.json -n eap7

Now you can import and instantiate the application template:

$ oc create -f https://raw.githubusercontent.com/siamaksade/wildfly-swarm-hystrix-example/eap7/eap7-microservices-example.yaml
$ oc new-app eap7-microservices-example -p IMAGE_STREAM_NAMESPACE=[openshift|eap7]

IMAGE_STREAM_NAMESPACE parameter tells OpenShift where to find the ImageStream for JBoss EAP 7.0. Set the value to the namespace you have installed the ImageStream.

 

That was all needed. OpenShift starts cloning the source codes, building the Java application, deploying onto JBoss EAP 7.0 Beta, building Docker images for the deploy applications and start the service containers.

Conclusion

JBoss EAP 7.0 image simplifies building and deploying container-based microservices by enabling the developer to point to the source code repository of the services and let OpenShift to build, deploy and run the services and manage their lifecycle.