Hey all,

Just wondering what the consensus is on hosting directly on a computer versus virtualization? Right now I’m hosting my Lemmy instance on a Hetzner VPS, but I would like to eventually migrate to my Linux box at home. It currently runs as a media PC (Ubuntu) in the living room, but I always intended to self-host other software on the side since it should be more than capable of doing both (Ryzen 5600G, 16gb DDR4).

I’m just torn though - should I host a virtual machine on it for Lemmy, or run it directly on Ubuntu as-is? I plan to do some further self-hosting projects as well later down the line.

  • PriorProject@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 year ago

    I run everything in docker compose and the two wins I feel like I get out of doing so are:

    • State in well-identified volumes. I’ve run multiple services on shared bare metal, and multiple services in isolated VMs. In both cases, I was equally terrified of upgrades and migrations because I frequently had no idea where in the filesystem critical data was stored. I would often have some main data dir I knew about, but little confidence that other important data wasn’t stored elsewhere. With docker volumes, if I can restart a container without losing data I can migrate to a new host without losing data just by copying my volume dirs. And I restart containers frequently so I always have high confidence in my ability to backup, upgrade, and migrate.
    • Library and os-userspace isolation. This is the thing docker is known for, I never worry that upgrading a lib for app-a is going to break app-b. This is really a secondary benefit for me, though. I rarely had this problem even on shared metal with many apps, and never experienced it in isolated VMs. For me it’s a secondary benefit to the nice volume management tools.

    Docker is in no way unique in its ability to provide state management, but ephemeral container enforce good state management, and the docker tools for doing it provide a very nice experience, so it is my preference.

  • beigegull@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    User accounts are a reasonable isolation mechanism for reasonably trustworthy server software.

  • sv1sjp@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    Personally, I would prefer docker containers as I can move them to a new server or even create backups very easily.

    • Onion6068@feddit.de
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Backups are easily done with virtual machines as well. Taking, moving and restoring such backups is in fact much easier than moving docker containers between hosts as you don’t have to differentiate between volumes and locally mounted directories for example. That being said, depending on the use case, containers can be a nice and lightweight solution to separate applications on a userspace level

  • Qazwsxedcrfv000@lemmy.unknownsys.com
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    It does not hurt to create a VM or LXC for it. The overhead is not prohibitive. If things go astray, you can just kill the VM or LXC and restart from sketch. Though setup and management can be an issue as you have to install at least some software for VM management in your media PC.

  • Thief
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 year ago

    Only time you dont use virtualisation or containers would be if real time performance is critical. Eg: a firewall inspecting packets in/out or some other service or appliance where small delays can impact performance. Same kind of reasons why gaming on a vm is never quite as good as a bare metal machine.

    • z3bra@lemmy.sdf.org
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Performance is not the only use case though:

      Using virtualisation (containers included) adds a great level of overhead to the system which can be problematic on low resources hosts. It also adds a layer of complexity that one might not want to deal with when hosting a service.

  • callcc@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    I’m not sure there is a consensu here, it’s a trade off in many dimensions: security, simplicity, performance, independence, ease of management etc.

    Bare metal gives you best performance, good simplicity since there are the least moving parts and the least amount of code deployed. It is fairly easy to manage if you know your distro and service well. You might run into trouble if you want to run non packaged software and compile things on your own.

    Containers are pretty efficient and simple to use because a lot of software comes pre-packaged (usually including a basic OS, w/o kernel). They are meant to only have one service per container, which can lead to quite some complexity in inter-connecting them. Security wise, they are less well isolated than VMs between each other and to the host. Operating on their persisted state can be very easy and lightweight. One drawback is that people often don’t understand whats happening inside (cf. Reproducibility). The saying goes: As with smoothies, you immeadiately know if you like it (a container) but you don’t know what’s inside.

    VMs are slightly less efficient but have a larger management overhead, ie. You need to configure and upgrade each OS (users, firewall rules etc) on its own, on the other hand you gain flexibility by being able to install different distros or having different versions around. You can also more easily manage the state of the machines (backups, snapshots etc). Security wise, VMs are pretty well isolated from each others and the hypervisor, often the configuration of the machines is the weak point (firewall, sshd or other services).

  • skilltheamps@feddit.de
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 year ago

    You want so isolate the things you host from one another (security, making updates easier etc). So if you host just one thing you can do so on the host directly. If you host multiple services you may seek some separation method.

    VMs is one method, but it wastes a lot of resources, especially RAM. A more elegant way is containers. Both the docker/podman route as well as the LXC way are quite polular.

  • Oliver Lowe@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    One thing I think about is isolation. Do you want/need to strongly isolate the software and its data from the host operating system?

  • BrianTheeBiscuiteer@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year ago

    In any case I wouldn’t host on a machine I use daily (i.e. a personal computer). Worst case is an attacker wiping your machine or encrypting everything and holding your data hostage. If that happened to one of my servers I’d just shrug and reimage.

    If performance is paramount or you have a low resource device like a rPi then containers are fine. If you have something with decent processing power I say go the extra mile and setup a simple VM using Qemu. A few distros offer cloud images so you don’t have to install from an ISO.

  • Cobrachicken@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    1 year ago

    Imho any form of containerization/virtualization is better than a dedicated machine, for server duties - if only for (in my case) easy backup and rollback in case of human error.

    Going with Proxmox VMs atm, and slowly wrapping my head around LXC on a separate “playgound” Proxmox machine.

  • BrainTheBest5@lemm.ee
    link
    fedilink
    English
    arrow-up
    0
    arrow-down
    1
    ·
    1 year ago

    If you use a full VM you’ll lose plenty of performance and I don’t think it’ll cope really well with domain names. If you really want to go the “keep everything separated” route use container software, like Docker. It’ll use the same kernel as the host, so no weird networking rerouting/bridging etc… I don’t have any experience with containers, since I run all of my “homelab” bare metal on a Pi, and with this approach I never faced any issues. Containers could be useful if you were running something unorthodox like Gentoo and you need to run software that won’t work on it, even if compiled to run, but it exist as a package on another distro. Then you can just spin up a container for that distro, install the software et voilà, you’re ready to go. AFAIK there shouldn’t be a package for lemmy on any distro, so just clone the source code and compile it, it should be fairly distro-agnostic. Maybe you could compile it in a container to keep your host clean of compile dependencies, but other than that, there’s no real gain. I like to compile stuff, so having a shitload of dependencies already there is pretty handy for me, but for a production system, it’s better to keep it clean.