-
Notifications
You must be signed in to change notification settings - Fork 2
Fix per node example script #9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Fix issue pgEdge#6
|
Hi @zguig52 - these examples are built around leveraging the hostnames provided to services in docker-compose - so postgres-n1 / postgres-n2 are the correct hostnames that we want to wire up subscriptions for in spock. The purpose of these examples are to quickly try out these images (postgres + extensions) without really changing anything - the distributed one is primarily for giving you a quick path to trying out spock. The issue referenced in this PR seems to be providing hostnames / specific IPs to some of these variables, which seems a bit beyond the intent of the examples. These aren't really for production usage. If you can tell me a bit more about how you are using or have adapted this example, I can consider incorporating it into the examples without breaking their purpose, or suggest another tool for you that might be easier to use. One idea to perhaps support solving this issue would be to support a |
|
Hi @mmols , Thanks for your feedback. I just finished testing deployment of pgEdge, which seems a promising "Galera like" extension for PostgreSQL. Thanks for your work on this project. I will test / use it more closely in coming days. I started by following a bit "blindly" the examples from the repo but had to rework it a bit. My target was to deploy a single PG instance for multiple DB / projects. Hereafter are some feedbacks and improvements I did that could simplify pgEdge deployment / use in container contexts.
I changed the scripts to customized postgresql.conf + pg_hba.conf, including all customized configuration for Spock. For pg_hba, I changed the deprecated md5 authentication scheme to the current scram-sha-256 scheme for (could be customized for less open private networks): For postgresql.conf, I directly included extensions required load + spock requirements, which are these non default parameters: For the initialisation, I adapted the example scripts like this, by using the same current node syntax as for all nodes syntax: With these 3 files, deployment is quite easy, with following configuration (example for podman rootless quadlet files). databases.network: postgresql.pod: postgresql.container:
Once the containers are mounted with the custom conf and init script inside auto bootstrap folder, once all nodes are started, I is only needed to call again the same to finish the wiring. Another advantage is that you can also call the same script with 3 other env vars, to create a new user/password + db for any project: What do you think of this strategy?
Have you already tried to pass extensions + spock related SQL to the template1 DB, so when creating a new DB, everything is already prepared for multi-master use?
|
Fix issue #6