Open srflaxu40 opened 4 years ago
We currently don't support Pod lifecycle hooks. We bootstrap databases via Patroni/Spilo. Not sure, if the operator should do any additional bootstrapping other then database/role setup. We've already planned to improve the latter, but running any kind of DB setup (see also #366) I would better leave it to schema migration tools.
How do you deploy spilo within the zalando/postgres-operator framework?
I guess for that question you head to the operator repo.
Most basic and bootstrap that is part of every pg cluster happens in spilo on promote, that is how we roll out defaults and also add new stuff as part of a rolling upgrade.
Everything else we encourage to rely on Flyway or similar to deploy and bootstrap application specific changes.
Thanks, @Jan-M and @FxKu .
Curious question - if I were to use patroni to do something with this:
post_bootstrap or post_init: An additional script that will be executed after initializing the cluster. The script receives a connection string URL (with the cluster superuser as a user name). The PGPASSFILE variable is set to the location of pgpass file.
Where do I define this? Currently I deploy the zalando postgres-operator in its own chart, and then downstream I deploy our minimal pg cluster with a different chart we created. It is pretty basic, but how would I feed things like post_init
to it? Here is the template file under the chart's ./templates/
directory for example:
---
apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
name: test-postgres
spec:
teamId: {{ .Values.database.teamId }}
volume:
size: {{ .Values.database.size }}Gi
numberOfInstances: 1
users:
{{ .Values.database.user }}: # database owner
- superuser
- createdb
databases:
datahub: {{ .Values.database.user }} # dbname: owner
postgresql:
version: "11"
If you need this in every Postgres cluster then you better do a tiny overlay image over our Spilo image where you just add this file in the right place. And then use that image via the Postgres operator.
For testing you can also specify the new image in the postgres manifest.
@Jan-M Thanks for the advice! One thing I am having trouble wrapping my head around is I get that postgres-operator uses patroni/spilo stuff under the cover but how do I utilize patroni attributes and environment variables in my postgres cluster manifest when actually deploying a cluster (after pg operator is already running in k8s)?
I'd like to be able to set PG USERNAME/PASSWORD and PGPASSFILE type stuff.
@Jan-M Perhaps call the patroni post_init from a cluster manifest? Where would I put it in this example:
---
apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
name: test-postgres
spec:
teamId: {{ .Values.database.teamId }}
dockerImage: {{ .Values.image.repository }}
volume:
size: {{ .Values.database.size }}Gi
numberOfInstances: 1
users:
{{ .Values.database.user }}: # database owner
- superuser
- createdb
databases:
datahub: {{ .Values.database.user }} # dbname: owner
postgresql:
version: "11"
Is there a proper place for this in the downstream cluster 'spec' (or postgres operator spec)?
Was also wondering about this, I check both operator & spilo (version we're running) sources and I don't see any entry into CR manifest to do so. Perhaps running a basic side car container with a common volume with the STS to change few envdir files (specially log ones, can't change region, we're using OVH)
P.S: BTW init containers won' t work, spilo overrides them after bootstraping
Hi @FxKu
In zalando when we specific post_bootstrap or Post_init invalid field, Can we use this options in zalando?
error: error validating "post_test.yaml": error validating data: ValidationError(postgresql.spec.patroni): unknown field "post_init" in do.zalan.acid.v1.postgresql.spec.patroni; if you choose to ignore these errors, turn validation off with --validate=false
error: error validating "post_test.yaml": error validating data: ValidationError(postgresql.spec.patroni): unknown field "post_bootstrap" in do.zalan.acid.v1.postgresql.spec.patroni; if you choose to ignore these errors, turn validation off with --validate=false
Is there a way to run an initialization script that I used to run when using postgres as a statefulset using the lifecycle policy?