github.com/koderover/helm@v2.17.0+incompatible/docs/chart_template_guide/values_files.md (about)

     1  # Values Files
     2  
     3  In the previous section we looked at the built-in objects that Helm templates offer. One of these built-in objects is `Values`. This object provides access to values passed into the chart. Its contents come from four sources:
     4  
     5  - The `values.yaml` file in the chart
     6  - If this is a subchart, the `values.yaml` file of a parent chart
     7  - A values file is passed into `helm install` or `helm upgrade` with the `-f` flag (`helm install -f myvals.yaml ./mychart`)
     8  - Individual parameters passed with `--set` (such as `helm install --set foo=bar ./mychart`)
     9  
    10  The list above is in order of specificity: `values.yaml` is the default, which can be overridden by a parent chart's `values.yaml`, which can in turn be overridden by a user-supplied values file, which can in turn be overridden by `--set` parameters.
    11  
    12  Values files are plain YAML files. Let's edit `mychart/values.yaml` and then edit our ConfigMap template.
    13  
    14  Removing the defaults in `values.yaml`, we'll set just one parameter:
    15  
    16  ```yaml
    17  favoriteDrink: coffee
    18  ```
    19  
    20  Now we can use this inside of a template:
    21  
    22  ```yaml
    23  apiVersion: v1
    24  kind: ConfigMap
    25  metadata:
    26    name: {{ .Release.Name }}-configmap
    27  data:
    28    myvalue: "Hello World"
    29    drink: {{ .Values.favoriteDrink }}
    30  ```
    31  
    32  Notice on the last line we access `favoriteDrink` as an attribute of `Values`: `{{ .Values.favoriteDrink }}`.
    33  
    34  Let's see how this renders.
    35  
    36  ```console
    37  $ helm install --dry-run --debug ./mychart
    38  SERVER: "localhost:44134"
    39  CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart
    40  NAME:   geared-marsupi
    41  TARGET NAMESPACE:   default
    42  CHART:  mychart 0.1.0
    43  MANIFEST:
    44  ---
    45  # Source: mychart/templates/configmap.yaml
    46  apiVersion: v1
    47  kind: ConfigMap
    48  metadata:
    49    name: geared-marsupi-configmap
    50  data:
    51    myvalue: "Hello World"
    52    drink: coffee
    53  ```
    54  
    55  Because `favoriteDrink` is set in the default `values.yaml` file to `coffee`, that's the value displayed in the template. We can easily override that by adding a `--set` flag in our call to `helm install`:
    56  
    57  ```console
    58  helm install --dry-run --debug --set favoriteDrink=slurm ./mychart
    59  SERVER: "localhost:44134"
    60  CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart
    61  NAME:   solid-vulture
    62  TARGET NAMESPACE:   default
    63  CHART:  mychart 0.1.0
    64  MANIFEST:
    65  ---
    66  # Source: mychart/templates/configmap.yaml
    67  apiVersion: v1
    68  kind: ConfigMap
    69  metadata:
    70    name: solid-vulture-configmap
    71  data:
    72    myvalue: "Hello World"
    73    drink: slurm
    74  ```
    75  
    76  Since `--set` has a higher precedence than the default `values.yaml` file, our template generates `drink: slurm`.
    77  
    78  Values files can contain more structured content, too. For example, we could create a `favorite` section in our `values.yaml` file, and then add several keys there:
    79  
    80  ```yaml
    81  favorite:
    82    drink: coffee
    83    food: pizza
    84  ```
    85  
    86  Now we would have to modify the template slightly:
    87  
    88  ```yaml
    89  apiVersion: v1
    90  kind: ConfigMap
    91  metadata:
    92    name: {{ .Release.Name }}-configmap
    93  data:
    94    myvalue: "Hello World"
    95    drink: {{ .Values.favorite.drink }}
    96    food: {{ .Values.favorite.food }}
    97  ```
    98  
    99  While structuring data this way is possible, the recommendation is that you keep your values trees shallow, favoring flatness. When we look at assigning values to subcharts, we'll see how values are named using a tree structure.
   100  
   101  ## Deleting a default key
   102  
   103  If you need to delete a key from the default values, you may override the value of the key to be `null`, in which case Helm will remove the key from the overridden values merge.
   104  
   105  For example, the stable Drupal chart allows configuring the liveness probe, in case you configure a custom image. Here are the default values:
   106  ```yaml
   107  livenessProbe:
   108    httpGet:
   109      path: /user/login
   110      port: http
   111    initialDelaySeconds: 120
   112  ```
   113  
   114  If you try to override the livenessProbe handler to `exec` instead of `httpGet` using `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, Helm will coalesce the default and overridden keys together, resulting in the following YAML:
   115  ```yaml
   116  livenessProbe:
   117    httpGet:
   118      path: /user/login
   119      port: http
   120    exec:
   121      command:
   122      - cat
   123      - docroot/CHANGELOG.txt
   124    initialDelaySeconds: 120
   125  ```
   126  
   127  However, Kubernetes would then fail because you can not declare more than one livenessProbe handler. To overcome this, you may instruct Helm to delete the `livenessProbe.httpGet` by setting it to null:
   128  ```sh
   129  helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null
   130  ```
   131  
   132  At this point, we've seen several built-in objects, and used them to inject information into a template. Now we will take a look at another aspect of the template engine: functions and pipelines.