While the normal assumption of port `5432` for a postgresql server is pretty reliable I found that DigitalOcean puts them on a somewhat random port. This adds the ability to specify the port in the helm chart.
ENABLE_STARTTLS is designed to replace ENABLE_STARTTLS_AUTO by accepting
three values: 'auto' (the default), 'always', and 'never'. If
ENABLE_STARTTLS isn't provided, we fall back to ENABLE_STARTTLS_AUTO. In
this way, this change should be fully backwards compatible.
Resolves#20311
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
This patch updates the helm chart appVersion to the current release and
removes the additional definition in the image tag field, to reduce
duplication.
Since the image will automatically default to the Charts' app version
anyway and this is the more common place to specifiy application
versions for helm charts, this patch switches the prefering this field.
The reason why to use the tag field for the chart itself, seems to be
gone. Since renovatebot is no longer used.
* Mark job pods not to use Istio's envoy sidecar
Istio injects sidecars into pods to implement mTLS between pods. Jobs
usually don't know about this, so they don't signal the Envoy process
to stop when the job finishes. Since at least one process is running
in the pod, Kubernetes doesn't consider the job to be completed, so it
lingers.
By adding the `sidecar.istio.io/inject` annotation set to `"false"`,
we let Istio know that it should not inject the sidecar. If Istio is
not installed, then this has no impact.
* Support arbitrary job annotations in the Helm chart
Rather than focus on Istio, this allows arbitrary annotations for job pods.
* Add in-line documentation for pod/job annotations
* Add ability to specify an existing Secret (#18139)
Closes#18139
* Allow using secrets with external postgres
* Upgrade CronJob to batch/v1
* Allow using redis.auth.existingSecret
* Helmignore mastodon-*.tgz for easy local development
* Upgrade helm dependencies
* Upgrade postgresql to 11
* Allow putting SMTP password into a secret
* Add optional login to SMTP secret
This to allow setting LOGIN either in values.yaml or
in the secret.
* Switch to bitnami charts full archive
This prevents older versions from disappearing, see
https://github.com/bitnami/charts/issues/10539 for
full context.
Co-authored-by: Ted Tramonte <ted.tramonte@gmail.com>
This adds a mastodon.streaming.base_url setting in the Helm chart values
file to allow setting the STREAMING_API_BASE_URL in the Mastodon environnment
config map.
* Bump version to 3.5.2
* Change some entries to be more clear
* Add some extra notes
* Fix line wrap
Co-authored-by: Eugen Rochko <eugen@zeonfederated.com>
- move application variables under `mastodon` namespace
- restore standard yaml structure for ingress configuration
- move values.yaml.template to values.yaml
The cronjob tries to get key from `mastodon` secret instead of
`mastodon-postgresql` - so the cronjob fails with this error:
Error: couldn't find key postgresql-password in Secret [NS]/mastodon
Another solution is to save the postgres password in mastodon secret,
but that means that the password is placed in two places.
Postgresql use <fullname>-postgresql name as secret name.
