I do LXC, just seems easier since I can mess with things and use Cockpit or whatever to manage it, without worrying about the host system.
Self Hosted - Self-hosting your services.
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
- No harassment
- crossposts from c/Open Source & c/docker & related may be allowed, depending on context
- Video Promoting is allowed if is within the topic.
- No spamming.
- Stay friendly.
- Follow the lemmy.ml instance rules.
- Tag your post. (Read under)
Important
Beginning of January 1st 2024 this rule WILL be enforced. Posts that are not tagged will be warned and if not fixed within 24h then removed!
- Lemmy doesn't have tags yet, so mark it with [Question], [Help], [Project], [Other], [Promoting] or other you may think is appropriate.
Cross-posting
- [email protected] is allowed!
- [email protected] is allowed!
- [email protected] is allowed!
- [email protected] is allowed if topic has to do with selfhosting.
- [email protected] is allowed!
If you see a rule-breaker please DM the mods!
Thank you. So the advantage of the isolation of LXC for you is to be able to tinker with the service without affecting the host.
Personally I run almost everything in docker, with the launch configs stored in git, backed by zfs. This means that if the host dies I can import that zpool, docker compose up -d
and be done with it.
I suppose the same could be done with VMs or LXC. The main thing is to keep it all separate from the bare metal OS, and in a technology that allows quick provisioning from a launch config of some sort, be it makefile, shell script, docker-compose, or whatever.
Thank you. Is the only reason that you run it in containers for the easy reproducibility, or is there any other reason that you want that separation from the bare metal OS?
Both, actually, and those things are directly related. If I need to migrate a single thing to another machine it's just rsync
and make run
. Of course this requires the bare metal to have docker and make, so some bare metal configuration management is also needed.
Thanks again.
Right. You kind of want your bare metal OS as vanilla as possible. If you need to nuke and pave, you don’t need to worry about re-applying various configs. Additionally, on a theoretical level, if there’s a bug in something on the bare metal OS, the separation provided by VMs and containers should mean it doesn’t affect the the apps in those VMs / containers.
That seems easier - at least to me - than keeping track of configs in text files or even Ansible playbooks.
Thank you, that makes sense. I figure that separation provided by VMs and containers is also a security advantage, in case the software in them has vulnerabilities.