Container Environment Variables

Hi folks,

Can I please check, should The key/vaue pairs in a RuntimeEnvironment file passed to gravity install with —config get set as environment variables in all of the containers of my deployment?

When I exec in using kubectl exec bash I am not seeing them set.

I am hoping to use this strategy to pass in bare metal deployment configuration.

If container env setting is supposed to happen via a RuntimeEnvironment it must be a problem at my side, but the docs aren’t 100% conclusive that this is the intention. The docs mention the master ‘planet’ container has these environment variables, so I am not sure if my deployment containers will also have them set.

I do hope that this is the intention, as I can’t see another route to getting install-specific config into the deployment.

This is the install command that I am using:

./gravity install --advertise-addr=$WAN_IP --token=abcdef --config=envars.yaml

And this is the contents of envars.yaml:

kind: RuntimeEnvironment
version: v1
spec:
  data:
    SITE_CODE: "xxx"
    API_KEY: "yyy"
    MQ_PASSWORD: "zzz"

I can’t see any of $SITE_CODE, $API_KEY or $MQ_PASSWORD in my containers.

All help appreciated. Thanks in advance!

David

Hi @dznicol

The RuntimeEnvironment resource set’s environment variable within the planet container only (the container we use to host kubernetes processes). This container isn’t a pod and doesn’t have an effect on software running within kubernetes, it’s a container we use to ship a common platform to any of the linux OSes we support. The common use case for this, is setting HTTP/HTTPS proxy env variables, so docker running inside planet can reach out to approved docker registries, where the outbound network access is restricted to a HTTP(S) proxy.

The env variables within pods, are controlled by kubernetes, and are set as per the PodSpec provided to kubernetes. So instead of passing a kind: RuntimeEnvironment resource to the installer, you can pass a regular kubernetes ConfigMap or Secret to the installer, to have it loaded into the API server during install. And the resources shipped with the application can be configured to refer to the object created by the user.

This also doesn’t necessarily have to happen at install time, the ConfigMap/Secret can be created after the installation, with the Deployments just waiting until the ConfigMap or Secret they refer to are created. The post-install screen if using the UI can also be used to create the object if using UI based installations.

Here’s the kubernetes Docs on how to refer to a configmap from a PodSpec just in case you’re not aware: https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#define-container-environment-variables-using-configmap-data

Hi @knisbet,

Thanks very much for the information. Do I need to wrap the ConfigMap file passed in with --config in some other type? When I try to pass in the ConfigMap to the cmd line installer I get:

[ERROR]: unsupported resource "ConfigMap", supported are: [cluster_auth_preference github auth_connector user token logforwarder smtp alert alerttarget tlskeypair authgateway runtimeenvironment clusterconfiguration role oidc saml trusted_cluster endpoints]

I see that Gravity 7 allows for --values and --set=x=y. Do you think that I need to be using Gravity 7? I am conscious 7 is beta, our release date is end April. Is it safe to use?

Initial tests for me are that Gravity 7 is building much bigger tar files (2.5GB versus 1.4GB in Gravity 6), and generating this error … so I am not sure whether to move to Gravity 7 or try to get Gravity 6 with ConfigMap injected in:

The following checks failed:
	[×] failed to validate etcd disk requirements (rpc error: code = Unknown desc = failed to execute fio test: )

Thanks for your help.

David

If you’re using helm to install you’re app, you can use --values and --set to pass parameters to helm. https://gravitational.com/gravity/docs/pack/#customizing-helm-values

Values/Set flags are meant to be specific to helm though, the --config option is documented as working with arbitrary resources. Based on the error you’re receiving, it looks like it’s inadvertently only allowing gravity resources. Myself or someone else on the gravity team will need to take a look at whether that’s broken or not.

The gravity 7 builds being larger, are due to gravity 7 including openebs (https://openebs.io/).

Whether gravity 7 is safe to use really depends on your risk tolerance, so it’s difficult to advise on. The way I would look at it is, if Gravity 6.1 (the latest LTS release) has all the functionality that you need, I would probably stick with that as a conservative choice, and let other customers be the first to adopt gravity 7 and discover issues. On the other hand, if there is something driving you towards gravity 7, there is functionality you need, and you don’t mind upgrading frequently on non-LTS releases, then it might be within you’re interest to adopt gravity 7.

Hi @knisbet,

I am using a helm Chart for our deployment. Using --values or --set would be good, however the docs say this feature is Gravity v7 onwards, and in testing gravity 6, it rejected --values/–set params.

Gravity 6 config docs do suggest that ConfigMap isn’t one of the allowed types (https://gravitational.com/gravity/docs/config/).

Is there any other strategies for getting install-specific config into a Gravity 6 deployment? I am failing to get Gravity 7 fio checks to pass, so am planning to stick with 6.

I am happy to try other mechanisms for getting sensitive data into our install.

David