continuous-integration/drone/push Build is passing Details
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).
See https://artifacthub.io/packages/helm/vikunja/vikunja for version information and installation instructions.
Define ingress settings according to your controller (for both API and Frontend) to access the application.
You can set all Vikunja API options as yaml under
For example, you can disable registration (if you do not with to allow others to register on your Vikunja), by providing the following values in your
You can still create new users by executing the following command in the
./vikunja user create --email <email@example.com> --user <user1> --password <password123>
To effectively run multiple replicas of the API,
make sure to set up the redis cache as well
configuring the redis subchart (see values.yaml)
and the connection in Vikunja
Use an existing file volume claim
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:
To have the chart create one on your behalf:
# You can find the default values
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
this is how you would add the value stored at key
VIKUNJA_DATABASE_PASSWORD as the environment variable named
If the keys within the secret are the names of environment variables, you can simplify passing multiple values to this:
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.
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
Then your secret should look something like the following so that it will mount properly:
Modifying Deployed Resources
Oftentimes, modifications need to be made to a Helm chart to allow it to operate in your Kubernetes cluster.
Anything you see in bjw-s'
including the top-level keys, can be added and subtracted from this chart's
frontend, and (optionally)
For example, if you wished to create a
serviceAccount as can be seen here for the
Then, (for some reason), if you wished to deploy the
frontend as a
DaemonSet (as can be seen here), you could do the following:
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.