I installed mongodb chart from bitnami as follows
helm install mongodb bitnami/mongodb
which created this file ./charts/mongodb-10.15.2.tgz
What I do not understand and what I cant find is how to link Secrets to these kind of subcharts. I am aware that values.yaml can override child subcharts. What really confuses me is that this downloaded subchart is just encoded file and I have absolutely no idea how to bend it in terms of deployment/service...
Therefore my question is, how to supply this subchart (of which I dont know anything) with Secrets like dbpassword, dbroot... ? (I hope that the secrets are not supplied via values.yaml override)
When you have sub chart, you map them probably as a dependency (look at the condition carefully, that will match with your values.yaml of the same parent chart.), and here is how you pass the sub-charts values.
Now, I believe you are using this mongodb chart, and in case you want to pass the passwords, you might want to create a k8s secret object and pass the name here.
Now let's say,
There is a chart A and MongoDB is a sub chart of the chart A,
if you add MongoDB as a dependency like this, you can put the configuration/values of chart MongoDB, in A values, just like this.
Now, for the secrets, there is mentioned in the values.yaml of MongoDB, you can create a custom secret and pass the name of the same there, if still not satisfied, you might want to pass the env vars directly to the MongoDB charts values.
and most importantly, when you defining any chart as dependency or sub chart, you would know which chart it is and what are the values it takes,
you can nest the same values in the parent chart.
When you have more time you can spend some here :)
Related
I have a helm chart which creates namespace and bunch of other Kubernetes resources. I want make sure that user will not be able to change the namespace name once created. I was trying to use JSON schema validation but it cannot compare old and new value. What would be right way to do validate if existing value is changed in the helm values for the existing helm release.
I have helm charts created for a microservice that I have built and everything is working as expected. Now, I have created a new k8s namespace and I want to try to deploy the same helm charts as my old namespace. Although, I have just one value that I need it different while everything else remain the same.
Do I have to create another values.yaml for the new namespace and copy everything over and update the one field I want updated ? Or is there any other way ? I do not want to use the --set method of passing updates to the command line.
David suggested the right way. You can use different values.yaml where you can specify the namespace you want to deploy the chart:
$ helm install -f another-namespace-values.yaml <my-release> .
It's also entirely possible to launch helm chart with multiple values.
For more reading please check values section of helm docs.
I'm using the mongodb helm chart and the mongo-express one. mongodb generates the name depending on my release name, so it is dynamic. The mongodb service name will be something like my-release-mongodb.
mongo-express requires to pass mongodbServer - the location at which the mongodb can be reached. How can I provide this value to mongo-express if it is generated and can change depending on the release name?
Helm doesn't directly have this ability. (See also helm - programmatically override subchart values.yaml.) It has a couple of ways to propagate configured values from a subchart to a parent but not to use computed values, or to send these values to a sibling chart.
In the particular case of Services created by a subchart, I've generally considered the Service name as part of the chart's "API": you know the Service will be named {{ .Release.Name }}-mongodb and you just have to hard-code that in the consuming chart.
If you're launching this under a single "umbrella" chart, this is a little more straightforward. Both parts have the same release name, so you can construct the service name the same way. (Umbrella charts have other limitations – if you have multiple services that each should have an independent MongoDB installation, Helm will only deploy the database once for the whole umbrella chart – but you can still hit this same problem making HTTP calls between microservices.)
If they're totally separate installations, you may need to pick the release name yourself and pass it in as a value.
helm install thedb ./mongodb
helm install theapp ./mongo-express --set serviceName=thedb-mongodb
This also a place where a still higher-level tool like Helmfile or Helmsman can come in handy, since that would let you specify these parameters in a fixed file.
I am new to the Kubernetes and especially using helm. I installed the charts and it works fine with default values. I want to the add smtp server setting in the values.yml file for the chart. I am confused on how to inject the values while installing the chart. This is the chart that I am using https://github.com/helm/charts/tree/master/stable/prometheus-operator.
After installing the helm chart with default values I see that there is a deployment called prometheus-operator-grafana which has values GF_SECURITY_ADMIN_USER and GF_SECURITY_ADMIN_PASSWORD but I am not sure where these values are coming from.
Help with how these values work and how to inject them would be appreciated.
The interaction between parent and child chart values is summarize very well in this SO answer: helm overriding Chart and Values yaml from a base template chart
There are two separate grafana chart mechanisms that control such a thing: adminUser and adminPassword or admin.existingSecret along with admin.userKey and admin.passwordkey
Thus, helm ... --set grafana.adminUser=ninja --set grafana.adminPassword=hunter2 will do what you want. The fine manual even says they are using grafana as a subchart, and documents that exact setting as the first value underneath the grafana.enabled setting. Feel free to file an issue with the helm chart to spend the extra characters and document the grafana.adminUser setting, too
Let's say we have to manage a database connection string for stages test, int and prod.
What are the patterns here for Kubernetes?
I would handle general configuration via ConfigMaps. Create configuration for each environment and have your pods/deployment consume the values via environment variables.
This approach allows you to decouple your configuration from your k8 object definition and gives the ability to inject the required config per environment.
For sensitive data, which might include a username and password in a connection string for example, consider using Secrets instead.
The best way in my experience is to use a higher level construct like Helm Chart. This way you manage all your manifests in platform agnostic way and make them configurable during chart install/update.
That way you can use both ConfigMaps, Secrets or env vars, and populate them from values set during install/upgrade. With helm, you would do it somewhat like this :
helm install -f values.yaml : where values yaml contains all your non-default values (ie. db password)
helm upgrade <release> --reuse-values --set image.tag=1.0.1 to say release a new version keeping all other values defined during initial install.
For non-default components like ie. development database, you can use value like devdb.enabled with a default value to false and set it to true only on dev env where you want to launch devdb pod and point your database service there (all the logic for it within manifest templates in helm chart)