Helm Bundle with Redis and PostgreSQL using helm optional dependencies
Hey I just wanted to check if any work was being done towards creating a bundle chart with redis and postgresql included.
If not then I would like to contribute, my thoughts are not to create a new helm chart but to enable options in the existing chart to create the services (so there is no repetition).
The best way to achieve this is likely using helm optional dependencies
I am thinking to have them off by default to maintain backward compatibility where possible. However if there is a conflict in the already existing values.yaml it may be possible something needs to change to prevent overriding a child charts options since the redis and postgresql dependency will respond to the redis and postgresql objects in values.yaml by default (I will confirm if there is any conflict in this way later).
Let me know if this is amiable as I would rather not have to overlay these components seperateley if I don't have to, as its nicer to do it from mainline.
There isn't currently, it would be nice to find a set of charts that already support this and use images which support arm64, but I have not been able to find any, however it has not been a priority of mine as of late.
Ah I did not realize arm64 support was a condition.
Yes you are right many charts like the bitnami charts in particular tend not to support arm64 (as i recently discovered with ingress-nginx chart in my mixed architecture homelab cluster). Being as this will be an opt-in sort of thing, would it not be ok to use a non-arm64 chart anyway as a stopgap? Then in future if work is done elsewhere to make a much more multi-architecture chart we can swap charts since it will be a case of changing the dependency reference and a few options to match the new chart to the older one.
It wasn't specifically a condition, but felt like a likely roadblock to some users. Feel like adding it without that will lead to additional maintenance issues and a large refactoring later. I may be overthinking it though,
By virtue of helm dependencies being mostly separate I think this should be relatively minimal. In theorey it will still be the same redis or postgresql just managed by different variables in a different chart when it is time to swap over. So I believe it shouldn't be an ordeal to refactor if necessary.
The way i see it, currently a good set of users will try the current chart and find it does not come with batteries then be turned off. At the very least this way with a few options they can at-least spin up a proof of concept instance with sane defaults, and if they want to get really invested then they can probably worry about spinning their own instances of redis postgres etc for other architectures.
However if you are not comfortable with this, that is completely fine I understand. For now I can just overlay my own separately, it just would have been cleaner and benefited more people to be included here even if behind enable flags.
Ok so to follow up on this, I have created my own gitlab-based helm chart from scratch to fulfill this need. Batteries included just add SMTP.
It fully integrates Authelia Docker with Postgres, Redis, OpenLDAP, (all pinned versions) their volumes/ persistence. It also comes with the necessary network policies to lock down ingress and egress. It even comes packaged with necessary management tools like phpldapadmin and postgresadmin (only accessible by kubectl port-forward atm). It will be default create shadow users you specify with random passwords, so you can administer everything immediately. Everything is tied to a central secret that is automatically generated for you, and can be disabled to replace with your own/ make persistent values. I even use it with bitnami sealed-secrets by overlaying the sealed-sealed secret and disabling the charts own secret generation.
https://gitlab.com/GeorgeRaven/authelia-helm I am still cleaning up a few things like the authentication backend file provider. This should allow people to quickly test / POC Authelia and let them hit the ground running. It is all versioned and integrated to gitlab CI/CD along with gitlab helm package registry.
@james-d-elliott Thanks for taking the time to respond to me previously, if you have a chance to have a look over this chart please let me know if there is anything you would like to see in it for a batteries included PoC install. Hopefully this can scratch that itch that other may have like I did.
I built some cookie cutter charts for redis/postgres that you should be able to use and mod pretty simply. https://github.com/htaic/helm-charts/tree/main/charts/redis https://github.com/htaic/helm-charts/tree/main/charts/postgresql
Bitnami now publishes arm64 versions of redis, mariadb and postgresql. I am a new user of Authelia, but this would be useful to me - so if there are no objections then I'll crack on and make a PR for this.
This should have been closed via #223 and #225 but it's still open
It's not merged into master yet, when it is it will be automatically.
Just to give up an update. I submitted PRs #223 and #225 to add support for subcharts. They seemed to work fine in testing but we encountered problems merging this in, so it was reverted.
Turns out this is a bug in Helm which I have reported in https://github.com/helm/helm/issues/12992 but nobody seems to know what the problem is. Helm maintainers have been able to reproduce the problem by forking this repo, but not by copying the Chart.yaml into a new repo. I don't think they're placing a high priority on the issue.
So this feature is kind of blocked, but the root cause seems to be "something" that is different about this specific chart repo. I can't figure out what's going on, and the lack of bundled database is holding up my project, so I'm tempted to just copy this chart into my own repo and be done with it. Unless anyone else wants to have a go at figuring out what's wrong?