In the documentation for helm subcharts and globals, they list 4 details of which 2 I want to focus on
A subchart is considered "stand-alone", which means a subchart can never explicitly depend on its parent chart.
For that reason, a subchart cannot access the values of its parent.
A parent chart can override values for subcharts.
Helm has a concept of global values that can be accessed by all charts.
From the examples it seems like 1 and 4 are contradictory. If I create a global variable in the parent chart and then reference this in the sub chart, would this not create a dependency between the parent and sub charts?
The sub chart will still be considered "stand-alone". Using global values will create a dependency on the values.yaml of your parent chart (not an explicit dependency on the parent chart itself).
To overcome this, you must explicitly pass the parent values (via --values flag) when installing individual sub-charts. e.g.:
Supposing the following structure:
$ tree parent/
parent/
├── charts
│ └── child
│ ├── Chart.yaml
│ └── templates
│ └── configmap.yaml
├── Chart.yaml
└── values.yaml
To install the child subchart individually, you must use:
helm install ./parent/charts/child/ --values ./parent/values.yaml
There is an open discussion (#4767) in helm project to improve this.
Related
I have the following in main.tf
data "kubectl_path_documents" "yaml-files" {
pattern = "${path.module}/manifests/*.yaml"
}
resource "kubectl_manifest" "yaml-manifests" {
for_each = toset(data.kubectl_path_documents.yaml-files.documents)
yaml_body = each.value
}
I would need to parameterize certain fields in the yaml files to be able to deploy different set of resources for dev vs prod. I knew there was a way to do this if it was one yaml. How should this be done for many yaml files
├── manifests
│ ├── gdp-configmap.yaml
│ ├── gdp-agent-deamonset.yaml
│ ├── gdp-collector-configmap.yaml
│ ├── gdp-collector-deployment.yaml
Any help is appreciated.
I was able to resolve this using a null_resource that executes a sh script with values to be sed'ed.
I have a sub-chart which is being used by many other Charts, the sub-chart has a Deployment file in it that is using access files.
The deployment includes the following line {{- range $value := .Files.Lines "test.list" }} and test.list file is under the main chart.
MAIN CHART
├── Chart.yaml (with dependency for the sub-chart)
├── values.yaml
└── test.list
SUB CHART
├── Chart.yaml
├── templates
│ ├── deployment.yaml (including the {{- range $value := .Files.Lines "test.list" }}
└── values.yaml
Unfortunately, the test.list file is being ignored unless I am moving it inside the sub-chart. Is there anyway to solve this issue?
Thank you. Your question helped me to figure out my own issue: I could not get the .Files.Glob to use the sub-chart's files, it would only find files in the main chart.
My solution is to not use named templates from the sub-chart.
Maybe it is an option for you to put the .Files.Lines into a named template in the sub-chart and include it into the main chart. That way the .Files will be run in the context of the main chart.
I am creating a helm chart for the job I want to run in our k8 cluster. When you execute helm create it creates templates that I do not need.
$ helm create new-job
Creating new-job
$ tree new-job/
new-job/
├── Chart.yaml
├── charts
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ ├── hpa.yaml
│ ├── ingress.yaml
│ ├── service.yaml
│ ├── serviceaccount.yaml
│ └── tests
│ └── test-connection.yaml
└── values.yaml
3 directories, 10 files
Is there a way to only create a template containing only job.yaml?
Helm has the option to use a custom "starter":
helm create --starter /path/to/starter/chart my-chart
There's nothing magical about helm create. Just so long as the chart has a Chart.yaml file and a templates subdirectory, Helm can install it. You can mkdir an empty directory and create the Chart.yaml file from scratch using your favorite text editor, if you'd prefer.
# Chart.yaml, with only the required fields
apiVersion: v2
name: my-chart
version: '0.0.1'
mkdir my-chart; cd my-chart
$EDITOR Chart.yaml
mkdir templates
$EDITOR templates/job.yaml
helm install --generate-name .
You can also go the other direction; start from the helm create template and delete all of the parts you don't need. Of note, there are a couple of generically helpful things in _helpers.tpl you might want to retain. (Keeping the ServiceAccount turns out to be useful in a couple of situations, and if you use Istio, it also likes you to have a Service even if you don't accept inbound connections.)
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
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.
I have used vscode 1.41.1 on my mac for a few months and it worked good until I started to use go modules for dependency management. At the moment I am rewriting a simple tool and introduce packages for separate functionalities.
My code structure looks like this:
├── bmr.go -> package main & main(), uses below packages
├── check
│ ├── check.go -> package check
│ └── check_test.go
├── go.mod
├── go.sum
├── push
│ ├── push.go -> package push
│ └── push_test.go
└── s3objects
├── s3objects.go -> package s3objects
└── s3objects_test.go
My go.mod file:
module github.com/some-org/business-metrics-restore
go 1.13
require (
github.com/aws/aws-sdk-go v1.28.1
github.com/go-redis/redis v6.15.6+incompatible
github.com/sirupsen/logrus v1.4.2
github.com/spf13/viper v1.6.1
github.com/stretchr/testify v1.4.0
golang.org/x/sys v0.0.0-20200113162924-86b910548bc1
)
All is fine when I invoke go test/run/build commands from the shell. But when I use 'Debug' -> 'Run Without Debugging' I get:
go: finding github.com/some-org/business-metrics-restore/push latest
go: finding github.com/some-org/business-metrics-restore latest
go: finding github.com/some-org/business-metrics-restore/check latest
go: finding github.com/some-org/business-metrics-restore/s3objects latest
build command-line-arguments: cannot load github.com/some-org/business-metrics-restore/check: module github.com/some-org/business-metrics-restore#latest found (v0.0.0-20191022092726-d1a52439dad8), but does not contain package github.com/some-org/business-metrics-restore/check
Process exiting with code: 1
My code currently is in a feature branch and d1a52439dad8 is the first (init) and only commit on master. No code for the tool (incl. 3 mentioned non main packages) is in the master branch.
The problem here is that for some reason as you see above vscode fetches state from master and I cannot override this behaviour.
Can anyone help me?
Thanks!
Best Regards,
Rafal.
I realized that if the go.mod is not at the root of your project VSCode does not work properly. I have an AWS SAM project with the following structure:
├── Makefile
├── README.md
├── nic-update
│ ├── go.mod
│ ├── go.sum
│ ├── main.go
│ ├── main_test.go
│ └── r53service
│ └── r53.go
├── samconfig.toml
└── template.yaml
and the only way it works if by starting VSCode from the nic-update directory.
My go.mod has the following content:
require (
github.com/aws/aws-lambda-go v1.13.3
github.com/aws/aws-sdk-go v1.32.12
)
module github.com/jschwindt/ddns-route53/nic-update
go 1.14
I realized that if the go.mod is not at the root of your project VSCode does not work properly
That might now (Oct. 2020) be supported, as a consequence of gopls v0.5.1 and its experimental feature Multi-module workspace support from the proposal 32394.
Even if you don't have multiple modules, a go.mod in a sub-folder (instead of the root folder of your project) will be better managed (if you activate the gopls.experimentalWorkspaceModule setting).
As noted by kayochin in the comments:
The setting should be "gopls": {"build.experimentalWorkspaceModule": true}
See the documentation "gopls / Settings / experimentalWorkspaceModule bool".
I have also had trouble with VS Code and modules. The current status of VS Code support for Go Modules is kept up to date here: https://github.com/golang/vscode-go#Set-up-your-environment
In that link they suggest ditching most of the existing extensions VS Code encourages you to install with Go and instead using the language server gopls with these directions:
Add the below in your settings to use it.
"go.useLanguageServer": true
Note: You will be prompted to install the latest stable version of gopls as and when the Go tools team tag a new version as stable.
You should also fix autoimporting:
Add the setting "go.formatTool": "goimports" and then use Go: Install/Update Tools to install/update goimports as it has recently added support for modules.
When you do these things, keep in mind that you'll also lose a couple of features:
Completion of unimported packages doesnt work
Find references and rename only work in a single package