However, I don't quite understand why it still has to be searching for every single app. Isn't there an easier way to know that a machine has roles/attributes that require postgres access? If it's not bound to the application, then it can never be out of sync.
I have found a better way. See ee9c241a4d, I have added a postgresql_client role
I'm going to look into it, there has to be a way that looks good in Chef code. Not having to run Chef again on the primary every time we add a new service will be useful
Replication is a special right, this is defined here for replicas:
postgresql_access "#{replica[:hostname]} replication" do |
|
access_type "host" |
|
access_db "replication" |
|
access_user "replication" |
|
access_addr "#{replica[:ipaddress]}/32" |
|
access_method "md5" |
|
notifies :reload, "service[#{postgresql_service}]", :immediately |
|
end |
A server connecting to the PostgreSQL primary as a client is not necessarily a replica, but as you said it could be done for all databases at once. I had the idea of definining each database as we need a recipe anyway to create the postgreSQL user and database for each service. Allowing access to all databases for a server could be done as part of the primary recipe, however it means the list of all services that use PostgreSQL would live there instead of the recipe for the service. I'm not opposed to doing that, I just thought doing it per database was clearer.
postgresql is a dummy service, it only runs /bin/true. The service to disable is the content of the postgresql_service variable (postgresql@12-main), so this can be moved above
Moving everything bit by bit to a new server sounds good.
Regarding the name of the new server, personally I would go with Draco as it the simplest name but the other names are alright too
I have pushed a proof of concept that creates a /var/lib/local/encrypted_data encfs dir and mounts it to /mnt/data. This is done using a Systemd unit that prompts for the encryption password, and then starts the Postgresql unit. See the last commit