-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Description
Name and Version
bitnami/mastodon
What architecture are you using?
amd64
What steps will reproduce the bug?
On the latest version of k3s, deploy the 3.2.2 helm chart through Argo CD with the below values passed into an ApplicationSet.
Since there's no values in the bitnami/mastodon chart's values.yaml for sslcert, sslmode, sslkey, or sslrootcert, I was using the equivalent PG env vars via the extraEnvVars parameters for all sections of the values.yaml that allow them, along with extraVolumes and extraVolumeMounts for the actual certs. Since these are not passed into the initContainers, the wait-for-db container will timeout trying to connect to the database.
Are you using any custom parameters or values?
## @section Mastodon Web Parameters
web:
replicaCount: 1
## Mastodon web resource requests and limits
## ref: http://kubernetes.io/docs/user-guide/compute-resources/
resources:
limits: {}
requests: {}
# Array with extra env variables to add to Mastodon web nodes
extraEnvVars:
- name: "PGSSLCERT"
value: /etc/secrets/mastodon/tls.crt
- name: "PGSSLKEY"
value: /etc/secrets/mastodon/tls.key
- name: "PGSSLROOTCERT"
value: /etc/secrets/ca/ca.crt
extraVolumes:
- name: postgres-ca
secret:
secretName: mastodon-postgres-server-ca-key-pair
defaultMode: 0440
- name: postgres-client-certs
secret:
secretName: mastodon-postgres-mastodon-cert
defaultMode: 0440
extraVolumeMounts:
- name: postgres-ca
mountPath: /etc/secrets/ca
- name: postgres-client-certs
mountPath: /etc/secrets/mastodon
externalDatabase:
host: mastodon-postgres-rw.mastodon.svc
port: 5432
user: mastodon
database: mastodon
existingSecret: "mastodon-pgsql-credentials"
existingSecretPasswordKey: "password"What is the expected behavior?
The expected behavior is that ssl/tls connections are supported in the values.yaml under externalDatabase like:
externalDatabase:
sslmode: ""
sslcert: ""
sslkey: ""
sslrootcret: ""Then in the init container, include that in the connection string here:
| mastodon_wait_for_postgresql_connection "postgresql://${MASTODON_DATABASE_USER}:${MASTODON_DATABASE_PASSWORD:-}@${MASTODON_DATABASE_HOST}:${MASTODON_DATABASE_PORT_NUMBER}/${MASTODON_DATABASE_NAME}" |
And then the wait-for-db container would maybe come up. Other alternatives are:
- passing in the
web.extraEnvVars,web.extraVolumes, andweb.extraVolumeMountsto the web init container. - allow disabling of the wait-for-db container
What do you see instead?
The mastodon web pod is in an Init:CrashLoopBackOff Status:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mastodon-web-854947446-xr4x9 0/1 Init:CrashLoopBackOff 20 (55s ago) 149m
$ kubectl logs -c wait-for-db mastodon-web-854947446-g8lg4
mastodon 15:40:11.06 INFO ==> Waiting for PostgreSQL to be ready at mastodon-postgres-rw.mastodon.svc:5432/mastodon
mastodon 15:43:41.72 ERROR ==> Could not connect to the PostgreSQL databaseAdditional information
No response