Mastodon is an open-source, federated (i.e., decentralized) social network, inspired by Twitter's "microblogging" format, and used by upwards of 4.4M early-adopters, to share links, pictures, video and text.
Why would I run my own instance?
That's a good question. After all, there are all sorts of public instances available, with a range of themes and communities. You may want to run your own instance because you like the tech, because you just think it's cool
You may also have realized that since Mastodon is federated, users on your instance can follow, toot, and interact with users on any other instance!
If you're not into that much effort / pain, you're welcome to join our instance
The Mastodon project doesn't currently publish a versioned helm chart - there's just a helm chart stored in the repository (I plan to submit a PR to address this). For now, we use a GitRepository instead of a HelmRepository as the source of a HelmRelease.
We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the flux design, I create this example yaml in my flux repo at /bootstrap/namespaces/namespace-mastodon.yaml:
/bootstrap/namespaces/namespace-mastodon.yaml
apiVersion:v1kind:Namespacemetadata:name:mastodon
Kustomization
Now that the "global" elements of this deployment (just the GitRepository in this case) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at /mastodon. I create this example Kustomization in my flux repo:
apiVersion:kustomize.toolkit.fluxcd.io/v1kind:Kustomizationmetadata:name:mastodonnamespace:flux-systemspec:interval:15mpath:mastodonprune:true# remove any elements later removed from the above pathtimeout:2m# if not set, this defaults to interval duration, which is 1hsourceRef:kind:GitRepositoryname:flux-systemhealthChecks:-apiVersion:apps/v1kind:Deploymentname:mastodon-webnamespace:mastodon-apiVersion:apps/v1kind:Deploymentname:mastodon-streamingnamespace:mastodon-apiVersion:apps/v1kind:Deploymentname:mastodon-sidekiqnamespace:mastodon
ConfigMap
Now we're into the mastodon-specific YAMLs. First, we create a ConfigMap, containing the entire contents of the helm chart's values.yaml. Paste the values into a values.yaml key as illustrated below, indented 4 spaces (since they're "encapsulated" within the ConfigMap YAML). I create this example yaml in my flux repo:
Commit the changes to your flux repository, and either wait for the reconciliation interval, or force a reconcilliation1 using flux reconcile source git flux-system. You should see the kustomization appear...
Now hit the URL you defined in your config, and you should see your beautiful new Mastodon instance! Login with your configured credentials, navigate to Preferences, and have fun tweaking and tooting away!
What's my Mastodon admin password?
The admin username may be output by the post-install hook job which creates it, but I didn't notice this at the time I deployed mine. Since I had a working SMTP setup however, I just used the "forgot password" feature to perform a password reset, which feels more secure anyway.
If your instance feels lonely, try using some relays to bring in the federated firehose!
Summary
What have we achieved? We now have a fully-swarmed Mastodon instance, ready to federate with the world!
Summary
Created:
Mastodon configured, running, and ready to toot!
Chef's notes 📓
There is also a 3rd option, using the Flux webhook receiver to trigger a reconcilliation - to be covered in a future recipe! ↩
Tip your waiter (sponsor) 👏
Did you receive excellent service? Want to compliment the chef? (..and support development of current and future recipes!) Sponsor me on Github / Ko-Fi / Patreon, or see the contribute page for more (free or paid) ways to say thank you! 👏
Employ your chef (engage) 🤝
Is this too much of a geeky PITA? Do you just want results, stat? I do this for a living - I'm a full-time Kubernetes contractor, providing consulting and engineering expertise to businesses needing short-term, short-notice support in the cloud-native space, including AWS/Azure/GKE, Kubernetes, CI/CD and automation.
Want to know now when this recipe gets updated, or when future recipes are added? Subscribe to the RSS feed, or leave your email address below, and we'll keep you updated.