Utilize bjw-s's common Helm library.
#13
konrad
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch ":new-helm-chart"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Utilizing the library allows users the same configuration that they expected from
k8s@home, since that's the library that was used. (#10)This greatly decreases the development toil as well, as you can see.
I've created two different
Ingressobjects to decouple thebackendfrom thefrontend, so that users can set up one, the other, or both.I've created this as a draft so that I can get any input you might have, if you want to go this route :)
Todo
[DRAFT] Utilize bjw-s's `common` Helm library.to [WIP] Utilize bjw-s's `common` Helm library.This chart should create all the resources needed now, just need to do some brain gymnastics of what URLs to set the Frontend/Backend to by default...NodePorts perhaps?
@vlasov-y @xeruf thoughts?
I'm essentially trying to mirror what Immich is doing here: https://github.com/immich-app/immich-charts
But of course for Vikunja, and allowing a user to set up:
On top of the optional deployments (Typesense, Redis, PostgreSQL, etc.).
If you guys like where I'm going with this, I can continue on with it from input from you all. If not, no hard feelings either :)
@konrad I can finish this up this weekend if you're still interested in this approach. If not, I'll just keep it on pause :)
@ -0,0 +1,34 @@{{- define "vikunja.backend.hardcodedValues" -}}global:nameOverride: backendIs this a special "backend" or the api service? If it's the api, it should be called api.
(I know there are still parts of Vikunja's documentation where it's called "backend" but I'd like to get rid of that anyway)
Gotchya, I'll rename that to be
apiinstead. I sawbackendin the docs like you said, so I just ran with that.@ -13,3 +1,1 @@{{- toYaml . | nindent 4 }}{{- end }}{{- end }}{{- define "vikunja.serviceAccount.hardcodedValues" -}}Is that a Vikunja user or a system user?
It's a Kubernetes "non-human" user, a Kubernetes-specific object.
I went ahead and removed it, the user can add it to each pod as they see fit :)
@ -16,2 +7,2 @@# If not set and create is true, a name is generated using the fullname templatename: ""env:VIKUNJA_REDIS_HOST: '{{ printf "%s-redis-master" .Release.Name }}'Is there a reason we're using env here and not the config directly?
We should still be able to configure Vikunja as it can be done currently: https://kolaente.dev/vikunja/helm-chart/src/branch/main/values.yaml#L142
There are things that can't be configured via env like openid providers.
Ah, didn't know that. I thought everything was configurable via
envvariables (which I've always found easier to manage), but I'll go ahead and use theconfiginstead.I like the general idea of making the chart simpler.
What about the upgrade path?
Upgrade path (like upgrading to newer versions of Vikunja) would just require a user to reference a newer version of the image at the top of
values.yaml.Not only does it make it simpler, it also allows the user to add/modify the
values.yamlto include any of the keys/values you see here (a081de5302/charts/library/common/values.yaml) to add things such as other services, sidecars, etc.It allows for a ton of customization out of the box, so a user can do whatever they want more or less. Offloading all of the "nuances" a Helm chart would typically have to support (for all of the various weird Cluster configurations) to the
commonlibrary :)Are you phasing out
VIKUNJA_API_URLby chance? I don't see it at https://vikunja.io/docs/config-options/, but I still see it in theinjector.shfor the Docker container...I'm also trying to add some comments to the
values.yamlso that a user is less lost when trying to use the Helm chart. I also intend to update the README.md.I mean upgrading from the current chart to the new one.
No, that's a frontend option. The docs on the page you linked are only for the api.
As long as the api and frontend are reachable under the same domain and port you don't need to set the api url though.
config.ymlto be a string e29dc292b0I see what you're saying - from a user's perspective, what is updating to this version of the Helm chart like. It will definitely require some changes from a user (so therefore it will be a "breaking" change), but will also make it quite a bit easier to support from our end, while still allowing nearly infinite customization.
Understood, it was slightly buried on the Frontend page. I found it now. Thank you!
[WIP] Utilize bjw-s's `common` Helm library.to Utilize bjw-s's `common` Helm library.@konrad should be ready for another readthrough whenever you're free, I'm confident this now both works and delivers on expectations.
@ -3,3 +3,2 @@Customizable deployment of frontend and api.Deploys bitnami's PostgreSQL and Redis as subcharts if you want.Deployes both frontend and api. Also, you can deploy bitnami's PostgreSQL and Redis as subcharts if you want.Typo: Should be "deploys"
oops, thanks for catching that! fat finger
d8500214e9@ -13,3 +12,2 @@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.config`: https://vikunja.io/docs/config-optionsThe 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: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?:
688a055c36Looks good!
@ -0,0 +28,4 @@custom: truespec:httpGet:path: /api/v1Shouldn't this use
/api/v1/infoas/api/v1will usually give an error?LOL, I've gotta say, that explains a lot about my own Vikunja deployment after realizing that
/api/v1returns a401...fixed!
61b8892ff0hehe yeah there's an item in the backlog to add a
healthendpoint eventually which would also check if the db connection works etc.@ -163,0 +17,4 @@####################### VIKUNJA COMPONENTS ######################## You can find the default valuesDoesn't this need a link to the docs with the default config?
fixed
d8500214e9@ -183,0 +37,4 @@# proxy-body-size is set to 0 to remove the body limit on file uploadsnginx.ingress.kubernetes.io/proxy-body-size: "0"hosts:- host: vikunja.localWhy
vikunja.local?The existing chart has “chart-example.local”, I figured that changing that to “vikunja.local” would be more Vikunja “branded”, if you will, lol.
I can change it back if you would prefer!
I'm fine with either but it should be clear that the value is only an example value and should be changed.
7d2f43fee3@ -183,0 +57,4 @@host: '{{ .Release.Name }}-postgresql'service:# Vikunja needs to know the frontend URL for password reset emails.frontendUrl: http://vikunja.localBut the default value for this one is the one defined in the ingress, why define it here again?
Fair, forgot to use the
ingressvalue for that variable as well. I went ahead and fixed it. I also included a comment to to the user incase they aren't using aningressresource (I was even using aServicebehind a central Nginx until recently)fixed!
9cd4680e70andc601e5e449@ -0,0 +40,4 @@{{ if and .Values.frontend.ingress.enabled .Values.api.configMaps.config.enabled}}configMaps:# The configuration for Vikunja's backend.Nitpick, but please use "api" here instead of "backend".
Done:
76b209a70c:)@ -0,0 +59,4 @@VIKUNJA_TYPESENSE_ENABLED: "true"{{ end }}# Logic to decide what the api URL should beBut it's called "frontend url", why call it "api url" in the comment?
Also what is that value used for? Vikunja itself does not use it.
Yeah that logic was in the wrong place, that was meant for the Frontend container to "learn" what the API URL was. Fixed:
3ea99647e2/apito/api/v1envkey.I've opted to using the
envkey for theapicontainer, since Helm templating is enabled on the environment variables - so users can providesecretRefto reference an external secret (that could hold the user's PostgreSQL password, etc.).I've deployed this to my Kubernetes cluster, and two other unlucky victims (friends) have it running in their cluster as well.
@ -20,2 +17,3 @@### Registration (creating users)### ReplicasYou 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`: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
valuesof the Helm deployment to create theconfig.ymland make changes. Would it be adequate to perhaps rename the section to "Example of how to createconfig.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!
ce56e07518Renaming is great!
@ -0,0 +16,4 @@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" }}"What if the api ingress is using https?
By default,
ingress-nginxredirects HTTP to HTTPS and the annotationnginx.ingress.kubernetes.io/force-ssl-redirect: "true"can be used with other Kubernetes Ingress objects to redirect HTTP to HTTPS. It's "normal" in the deployments I've created to have to create that annotation on the Ingress if I've required that redirection (or the other way around :))Thank you very much for the effort!