NOTICE: Helm chart rework + future deprecation of this chart.

[timetinytim]

We have some big plans for our official Mastodon helm chart.

The way we've been developing and distributing the current helm chart has been less than ideal in a few different ways, and since there's been a shortage of time and people to work on making this chart better & address users' issues and suggestions, development of this particular chart has not always followed best practices or used consistent conventions. So as a result, we want to move this chart to a new home, clean up the bloat, and refactor it into a couple different charts to better suit different use cases.

Our overall goals for this are:

• Host our helm charts from a git repo that has helm repo support (helm repo add ...).
• Host multiple helm charts out of one github repo.
  • Initial idea is one chart which includes dependencies, and one standalone for those bringing their own.
  • Allows us to host other helm charts that we write/utilize in our own instances.
• Refactor/simplify the chart itself to be less bloated, and be more consistent with best practices and conventions.

All of this means that we will need to create a new git repository to host this. The new home for these charts will be located here once they're ready: https://github.com/mastodon/helm-charts.

This also means that this chart will eventually be deprecated, but we have no intention of doing it right away. Now that we have more resources to devote to the helm charts, we be going through all the issues and PRs in this chart, and addressing/incorporating them wherever we can, which will all be carried forward into the new chart. And this chart will continue to be supported for a while after the new charts' release to give everyone time to transition. However, because of these plans, any PRs or suggestions that result in large or fundamental changes will have to be rejected for the time being until the new repo is up and ready to go.

Please feel free to comment with any concerns or questions you might have!

[24367dfa]

Have you considered using the github container registry to release the helm chart?

[WyriHaximus]

Excited to see this, installing Mastodon through TerraForm is a pain with the current setup.
Will the new chart be able to in-place update installs of this chart without any downtime?

[timetinytim]

@24367dfa
We have! That's one thing the new repository will be able to do. The way the current repo is set up doesn't allow this.

@WyriHaximus
Ideally yes, but we will have to see. One of the issues with the current chart is a lack of naming consistency, both within the code and in the resources created, and we want to fix that as well. But I personally definitely want it to be easy to update in-place, as that's what I want to do with the official instances 🙂

[WyriHaximus]

@timetinytim Well, you could fix that with a multi step upgrade process using multiple versions to do that seamlessly. Happy to help test that

[abbottmg]

I have a couple things I've implemented in a wrapper chart for my instance, which may be beneficial to this new effort. I'll bring them up here since it looks like early days on the other repo:

• I wrote a pair of templates that allows more flexibility with ingresses, with the particular aim of accepting a list of hosts, each with a list of paths, and customizing ingress config at each point in that tree. One template handles in-cluster endpoints (useful for matching mastodon's default nginx conf and adding additional subdomains for monitoring or anything else the k8s project may want to support directly) while the other handles external endpoints (namely my S3 provider). The two templates can be combined as a refactor pass if others want to use it
• A basic deployment of statsd, prometheus, and grafana, along with a nice statsd mapping from an IPng blog post
• Rather than maintaining separate charts for postgres and all the ancillary tools that benefit it (eg pgbouncer, patroni for HA), I evaluated and ended up using the CrunchyData postgres operator. It offers a full postgres stack of the below tools, with a well thought out CRD and--more importantly IMHO--all the intercompatibility work done for each supported major version of pg:
  • postgres
  • pgbouncer
  • patroni
  • pgbackrest
  • pgAdmin
  • monitoring via pgMonitor (including support for prometheus, grafana, alertmanager) and pgnodemx

The PGO is notable in that they actually prefer that downstream developers implement and maintain their own chart to configure the CRD, asking that you at least fork their example repo chart rather than rely on them to publish the chart. It's a strange choice, and the example chart has a pretty good values hierarchy and handles most cases well, but the choice does align with your desire to own the dependency charts. You could even fork the operator chart as well, but I think pinning particular commits within the CRD chart would be fine. Either way, this would provide access to really solid support and documentation for setting up a postgres stack with relatively little effort compared to implementing a similar stack.