How to refer to a variable in an environment/region specific Kustomization.yml with a Dockerfile

51 views Asked by At

I currently have a need to customize a Dockerfile script so that I can copy only the environment and region specific certificates to an EKS container. Currently, my application is copying all certificates from all environments to each EKS container as show below:
ADD --chown=*******:******* certs/ /opt/certs/
My current strategy is to remove the hardcoded directory and create a new environment variable in each region specific Kustomization file that our Dockerfile can refer to.

Is it possible for our Dockerfile to refer to an external file in order to assign a value to a Docker variable/ARG/ENV?

I've tried referring to the Kustomization.yml directly in the Dockerfile but it, of course, does not recognize the variables as it contains no reference to the Customization file.

1

There are 1 answers

0
Gaël J On

Dockerfile is used at "build" time to create container images.

Kustomize is used at "deploy" time to generate Kubernetes manifests.

They work at two different stages.

Once you've built an image with some files in it, they'll always be in the image. You can optionally build a new image from the previous that remove some files but technically this won't make the image smaller nor completely remove the files because container images are built with layers and the "remove file" would only be a layer on top of the previous image.

Back to your question, what you could do is to set a environment variable via Kustomize which will be set on the container at "runtime" and the container could do something using this variable (the process that runs in the image could to be precise). But that's not really intended to remove files (it would be surprising for a process to remove such files when starting), it could be used to choose which files to use though.

What you should rather do is to not package the certificates in the image but provide them at runtime via a volume mount. This will have the benefit that you can update certificates without rebuilding the image. Think of the certificates as configuration: you wouldn't harcode configuration in the image. This volume mount can be configured via Kustomize and a ConfigMap + configmapGenerator for instance (there's many other ways).