feat: update mountPath and update readme for using secrets as config file (#17)

This is in the spirit of #16 (thanks for all the help @hugosxm), but I wanted to make sure that it was complete, so that users would be able to deploy the Vikunja Helm Chart easily.

This PR resolves the following:
- Increased documentation around utilizing environment variables from Kubernetes secrets.
- Increased documentation for utilizing a Kubernetes secret as the `config.yml` file instead of a ConfigMap
- Fix the incorrect `mountPath` for the `api` pod.

Co-authored-by: perf3ct <jonfuller2012@gmail.com>
Reviewed-on: #17
Reviewed-by: konrad <k@knt.li>
Co-authored-by: perfectra1n <perf3ctsec@gmail.com>
Co-committed-by: perfectra1n <perf3ctsec@gmail.com>

Chart.yaml

@@ -10,7 +10,7 @@ description: |-
   the high alpine areas of the Andes and a relative of the llama.
 annotations:
   category: TaskTracker
-version: 0.3.0
+version: 0.3.1
 appVersion: 0.21.0
 kubeVersion: ">= 1.19"
 dependencies:

README.md

@@ -39,9 +39,71 @@ api:
       enabled: true
       accessMode: ReadWriteOnce
       size: 10Gi
+      mountPath: /app/vikunja/files
       storageClass: storage-class
 ```
 
+### Utilizing environment variables from Kubernetes secrets
+
+Each environment variable that is "injected" into a pod can be sourced from a Kubernetes secret. This is useful when you wish to add values that you would rather keep as secrets in your GitOps repo, as environment variables in the pods.
+
+Assuming that you had a Kubernetes secret named `vikunja-env`, this is how you would add the value stored at key `VIKUNJA_DATABASE_PASSWORD` as the environment variable named `VIKUNJA_DATABASE_PASSWORD`:
+
+```yaml
+api:
+  env:
+    VIKUNJA_DATABASE_PASSWORD:
+      valueFrom:
+        secretKeyRef:
+          name: vikunja-env
+          key: VIKUNJA_DATABASE_PASSWORD
+    VIKUNJA_DATABASE_USERNAME: "db-user"
+```
+
+Alternatively, instead of defining each and every key, if the keys within the secret are the names of environment variables, you could also do the following:
+
+```yaml
+api:
+  envFrom:
+    - secretRef:
+      name: vikunja-secret-env
+  env:
+    VIKUNJA_DATABASE_USERNAME: "db-user"
+```
+
+This will add all keys within the Kubernetes secret named `vikunja-secret-env` as environment variables to the `api` pod. Additionally, if you did not have the key `VIKUNJA_DATABASE_USERNAME` in the `vikunja-secret-env` secret, you could still define it as an environment variable seen above.
+
+How the `envFrom` key works can be seen [here](https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml#L155).
+
+### Utilizing a Kubernetes secret as the `config.yml` file instead of a ConfigMap
+
+If you did not wish to use the ConfigMap provided by the chart, and instead wished to mount your own Kubernetes secret as the `config.yml` file in the `api` pod, you could provide values such as the following (assuming `asdf-my-custom-secret1` was the name of the secret that had the `config.yml` file):
+
+```yaml
+api:
+  persistence:
+    config:
+      type: secret
+      name: asdf-my-custom-secret1
+```
+
+Then your secret should look something like the following so that it will mount properly:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: asdf-my-custom-secret1
+  namespace: vikunja
+type: Opaque
+stringData:
+  config.yml: |
+    key1: value1
+    key2: value2
+    key3: value3
+
+```
+
 ### Modifying Deployed Resources
 
 Often times, modifications need to be made to a Helm chart to allow it to operate in your Kubernetes cluster. By utilizing bjw-s's `common` library, there are quite a few options that can be easily modified.

values.yaml

@@ -25,6 +25,7 @@ api:
       # existingClaim: # your-claim
       accessMode: ReadWriteOnce
       size: 10Gi
+      mountPath: /app/vikunja/files
       # storageClass: storage-class
   ingress:
     main: