Universal Messaging 10.11 | Installation Guide | Using Containers
 
Using Containers
Universal Messaging Container Images on Software AG Container Repository
Software AG offers official Universal Messaging server images on the Software AG Container Repository at https://containers.webmethods.io/products/universalmessaging-server. Software AG builds, tests, and promotes these container images on a regular basis. The images use Red Hat UBI 8 as a base image.
The Software AG Universal Messaging Server image contains the Universal Messaging server and the tools for command-line administration and monitoring of Universal Messaging.
You can also run the server container in serverless mode, which means you can use only the included tools to manage and administer other Universal Messaging server containers.
Docker Scripts on GitHub
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.
Creating Universal Messaging Container Images Using Software AG Installer
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.
Running Universal Messaging Docker Images
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:
docker run -d -p 9000:9000 --name umservercontainer universalmessaging-server:10.11
You can then use the host ports to access the server remotely via a URL, for example:
nsp://dockerhostname:hostport
Optionally, you can specify the follwing environment variables when running an image:
*REALM_NAME - the name of the Universal Messaging realm.
*INIT_JAVA_MEM_SIZE - the initial Java heap size in megabytes.
*MAX_JAVA_MEM_SIZE - the maximum Java heap size in megabytes.
*MAX_DIRECT_MEM_SIZE - the maximum direct memory size in gigabytes.
*BASIC_AUTH_ENABLE - enables basic authentication on the server.
*BASIC_AUTH_MANDATORY - enables and manages basic authentication on the server.
*STARTUP_COMMAND - configues the server to execute a given command at startup.
*LOG_FRAMEWORK - enables the Log4j2 logging framework. The valid value is log4j2. If this variable is not specified, the server uses the default logging framework (fLogger).
*TOOLS_ONLY - starts the container in serverless mode. You can use such containers to run only the included tools to manage other Universal Messaging server containers.
The following is an example of running an image with the environment variables specified:
docker run -d -e REALM_NAME=umtest -e INIT_JAVA_MEM_SIZE=2048 -e MAX_JAVA_MEM_SIZE=2048
-e MAX_DIRECT_MEM_SIZE=3G -e BASIC_AUTH_ENABLE=Y -e BASIC_AUTH_MANDATORY=Y -e LOG_FRAMEWORK=log4j2
-e STARTUP_COMMAND="runUMTool.sh CreateChannel -channelname=test -rname=nsp://localhost:9000"
-p 9000:9000 --name umservercontainer universalmessaging-server:10.11
The following is an example of running a container in serverless mode:
docker run -d --name umtoolsonly -e TOOLS_ONLY=true sagcr.azurecr.io/universalmessaging-server:10.11
docker exec umtoolsonly runUMTool.sh ListChannels -rname=nsp://host:mappedPort
For more information about using the runUMTool tool, see Syntax reference for command line tools.
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.
Using the Log4J2 Logging Framework
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:
Configuration packages="com.softwareag.um.extensions.logger.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:
*DefaultLogSize logging configuration property
*LogManager logging configuration property
*RolledLogFileDepth logging configuration property
*Dynamic reconfiguration using the monitorInterval Log4J configuration attribute
*Rolling the log file
For more information about the logging properties, see Realm Configuration.
For more information about the Administration API, see Universal Messaging Administration API.