Remove frontend container for new merged docker #29

Merged
konrad merged 14 commits from xeruf/helm-chart:merged-docker into main 2025-01-29 12:35:33 +00:00
6 changed files with 71 additions and 150 deletions

View File

@ -1,12 +1,12 @@
dependencies:
- name: redis
repository: https://charts.bitnami.com/bitnami
version: 17.11.6
version: 18.6.3
- name: postgresql
repository: https://charts.bitnami.com/bitnami
version: 12.1.9
version: 16.3.0
xeruf marked this conversation as resolved
Review

Is this postgres version 16? Because if we're upgrading this, why not upgrade directly to postgres 17?

Is this postgres version 16? Because if we're upgrading this, why not upgrade directly to postgres 17?
Review

It is postgres 17, this is the chart version ;)

It is postgres 17, this is the chart version ;)
Review

Gotcha!

Looks like 16.4.5 is out btw

Gotcha! Looks like 16.4.5 is out btw
- name: common
repository: https://bjw-s.github.io/helm-charts
version: 1.5.1
digest: sha256:efadd6fed4908e6062d0d227177d5d650e5fe5b9c94f1cc99feb33ce3a1d0916
generated: "2023-10-05T14:21:22.588364801-07:00"
digest: sha256:4a2313f157c919ad08b4e8e425e564baf268b3c72fc625d9da5e4d2aada64191
generated: "2024-12-13T12:48:20.656317575+01:00"

View File

@ -2,25 +2,25 @@ apiVersion: v2
type: application
name: vikunja
home: https://kolaente.dev/vikunja/helm-chart
icon: https://kolaente.dev/vikunja/helm-chart/raw/commit/d1f609a6c4b4d06c793611f3af812c98e07d502b/icon.png
icon: https://kolaente.dev/vikunja/helm-chart/raw/main/icon.png
deprecated: false
description: |-
The open-source, self-hostable to-do app. Organize everything, on all platforms.
Also one of the two wild South American camelids which live in
the high alpine areas of the Andes and a relative of the llama.
annotations:
category: TaskTracker
version: 0.4.3
appVersion: 0.21.0
version: 1.0.0
xeruf marked this conversation as resolved
Review

Why 1.0.0 instead of 0.5.0?

Why 1.0.0 instead of 0.5.0?
Review

Because this update is a breaking change, and I don't find dragging out a 1.0 productive anyway, also for Vikunja, it just makes the first number meaningless (See Java, where they dropped it at some point).
For exxample for Vikunja, I believe the upgrade 0.22 to 0.23 should have been a major bump since it changes the structure majorly.
For me 0.X is for software that is not properly usable, which Vikunja and this helm chart are long past.

Because this update is a breaking change, and I don't find dragging out a 1.0 productive anyway, also for Vikunja, it just makes the first number meaningless (See Java, where they dropped it at some point). For exxample for Vikunja, I believe the upgrade 0.22 to 0.23 should have been a major bump since it changes the structure majorly. For me 0.X is for software that is not properly usable, which Vikunja and this helm chart are long past.
Review

I see your point, but you also said you want to merge this as is and then fix it later. That's not a definition of the very first 1.0 release 🙂

I see your point, but you also said you want to merge this as is and then fix it later. That's not a definition of the very first 1.0 release 🙂
appVersion: 0.24.6
kubeVersion: ">= 1.19"
dependencies:
- name: redis
repository: https://charts.bitnami.com/bitnami
version: 17.11.6
# TODO Consider switch to valkey - staying with pre-fork redis 7.2.4 for now
version: 18.6.3
condition: redis.enabled
- name: postgresql
version: 12.1.9
repository: https://charts.bitnami.com/bitnami
# https://github.com/bitnami/charts/blob/main/bitnami/postgresql/Chart.yaml
version: 16.4.5 # Postgres 17.2
condition: postgresql.enabled
- name: common
repository: https://bjw-s.github.io/helm-charts
@ -30,15 +30,12 @@ keywords:
- todo
- to-do
- task
- tack-tracker
- task-tracker
- project-management
- self-hosted
maintainers:
- name: Vikunja
url: https://vikunja.io
- name: Yurii Vlasov
email: yuriy@vlasov.pro
url: https://vlasov.pro
konrad marked this conversation as resolved Outdated

Why did you remove Yurii?

Why did you remove Yurii?
Outdated
Review

