Skip to content

Latest commit

 

History

History
103 lines (74 loc) · 5.35 KB

README.adoc

File metadata and controls

103 lines (74 loc) · 5.35 KB
Raw

Configuration Template

This example demonstrates the usage of the Configuration Template pattern. As described in detail in our book, this pattern is helpful for dynamically creating configuration during application startup by processing templates on the fly. Again, please refer to the book for the pros and cons of this approach.

Wildfly configured with templates and ConfigMaps

In this example, we will configure a Wildfly application server. As you may know, Wildfly uses an XML syntax for its configuration, which can be lengthy. Therefore, we will use a configuration template to configure only a tiny part differently for different environments. In our example, we use a standalone.xml template filled with values from a ConfigMap before the server starts.

The only data we want to adopt in this simple example is the log format. The format is adjusted so that each log line is prefixed with the environment it is running in (prod or dev). We parameterize standalone.xml for this with a single line:

<formatter name="COLOR-PATTERN">
   <pattern-formatter pattern="{{ (datasource "config").logFormat }}"/>
</formatter>

We use gomplate as a template processor with the notion of "datasources". For template syntax, please refer to Go Templates.

As described in the pattern’s description, a Kubernetes init container containing the templates is used for processing the templates. The Docker build files for this container are in init-container.

Please check its README on how to re-create the image, but we have already pushed it to Docker Hub for your convenience.

Running the example

The values to fill into the template come from a ConfigMap, which needs to be created first.

We create two ConfigMaps named dev-params and prod-params from the directories dev and prod. Both contain sample configurations in a file "config.yml" that can be used in the standalone.xml template.

To create the ConfigMaps that we use (assuming the current working directory is the directory of this README) for both a development and a production environment:

kubectl create configmap dev-params --from-file=dev
kubectl create configmap prod-params --from-file=prod

Then start the service and deployment as specified in wildfly.yml:

kubectl apply -f https://k8spatterns.io/ConfigurationTemplate/wildfly.yml

To check that the configuration was correctly processed, examine the logs:

kubectl logs -f $(kubectl get pod -l app=wildfly -o name) server
....
DEVELOPMENT: 14:52:14,049 INFO  [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052: Starting JBossWS 6.1.0.Final (Apache CXF 3.5.2.jbossorg-3)
DEVELOPMENT: 14:52:14,094 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
DEVELOPMENT: 14:52:14,096 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 27.0.0.Final (Wild
DEVELOPMENT: 14:52:14,097 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
DEVELOPMENT: 14:52:14,098 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
....

Note the added prefix DEVELOPMENT, which comes from the ConfigMap.

Now let’s switch over to the prod-params by patching the deployment:

kubectl patch deployment wildfly \
  -p '{"spec": {"template": {"spec": {"volumes": [{"name": "wildfly-params", "configMap": {"name": "prod-params"}}]}}}}'

And then recheck the log with

kubectl logs -f $(kubectl get pod -l app=wildfly -o name) server
....
PRODUCTION: 14:49:04,729 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) WFLYDS0013: Started FileSystemDeploymentService for directory /opt/jboss/wildfly/standalone/deployments
PRODUCTION: 14:49:04,745 INFO  [org.jboss.ws.common.management] (MSC service thread 1-3) JBWS022052: Starting JBossWS 6.1.0.Final (Apache CXF 3.5.2.jbossorg-3)
PRODUCTION: 14:49:04,785 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
PRODUCTION: 14:49:04,786 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 27.0.0.Final (WildFly Core 19.0.0.Final) started in 2068ms - Started 290 of 563 services (357 services are lazy, passive or on-demand) - Server configuration file in use: standalone.xml
PRODUCTION: 14:49:04,787 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
PRODUCTION: 14:49:04,788 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
....

That concludes our demo on how to easily parameterize large configuration files with values you store in a ConfigMap.

Please also look at the comments within wildfly.yml, which explain this example in more detail.