Summary:
I want to be able to get config.template files in InitContainer from Container.
The existing state:
There are template configuration files, that rarely change and contains PlaceHolders, stored inside the image of the container.
When we create the container in the kubernetes there is a script stored also in the image that run and replace all the PlaceHolders with the real values and then start the service.
The desired state:
Having a Init-Container that built from generic image with generic code that need to get as arguments only the directories of the template files (as array of directories) and when it run it take all the template files from the container's image (throw volume), replace the PlaceHolders with the real value and create a final configuration files in a volume that shared with the container.
That way the Init-Container do the preparations and when it done the Container need to start immediately with the prepared configuration files.
also, the same image of the Init-Container can be used in pods with other containers.
The Problem:
The Init-Container is start first and the volume that map to the Container image and supposed to contain the config.template files is still empty when the Init-Container is running.
My Questions:
I think there is no a way to access the files from container in pod into init-containers
. The volume
that is shared between your init-container
and the container of pod is empty because the container of pod is not started until all init-containers successfully exit(with exit code 0
).
So the way I suggest you do stuff is create a configMap
with the templates
you want. Mount this configMap
inside the init-container
. And inside the init-container
do the replacement of place holder values in template
coming from configMap
and dump it into the volume
you have shared between container of pod and the init-container
of the pod.
Now this helps you change the config as you want, all you need to do is update the configMap
resource. Also the code to replace the place holder values can change and all you need to do is build the image for init-container
. Also this helps you keep the init-container image generic as you want.
With this de-coupling your source code container remains independent of change in the config.
Also this init-container
and configMap
gets used into other pods as you like it.