He does not seem active anymore, I understand this not as credits but as active maintainers so instead of adding in me and the others I thought keeping it minimal is best. Other charts I saw kept it similarly

He does not seem active anymore, I understand this not as credits but as active maintainers so instead of adding in me and the others I thought keeping it minimal is best. Other charts I saw kept it similarly

That makes sense.

That makes sense.
sources:
- https://kolaente.dev/vikunja/helm-chart
- https://vikunja.io

View File

@ -1,19 +1,35 @@
Vikunja Helm Chart
===
# Vikunja Helm Chart
This Helm Chart deploys both the Vikunja [frontend](https://hub.docker.com/r/vikunja/frontend) and Vikunja [api](https://hub.docker.com/r/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](https://github.com/bitnami/charts/tree/main/bitnami/postgresql) and [Redis](https://github.com/bitnami/charts/tree/main/bitnami/redis) as subcharts if you want, as Vikunja can utilize them as its database and caching mechanism (respectively).
This Helm Chart deploys the [Vikunja](https://hub.docker.com/r/vikunja/vikunja) container
in addition to other Kubernetes resources to quickly create a full-featured Vikunja deployment.
This includes Bitnami's [PostgreSQL](https://github.com/bitnami/charts/tree/main/bitnami/postgresql)
and [Redis](https://github.com/bitnami/charts/tree/main/bitnami/redis) as subcharts if you want,
so Vikunja can use them as database and cache respectively.
See https://artifacthub.io/packages/helm/vikunja/vikunja for version information and installation instructions.
See https://artifacthub.io/packages/helm/vikunja/vikunja for version information
and installation instructions.
## Upgrading to v1
Both Vikunja containers got merged into one with Vikunja version 0.23.
A separate `frontend` configuration is now obsolete,
so deleting that and renaming the key `api` to `vikunja`
should mostly "just work".
The only other major change is the `configMaps.config` key
which was changed to `api-config` to continuously reflect
that it only applies to the API.
The Configmap name in the cluster thus stays the same.
## Quickstart
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 `api.configMaps.config.data.config.yml`: https://vikunja.io/docs/config-options
Define ingress settings according to your controller to access the application.
You can configure Vikunja API options as yaml under `vikunja.configMaps.config.data.config.yml`:
https://vikunja.io/docs/config-options
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 `values.yaml`:
```yaml
api:
vikunja:
configMaps:
config:
enabled: true
@ -23,7 +39,7 @@ api:
enableregistration: false
```
You can still create new users by executing the following command in the `api` container:
You can still create new users by executing the following command in the `vikunja` container:
```bash
./vikunja user create --email <user@email.com> --user <user1> --password <password123>
@ -35,7 +51,7 @@ You can still create new users by executing the following command in the `api` c
To effectively run multiple replicas of the API,
make sure to set up the redis cache as well
by setting `api.configMaps.config.data.config.yml.keyvalue.type` to `redis`,
by setting `vikunja.configMaps.config.data.config.yml.keyvalue.type` to `redis`,
configuring the redis subchart (see [values.yaml](./values.yaml#L119))
and the connection [in Vikunja](https://vikunja.io/docs/config-options/#redis)
@ -47,7 +63,7 @@ or have the chart create one on your behalf.
To have the chart use your pre-existing PVC:
```yaml
api:
vikunja:
persistence:
data:
enabled: true
@ -58,7 +74,7 @@ To have the chart create one on your behalf:
```yaml
# You can find the default values
api:
vikunja:
enabled: true
persistence:
data:
@ -79,7 +95,7 @@ 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`:
```yaml
api:
vikunja:
env:
VIKUNJA_DATABASE_PASSWORD:
valueFrom:
@ -93,7 +109,7 @@ If the keys within the secret are the names of environment variables,
you can simplify passing multiple values to this:
```yaml
api:
vikunja:
envFrom:
- secretRef:
name: vikunja-secret-env
@ -101,16 +117,16 @@ api:
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.
This will add all keys within the Kubernetes secret named `vikunja-secret-env` as environment variables to the `vikunja` 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](https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml#L155).
### 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):
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 `vikunja` 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):
```yaml
api:
vikunja:
persistence:
config:
type: secret
@ -139,24 +155,16 @@ stringData:
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' `common` library](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.
underneath the `vikunja` and (optionally) `typesense` key.
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:
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 `vikunja` pod:
```yaml
api:
vikunja:
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:
controller:
type: daemonset
```
## Publishing
The following steps are automatically performed when a git tag for a new version is pushed to the repository.

View File

@ -1,29 +0,0 @@
{{- define "vikunja.frontend.hardcodedValues" -}}
global:
nameOverride: frontend
service:
main:
enabled: true
primary: true
type: ClusterIP
ports:
http:
enabled: true
primary: true
port: 80
protocol: HTTP
env:
{{- if .Values.api.ingress.main.enabled }}
VIKUNJA_API_URL: "http://{{ index .Values.api.ingress.main.hosts 0 "host" }}{{ index .Values.api.ingress.main.hosts 0 "path" }}"
{{ end }}
{{ end }}
{{ if .Values.frontend.enabled }}
{{- $ctx := deepCopy . -}}
{{- $_ := get .Values "frontend" | mergeOverwrite $ctx.Values -}}
{{- $_ = include "vikunja.frontend.hardcodedValues" . | fromYaml | merge $ctx.Values -}}
{{- include "bjw-s.common.loader.all" $ctx }}
{{ end }}

View File

@ -1,9 +1,7 @@
{{- define "vikunja.api.hardcodedValues" -}}
global:
nameOverride: api
{{- define "vikunja.vikunja.hardcodedValues" -}}
service:
main:
controller: main
enabled: true
primary: true
type: ClusterIP
@ -14,6 +12,9 @@ service:
port: 3456
protocol: HTTP
podSecurityContext:
fsGroup: 1000
persistence:
config:
enabled: true
@ -46,23 +47,9 @@ env:
{{ if .Values.typesense.enabled }}
VIKUNJA_TYPESENSE_ENABLED: "true"
{{ end }}
{{ if and .Values.frontend.ingress.enabled .Values.api.configMaps.config.enabled}}
# The configuration for Vikunja's api.
# https://vikunja.io/docs/config-options/
VIKUNJA_SERVICE_FRONTENDURL: "http://{{ index .Values.frontend.ingress.main.hosts 0 "host" }}{{ index .Values.frontend.ingress.main.hosts 0 "path" }}"
{{ end }}
# Logic to decide what the api URL should be
{{ if .Values.frontend.ingress.enabled }}
VIKUNJA_FRONTEND_URL: "http://{{ index .Values.frontend.ingress.main.hosts 0 "host" }}{{ index .Values.frontend.ingress.main.hosts 0 "path" }}"
{{ end }}
{{ end }}
{{ if .Values.api.enabled }}
{{- $ctx := deepCopy . -}}
{{- $_ := get .Values "api" | mergeOverwrite $ctx.Values -}}
{{- $_ = include "vikunja.api.hardcodedValues" . | fromYaml | merge $ctx.Values -}}
{{- $_ := get .Values "vikunja" | mergeOverwrite $ctx.Values -}}
{{- $_ = include "vikunja.vikunja.hardcodedValues" . | fromYaml | merge $ctx.Values -}}
{{- include "bjw-s.common.loader.all" $ctx }}
{{ end }}

View File

@ -4,19 +4,15 @@
## Refer there for more detail about the supported values.
## Any values that you find in the above `values.yaml` can be provided to this chart and are then rendered.
image:
tag: 0.21.0
######################
# VIKUNJA COMPONENTS #
######################
# You can find the default values that this `values.yaml` overrides, in the comment at the top of this file.
api:
enabled: true
vikunja:
xeruf marked this conversation as resolved Outdated

This might need renaming as it is not only the api anymore?

This might need renaming as it is not only the api anymore?
Outdated
Review

was deliberating to put that into v2.0 but maybe now is better yeah

was deliberating to put that into v2.0 but maybe now is better yeah
image:
repository: vikunja/api
tag: 0.21.0
pullPolicy: IfNotPresent
repository: vikunja/vikunja
#tag: "latest"
xeruf marked this conversation as resolved Outdated

This tag does not exist.

This tag does not exist.
Outdated
Review

my bad, correction coming up

my bad, correction coming up
#pullPolicy: Always
Review

Why comment this?

Why comment this?
Review

Cause a specific chart version should always deploy a specific app version by default, which comes from the Chart.yaml. Commented sections are as reference for users.

Cause a specific chart version should always deploy a specific app version by default, which comes from the `Chart.yaml`. Commented sections are as reference for users.
Review

If it's not used, it should be removed. The reference and possible options should be documented elsewhere.

If it's not used, it should be removed. The reference and possible options should be documented elsewhere.
Review

Also right now it's not specified what it pulls, IMHO this should include the tag (but maybe not latest)

Also right now it's not specified what it pulls, IMHO this should include the tag (but maybe not latest)
Review

it is specified in Chart.yaml, I would not want to duplicate it

there are other options which are also commented out, having the values.yaml as a reference is common practice in helm charts

it is specified in `Chart.yaml`, I would not want to duplicate it there are other options which are also commented out, having the values.yaml as a reference is common practice in helm charts
persistence:
# This is your Vikunja data will live, you can either let
# the chart create a new PVC for you or provide an existing one.
@ -36,20 +32,15 @@ api:
hosts:
- host: vikunja.local
paths:
- path: "/api/v1"
- path: /
tls: []
configMaps:
# The configuration for Vikunja's api.
# The configuration for Vikunja's api
# https://vikunja.io/docs/config-options/
config:
api-config:
enabled: true
data:
config.yml: |
# Vikunja needs to know the frontend URL for password reset emails.
# So you might need to provide its value, if you're not using an ingress.
# service:
# frontendUrl: http://vikunja.local
typesense:
# Typesense will only work if it is enabled below (typesense.enabled).
url: "{{ printf "%s-typesense" .Release.Name }}:8108"
@ -63,43 +54,9 @@ api:
# You could also use MySQL or SQLite, but we recommend PostgreSQL.
# https://vikunja.io/docs/config-options/#type
VIKUNJA_DATABASE_TYPE: "postgres"
VIKUNJA_DATABASE_USER: "{{ .Values.postgresql.global.postgresql.auth.username }}"
VIKUNJA_DATABASE_PASSWORD: "{{ .Values.postgresql.global.postgresql.auth.password }}"
VIKUNJA_DATABASE_NAME: "{{ .Values.postgresql.global.postgresql.auth.database }}"
frontend:
enabled: true
# You can add any of the top-level keys in the common chart's `values.yaml` to override them here.
# For example, this values.yaml file overrides the image values, located here:
# https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml#L63-L69
image:
repository: vikunja/frontend
tag: 0.21.0
pullPolicy: IfNotPresent
# You can use either a `service` or an `ingress` to interact with Vikunja's frontend.
# `Ingress` is the recommended option, but you can still set the `service` to
# `LoadBalancer` or another service type.
# https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml#L294-L354
service:
main:
type: ClusterIP
# https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml#L393-L436
ingress:
konrad marked this conversation as resolved Outdated

Don't we still need an ingress?

Don't we still need an ingress?
Outdated
Review

still present, this is just the frontend

still present, this is just the frontend

gotcha.

gotcha.
main:
enabled: true
annotations:
# proxy-body-size is set to 0 to remove the body limit on file uploads
nginx.ingress.kubernetes.io/proxy-body-size: "0"
hosts:
# This is just an example. You should change this to your own domain.
- host: vikunja.local
paths:
- path: "/"
tls: []
# You only need to provide the URL to the API as environment variable here if you deviate from the "built-in" ingress in the api section.
#env:
# VIKUNJA_API_URL: http://vikunja.local/api
VIKUNJA_DATABASE_USER: "{{ coalesce .Values.postgresql.global.postgresql.auth.username .Values.postgresql.auth.username }}"
VIKUNJA_DATABASE_PASSWORD: "{{ coalesce .Values.postgresql.global.postgresql.auth.password .Values.postgresql.auth.password }}"
VIKUNJA_DATABASE_NAME: "{{ coalesce .Values.postgresql.global.postgresql.auth.database .Values.postgresql.auth.database }}"
##########################
# END VIKUNJA COMPONENTS #
@ -114,12 +71,13 @@ frontend:
# https://github.com/bitnami/charts/tree/main/bitnami/postgresql/#parameters
postgresql:
enabled: true
global:
postgresql:
auth:
username: vikunja
database: vikunja
password: vikunja
primary:
networkPolicy:
enabled: false
auth:
username: vikunja
database: vikunja
password: vikunja
# ┬─┐┬─┐┬─┐o┐─┐
# │┬┘├─ │ ││└─┐