Ask HN: Best way to set up self-managed Postgres clusters? Imagine you need to set up 100 Postgres clusters on Linux machines – self-managed, not RDS or CloudSQL or Azure or anything. What's the best path in YOUR opinion? 1) apt/yum/... install 2) docker / docker-compose 3) kubernetes |
The only answer that makes any sense here is Ansible.
Arguments:
Way simpler
Can fall back to using plain SSH if things goes really wrong
No vendor lock in
One less bit of technology in the mix to go wrong
Very boring, which means very reliable
How big are these instances expected to get for the next few years?
OLTP, OLAP, warehouse, or a combo?
What's your budget?
What is your team most familiar with?
Will they be publicly exposed for shared hosting? Or behind a VPN/VPC serving only your employer?
Has anyone had a good time using Docker for something like this? (I haven't but the paravirt persistence may have gotten better?)
But why? Patroni is great for HA and it doesn't require k8s.
K3s, Calico (or whatever you prefer), Istio with cert-manager and self-manager CA (or whatever you prefer for your service mesh), kube-prometheus, OTEL or Jaeger for the mesh visibility, pick the operator (I used Crunchy Data operator but there are at least two other solid choices), will get one far at low cost. Of course, use reliable infrastructure provider of one's choice.
No need to think about placement (one still can if they want to), addressing, firewalling, DNS, IP assignment, and so on. Add nodes to the cluster as necessary and let it sort itself out.
Some understanding of Kubernetes is necessary, indeed. But it's a stack usable every time once learned.
Context: https://twitter.com/samokhvalov/status/1771573110858269014
~1000 votes in just one day – obviously, this is an attractive topic to discuss, so wanted to have a thoughtful conversation here on HN.
The only answer that makes any sense here is Kubernetes.
This reads like a brazen misunderstanding/misrepresentation of Ansible.
Like... imagine the position of Terraform, a Kubernetes darling, and that's it.
I could especially see Ansible being used when not buying toy clusters, but building your own. I don't know how useful CRUD on the objects like deployments would be. Enough to do the job.
Point being, Kubernetes doesn't exclude Ansible in the slightest, whatsoever.
This was just enough for me to post... they aren't mutually exclusive. It's yet another layer of yaml to throw at the declaration problem.
Where/what/how is entirely up to the user. I'll take your money and then move on to the next thing to manage
> It's yet another layer of yaml to throw at the declaration problem.
Really, my head is already starting to hurt. I KNOW.
> This was just enough for me to post... they aren't mutually exclusive.
I'm sorry but there's no fucking good reason to templatize k8s yaml into Jinja/Ansible. Just hell no. Just more Ansible Things that look like a solution because folks don't actually know k8s.
I'm not saying using Ansible for K8s is necessarily a good idea, just that laughing because it's mentioned in the same neighborhood is hardly reasonable
I'd gladly use it for node-level tasks, for example - in the cluster I'd be less excited.
Custom facts are neat. The module library is neat. Possibilities are too, dismissive nature isn't