Kubernetes helm-chart support

[DreamingRaven]

Hey, Merry Christmas!

I had some time, and I wanted to deploy PlanarAlly on my infrastructure. To do so I created a helm chart. I wanted to give this helm-chart upstream so others could benefit and to improve visibility. This PR includes:

• The helm chart necessary to deploy PlanarAlly to kubernetes including persistence, ingress, and all the usual goodness in as standard a way as possible.
• Workflows to:
  • Test the helm chart is functioning in a docker container spun up Kubernetes cluster (kind)
  • Automation to keep the README up to date with the values.yaml of the helm chart
  • Automation of helm chart releases to gh-pages which will end up being indexed here https://Kruptein.github.io/PlanarAlly/index.yaml my version is here https://dreamingraven.github.io/PlanarAlly/index.yaml
• Makefile to helm build, and run the local cluster using Minikube to expedite development and local testing

Let me know what you think, hope you have had a merry day thus far!

A few things to note:

• The Makefile is based on podman rather than docker. Podman is the preferred option currently, supporting rootless containers and is vendor-agnostic. Users of docker can install podman, but not all podman users can install docker, since they may not be using the docker daemon or container-d at all (I use cri-o for instance).
• The workflows are somewhat opinionated for their triggers, please feel free to let me know if you would prefer something else.
• The helm chart while it is fairly flexible and sets up a reasonable server it may not fit every single use case, so there may need to be added features in the future as users needs develop.

[Kruptein]

First of all, thanks for taking the time to do this work and check out PlanarAlly!

That said, I'm a bit hesitant to add this to the main repository. Not because I don't think this is valuable, quite the contrary, but I would like to keep the core repository as clutter free as possible and this does add a whopping 719 lines that don't directly influence the main runtime code.

I do appreciate that pretty much all of that resides in the charts folder, but I'm not super familiar with helm myself, which makes it quite the burden for me as I need to ensure that it remains up to date.

Given that I'm not super up to date with helm, is it feasible to maintain this outside of the core repository or does its functionality depend on the source code living in the same directories?

Some things we could try to do:

• you maintain a repository where these files reside and we make sure that the PA documentation clearly marks that as a source to run PA using helm. (the README in this repo also is in dire need of an update and can be more focused on tech people so could also include some links)
• we add it to the pa-docs repo
• I make a new repository that serves as a location for all server related examples / configurations
  • this could also have example nginx / apache / k8s / ... folders/files

Does any of this stand out as something that you can agree with ? I do think the latter could be helpful in general as this isn't the first sort of server config related PR I've had that I find difficult to merge in the main repo, but would have no difficulties with accepting in some more community driven collection of tools.

[DreamingRaven]

Hey @Kruptein, don't worry, these files have absolutely no requirement to live in the same repository! The only link between the two is the docker image which does not exist in the repository anyway: https://github.com/DreamingRaven/PlanarAlly/blob/e9781d2c471c653215f21f2ed0164c83ff3d64bc/charts/planarally/values.yaml#L12-L20

To be fair, I do try to split my helm charts from source, so I do think this is a perfectly reasonable approach to take, plus it makes documenting the helm usage easier. I personally would not (option 2) add it to the docs repo directly (if I understood you correctly) as that feels out of place to me. I am happy with both options 1 and 3, although I realise if you aren't super comfortable with helm / kubernetes option 3 still puts that burden on you somewhat, but as a community repository could work. I am happy to turn this into a bespoke repository (option 1), I also noticed there were other similar such repositories https://github.com/donicrosby/PlanarAlly-k8s.

If it is amiable to you I will draft a bespoke repository (option 1) for now, then if you want to expand it feel free to pull it in to a community fork under your namespace which I will occasionally chip into, for hosting in general (option 3) for helm, compose, raw docker etc. Does that sound alright?

I don't envision lots of updates being necessary no matter what option we pick unless more complex environment variables or configuration files get added but it will need renovate to make sure the docker container being pointed to is kept up to date which is only something like https://gitlab.com/GeorgeRaven/authentik-manager/-/blob/master/renovate.json?ref_type=heads.

[Kruptein]

glad to hear!

I think option 3 is probably the best long term solution, but I think option 1 is good to start with until I set some time apart to properly set something up.

Thanks for the work, I'll close this for now, but feel free to post with any updates.