I am installing postgres as a dependency in my helm chart, and need to retrieve the connection details.
Postgres connection URIs in kubernetes are of the form:
postgres://username:password#servicename.namespace.svc.cluster.local:port/dbname
The username, password, namespace, port, and dbname are all easily accessible through .Values.postgresql...., and .Release.Namespace, but the service name is initialized using the subchart template common.names.fullname.
Accessing subchart templates is surprisingly not a thing, and probably wouldn't work anyways due to context changes.
What's a simple way to configure my application to access the database?
I'm usually content to observe that the subchart obeys the typical Helm convention of naming its objects {{ .Release.Name }}-{{ .Chart.Name }}. If the subchart uses that convention, and I'm getting the database from a subchart named postgresql, then I can hard-code that value in my template code:
- name: PGHOST
value: '{{ .Release.Name }}-postgresql'
My experience has generally been that the Bitnami charts (and the older stable charts) have been pretty good about using semantic versioning, so if this name changes then the major version of the chart will change.
Related
We have two networks that suppose to use the sane name ClientApp but different values in the values.yaml file. The network_a works when on a particular network.
For example a user with a particular laptop with network_a can access the application url and can access network-a.co.uk URL. but the issue is that another type of laptop require network_b and we do not want to overrides network_a in the values.yaml file but define also the network_b in order to access application in network-b.co.uk.
deployment.yaml
env:
- name: ClientApp
value: {{ .Values.env.network_a }}
// how to define network_b on this deployment template
values.yaml
env:
network_a: https://network-a.co.uk
network_b: https://network-b.co.uk
Since we can not call the same variables name in the deployment.yaml, how would I put the network_b to use the values from the deployment using the same name ClientApp.
I'm deploying a spring cloud data flow cluster on kubernetes with helm and the chart from bitnami. This works fine.
Now I need an additional template to add a route. Is there a way to somehow add this or inherit from the bitnami chart and extend it? Of course I'd like to reuse all of the variables which are already defined for the spring cloud data flow deployment.
That chart has a specific extension point for doing things like this. The list of "Common parameters" in the linked documentation includes a line
Name: extraDeploy; Description: Array of extra objects to deploy with the release; Value: []
The implementation calls through to a helper in the Bitnami Common Library Chart that calls the Helm tpl function on the value, serializing it to YAML first if it's not a string, so you can use Helm templating within that value.
So specifically for the Bitnami charts, you can include an extra object in your values.yaml file:
extraDeploy:
- apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: '{{ include "common.names.fullname" . }}'
...
As a specific syntactic note, the value of extraDeploy is a list of either strings or dictionaries, but any templating is rendered after the YAML is parsed; this is different from the normal Helm template flow. In the example above I've included a YAML object, but then quoted a string value that begins with a {{ ... }} template, lest it otherwise be parsed as a YAML mapping. You could also force the whole thing to be a string, though it might be harder to work with in an IDE.
extraDeploy:
- |-
metadata:
name: {{ include "common.names.fullname" . }}
You can just create the YAML template file in the templates folder and it will get deployed with the chart.
You can also edit the existing YAML template accordingly and extend it no need to inherit or much things.
For example, if you are looking forward to adding the ingress into your chart, add ingress template and respective values block in values.yaml file
You can add this whole YAML template in folder : https://github.com/helm/charts/blob/master/stable/ghost/templates/ingress.yaml
and specific values.yaml block for ingress.
Or for example your chart dont have any deployment and you want to add deployment you can write your own template or use form internet.
Deployment : https://github.com/helm/charts/tree/master/stable/ghost/templates
there is deployment.yaml file template and you can get specific variables that the template uses into values.yaml and you have extended the chart successfully.
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 using helm version 2.14.1. I have created helm charts for an application that will be deployed by users to test their code on kubernetes cluster. I want to add labels for username values, so I can retrieve deployments by users (deployments by user labels). Is there a way to include system username in helm charts just like we do in Java with System.getProperty("user.name"). My helm template is like this:
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "common.fullname" . }}--{{ Release.name }}
labels:
application: {{ include "common.name" . }}
branch: "{{ Release.name }}"
username: "{{ System.user.name }}" # need to fetch the logged in user from system here
spec:
...
Is there a standard way to achieve this or is there anyway I can allow users to input there usernames from command line while using helm install or helm template commands?
EDIT:
Although, the --set works for me in setting the values for my chart, I also need to set the same value in the dependencies. Something like this:
values.yaml
username: ""
dependency1:
username: {{ .Values.username }}
dependency2:
username: {{ .Values.username }}
...
Of course the above implementation doesn't work. I need to reference the set value in the dependencies as well
This is a community wiki answer based on the comments and posted for better visibility. Feel free to expand it.
You can use the helm template command with a --set option:
--set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)
--set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2)
--set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)
The --set parameters have the highest precedence among other methods of passing values into the charts. It means that by default values come from the values.yaml which can be overridden by a parent chart's values.yaml, which can in turn be overridden by a user-supplied values file, which can in turn be overridden by --set parameters.
You can check more details and examples in the official docs.
I have resolved this. Thanks for help #MichaelAlbers and #WytrzymałyWiktor. So the solution is as below.
helm template path/to/chart --set global.username=username
And then in all the templates refer to this value as {{ .Values.global.username }}. This works for any dependency chart as well.
I have a service for which a helm chart has been generated. This helm chart spins off zookeeper and mysql containers with which the service communicates.
I now want to create a helm chart that spins off a platform of services of which the above service is one. When i attempt to do this, I use tags to disable the above service's dependencies that are listed in the helm chart, like so:
tags:
service-zookeeper: false
service-mysql: false
Now, i have a few init containers(liquibase) that populate the mysql instances created via dependencies whenever the service is deployed. I need to pass a separate, stand alone mysql container as the instance of mysql that this init container needs to populate. A similar chroots job for zookeeper exists.
The problem I need help tackling is that I can't seem to find a way to pass the separate mysql container as the container that needs to be populated by the first service's liquibase init-container. Is there any way to do so? Any help/insights are appreciated.
You just need the MySQL Service's hostname and credentials for this.
Remember that the Helm YAML templates can use everything in the Go text/template language. That includes conditionals {{ if ... }}...{{ else }}...{{ end }}, among other control structures, plus most of the support functions in the Sprig library. This can become verbose, but neatly solves this class of problem.
For the host name, one approach is to assert a single service name, whether installed by your chart itself or the wrapper chart. (If the top-level chart installs MySQL, and also installs your service, they will have the same Helm release name and the same generated hostname, independently of whether MySQL is a direct dependency of your chart.)
- name: MYSQL_HOST
value: {{ printf "%s-mysql.%s.svc.cluster.local" .Release.Name .Release.Namespace | quote }}
Another is to pass it in the values.yaml configuration, optionally. The Sprig default function is useful here.
- name: MYSQL_HOST
value: {{ .Values.mysqlHostname | default (printf "%s-mysql.%s.svc.cluster.local" .Release.Name .Release.Namespace) | quote }}
You can use a similar approach to either find the Secret the MySQL installation saves its passwords in or reconstruct it from configuration.