standalone.xml ). There are many tools like  Tiller  (Ruby) or  Gomplate (Go) for pro‐ cessing templates during application initialization. Figure 21-1 is a  Configuration Template  example filled with data coming from environment variables or a mounted volume, possibly backed by a ConfigMap. Before the application is started, the fully processed configuration file is put into a location where it can be directly used like any other configuration file. There are two techniques for how such live processing can happen during runtime: For Kubernetes, the  Init Container  approach is the most appealing because we can use ConfigMaps directly for the template parameters. The diagram in Figure 21-1 illus‐ trates how this pattern works. The application’s Pod definition consists of at least two containers: one init container for the template processing and one for the application container. The init container contains not only the template processor, but also the configuration templates them‐ 166  |  Chapter 21: Configuration Template Figure 21-1. Configuration template • We can add the template processor as part of the  ENTRYPOINT  to a Dockerfile so the template processing becomes directly part of the container image. The entry point here is typically a script that first performs the template processing and then starts the application. The parameters for the template come from environ‐ ment variables. • With Kubernetes, a better way to perform initialization is with an  Init Container of a Pod in which the template processor runs and creates the configuration for the application containers in the Pod.  Init Containers  are described in detail in Chapter 14.