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?
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
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
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
I have added mysql in requirements.yaml. Helm dependency downloads the mysql chart
helm dependency update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "nginx" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 1 charts
Downloading mysql from repo <our private repository>
Deleting outdated charts
But when I do helm install my_app_chart ../my_app_chart
It gives error
Error: found in Chart.yaml, but missing in charts/ directory: mysql
You don't have to add it to the control version system, you just download them again if for some reason you have lost them (for example when you clone the repository). To do this, execute the command:
helm dependency update
The above command will download the dependencies you've defined in the requirements.yaml file or dependencies entry in Chart.yaml to the charts folder. This way, requirements are updated and you'll have the correct dependencies without worrying about if you updated them also in the control version system.
I updated .helmignore
# Patterns to ignore when building packages.
# This supports shell glob matching, relative path matching, and
# negation (prefixed with !). Only one pattern per line.
.DS_Store
# Common VCS dirs
.git/
.gitignore
.bzr/
.bzrignore
.hg/
.hgignore
.svn/
# Common backup files
*.swp
*.bak
*.tmp
*~
# Various IDEs
.project
.idea/
*.tmproj
.vscode/
charts/
It contained charts/ I removed the entry and it worked
# Patterns to ignore when building packages.
# This supports shell glob matching, relative path matching, and
# negation (prefixed with !). Only one pattern per line.
.DS_Store
# Common VCS dirs
.git/
.gitignore
.bzr/
.bzrignore
.hg/
.hgignore
.svn/
# Common backup files
*.swp
*.bak
*.tmp
*~
# Various IDEs
.project
.idea/
*.tmproj
.vscode/
I have encountred the same error message when I first started learning how to use libcharts, I used chart.yaml to specify the dependency of the libchart like so:
chart.yaml
...
dependencies:
- name: mylibchart
version: 0.1.0
repository: file://path/to/libchart
and in that libchart chart.yaml data was like this:
apiVersion: v2
name: lib <-- this was causing the error to occur (should be mylibchart instead)
description: A Helm chart for Kubernetes
type: library
version: 0.1.0
appVersion: "1.16.0"
so as you can see the name specified in the dependencies has to be the same name of the chart/libchart.