Payara Docker Images – Update

A year ago, we brought you our first Docker images. Today, we have updated them with a few changes and refinements.

For those already familiar with Docker, here are the key points

• The images are automatically built to Docker hub and can be pulled with the following commands:
  • docker pull payara/server-full
  • docker pull payara/server-web
  • docker pull payara/micro
• We no longer use Oracle JDK
  • Since the images have the JDK built into them, using Oracle JDK would count as redistribution, which would break Oracle’s license terms
• Each release (currently) uses the short versioning scheme
  • We began with 161.1 and also build from the latest prerelease every day, so you can pull the following images:
    • payara/server-full:161.1
    • payara/server-full:162
    • payara/server-full:latest
    • payara/server-full:prerelease
  • The “latest” tag is by Docker convention – it will always reflect the latest released version of Payara Server or Payara Micro

What changes have we made?

The main thing to change was the base image. Initially we were using Ubuntu but, since the 14.04 LTS edition does not have Java 8 in its package repositories, we had to use a non-LTS version to be on the latest JDK (16.04 LTS was, obviously, unavailable at the time). The new images are built from the official JDK Docker images, meaning that each (new) build will use the latest update of Java without our input.

The JDK images are provided on a Debian base and an Alpine Linux base. Both Payara Server images (full and web profile) use the Debian edition so, if you wanted to build an image on top of them, you have got access to all the Debian repositories and Bash.

The Payara Micro images use the Alpine Linux edition; the main driver for this being size. Payara Micro is a micro Java EE platform for microservices. A 1.284GB Docker image is not what I would call Micro! Reducing that size by over 1GB is a very valuable saving:

The other thing to note is that the admin user in the Payara Server images now has a default password of “admin”. We have made the change in an open way so that you can copy this method to change the password to something more secure yourself in your own Dockerfile. For development purposes, it can be left as-is.

How can you use the Payara Docker images?

Our expectation in providing these images is that they will be used either with your own Dockerfiles as part of your CI process or through a tool like Docker Compose like I have with my docker-compose demo repository:

version: '2'
services:
  micro1:
    image: payara/micro:162
    ports:
     - "1080:8080"
    volumes:
     - ./payara-micro/deployments:/opt/payara/deployments
    entrypoint:
     - java
     - -jar
     - /opt/payara/payara-micro.jar
     - --deploymentDir
     - /opt/payara/deployments
  payara-full:
    build: ./payara-server-full
    ports:
     - "2080:8080"
    entrypoint:
     - /opt/payara41/bin/asadmin
     - start-domain
     - -v

This example would start Payara Micro and Payara Server (full profile); the Payara Micro container will deploy whatever resource is in the ./payara-micro/deployments folder.

You’ll notice that the “micro1” container starts by pulling directly from Docker Hub. The “payara-full” container starts by first building a new image from the directory which contains the following Dockerfile:

FROM payara/server-full:162

RUN /opt/payara41/bin/asadmin start-domain && 
    /opt/payara41/bin/asadmin --user admin --passwordfile=/opt/pwdfile set-hazelcast-configuration --enabled=true --dynamic=true

COPY rest-jcache.war /opt/payara41/glassfish/domains/domain1/autodeploy

Here, the WAR file to be deployed is copied over in creating the new layer. It is important to make sure to enable Hazelcast by using the asadmin subcommand set-hazelcast-configuration and to add --dynamic=true so that the change takes place immediately.

If I wanted Payara Server to be started when I run the container, I would add an ENTRYPOINT in to the Dockerfile, or supply it as an argument to my docker run command.