Move PostgreSQL to VMs and access via Zerotier #282
Labels
Clear labels
monitoring
bug
design
dev environment
docs
duplicate
enhancement
feature
good first issue
idea
invalid
kredits-1
kredits-2
kredits-3
on hold
ops
question
security
ui/ux
wontfix
service
discourse
Kosmos Community Forums
Infrastructure metrics, alerts, notifications, etc.
service
accounts
Kosmos Accounts
service
drone-ci
Kosmos Drone CI
service
email
mail.kosmos.org
service
garage
S3-compatible object storage
service
gitea
Kosmos Gitea
service
ipfs
Kosmos IPFS
service
mastodon
kosmos.social
service
nostr
Relays, Blossom server, etc.
service
postgres
Database cluster
service
remotestorage
Portable data storage for the Web
service
wiki
Kosmos Wiki
service
xmpp
Kosmos Chat
Something is not working
Graphic/visual design
Config, builds, CI, deployment, etc.
Documentation
This issue or pull request already exists
Improving existing functionality
New functionality
Dive in, and start contributing
Something to consider
Not a bug
Small contribution
Medium contribution
Large contribution
Currently not actionable
Manual IT ops activities
Looking for an answer
release
major
release
minor
release
patch
All your base are belong to us
User interface, process design, etc.
This won't be fixed
No labels
kredits-3
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: kosmos/chef#282
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Update Jan 24:
@greg and I have finished the migration of our PostgreSQL cluster from the host systems of Andromeda, Centaurus, and Draco, to new VMs on Centaurus and Draco.
Instead of the previous encfs setup, we now use standard full-disk encryption (LUKS/LVM) for the VMs to encrypt data at rest. So the decryption password has to be provided during the booting of the VM now.
The new setup also uses our Zerotier private network exclusively for database connections, and thus no public connections or TLS anymore.
In order to make both this migration seamless, as well make the switching of the primary node to a hot standby node much easier and quicker in the future as well, we have changed all database clients to use a custom
/etc/hostsentry (pg.kosmos.local).Then we created a script to run all the steps for switching the primary at once, both triggering the promotion of a standby node to primary, as well as stopping the old one, and updating the hosts entries without full Chef runs. This way, all clients will immediately re-connect to the new primary after promotion, which worked exactly as intended when we did it for this migration.
refs #280
@greg I was thinking about the most simple, low-tech, and stable solution for updating the postgres master address, and my last idea was:
/etc/hostsentry on all postgres client VMsThis way, we don't need our own DNS server at all, and there's no extra connection or caching to think about. WDYT?
Yeah that seems like a good solution for now!
I had a look, and it looks good to me, but I know absolutely zero about the ruby code, let alone the infrastructure. So take my approval for a grain of salt :)
EDIT: Also, I couldn't add my name to the reviewrs list
If you leave a comment using the review function on the changed-files tab (green button on the right), then you'll be added to the list, and also kredited by @galfert's new script.
LGTM!