content_image/848287.jpg
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: 

• 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. 

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. 

<img src='content_image/848287.jpg'>

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‐ 

