Helm Dependencies

From NovaOrdis Knowledge Base
Revision as of 01:21, 16 December 2019 by Ovidiu (talk | contribs) (→‎Overview)
Jump to navigation Jump to search

External

Internal

Overview


Revised for Helm 3


All applications, maybe with the exception of the most trivial, usually depend on other runtime components, such as web servers, caches, databases, etc. Helm provides a mechanisms to formally specify, manage and deploy these dependencies as part of a release. A Helm chart may declared dependencies, which are other Helm charts published in external repositories, conveniently packaged by people who presumably know the respective components well.

To Deplete

Helm Dependencies TODEPLETE

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".

Helm behaves differently. 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

The enforcement of presence of dependencies happens when the chart is packaged with helm package command. If a chart is packaged manually, and its dependencies are omitted while building the chart archive, the chart archive cannot be installed. An attempt to install a chart archive that does not embed dependencies produces:

Error: found in Chart.yaml, but missing in charts/ directory: some-dependency-chart

For more details on how to package a chart with its dependencies, see:

Packaging and Dependencies

Subcharts

The charts stored in the "charts/" subdirectory are also known as "subcharts".

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: http://helm-example.com/charts
...

Note that simply declaring the dependency in Chart.yaml is not sufficient. The dependency needs to be physically downloaded and placed in the charts/ subdirectory with:

helm dependency update

Aliases

Each element of the "dependencies" list allows for an optional "alias" attribute.

Packaging and Dependencies

Packaging and Dependencies

Dependencies and Values

Dependency configuration values should be specified in the top chart values.yaml, and should be prefixed with the dependency name. It is recommended to only override values in the top level chart, and not in any subchart.

TODO:

  • Example

Dependency Operations