In the previous "
Lessons from the field" post we covered performance optimizations for Java running in containers. Joe McClure added some additional Liberty container performance optimizations in his blog post
here. In this post, we will cover some more general tips on using Liberty in containers.
Obtaining Liberty Container Images
Liberty container images are available from both Docker Hub and the IBM container registry. Both Open Liberty and WebSphere Liberty are available using both Ubuntu and the Red Hat Universal Base Image (UBI). You can further customize the image using the image tag. The available options are:
Version - You can specify a version number such as 21.0.0.7, or leave it out to select the latest fix pack
Feature Set - Specifying 'full' will give you an image with all available features installed. Specifying 'kernel-slim' (for Open Liberty) or 'kernel' (for WebSphere Liberty) will give you an
image without any features installed. For more information on the tradeoffs involved in using the kernel image, see Joe's previous blog post.
Java version - On Open Liberty you can use 'java8', 'java11', or 'java15' to choose a Java version. With WebSphere Liberty you can choose 'java8' or 'java11'
Java vendor - You can choose either 'openj9' or 'ibmjava'
Architecture - WebSphere Liberty images support additional architectures. You can choose 's390x', 'ppc64le', or 'amd64'
For example, to pull Open Liberty version 21.0.0.8 using version 8 of OpenJ9 java that contains all features from DockerHub, you would run:
docker pull openliberty/open-liberty:21.0.0.8-full-java8-openj9-ubi
IBM Container Registry Images
Open Liberty and WebSphere Liberty images on both Ubuntu an UBI can be accessed on the IBM container registry using icr.io/ibm/liberty:<tag>. For example,
icr.io/ibm/liberty:21.0.0.8-wl-kernel-java8-openj9 would be used to pull version 21.0.0.8 of the WebSphere Liberty kernel image with version 8 of OpenJ9.
icr.io/ibm/liberty:21.0.0.8-ol-full-java11-openj9 would be used to pull version 21.0.0.8 of the Open Liberty 'full' image with version 11 of OpenJ9.
For more information on Liberty in the IBM container registry and a list of available images, see the IBM Cloud container registry documentation
here.
Source To Image (S2I) Liberty Images
An alternative to using the above images would be to use the Open Liberty or WebSphere Liberty "Source To Image" (S2I) images. With S2I, you would reference a Liberty S2I repository and a source code repository that contains your application code to automatically construct a container image. For example, the following commands would construct and run a WebSphere Liberty container named
websphere-liberty-test that contains a sample application named 'ferret':
$ s2i build https://github.com/WASdev/sample.ferret.git ibmcom/websphere-liberty-s2i:21.0.0.8-java8 websphere-liberty-test$ docker run -p 9080:9080 websphere-liberty-testThe S2I utility will build the application in the github repository using Maven, and create a new container image with the application binaries installed.
Open Liberty S2I images are available on docker hub using openliberty/open-liberty-s2i:{version}-{java version}, where the java version can be either java8 or java11. Similarly, WebSphere Liberty S2I images are available using ibmcom/websphere-liberty-s2i:{version}-{java version}. For more information, see the github repositories for
Open Liberty S2I and
WebSphere Liberty S2I.
Configuring Liberty Containers
You can configure your Liberty containers manually by copying in a server.xml file during the container build process:
COPY --chown=1001:0 server.xml /config/Applications can be copied to the 'apps' or 'dropins' directories:
COPY --chown=1001:0 Sample1.war /config/dropins/COPY --chown=1001:0 Sample2.war /config/apps/If you are using the 'kernel-slim' Open Liberty image, ensure that you are running the 'features.sh' script as part of the build to install required features:
RUN features.shLiberty features are downloaded from maven central by default, but you can change the repository used by the features.sh script by adding a file named featureUtility.properties:
COPY --chown=1001:0 featureUtility.properties /opt/ol/wlp/etc/For more information on the featureUtility.properties file, see the documentation
here
Logging in JSON format
In a containerized environment, you may want to consider logging in JSON format for consumption by an external logging stack such as the
elastic stack.
You can configure logging in JSON format in bootstrap.properties, or through environment variables set either at build time or during container invocation.
To enable JSON logging using bootstrap.properties, add the following to your bootstrap.properties file:
com.ibm.ws.logging.console.log.level=infocom.ibm.ws.logging.console.format=jsoncom.ibm.ws.logging.console.source=message,trace,accessLog,ffdc,auditCopy the bootstrap.properties file into Liberty's configuration directory by adding the following to your Dockerfile:
COPY --chown=1001:0 bootstrap.properties /config/To enable logging of all sources in JSON format at build time using environment variables, add the following to your Dockerfile:
ENV WLP_LOGGING_CONSOLE_FORMAT=JSONENV WLP_LOGGING_CONSOLE_LOGLEVEL=infoENV WLP_LOGGING_CONSOLE_SOURCE=message,trace,accessLog,ffdc,auditTo enable the same variables at runtime, they would be passed into the Docker command using `-e`:
docker run -d -p 80:9080 -p 443:9443 -e WLP_LOGGING_CONSOLE_FORMAT=JSON -e WLP_LOGGING_CONSOLE_LOGLEVEL=info -e WLP_LOGGING_CONSOLE_SOURCE=message,trace,accessLog,ffdc,audit websphere-liberty:latest
Directory Structure
The directory
/liberty is a symbolic link to
/opt/ibm on WebSphere Liberty images, and
/opt/ol on Open Liberty images.
Liberty on Docker changes the directory of messages.log and FFDC to
/logs using the
LOG_DIR environment variable.
Liberty on Docker changes the current working directory of the Liberty process to
/liberty/wlp/output using the
WLP_OUTPUT_DIR environment
variable. This directory will contain any javacores or other dump files generated during the runtime of the container.
The symbolic link
/config will point to the
/liberty/wlp/usr/severs/defaultServer directory. This directory will contain files such as:
/config/server.xml - The primary configuration file for the server
/config/bootstrap.properties - Contains properties to be set before the server begins starting
/config/server.env - Contains variables that will be set in the environment prior to starting the server
/config/configDropins/defaults - Contains configuration files that will not take precedence over conflicting configurations in server.xml
/config/configDropins/overrides - Contains configuration files that will take precedence over conflicting configurations in server.xml
/config/dropins - Contains applications that are not defined in server.xml
/config/apps - The default directory for applications that are defined in server.xml
In a non-container environment, JVM parameters are typically provided in the jvm.options file. This file does not support variable substitution, so in a container environment these parameters should be specified either by using the
JVM_ARGS environment variable or by mounting the jvm.options file.
More Information
The
Open Liberty Guides site has several resources for learning how to use Liberty in containers, such as
Containerizing Microservices and
Containerizing, Packaging, and Running a Spring Boot application.
In a future blog post, we will cover running Liberty containers in a Kubernetes environment.
#app-platform-swat#automation-portfolio-specialists-app-platform#Java#WebSphere#WebSphereApplicationServer(WAS)#WebSphereLiberty