32
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 27 Sep 2023
32 points (94.4% liked)
Selfhosted
39677 readers
173 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
I run Debian on all my vms, they have no GUI installed at all. I manage all of them over SSH
Yes, that is what i am used to.
I guess headless is better for performance and i do not see an advantage at all.
Another question: Why do you have several debians-vm's? You also could take one, right?
I use multiple VMs, and group things either by security layer or by purpose.
When organising by purpose, I have a VM for reverse proxies. Then I have a VM for middleware/services. Another VM (or multiple) for database(s). Another VM for backend/daemon type things.
Most of them end up running docker, but still.
Lets me tightly control access between layers of the application (if the reverse proxy gets pwnd, the damage is hopefully contained there. If they get through that, the only get to the middleware. Ideally the database is well protected. Of course, none of that really matters when there's a bug in my middleware code!)
Another way to do it is by purpose.
Say you have a media server things, network management things, CCTV things, productivity apps etc.
Grouping all the media server things in a VM means your DNS or whatever doesn't die when you wiff an update to the media server. Or you don't lose your CCTV when you somehow link it's storage directory into the media server then accidentally delete it. If that makes sense.
Another way might be by backup strategy.
A database hopefully has point in time backup/recovery systems in place. Whereas a reverse proxy is just some config (hopefully stored on GitHub) and can easily be rebuilt from scratch.
So you could also separate things by how "live" the data is, or how often something is backed up, or how often something gets reconfigured/tweaked/updated.
I use VMs to section things out accordingly.
Takes a few extra GB of storage/memory, has a minor performance impact. But it limits the amount of damage my dumb ass can do.
I run a vm for each service, a php vm, a mysql vm, etc. But yes you could just have a big vm run everything
At that point why even run proxmox.
As I wrote in my other reply, you typically want a separate VM for each service so that the OS configurations don't conflict, and also so that you can shut down the VM for one service (e.g. for installing updates or migrating to another cluster node) without causing downtime to other services.