Payara 5 in docker with autodeploy function

jakarta-ee

I wanted to play around with going back to the roots of java(EE) and wanted to take the docker part a step further.
Why not have the platform as a docker image in such a way that when building the project the docker image will take care of the
deployment automatically after each build.

Goal

  • Building a Java EE application as easy as possible
  • Have all the cool stuff available from MicroProfile
  • Stay as close to the core as possible.

Prerequisites

  • Docker installed
  • Java 8 installed
  • IDE
  • A sense of adventure :-)

Steps

Payara docker image

I wanted to make a docker image with Payara 5 on it. See this blog for more information on it.
It has to be configurable is such a way that it does not need to be rebuild every time I create an artifact.
Assume that the war I create will be deployed on a similar server and that I don’t need to deploy the
whole platform every time. So I don’t want to build my docker image every time either
when programming and building my application.

So I need:

  • Payara as a docker image -> ivonet/payara:5.184
  • a way to deploy automatically after each maven build
  • have it exposed to the local machine

In the image a link has been created between /autodeploy and the actual autodeploy diretory in the image (see the Dockerfile for more information). This is done for
convenience and ease of reading. Now you can mount this directory as a volume.

How to get auto deploy working?

In order to do this I have chosen to add a very small part to my maven java project to facilitate the autodeploy feature. 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    ...
    <build>
        <finalName>${artifactId}</finalName>
        <plugins>
            ...
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-war-plugin</artifactId>
                <version>3.1.0</version>
                <configuration>
                    <failOnMissingWebXml>false</failOnMissingWebXml>
                    <warName>${project.build.finalName}</warName>
                    <outputDirectory>artifact</outputDirectory>
                </configuration>
            </plugin>
            ...
        </plugins>
    </build>
    ...
</project>

When executing mvn package it will build the war file but also copy the final artifact to the
<project>/artifact directory.

When starting the created docker container (from the project directory) we can now make sure
that it will mount the <project>/artifact directory to the /autodeploy container directory.

1
2
3
4
5
docker run -d --name payara        \
  -p 8080:8080                     \
  -p 4848:4848                     \
  -v $(pwd)/artifact:/autodeploy   \
  ivonet/payara:5.184

This command will run the Payara 5 Full profile server in daemon mode, with the <project>/artifact folder mounted as a folder to
its inner /autodeploy directory.

Now if you build your project:

mvn clean package

it will build the war in the target folder and the plugin defined in the pom.xml file will make sure that the artifact is copied to the <project>/artifact directory
The Payara server is monitoring that folder because it has been mounted to its autodeploy directory and it will see
a new artifact in the directory. Now it will autodeploy that artifact with the artifact name as the rootContext.

So if you project is called HelloWorld the artifact will be called ./artifact/HelloWorld.war and the url for Payara will become
http://localhost:8080/HelloWorld.

Every time you rebuild the project with the maven commando’s payara will redeploy the artifact as it will recognise that it has changed.
Now you can build and test your software without having to build a new image every time while still testing against the final environment.

Pretty cool if I do say so myself 😄

Have fun,

Ivo.

Note

While creating the image I had started out with a small alpine openjdk 1.8 docker image,
but to my dismay it threw this error java.lang.NoClassDefFoundError: sun/security/ssl/SupportedEllipticCurvesExtension
when I tried to enable the remote Admin console. In the end I got it to work on a CentOs with a java 1.8.0_191 version
installed on it.
I must say that it was a big surprise for me that this bug was there and I will try again with standard
OpenJdk versions at a later date as I also want to migrate to Java 11+ but for now it is what it is 😄

Maven Archetype

This feature is also used in projects generated with this Maven Archetype.