= Base This Helm-Chart called base is there to bundle multiple components (helm-charts which maybe deployes another flux-repository). == Base-Values On this way, it is possible to use one `values.yaml` to setup multiple-components together or multiple overlapping `values.yaml` (e.g. for staging, stacks and so on). For example, take an look in my xref:infra:index.adoc[Infra] and xref:mycloud:index.adoc[myCloud] stack. [WARNING] ==== I will do a versioning of this Base Helmchart and every components chart (but not for my default values). This is just for my setups. As in Hint, it is possible to use `valuesFrom:` and deploy ConfigMap, see https://fluxcd.io/flux/components/helm/helmreleases/#values-references[fluxcd]. ==== === Shared Values The values `global:` and `commons:` are down passed into every component values. This values could be overwritten inside the setup of every component `components..global:` or `components..commons:`. See also xref:#_values[Components - Values] == Components The components are an helmchart in the `commons.helm.chart.sourceRef` root. Everything else is components specific and could be set under: [source,yaml] ---- commons: namespace: labels: orgs: example helm: release: install: test: upgrade: driftDetection: componentCommons: helm: release: interval: 10m components: : enabled: true <1> name: <2> namespace: <3> name: labels: team: my skip_create: false valuesFrom: <4> values: <5> ---- <1> install this components (or not) <2> if set use component by name otherwise component is used by component-release-name <3> setup namespace, where component is deployed (e.g. name, labels of namespace, skip-create) if not set use namespace of current Base <4> use `valuesFrom` an `Secret` or `ConfigMap` <5> use values direct === Namespace It is possible to deploy an components into a specific namespace (and create this). ==== Use existing Namespace [source,yaml] ---- components: : namespace: name: "default" skip_create: true ---- ==== Same Namespace as Base [source,yaml] ---- components: : namespace: name: nil <1> ---- <1> or never set this part ==== New Namespace [source,yaml] ---- commons: namespace: labels: <1> orgs: example components: : namespace: name: "my-namespace" labels: <2> team: my ---- <1> optional with labels on every new namespace by this component-release <2> optional with labels on this component-release === Values There are multiple options to set values of an components. Here in short the four options and order by overwrite priority. [source,yaml] ---- global: <3> commons: <3> componentCommons: helm: release: valuesFrom: <1> components: : valuesFrom: [] <2> values: <4> ---- <1> `valuesFrom` for every components (e.g one or multiple `ConfigMap` or `Secrets`) <2> `valuesFrom` of a specific component <3> `global:` or `commons` for every componets <4> values for a specific component ==== Adjust Component setup (fluxcd values) [source,yaml] ---- commons: <1> helm: release: install: test: upgrade: driftDetection: componentCommons: helm: release: <2> interval: 10m ---- <1> is part of commons, for maybe reuse inside of an component-chart. <2> is part of componentCommons for just use of component use level. ==== init-Version [WARNING] ==== Since FluxCD supports driftDetection (with version 2.2) we maybe drop that idea. ==== This is a small workaround to setup manifest in later step / rerun an component-chart, as e.g. CRD installation by an HelmRelease which is part of the used Component-Chart. .Helper which should be put into the Component-Chart (with Capabilities if every is there to setup / to retries) [source,yaml] ---- apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-init namespace: "{{ .Values.init.namespace }}" data: {{- if and (.Capabilities.APIVersions.Has "monitoring.coreos.com/v1/PrometheusRule") (.Capabilities.APIVersions.Has "monitoring.coreos.com/v1/ServiceMonitor") }} init: "-1" {{- else }} init: "{{ add1 .Values.init.version }}" {{- end }} ----