Hacker News Reader

Comment by toredash | Hacker News Reader

2 cents his hosts file points localhost to the prod db IP

Yep. Nowadays a kubectl port-forward makes something like this all too easy. They accidentally had the kubecontext point at the production cluster instead of dev, set up the port-forward to the database, and whoops! At least that's how this could happen to me, even with my years of experience in doing unexpected things to production databases.

That whole ecosystem is a devexp nightmare. I try to stay away from it entirely having worked with it extensively.

Docker + Kubernetes are the biggest socially-acceptable hacks in the industry at the moment.

Why do you think they are hacks? Could you please elaborate?

In my opinion, they nicely abstract over server hardware and services running on them, so one is able to have simple infrastructure-as-code management of otherwise complicated setups.

I'm betting on a tunnel, myself. And grandparent is probably wrong, they most likely have dedicated mysql machines so "localhost" will never be the db.

I think so as well.

It doesn't even make sense to connect to a managed database using 'localhost'.

Managed databases are never localhost. They are hosted outside your VPS and you use a DNS name to connect to them.

That could've happened if the database is not accessible from the Internet and they were using a tunnel which binds to localhost (e.g. `ssh -L`).

It does make sense to connect to localhost on dev machines. But if that's the setup, I guess one should avoid from tunneling to localhost to avoid potentially dangerous confusion (hmm... I think I'm guilty of that on a couple projects, need to check if that's true...)

Yeah, my guess would be that the script got executed on prod server by, ups was I in that terminal window, accident! Localhost is after all the-local-host, no matter what server it's on. Better to also have clear convention regarding name of prod db name versus test db (i.e. "test_mysaas" versus "mysaas").

Plus of course using git with a hook specifically for preview versus production (i.e. "git push production") that way local specific scripts can be stripped even if in same repo.

Yeah this is how I once deleted my production database. One thing I did to mitigate this was colour code the prompts for local/staging/production.

Yeah, if one has to regularly interact directly with prod, some sort of visual indicator is super helpful.

My guess would be something like PgBouncer. Someone may have installed it to the production server at some point in the past.

One solution to this is to make sure only the production servers can connect to the production database.

Reply on news.ycombinator.com