Overview
webMethods Microservices Runtime provides scripts that allow generating Dockerfiles and Docker images. In previous articles, we described ways to create Docker images and run Docker containers. In the earlier versions of Microservices Runtime, one was required to embed configurations inside a Docker image, and one could only update an existing configuration using a configuration variables template. In version 10.11 and the latest fixes of earlier versions, Microservices Runtime allows creation of configurations using a configuration variable template. This article provides an overview of how the same Docker image of Microservices Runtime can be used across different stages in the development life cycle with different configurations.
Prerequisites
-
You have some familiarity with the Docker technology
-
You have Docker installed in your environment and it is running as a daemon
-
You have familiarity with support of Docker in webMethods Microservices Runtime. More information about this can be found at Microservices Runtime with Docker
Environment variables support in Microservices Runtime
Microservices Runtime supports different environment variables that can be supplied when starting a Docker container. These environment variables allow the supplying of the License file (SAG_IS_LICENSE_FILE) for the container, setting the minimum (JAVA_MIN_MEM) and maximum (JAVA_MAX_MEM) heap size for the container, and providing the configuration variables template (SAG_IS_CONFIG_PROPERTIES). More information about these environment variables can be found at Environment Variables.
Configuration variables support in Microservices Runtime
The configuration variables template is a way to configure the container running Microservices Runtime. For this article, we will use the Docker image of Microservices Runtime published on https://hub.docker.com/_/softwareag-webmethods-microservicesruntime. You can also use Docker images created in your environment. One of the ways the configuration variables template can be supplied to a container is by using the SAG_IS_CONFIG_PROPERTIES environment variable.
The configuration variable template is a Java properties file containing key-value pairs where each key represents a particular asset’s property for which you can specify a value. The value specified for individual keys can have one of the following formats:
-
Plain text
-
Environment variable; an example value can be $env{JDBC_URL}, where JDBC_URL is the environment variable containing the actual value that will be substituted at startup time
-
Encrypted value; an example value can be {AES}CsazC/…, you can use Microservices Runtime’s Admin UI to generate encrypted value. Documentation here provides more information on this
-
Kubernetes secrets; an example value can be $secret{jdbcurl}, where jdbcurl is the secret stored in Kubernetes.
Specifying configuration variables template in Microservices Runtime
The following command can be used to supply the configuration variables template to the Docker container.
docker run -d --name msrcontainer -p 5555:5555 -v /opt/data/customapp.properties:/opt/data/customapp.properties -e SAG_IS_CONFIG_PROPERTIES=/opt/data/customapp.properties -e JDBC_URL="jdbc:wm:oracle://prodhost:1521;serviceName=orcl1" store/softwareag/webmethods-microservicesruntime:10.11.0.0
Please note that, in the example above, you will need to create a customapp.properties file in your HOST machine under /opt/data directory with content below:
globalvariable.variable1.value=newTestValue
globalvariable.variable2.value={AES}4LxEGBJV9ULP3Im7L8mrMzyKlsk7mNcMZh5J5LN9h+gZemVaEDK/i1nOfIdbbWyk
globalvariable.variable2.isSecure=true
proxyserver.proxyAlias.host=DummyHost
proxyserver.proxyAlias.password={AES}Y5IgMqjfvkgbg7p5VUZztw==
proxyserver.proxyAlias.port=7777
proxyserver.proxyAlias.username=proxyProdUser
jdbc.Oracle.dbURL=$env{JDBC_URL}
jdbc.Oracle.password={AES}Z00ucoomUFviQLodMDpoJg\=\=
jdbc.Oracle.userid=testuser
settings.watt.server.threadPool=100
settings.watt.server.threadPoolMin=10
Once the container is up and running, Microservices Runtime will have the following configurations applied in the container:
- JDBC Pool with Oracle as alias, testuser as user ID, and URL is updated with the value specified in JDBC_URL environment variable
- Global Variable variable1 with value as newTestValue
- Global Variable vairable2 with value provided as encrypted value and it is configured as password
- Extended Settings for threadPool and threadPoolMin are set as 100 and 10 respectively
- Proxy Server alias with alias as proxyAlias, host as DummyHost, port as 7777
You can login to Admin UI to check if the execution and steps described above are successful in your environment.
The Proxy Servers UI will display the configuration for the Proxy server as below – http://localhost:5555/WmAdmin/#/integration/dsp/settings-network.dsp
The Global Variables UI will display the configuration for the Configuration Variables as below – http://localhost:5555/WmAdmin/#/integration/dsp/settings-global-variables.dsp
Similarly, you can check configurations created for other artifacts in their respective screens.
Note: Please note that not all configurations can be created using this approach. The list of configuration assets that can be created is specified in Documentation.
Generate configuration variables template in Microservices Runtime
Microservices Runtime’s Admin UI allows the creation of a template from a currently running Microservices Runtime.
You can use Administration => Configuration variables => Generate Configuration Variables Template from the Admin UI to create a sample configuration variables template. Documentation provides more details on this action.
Conclusion
This article described a way to configure Microservices Runtime in a container. By doing this, you can reuse your Docker image of a Microservices Runtime across multiple stages in the development life cycle.
This article is part of the TECHniques newsletter blog - technical tips and tricks for the Software AG community. Subscribe to receive our quarterly updates or read the latest issue.