Mastodon, Part V: Installing and configuring Mastodon

This article is part of a series about installing and configuring a Mastodon instance on a cluster of Raspberry Pi computers running k3s. To go back to previous articles in the series, try any of the links below:

1. Introduction
2. Part I: My home network topology
3. Part II: The Mastodon Helm chart
4. Part III: Configuring and installing prerequisites
5. Part IV: The waking nightmare that is Let’s Encrypt
6. Part V: Actually installing Mastodon (this post)
7. Conclusions

Heyyy, we’ve finally arrived! Months and multiple blog posts later, here’s how to actually install a Mastodon instance on your k3s cluster of Raspberry Pi computers!

helm dep update
helm install mastodon ./ \
    --create-namespace \
    --namespace mastodon \
    -f path/to/custom/values.yaml

The dep update will pull down any new versions of the Bitnami charts needed to install the prerequisites we went over in Part III.

The install command creates an application called mastodon, using the templates in the current directory (hence ./), creates a new k3s namespace named mastodon for all the pods to occupy, and then the -f flag provides a path to the values.yaml file we customized back in Part II.

Is that it?

A lot of things are going to happen at this point.

First, there a couple of pods that will appear as one-time “jobs”, the most notable (to me) of which is the precompile pod. This one in particular can take awhile… or maybe it was just because it was running on little Raspberry Pi SBCs; the 4Bs are certainly fast, but they’re still pretty resource-constrained by workstation or server standards, so be patient here. Just because it’s taking awhile for anything to show up doesn’t mean something is wrong.

Second, there is a db-migrate job that kicks off. Despite the name, this actually happens both if you’re migrating and if you’re installing Mastodon for the first time. For some reason, there’s a race condition among these initial one-time pods, and if the db-migrate job doesn’t kick off right when it’s supposed to, it may never happen; there’s an open ticket looking at this problem and a PR with a proposed fix that hasn’t yet been merged. It’s something to keep an eye on; there are manual fixes specified in the open issue (basically the pod equivalent of turn-off-and-back-on) that I had to employ at least a couple of times.

Finally, there was an issue with sidekiq not properly registering the ingress task–kind of important for an application that relies heavily on ingress activity! But it required a very simple one-line addition to the values.yaml file, and it’s not even an issue anymore since this PR was merged back in early December 2022.

Yep, that’s it

And that’s pretty much it! You should have a shiny new Mastodon instance up and running at this point (hit the ingress endpoint to check it out)! Your work as instance administrator is only just beginning, though–you need to check out all the options you have available in terms of setting up and configuring your instance (creating its welcome message and purpose, setting up how new accounts register, and importing any new emojis you might want), but in terms of command line kubernetes, with the exception of continued maintenance and occasional updates, that’s it!

I’ll have a wrap-up post coming soon with more of my own thoughts on the whole process.