Helm Dependencies: Difference between revisions
Line 16: | Line 16: | ||
Helm does not automatically handle transitive dependencies, in the same manner as [[Maven]], for example, does: it is not possible to specify that chart "a" depends on chart "b", only specify the chart "b" "coordinates" (name, version and repository URL) and expect Helm to automatically pull "b" during the installation process. In this situation. Maven would contact the dependency's repository and pull the artifact. If that artifact had its own dependencies, specified by coordinates, Maven would recursively pull those as well, contacting as many repositories as necessary. This is known as what Maven friends refer to as "downloading the Internet". | Helm does not automatically handle transitive dependencies, in the same manner as [[Maven]], for example, does: it is not possible to specify that chart "a" depends on chart "b", only specify the chart "b" "coordinates" (name, version and repository URL) and expect Helm to automatically pull "b" during the installation process. In this situation. Maven would contact the dependency's repository and pull the artifact. If that artifact had its own dependencies, specified by coordinates, Maven would recursively pull those as well, contacting as many repositories as necessary. This is known as what Maven friends refer to as "downloading the Internet". | ||
Help does not behave like that. It expects instead a chart to '''embed all dependencies it needs, recursively'''. This decision was probably taken because the chart metadata is really small, especially when compressed. and the chart transitive dependency graphs are not large, so embedding the whole graph in an archive is feasible, which would not be in Maven's case. Indeed, for a | Help does not behave like that. It expects instead a chart to '''embed all dependencies it needs, recursively'''. This decision was probably taken because the chart metadata is really small, especially when compressed. and the chart transitive dependency graphs are not large, so embedding the whole graph in an archive is feasible, which would not be in Maven's case. Indeed, for a situation where an "a" chart depends on a "b" chart, and the "b" chart depends on a "c" chart, the structure of the "a"'s chart archive is; | ||
<syntaxhighlight lang='text'> | <syntaxhighlight lang='text'> | ||
a | a |
Revision as of 22:42, 15 December 2019
External
Internal
Overview
Revised for Helm 3
To Deplete
How Helm Dependencies Work
Helm does not automatically handle transitive dependencies, in the same manner as Maven, for example, does: it is not possible to specify that chart "a" depends on chart "b", only specify the chart "b" "coordinates" (name, version and repository URL) and expect Helm to automatically pull "b" during the installation process. In this situation. Maven would contact the dependency's repository and pull the artifact. If that artifact had its own dependencies, specified by coordinates, Maven would recursively pull those as well, contacting as many repositories as necessary. This is known as what Maven friends refer to as "downloading the Internet".
Help does not behave like that. It expects instead a chart to embed all dependencies it needs, recursively. This decision was probably taken because the chart metadata is really small, especially when compressed. and the chart transitive dependency graphs are not large, so embedding the whole graph in an archive is feasible, which would not be in Maven's case. Indeed, for a situation where an "a" chart depends on a "b" chart, and the "b" chart depends on a "c" chart, the structure of the "a"'s chart archive is;
a
├── Chart.yaml
├── charts
│ └── b
│ ├── Chart.yaml
│ ├── charts
│ │ └── c
│ │ ├── Chart.yaml
│ │ ├── templates
│ │ │ └── pod.yaml
│ │ └── values.yaml
│ ├── templates
│ │ └── pod.yaml
│ └── values.yaml
├── templates
│ └── pod.yaml
└── values.yaml
. Intermediate manual steps are required to install a chart that depends on other charts.
If we simply declare the chart "a" as dependent on chart "b" in the dependencies section of the "a"'s Chart and we attempt to install the chart "a", we get this:
Error: found in Chart.yaml, but missing in charts/ directory: b
What happens if a-1.0.0.zip is in a remote repository and does not have its dependencies in charts/?
Dependency Declaration
Dependencies are declared in Chart.yaml 'dependencies' section.
...
dependencies:
- name: # The name of the dependency
version: # The version of the dependency
repository: # Repository URL
...
Example:
...
# 'a' Chart.yaml
dependencies:
- name: b
version: 1.0.0
repository: # Repository URL
...