Idiomatic way for environment specific application configuration


In my current setup for creating an installable using gravity, I take

  • app specific config values e.g. database credentials/external service urls and create the application configmaps and helm chart value files.
  • create the gravity tar file with these config files in them
  • Install the gravity tar on a bare metal machine without any other input.

The downside is that I have to know the config values before I create the tar file. I would like to move to a more conventional approach where I have a gravity tar file and someone can customize it later with environment variables for e.g.

What is the best practice for doing this?

My current idea is to create the tar without any config. Then on the nodes where the cluster has to be installed,

  • untar the gravity file
  • run a Python script to take the config values from the end user and create configmaps/helm chart values in a folder CONFIG_FOLDER, export that as a environment variable
  • run the gravity installation process where my file (specified in the gravity app.yaml and hence will be run on installation) will pick them up from the CONFIG_FOLDER environment variable and install them

Is there an idiomatic way of doing this in Gravity?

Is there any way of passing kubernetes config files generated after the fact and generated outside the gravity tar file to the installation script inside the tar file?

I’d very much appreciate any guidance as I’m stuck and I have a deliverable soon.

I see the --config option. but it seems to be just one file of key value pairs? I currently have a process that takes user input and generates a directory of helm chart value files and configmaps. Is there any way I can pass this folder to my install script within the gravity installation process?

The --config command line option allows one to configure specified Kubernetes/Gravity resources during installation but it does not support templating.
The master (7.x) version has --set / --values mimicking helm’s which can be used with gravity install. These options might also be ported to 6.x given sufficient interest.

@RAbraham, we are extremely new to gravity and have a very similar use case.

What we are working on doing is having Gravity provision a single “install wizard” pod that we grant cluster management privileges to. That pod has a simple webapp for gathering and verifying information (like database access info, ingress SSL cert, etc). Once all of the information has been gathered, it creates a series of ConfigMaps and Secrets and then makes a series of helm install calls to deploy the rest of the platform.

I think it is pretty similar to, but we were struggling to get that to work and wanted the initial deploy to expose our wizard on port 80/443.

Not sure if it is idiomatic, or what the folks at Gravitational would recommend, but so far our prototyping is working very well.