730e165b36
This patch reworks the Pod rolling mechanism, which is supposed to update Pods with each migration run, but since the it generates a new random value on each helm execution, this will constantly roll all pods in a GitOps driven deployment, which reconciles the helm release. This is resolved by fixing the upgrade to the `.Release.Revision`, which should stay identical, unless config or helm release version have been changed. Further it introduces automatic rolls based on adjustments to the environment variables and secrets. The implementation uses a helper template, following the 1-2-N rule, and omitting code duplication. References: https://helm.sh/docs/chart_template_guide/builtin_objects/ https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments |
||
---|---|---|
templates | ||
.helmignore | ||
Chart.lock | ||
Chart.yaml | ||
LICENSE | ||
readme.md | ||
values.yaml |
Introduction
This is a Helm chart for installing Mastodon into a Kubernetes cluster. The basic usage is:
- edit
values.yaml
or create a separate yaml file for custom values helm dep update
helm install --namespace mastodon --create-namespace my-mastodon ./ -f path/to/additional/values.yaml
This chart has been tested on Helm 3.0.1 and above.
Configuration
The variables that must be configured are:
-
password and keys in the
mastodon.secrets
,postgresql
, andredis
groups; if left blank, some of those values will be autogenerated, but will not persist across upgrades. -
SMTP settings for your mailer in the
mastodon.smtp
group.
Administration
You can run admin CLI commands in the web deployment.
kubectl -n mastodon exec -it deployment/mastodon-web -- bash
tootctl accounts modify admin --reset-password
or
kubectl -n mastodon exec -it deployment/mastodon-web -- tootctl accounts modify admin --reset-password
Missing features
Currently this chart does not support:
- Hidden services
- Swift
Upgrading
Because database migrations are managed as a Job separate from the Rails and Sidekiq deployments, it’s possible they will occur in the wrong order. After upgrading Mastodon versions, it may sometimes be necessary to manually delete the Rails and Sidekiq pods so that they are recreated against the latest migration.
Upgrades in 2.0.0
Fixed labels
Because of the changes in #19706 the upgrade may fail with the following error:
Error: UPGRADE FAILED: cannot patch "mastodon-sidekiq"
If you want an easy upgrade and you're comfortable with some downtime then simply delete the -sidekiq, -web, and -streaming Deployments manually.
If you require a no-downtime upgrade then:
- run
helm template
instead ofhelm upgrade
- Copy the new -web and -streaming services into
services.yml
- Copy the new -web and -streaming deployments into
deployments.yml
- Append -temp to the name of each deployment in
deployments.yml
kubectl apply -f deployments.yml
then wait until all pods are readykubectl apply -f services.yml
- Delete the old -sidekiq, -web, and -streaming deployments manually
helm upgrade
like normalkubectl delete -f deployments.yml
to clear out the temporary deployments
PostgreSQL passwords
If you've previously installed the chart and you're having problems with
postgres not accepting your password then make sure to set username
to
postgres
and password
and postgresPassword
to the same passwords.
postgresql:
auth:
username: postgres
password: <same password>
postgresPassword: <same password>
And make sure to set password
to the same value as postgres-password
in your mastodon-postgresql
secret:
kubectl edit secret mastodon-postgresql