Add external loadbalancer support

[JonSchaeffer]

When running PostgreSQL clusters created with this tool in Google Cloud Project's Google Compute Engine, using VIP is not an option. Because of this, external Load Balancers like GCP's offering are needed. The networking behavior of GCP's load balancers creates a separate route on each VM the LB is applied to.

Because of this, the listen addresses for Patroni and PostgreSQL need to be updated to have the applications listen to the newly added routes. I had some trouble adding multiple IPs for Patroni's rest api service, so that is set to 0.0.0.0:{{ patroni_restapi_port }}. But I am able to specify each IP needed for the PostgreSQL config.

Additionally, there are two variables added in vars/main.yml.

• with_external_load_balancing | bool that can be set if the user wants to use external LBs or not
• load_balancer_ips | map that the user can add in the IPs for their load balancer(s).

I have been running this changes on a fork with success. These updates help with management. If I need to make an update to pg_hba.conf and run the update_config playbook, my patroni/postgresql listen address changes get re-written.

Best, Jon

[vitabaks]

Hi @JonSchaeffer Thank you for your contribution.

I understand that a special approach is needed for cloud providers, and I'm already working on it - https://github.com/vitabaks/postgresql_cluster/pull/464

Regarding this change, I suggest that instead of variables with_external_load_balancing and load_balancer_ips, just add the patroni_restapi_listen_addr and postgresql_listen_addr variables and leave the value 0.0.0.0 by default, to simplify the implementation and give the opportunity to set stricter rules (limit the list of addresses) who needs it.

What do you say?

Example:

pgbouncer_listen_addr: "0.0.0.0"
pgbouncer_listen_port: 6432

postgresql_listen_addr: "0.0.0.0"
postgresql_port: 5432

patroni_restapi_listen_addr: "0.0.0.0"
patroni_restapi_port: 8008

[JonSchaeffer]

Hi @vitabaks Thanks for the quick response.

I like your approach too. I think its more declarative and explains a bit more whats going on behind the scenes. Whereas my change may hide a little too much. I'm not sure how LBs reroute traffic in Azure or other providers so I'm probably not considering some cases. Your proposed change is more than adequate for me!

Best, Jon

[vitabaks]

@JonSchaeffer I created a separate PR (https://github.com/vitabaks/postgresql_cluster/pull/598) where I added patroni_restapi_listen_addr and postgresql_listen_addr variables.

I'm closing this PR.