We have 2 helm-charts:
helm-chart-A which deploys:
A-config-map
A-deployment
A-secret
helm-chart-B which deploys:
B-config-map
B-statefulset
B-secret
Is it possible to create an empty super hart which include the above as dependencies and deploy them?
e.g
helm-chart-C:
Chart.yaml:
dependencies:
helm-chart-A
helm-chart-B
--> Output:
Deploy helm-chart-A and helm-chart-B
In case yes, is it possible to specify as well the "helm.sh/hook-weight"? e.g. helm-chart-B has to be deployed before A
I use an example 2 charts but we have 7/8 charts that we want to deploy with an "helm super chart"
You can create a new chart C with two subcharts A and B, or just add them as dependencies, but you cannot easly control the execution order between the two charts (deploying all resources from A before B), you will have something like:
A-Namespace
B-Namespace
A-StatefulSet
B-ReplicaSet
A-Service
B-Service
To force helm to deploy the resources (not the charts) in some order, you can use helm hooks weights.
yes. Exactly the way you said:
helm-chart-C:
Chart.yaml:
dependencies:
helm-chart-A
helm-chart-B
as for ordering. Other than the hack of using helm hook's. There is none. Your charts shouldn't need to care about each other. Else they should be the same chart
Related
I am trying to create a helm based operator and for most part, I've got it working. However I need to make sure that the subcharts are installed before the operator is trying to create resources from those subcharts. For e.g I have mongodb community-operator helm chart as a subchart. However, when I deploy the operator i get the below error
failed to install release: unable to build kubernetes objects from release manifest: resource mapping not found for name: "test-mongodb" namespace: "default" from "": no matches for kind "MongoDBCommunity" in version "mongodbcommunity.mongodb.com/v1"
ensure CRDs are installed first.
Looks like its trying to create the mongodb instance before actually installing the operator and crds. How can I force it to first install the subcharts and then try to create mongodb instance.
inside the chart.yaml you can use the condition & tag
dependencies:
- name: subchart
version: 0.0.1
repository: https://chart.github.io/helm-charts
condition: subchart.enabled
so if the chart name as subchart is not installed already in cluster it will throw the error.
Official doc : https://helm.sh/docs/chart_best_practices/dependencies/
if you have multiple sub charts as dependencies you can also go with the tags
I have a Helm Umbrella Chart that I'm trying to write which has dependencies on 2 charts (for simplicity's sake). Chart A and Chart B. Both Chart A and Chart B have defined dependencies on Chart C. When I'm writing the Umbrella chart I specify a dependency on Chart A and B. When I try to install my Umbrella chart I get an error:
Error: INSTALLATION FAILED: serviceaccounts "chart-c" already exists
My guess is this is happening because both Chart A and Chart B are trying to install the Chart C app. How do I manage these dependencies in my Umbrella Chart?
I think you can do that with alias.
Example: In the dependencies section of the Chart.yaml file.
dependencies:
- name: mongodb
version: 12.1.2
repository: https://charts.bitnami.com/bitnami
alias: mongodb
condition: mongodb.enabled
- name: mongodb
version: 12.1.2
repository: https://charts.bitnami.com/bitnami
alias: mongodb-tracing
condition: mongodb-tracing.enabled
You can read more about alias here
I have a Helm Chart that looks like this:
apiVersion: v1
name: my-app
version: 1.0-123.4b3k32
I am trying to use helm template (or lint, it doesn't matter, they both throw the same error). With helm2 this wasn't a problem, but with helm3, it is complaining that
Error: validation: chart.metadata.version "1.0-304.0770996" is invalid
Now when executing helm template, I want to override this value using
helm template --set chart.metadata.version='0.0.0'
but I keep getting the same error, what am I doing wrong here?
Changing it in the Chart itself is not an option. I tested by changing it manually to 0.0.0 to see if it works and it does. Setting it to 0.0.0 during templating would be fine for me.
The Chart.yaml version: field is specified to be a semantic version; quoting the Helm documentation, "non-SemVer names are explicitly disallowed by the system." SerVer's rule 2 is:
A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers....
So changing the chart version to 1.0.0-456.a1b2c3d might resolve this problem. (SerVer rule 9 allows the -456... suffix to indicate a pre-release version but all of its examples have three-part versions before the hyphen.)
There is no way to override these Chart.yaml values with helm install or related commands. In particular helm install --set provides overrides to the values.yaml file, what template code sees as .Values.
I am trying to add a rabbitmq service using a bitnami helm chart. the chart contains one dependent helm chart which is called common.
The whole application itself is deployed using a parent helm chart and each service has its own separate helm chart.
the Helm chart structure looks like this-
\myapp
\charts
\service1
\service2
\service3
\messaging
\charts
\common
\templates
\chart.yml
\values.yml
When i ran "helm dependency update" from the 'messaging' dir, it downloaded a common-1.x.x.tgz file. i extracted the contents and placed it in the \messaging\charts\common folder
the original messaging\templates\chart.yml (rabbitmq helm chart) contained the following entry
dependencies:
- name: common
repository: https://charts.bitnami.com/bitnami
tags:
- bitnami-common
version: 1.x.x
because i cannot download during the "Helm install" execution i had to download the dependent helm charts beforehand and save them as a local dependency. After downloading the common.tgz file, i extracted the contents and updated the dependencies in the messaging\templates\chart.yml as follows
dependencies:
- name: common
repository: 'file://charts/messaging/charts/common'
tags:
- bitnami-common
version: 1.x.x
If i do "helm install messaging ." from \myapp\charts\messaging directory, the service gets deployed without any error. But when the application's parent helm chart is deployed i always get this error
"Error: found in Chart.yaml, but missing in charts/ directory: messaging"
Can someone please point out the mistake in the configuration? I moved around the contents of the common folder around multiple location, had them as tgz file, updated the repository path relative to the messaging directory instead of parent helm chart location, but in all cases, the installation of the messaging service fails with the above error
You don't need to unpack the charts/*.tgz file. If they're in that directory (and still packed up) then Helm will use them to run the deployment. Helm won't contact the external chart repository on its own, only when you run the helm dependency commands.
After you run helm dep up your filesystem layout should look like
myapp
\-- charts
\-- messaging
+-- charts
| \-- rabbitmq-8.15.3.tgz
|-- templates
| +-- deployment.yaml
| \-- service.yaml
+-- Chart.yaml
\-- values.yaml
You're ready to go in this state. Don't unpack anything.
If you need to copy this setup across a network boundary, include the charts/*.tgz files when you do it. It doesn't matter that Chart.yaml or requirements.yaml references an Internet location; helm install will only use those local archives.
I had a similar issue and it was because a developer had placed the Charts and templates etc in the charts directory. I kept getting errors saying it couldn't find directories so moved all the charts into a helm-charts directory instead as the charts directory is managed by Helm. When I updated the repository listing to pull from the new directory, my issue was resolved. I got the idea from this issue's comments and it worked. https://github.com/helm/helm/issues/2887
The use case is as follows:
overall-concern/
charts/
cloudformation-chart/
kubernetes-chart/
shared-library/
Both the Cloudformation and Kubernetes charts rely on the shared library. If I specify
it as a dependency in those charts, however, I need to do helm dependency update and
it will be copied into those charts' charts/ subdirectory and a Chart.lock file will
be generated. That seems unnecessary.
On the other hand, if I symlink the chart:
overall-concern/
cloudformation-chart/
charts/
shared-library -> ../../shared-library
It works, but I receive a warning when running helm template that there are symlinks
in the path, leading me to think that this is not intended or is otherwise deprecated:
walk.go:74: found symbolic link in path: ... (paths elided) ...
Is there a blessed solution that will let me use a local chart without treating it as
a formal "dependency" in Helm 3?