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.
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 huge patch file that I want to apply to specific overlays. I usually patch files under overlays as it is supposed to be. But the file is same and I do not want to copy it to each overlay. If I could keep my patch file app-new-manifest.yaml under base and patch it under overlay with a single line in kustomization.yaml, it would be awesome.
├── base
│ ├── app-new-manifest.yaml # I am trying to patch this
│ ├── kustomization.yaml
│ ├── app
│ │ ├── app.yaml
│ │ └── kustomization.yaml
└── overlay
└── environment1
│ ├── kustomization.yaml # I want to patch app-new-manifest.yaml in base
│
└── environment2
│ ├── kustomization.yaml # No patch. app.yaml will be as is
│
└── environment3
├── kustomization.yaml # I want to patch app-new-manifest.yaml in base
When I'm trying to do so, I get this error:
'/base/app/app-new-manifest.yaml' is not in or below '/overlays/environment1'
Which means, when you patch, the patch file has to be located under overlay not base. Is there any workaround to do this? Because copying the same file to each environment does not make sense to me.
Any ideas around this will highly be appreciated, thanks!
Edit:
Add /base/app/kustomization.yaml
resources:
- app.yaml
Add /overlays/environment1/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base/app
patchesStrategicMerge:
- ../../base/app/app-new-manifest.yaml # Patch new manifest
kustomize version:
{Version:kustomize/v4.2.0 GitCommit:d53a2ad45d04b0264bcee9e19879437d851cb778 BuildDate:2021-07-01T00:44:28+01:00 GoOs:darwin GoArch:amd64}
You can't include a file that is outside of you current directory, but you can include another directory that has a kustomize.yaml file. So organize your layout like this:
.
├── base
└── overlay
├── patched_based
├── environment1
├── environment2
└── environment3
In overlay/patched_base, place your patch file and a kustomization file like:
resources:
- ../base
patchesStrategicMerge:
- app-new-manifest.yaml
In overlay/environment1 and overlay/environment3, you have:
resources:
- ../patched_base
Whereas in overlay/environment2, you have:
resources:
- ../../base
I think this solves all your requirements:
You only need a single instance of the patch
You can choose to use the patch or not from each individual overlay
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.
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.