This example demonstrates the usage of the Configuration Template pattern. As described in detail in our Kubernetes Book this pattern is useful for dynamically creating configuration during application startup by processing templates on the fly. Please check out the pros and cons of this approach from the book.
|
Important
|
The configuration book chapters are in initial review and will be available soon in an early draft. Please stand by … |
In this example we will configure a Wildfly application server. As you probably know, Wildlfy uses an XML syntax for its configuration which can be quite lengthy. We will use a configuration template where we want to configure only a small part differently for different environments. In our example we use a standalone.xml template which is filled with values from a ConfigMap before the server starts.
The only datum we are want to adapt in this simple example is the log format. The format is adapted so that each log line is prefixed with the environment it is running (prod or dev). We parameterise standalone.xml for this with the single line:
<formatter name="COLOR-PATTERN">
<pattern-formatter pattern="{{ (datasource "config").logFormat }}"/>
</formatter>As a template processor gomplate is used which has the notion of "datasources". The template syntax please refer to Go Templates. Actually its an slightly adapted gomplate so that it fits our use case better. You found the changed version in the rhuss/gomplate repo.
As described in the pattern’s description an Kubernertes init-container is used for processing the templates. The docker build files for this container are in init-container.
Please check its README how to re-create the image, but we already pushed it to Docker hub for your convenience.
The value to fill into the template come from config map which needs to be created first.
The config map nused in the example has the name wildfly-parameters and contains a key config.yml. The directories dev and prod contains both sample configurations as it can be used in the standalone.xml template. You would create a different config-map with the name wildfly-parameters for each environment.
To create the configuration map use (assuming the current working directory is the directory of this README):
kubectl create configmap wildfly-parameters --from-file=devThen start the service and deployment as specified in wildfly.yml:
kubectl create -f wildfly.ymlIn order to check that the configuration was processed properly check now the logs:
kubectl logs -f $(kubectl get pod -o name | grep wildfly) server
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /opt/jboss/wildfly
JAVA: /usr/lib/jvm/java/bin/java
JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
=========================================================================
05:48:31,124 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final
05:48:31,294 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
05:48:31,408 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) starting
05:48:32,546 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
05:48:32,566 INFO [org.xnio] (MSC service thread 1-3) XNIO version 3.4.0.Final
05:48:32,580 INFO [org.xnio.nio] (MSC service thread 1-3) XNIO NIO Implementation Version 3.4.0.Final
DEVELOPMENT: 05:48:32,627 INFO [org.jboss.remoting] (MSC service thread 1-3) JBoss Remoting version 4.0.21.Final
DEVELOPMENT: 05:48:32,713 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 38) WFLYCLINF0001: Activating Infinispan subsystem.
.....Note the added prefix DEVELOPMENT which comes from the config map.
If you want to change the configuration, replace the config-map and restart the pod (you can directly c&p the first five lines):
kubectl delete cm wildfly-parameters
kubectl create configmap wildfly-parameters --from-file=prod
kubectl delete $(kubectl get pod -o name | grep wildfly)
sleep 15
kubectl logs -f $(kubectl get pod -o name | grep wildfly) server
configmap "wildfly-parameters" deleted
configmap "wildfly-parameters" created
pod "wildfly-cm-template-3436327307-j7db6" deleted
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /opt/jboss/wildfly
JAVA: /usr/lib/jvm/java/bin/java
JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
=========================================================================
07:19:18,894 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final
07:19:19,051 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
07:19:19,121 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0049: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) starting
07:19:20,292 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
07:19:20,311 INFO [org.xnio] (MSC service thread 1-4) XNIO version 3.4.0.Final
07:19:20,317 INFO [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.4.0.Final
PRODUCTION: 07:19:20,356 INFO [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 4.0.21.Final
PRODUCTION: 07:19:20,431 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 38) WFLYCLINF0001: Activating Infinispan subsystem.
PRODUCTION: 07:19:20,446 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 37) WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors
.....Please also have a look to the comments within wildfly.yml which explain this examples in even more details.