Updated example to deploy on Kubernetes using Helm Chart

[alvarolop]

Hello,

We have been extensively using the Matomo Bitnami Helm Chart for several demos and workshops. Due to the recent changes in the Bitnami catalog (https://github.com/bitnami/charts/issues/35164) we need to migrate to a better solution.

I’ve seen an example of how to deploy Matomo in Kubernetes/OpenShift using a Helm Chart but the configuration does not use the latest version. I’m not a Matomo expert to create it myself.

Is there a more complete Helm Chart in another of your repos or can we work together to develop one that could be contributed to this repository.

Best regards,

[achangjvi22]

We've ended up creating my own for our deployments, since I never found one that really worked out there. The issue is with auto-provisioning via the chart. I've not found a way to programatically do that. It wasn't an issue for me since we were converting from VM's to Kubernetes, we already had the config file in place. We also bake our own images from source.. We had chosen to use Nginx Unit with PHP vs Nginx with FPM multipod or Nginx-FPM single pod because of speed... But of course Nginx-Unit is also not being maintained now as of October, so we're making changes now.

The key is to persist the config.ini.php file in a PVC or direct NFS share, since any changes from the interface needs to be shared with other replicas which rules out a ConfigMap.

Then we've also found out that we needed to persist on the NFS share:

• /misc/user - for custom logos (although we could have baked this in to the image)
• /var/www/html/misc/DBIP-City.mmdb - since any-one replica may update this periodically and it needs to be available to each replica
• matomo.js - since if you're making changes to js trackers for new sites or changing the dimensions, this maybe updated by matomo.

Otherthan those persistent files, if you end up using a cronjob for archiving, you'd need to include in the chart provisions for running the archiving process as a Kubernetes CronJob.

And as of a few weeks ago, with the deprecation of Ingress-Nginx, a Gateway API deployment to route traffic to matomo... Which is what we're doing now as well..

I think at least with the files I've pointed out that need to persist, you can create a pretty simple chart from there.. Provisioning new instance though, is still a bit manual from our side, since we never looked in to figuring out how to create the Salt and provision the db... yet..

[alvarolop]

Hello @achangjvi22, thank you for your extensive answer. I might not have that kind of issues because our Matomo deployment was more experimental than production-ready. This is what we ended up doing:

• We use the bitnami original chart and we point to the dockerlegacy organization that still have the old container images for a while.
• We added the OpenShift Route creation to the values.yaml (Equivalent to the Gateway API but for OpenShift).

This is enough for us right now, with minimal effort, but we know that this is a temporal solution and that we will need to fully migrate to a solution that is not based on Bitnami.

[J0WI]

IMHO an official Heml Chart would be better suited in a dedicated repository in matomo-org to maintain it's own release schedule.