|
||
---|---|---|
templates | ||
.drone.yml | ||
.gitignore | ||
.helmignore | ||
Chart.lock | ||
Chart.yaml | ||
LICENSE | ||
README.md | ||
artifacthub-repo.yml | ||
icon.png | ||
values.yaml |
README.md
Vikunja Helm Chart
This Helm Chart deploys both the Vikunja frontend and Vikunja api containers, in addition to other Kubernetes resources so that you'll have a fully functioning Vikunja deployment quickly. Also, you can deploy Bitnami's PostgreSQL and Redis as subcharts if you want, as Vikunja can utilize them as its database and caching mechanism (respectively).
Requirements
- Kubernetes >= 1.19
- Helm >= 3
Quickstart
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. So, you'll need to create an account using the registration button.
That should be it!
Use an existing file volume claim
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:
api:
persistence:
data:
enabled: true
existingClaim: <your-claim>
To have the chart create one on your behalf:
# You can find the default values
api:
enabled: true
persistence:
data:
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
:
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:
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.
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):
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:
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.
Anything you see here, including the top-level keys, can be added and subtracted from this chart's values.yaml
, underneath the api
, frontend
, and (optionally) typesense
key.
For example, if you wished to create a serviceAccount
as can be seen here for the api
pod:
api:
serviceAccount:
create: true
Then, (for some reason), if you wished to deploy the frontend
as a DaemonSet
(as can be seen here), you could do the following:
frontend:
controller:
type: daemonset
Another Example of Modifying config.yml
(Enabling Registration)
You can disable registration (if you do not with to allow others to register on your Vikunja), by providing the following values in your values.yaml
:
api:
configMaps:
config:
enabled: true
data:
config.yml:
service:
enableregistration: false
If you need to create another user, you could opt to execute the following command on the api
container:
./vikunja user create --email <user@email.com> --user <user1> --password <password123>
Publishing
The following steps are automatically performed when a git tag for a new version is pushed to the repository. They are only listed here for reference.
- Pull all dependencies before packaging.
helm dependency update
- In order to publish the chart, you have to either use curl or helm cm-push.
helm package .
curl --user '<username>:<password>' -X POST --upload-file './<archive>.tgz' https://kolaente.dev/api/packages/vikunja/helm/api/charts
helm package .
helm repo add --username '<username>' --password '<password>' vikunja https://kolaente.dev/api/packages/vikunja/helm
helm cm-push './<archive>.tgz' vikunja
As you can see, you do not have to specify the name of the repository, just the name of the organization.