this post was submitted on 22 Dec 2024
42 points (97.7% liked)

Selfhosted

40734 readers
457 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:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. 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.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

Currently I'm running some services though Docker on a Proxmox VM. Before I had Proxmox, I thought containers were a very clean way of organizing my system. I'm currently wondering if I can just install the services I always use on the VM directly. What are the pros and cons of that?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 15 points 4 days ago (1 children)

I see containers as having a couple of advantages:

  1. Separation of dependencies - while not as big of issue as it used to be, just knowing that you won't end up with the requirements for one application conflicting with another is one less issue to worry about. Additionally, you can do anything you want to one container, without having an effect on another container. You don't get stuck wanting to reboot or revert the system, but not wanting to break a different running service.
  2. Portability - Eventually, you are going to replace the OS of that VM (at least, you should). Moving a container to a new OS is dead simple. Re-installing an application on a new OS, moving data and configs can be anywhere from easy to a pain in the arse, depending on the software.
  3. Easier fall back - Have you ever upgraded an application and had everything go to shit? In my years working as a sysadmin, I lost way too many evenings to this sort of bullshit. And while VM snapshots should make reverting easy, sometimes it just didn't work out that way. Containers force enough separation of applications that you can do just about anything to one container and not effect others.
  4. Less dependency on a single install - Have you ever had a system just get FUBAR, and after a few hours of digging the answer seems to be, just format the drive and start over? Maybe you tried some weird application out and the uninstall wasn't really clean. By having all that crap happen in containers, you can isolate the damage. Nuke the container, nuke the image, and the base OS is still clean.
  5. Easier version testing - Want to try out upgrading to version 2 of an application, but worried that it may not be fully baked yet or the new configs may take a while to get right? Do it off in a separate container on a copy of the data. You can do this with VMs and snapshots; but, I find containers to be less overhead.

That all said, if an application does not have an official container image, the added complexity of creating and maintaining your own image can be a significant downside. One of my use cases for containers is running game servers (e.g. Valheim). There isn't an official image; so, I had to roll my own. The effort to set this up isn't zero and, when trying to sort out an image for a new game, it does take me a while before I can start playing. And those images need to be updated when a new version of the game releases. Technically, you can update a running container in a lot of cases; but, I usually end up rebuilding it at some point anyway.

I'd also note that, careful use of VMs and snapshots can replicate or mitigate most of the advantages I listed. I've done both (decade and a half as a sysadmin). But, part of that "careful use" usually meant spinning up a new VM for each application. Putting multiple applications on the same OS install was usually asking for trouble. Eventually, one of the applications would get borked and having the flexibility to just nuke the whole install saved a lot of time and effort. Going with containers removed the need to nuke the OS along with the application to get a similar effect.

At the end of the day, though. It's your box, you do what you are most comfortable with and want to support. If that's a monolithic install, then go for it. While I, or other might find containers a better answer for us, maybe it isn't for you.

[–] [email protected] 2 points 3 days ago (1 children)

Man back when I played there was a community image at least

[–] [email protected] 2 points 3 days ago

I'm sure there are several out there. But, when I was starting out, I didn't see one and just rolled my own. The process was general enough that I've been able to mostly just replace the SteamID of the game in the Dockerfile and have it work well for other games. It doesn't do anything fancy like automatic updating; but, it works and doesn't need anything special.