Utilize bjw-s's common
Helm library.
#13
148
README.md
148
README.md
|
@ -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
|
||||
|
||||
```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
|
||||
konrad
commented
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.
perfectra1n
commented
Understood - it was meant to be more of an example of how you can utilize the 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?
perfectra1n
commented
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! 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
konrad
commented
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
|
||||
|
||||
|
|
|
@ -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'
|
||||
|
|
Loading…
Reference in New Issue
Block a user
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
Looks good!