WIP: main Update default values.yaml to make persistence work + update readme for secrets usage #16

Closed
hugosxm wants to merge 2 commits from hugosxm/helm-chart:main into main
2 changed files with 30 additions and 4 deletions

View File

@ -5,7 +5,7 @@ This Helm Chart deploys both the Vikunja [frontend](https://hub.docker.com/r/vik
## Requirements
- Kubernetes >= 1.19
- Kubernetes >= 1.19
- Helm >= 3
## Quickstart
@ -31,7 +31,7 @@ api:
To have the chart create one on your behalf:
```yaml
# You can find the default values
# You can find the default values
api:
enabled: true
persistence:
@ -52,7 +52,7 @@ For example, if you wished to create a `serviceAccount` as can be seen [here](ht
```yaml
api:
serviceAccount:
serviceAccount:
create: true
```
@ -62,7 +62,7 @@ Then, (for some reason), if you wished to deploy the `frontend` as a `DaemonSet`
frontend:
controller:
type: daemonset
```
```
### Another Example of Modifying `config.yml` (Enabling Registration)
@ -85,6 +85,31 @@ If you need to create another user, you could opt to execute the following comma
./vikunja user create --email <user@email.com> --user <user1> --password <password123>
```
### Utilizing secrets for `env` and `config.yml`
Review

Maybe we could change this header to be:
"Utilizing environment variables from Kubernetes secrets"?

"Each environment variable within the pod can be sourced from a secret in your values.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 (example here):

api:
  envFrom:
    - secretRef:
      name: vikunja-secret-env
  env:
    VIKUNJA_DATABASE_USERNAME: "db-user"

This way we can show in the example that you can both use environment variables from secrets, how to use envFrom, etc.

I should've included this already in the README.md, so I'm thankful that you brought it up!

Maybe we could change this header to be: "Utilizing environment variables from Kubernetes secrets"? "Each environment variable within the pod can be sourced from a secret in your `values.yaml`": ```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 (example [here](https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml#L155)): ```yaml api: envFrom: - secretRef: name: vikunja-secret-env env: VIKUNJA_DATABASE_USERNAME: "db-user" ``` This way we can show in the example that you can both use environment variables from secrets, how to use `envFrom`, etc. I should've included this already in the README.md, so I'm thankful that you brought it up!
Each env in the stack can be sourced from a secret in your `values.yaml`:
```yaml
api:
env:
VIKUNJA_DATABASE_PASSWORD:
valueFrom:
secretKeyRef:
name: vikunja-env
key: VIKUNJA_DATABASE_PASSWORD
```
If your vikunja config needs to contain sensible data, like oauth config, you can source it from a secret in your `values.yaml`:
```yaml
api:
Review

Instead of:

  persistence:
    config:
      enabled: true
      type: secret
      mountPath: /etc/vikunja/config.yml

You could do the following:

api:
  persistence:
    config:
      type: secret
      name: asdf-my-custom-secret1

Since the config is already enabled by default.

Also this way you can provide the name of the secret, and you don't have to provide the mountPath again since it's already part of the template here.

Instead of: ```yaml persistence: config: enabled: true type: secret mountPath: /etc/vikunja/config.yml ``` You could do the following: ```yaml api: persistence: config: type: secret name: asdf-my-custom-secret1 ``` Since the config is already enabled by default. Also this way you can provide the name of the secret, and you don't have to provide the `mountPath` again since it's already part of the template [here](https://kolaente.dev/vikunja/helm-chart/src/commit/62112e8df085b4868bb934f64c0debccee3d1545/templates/api.yaml#L22).
persistence:
config:
enabled: true
type: secret
mountPath: /etc/vikunja/config.yml
# Warning, you can not choose the secret name here, it will search for {{ Release.Name }}-api-config ! So please create your secret accordingly !
```
## Publishing
The following steps are automatically performed when a git tag for a new version is pushed to the repository.

View File

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