Utilize bjw-s's common Helm library. #13

Merged
konrad merged 41 commits from :new-helm-chart into main 2023-11-07 14:47:24 +00:00
2 changed files with 51 additions and 99 deletions
Showing only changes of commit 763de07818 - Show all commits

148
README.md
View File

@ -10,124 +10,76 @@ Helm >= 3
## Quickstart
Default settings should work for you and if you define ingress settings according to your controller (for both API and Frontend), you will be able to access the frontend. Anyway, it won't have any default credentials. In order to create a user, you **have to enable registration** and register a new user.
The majority of default values defined in `values.yaml` should be compatible for your deployment. Additionally, if you utilize an Ingress for both the API and Frontend, you will be able to access the frontend out of the box. However, it won't have any default credentials, you will need to **either** enable registration, or execute `/bin/sh` on the API container and run the following command:
konrad marked this conversation as resolved Outdated

Registration is enabled by default, maybe change this to "you need to create an account before using it, there are no default credentials".

Not sure if we should even leave this in here as it is not specific for the helm deployment.

Registration is enabled by default, maybe change this to "you need to create an account before using it, there are no default credentials". Not sure if we should even leave this in here as it is not specific for the helm deployment.

What do you think about this change?:

688a055c36

What do you think about this change?: https://kolaente.dev/vikunja/helm-chart/commit/688a055c369218558392df042f8ee6e16900e0f6

Looks good!

Looks good!
```bash
./vikunja user create --email <user@email.com> --user <user1> --password <password123>
```
If you do **not** wish to execute the above command in order to create a new user, you'll need to enable registration by appending

I don't think this should belong here as it's not specific for the helm deployment.

I don't think this should belong here as it's not specific for the helm deployment.

Understood - it was meant to be more of an example of how you can utilize the values of the Helm deployment to create the config.yml and make changes. Would it be adequate to perhaps rename the section to "Example of how to create config.yml" and move it to the bottom of the README.md?

Understood - it was meant to be more of an example of how you can utilize the `values` of the Helm deployment to create the `config.yml` and make changes. Would it be adequate to perhaps rename the section to "Example of how to create `config.yml`" and move it to the bottom of the README.md?

Renamed the section, and bumped the "modification" examples to the bottom of the README.md in order to highlight how to use a pre-existing PVC. Let me know if you find that to be adequate!

ce56e07518

Renamed the section, and bumped the "modification" examples to the bottom of the README.md in order to highlight how to use a pre-existing PVC. Let me know if you find that to be adequate! https://kolaente.dev/vikunja/helm-chart/commit/ce56e07518e9187f2f406a80c94dc8fddca53a87

Renaming is great!

Renaming is great!
```yaml
api:
config:
service:
enableregistration: true
configMaps:
config:
enabled: true
data:
config.yml:
service:
enableregistration: true
```
Once you have registered, you can disable registration back if you do not need it.
Once you've registered your user, feel free to disable registration if you don't wish for other users to register.
## Advanced features
### Modifying Resources
### Raw 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.
Often happens, that you have to deploy some cloud-specific resources that are not a part of the application chart itself. You have to either create an extra chart for that, or manage them with other tools (kustomize, plain manifests etc.). That is painful. We have a solution. If you want to create anything that is not present in the chart, *just add it in raw*!
Anything you see [here](https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml), including the top-level keys, can be added and subtracted from this chart's `values.yaml`, underneath the `api`, `frontend`, and (optionally) `typesense` key.
Let's say, you are hosted in [GKE](https://cloud.google.com/kubernetes-engine) and want to use Google-managed TLS certificates. In order to do that, you have to create a ManagedCertificate resource. It can be done this way.
For example, if you wished to create a `serviceAccount` as can be seen [here](https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml#L85-L87) for the `api` pod:
```yaml
api:
serviceAccount:
create: true
```
Then, (for some reason), if you wished to deploy the `frontend` as a `DaemonSet` ([as can be seen here](https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml#L12-L17)), you could do the following:
```yaml
frontend:
enabled: true
annotations:
kubernetes.io/ingress.class: gce
networking.gke.io/managed-certificates: gmc-example-com
hosts:
- host: example.com
paths:
- path: /
pathType: Prefix
raw:
- apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
name: gmc-example-com
spec:
domains:
- example.com
```
Or, let's say, you have decided to use Google SQL database instead of self-hosted, and placed credentials in Google Secret Manager. You plan to use [ExternalSecrets](https://external-secrets.io/v0.7.2/) to get that credentials. These can be easily integrated as well.
```yaml
# Disable embedded database
postgresqlEnabled: false
api:
config:
database:
# Use PostgreSQL database anyway
type: postgres
envFrom:
# Bind env variables from the secret
- name: VIKUNJA_DATABASE_USER
valueFrom:
secretKeyRef:
name: postgresql-credentials
key: username
- name: VIKUNJA_DATABASE_PASSWORD
valueFrom:
secretKeyRef:
name: postgresql-credentials
key: password
- name: VIKUNJA_DATABASE_HOST
valueFrom:
secretKeyRef:
name: postgresql-credentials
key: hostname
- name: VIKUNJA_DATABASE_DATABASE
valueFrom:
secretKeyRef:
name: postgresql-credentials
key: database
raw:
- apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
name: gcpsm
spec:
refreshInterval: 300
provider:
gcpsm:
projectID: my-google-project-id
- apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: postgresql-credentials
spec:
secretStoreRef:
kind: SecretStore
name: gcpsm
target:
deletionPolicy: Delete
refreshInterval: 5m
dataFrom:
- extract:
key: cloud-sql-credentials
```
Enjoy!
controller:
type: daemonset
```
### Use an existing file volume claim
In the `values.yaml` file, you can configure wether to create the Persistent Volume Claim or use an existing one:
In the `values.yaml` file, you can either define your own existing Persistent Volume Claim (PVC) or have the chart create one on your behalf.
To have the chart use your pre-existing PVC:
```yaml
# Specifies whether a PVC should be created
create: true
# The name of the PVC to use.
# If not set and create is true, a name is generated using the fullname template
name: ""
api:
persistence:
data:
enabled: true
existingClaim: <your-claim>
```
This is helpful when migrating from a different k8s chart and want to re-use the existing volume or if you need more control over how the volume is created.
To have the chart create one on your behalf:
```yaml
# You can find the default values
api:
enabled: true
persistence:
data:
enabled: true
accessMode: ReadWriteOnce
size: 10Gi
storageClass: storage-class
```
## Publishing

View File

@ -47,7 +47,7 @@ api:
config:
enabled: true
data:
config.yml: |
config.yml:
database:
# You should provide your own secret outside of this helm-chart and use `postgresql.global.postgresql.auth.existingSecret` to provide credentials to the postgresql instance (https://github.com/bitnami/charts/blob/5ff8ad5f3c754e3c2423d6abf46f522e8abe0410/bitnami/postgresql/values.yaml#L35-L39)
type: 'postgres'