If you want to build your own Universal Messaging container image to run in a Docker container, there are scripts available on GitHub that provide a template for setting this up. The scripts and accompanying documentation can be used as provided or can be altered to take account of specific environment requirements. Universal Messaging system requirements have been updated to reflect that Docker with a CentOS image is now supported in line with the other Software AG products. The samples use CentOS 8 as a base image.

The scripts are available at https://github.com/SoftwareAG/universalmessaging-server-docker-samples.

As an alternative to building your own Universal Messaging container image, there are official Universal Messaging container images on the Software AG Container Repository. These are container images that Software AG builds, tests, and promotes on a regular basis. The 10.11 images use ReadHat UBI8 as a base image.

The available container images are:

You can also build Docker images for Universal Messaging on Linux systems using Software AG Installer. This approach allows only limited customization, such as providing a custom base image. The images that you build using the Installer client are similar to the official Universal Messaging images on Docker Hub and can be used in the same manner.

For more information about building Docker images for Universal Messaging using Software AG Installer, see the documentation about creating Docker images on Linux in the Using Software AG Installer guide.

After you build or pull a Universal Messaging Docker image, you can run that image by using the docker run command. You must map the default container port 9000 to one of the host ports, for example:

You can then use the host ports to access the server remotely via a URL, for example:

Optionally, you can specify the follwing environment variables when running an image:

The following is an example of running an image with the environment variables specified:

When Universal Messaging uses the default logging framework, the output is recorded in the nirvana.log and UMRealmservice.log files and is also displayed in the console. Each log entry starts with the specific log file name with which that entry is associated. You can also fetch the logs of a continer by using the docker logs umservercontainer command.

When Universal Messaging uses Log4j2 as the logging framework, the server logs are directly displayed in the console and written in the UMRealmService.log file. The log entries are not prefixed by the log file name, because Universal Messaging generates only one log file.

Universal Messaging supports the Log4j2 logging framework for Docker images and provides a default Log4j2 configuration. To enable Log4j2 for Docker images, set the LOG_FRAMEWORK=log4j2 environment variable as part of the docker run command.

The log4j2.xml default configuration file is located inside the Universal Messaging container under /opt/softwareag/UniversalMessaging/lib/classes. The default configuration does not store the nirvana.log log file on disk but displays the log output to STDOUT. The output of the UMRealmService.log file is displayed in the console.

If you use a custom log4j2.xml configuration, you must retain the packages configuration entry that lists the Universal Messaging extension package for Log4j2:

To configure the server logging level, use the nAdminAPI or the fLoggerLevel logging configuration property in the Enterprise Manager. To configure that property, you must first set LogLevelOverride to true. A false value for LogLevelOverride restores the configuration from log4j2.xml and overrides fLoggerLevel.

The following functionalities are not supported on a Universal Messaging server using Log4j2:

For more information about the logging properties, see Realm Configuration.

For more information about the Administration API, see Universal Messaging Administration API.