They're Chef custom resources (https://docs.chef.io/custom_resources/), the concept that replaces LWRP (https://chef.readthedocs.io/en/latest/lwrps_custom.html)
TLS with Let's Encrypt is easier to set up than a self signed cert on all machines. In my experience generating self-signed certs in a pain in the ass.
If the primary PostgreSQL server is for example andromeda.kosmos.org with TLS, changing it to another server in the client configs is the same amount of work as changing an IP (changing the FQDN)
re: TLS, it's still useful between clients and servers even with firewall rules and access rules
I ran into a Chef bug that appears to be caused by the implementation of custom resources. Notifications are broken, so adding an access rule using the postgresql_access does not reload the service: https://github.com/sous-chefs/postgresql/issues/648
The custom resource I wrote was really useful since so much code is identical between a primary and a replica, but I might have to rewrite it another way (move the access rules to the recipe, for example). With this bug reloading the PostgreSQL service manually is needed after adding a new rule
I created a repo to reproduce the issue, a maintainer will take a look at it
This took more work than I originally thought to get it right, but I'm getting satisfied with the Chef resource I wrote to set up a PostgreSQL primary or replica, with a TLS cert provided by Let's Encrypt.
Now I'm going to perform the PostgreSQL upgrade in a VM and make sure everything goes smoothly
LGTM! Let's merge after deploying it, in case the turn_ip is required for STUN to function
As discussed in #147 it makes sense to first upgrade the current PostgreSQL server on andromeda to version 12, since the replication configuration has been improved (and simplified). In version 10 the replication settings had to be added to a config file in the data directory, since 12 they live in postgresql.conf with the rest of the config.
I have followed this tutorial to set up replication between two VMs: https://www.percona.com/blog/2019/10/11/how-to-set-up-streaming-replication-in-postgresql-12/
The new set up will have PostgreSQL run with TLS enabled, with certs generated by Let's Encrypt, so the clients and replication can be achieved securely.
In order to secure the servers, we will use a firewall rule that only allows connections from the IP of the servers that need it. We will also use client authentication to limit access to specific databases for each server, and allow for the replication server to the replication database
Now I need to remove some hardcoded values from the new recipes, using instead values from the Chef nodes living in the repo in nodes
I think we can start with the upgrade to 12 on Andromeda and switch to the new config, maybe on Tuesday? After this first step that will require a short downtime, we can install PostgreSQL to the new Hetzner server and confirm replication works, this will not require downtime