helm-charts VS charts

Honestly, just use the bjw-s app-template for it. It's not complex enough to warrant a from-scratch chart.

I just spoke with one of the k8s-at-home guys, and he hadn't heard of Helmet either, but he recommended this: https://github.com/bjw-s/helm-charts which has a bit more miles on it, formerly it was published as: https://github.com/k8s-at-home/library-charts – this is in thousands of charts, from what I can tell.

What about your charts being a 1:1 copy of Bernd Schorgers' app-template, formerly kah-common?

Spinning up workloads in kubernetes is much different than just spinning up a container in docker or even with docker compose. If someone has not already packaged it in a helm chart or some other kubernetes workload you'll have to develop one yourself. There are some nice library charts you can use as a base that should handle just about any random docker image you want to deploy. https://github.com/bjw-s/helm-charts/tree/main/charts/library/common there is also a repo of pre developed charts for common images. https://github.com/k8s-at-home/charts but be aware it was recently deprecated so it won't be receiving any updates.

I'm using this chart - it's a swiss army tool for any self-hosted docker containers lacking own helm files.

It seems to have some overlap with a similar library that has been developed over at the k8s-at-home community and later migrated to my personal repo: https://github.com/bjw-s/helm-charts/tree/main/charts/library/common (shameless plug :P).

It very much depends on how you structure and setup your applications. We always try to use Helm charts which means within each environment you have your Helm values and some generic stuff. In some cases we created kinda a blueprint chart which was generic enough to configure whatever we needed. A good example of that could be https://github.com/bjw-s/helm-charts. This keeps the „copy-pasting“ relatively organized and low effort.

Both of these examples seem pretty obvious and something you wouldn’t mess up, but as your chart grows, so does your values.yaml file. A great example is the Redis chart by Bitnami. I encourage you to scroll through its values file. See you in a minute!

We will write a Terraform module that will take a list of configurations for each required RabbitMQ instance. Luckily for us, we don't have to write the Kubernetes yaml configurations since the helm charts by Bitnami does a great job of doing all the things we discussed above. All we need to do is leverage Terraform Helm Provider and deploy the chart with the required values for our use case.

💡  The full details of helm charts can be referenced in their associated GitHub Repository.

I have a configmap with the ndjson set up under data:, similar to https://github.com/bitnami/charts/issues/6159 and it's subsequent answer.

This way, you can easily deploy any Helm charts from this public repo - https://github.com/bitnami/charts/tree/main/bitnami in just minutes.

The Bitnami Github Pages themselves usually cover everything you need to know. Configure a values.yaml file, or modify that to your liking, and you run helm install, as written in their docs.

The actual reason that our pods are not coming up is found when we review the helm installation that we are trying to run. If you check the dependencies in the GitHub repository (https://github.com/bitnami/charts/blob/main/bitnami/drupal/values.yaml) you find out that persistent storage is enabled by default and set to 8Gi. Also, the helm package uses MariaDB and the database size is specified to a default of 8Gi, thus setting the minimum storage for this installation to be 16Gi.

We're using https://github.com/bitnami/charts/tree/main/bitnami/spark, but I have heard good things about https://github.com/GoogleCloudPlatform/spark-on-k8s-operator as well. Hudi should not need any long running deployments as per the docs https://hudi.apache.org/docs/0.5.1/deployment/#deploying

Bitnami has its own scaffolding published at https://github.com/bitnami/charts/tree/main/template