CODEWITHSUNDEEP
kuberneteskubernetes-helm
Demi Goldberg
Demi Goldberg

Reputation: 81

helm chart install - will failed if dependency already installed

I have a few helm charts (each one is a microservice) but a few of them are dependent on a common chart (some secrets, pvcs, etc) It is possible to declare dependency between charts and the common chart but if a package already installed as dependency - the helm chart installation will fail.

I am looking for a way to install a helm chart with dependencies but if one of the dependent charts is already installed, ingone or print a massage but not fail the installation process.

Is there any smart way to handle that ? Like, check if a prerequisite chart has already been installed and bypass it without failed the whole process. Thx

Upvotes: 2

Views: 1343

Answers (2)

mtalexan
mtalexan

Reputation: 773

Unfortunately, no. Despite the claims from Helm's official documentation, it in fact has little to no similarity to a "package manager". Helm charts are actually completely monolithic and make no attempt to be anything else (the exact opposite of what package managers do).

Helm provides build time dependency resolution thru chart re-use, and deploy-time templating, but no deploy-time dependency anything. At deploy time it only:

  • Resolves template variables in the yaml
  • Creates one yaml file from the sub-yaml files
  • Orders/splits the object types in the yaml so certain k8s deploy requirements are met.
  • Adds it's own annotations to the objects so it can re-discover them on subsequent calls.
  • Deploys the yaml

Helm charts are required to have all of their dependencies "compiled in" at packaging time, meaning all recursive dependencies must be copied into the umbrella chart at packaging time. And at deploy time all those dependency charts are simply dumped into the single large yaml with no checks on what's already present in the cluster. It's only during deployment of the final yaml that it actually catches that there's a conflict (if there is one and it doesn't just create another instance of the same thing).

Upvotes: 1

Harsh Manvar
Harsh Manvar

Reputation: 30208

Ideally you can give dependencies using

https://helm.sh/docs/helm/helm_dependency/

# Chart.yaml
dependencies:
- name: nginx
  version: "1.2.3"
  repository: "https://example.com/charts"
- name: memcached
  version: "3.2.1"
  repository: "https://another.example.com/charts"

Helm charts store their dependencies in 'charts/'. For chart developers, it is often easier to manage dependencies in 'Chart.yaml' which declares all dependencies.

The dependency commands operate on that file, making it easy to synchronize between the desired dependencies and the actual dependencies stored in the 'charts/' directory.

You can also use the sub chart and parent chart format to manage the dependencies

Folder structure something will go like this

├── Chart.yaml
├── charts
│   └── django
│       ├── Chart.yaml
│       ├── templates
│       │   ├── deployment.yaml
│       │   ├── ingress.yaml
│       │   └── service.yaml
│       └── values.yaml
├── templates
└── values.yaml

For example : https://medium.com/craftech/one-chart-to-rule-them-all-3f685e0f25a9

You can also read more at official documentation : https://helm.sh/docs/chart_template_guide/subcharts_and_globals/

To this point we have been working only with one chart. But charts can have dependencies, called subcharts, that also have their own values and templates. In this section we will create a subchart and see the different ways we can access values from within templates.

Upvotes: 1

Related Questions