Comment

Comment on Those who are hosting on bare metal: What is stopping you from using Containers or VM's? What are you self hosting?

30p87@feddit.org ⁨1⁩ ⁨day⁩ ago

That I’ve yet to see a containerization engine that actually makes things easier, especially once a service does fail or needs any amount of customization. I’ve two main services in docker, piped and webodm, both because I don’t have the time (read: am too lazy) to write a PKGBUILD. Yet, docker steals more time than maintaining a PKGBUILD, with random crashes (undebuggable, as the docker command just hangs when I try to start one specific container), containers don’t start properly after being updated/restarted by watchtower, and debugging any problem with piped is a chore, as logging in docker is the most random thing imagineable. With systemd, it’s in journalctl, or in /var/log if explicitly specified or obviously useful (eg. in multi-host nginx setups). With docker, it could be a logfile on the host, on the guest, or stdout. Or nothing, because, why log after all, when everything “just works”? (Yes, that’s a problem created by container maintainers, but one you can’t escape using docker. Or rather, in the time you have, you could more easily properly(!) install it bare metal) Also, if you want to use unix sockets to more closely manage permissions and prevent roleplaying a DHCP and DNS server for ports (by remembering which ports are used by which of the 25 or so services), you’ll either need to customize the container, or just use/write a PKGBUILD or similar for bare metal stuff.

Also, I need to host a python2.7 django 2.x or so webapp (yes, I’m rewriting it), which I do in a Debian 13 VM with Debian 9 and Debian 9 LTS repos, as it most closely resembles the original environment, and is the largest security risk in my setups, while being a public website. So into qemu it goes.

And, as I mentioned, either stuff is officially packaged by Arch, is in the AUR or I put it into the AUR.

source

Sort:hotnew top

deadcade@lemmy.deadca.de ⁨1⁩ ⁨day⁩ ago
Personally I have seen the opposite from many services. Take Jitsi Meet for example. Without containers, it’s like 4 different services, with logs and configurations all over the system. It is a pain to get running, as none of the services work without everything else being up. In containers, Jitsi Meet is managed in one place, and one place only. (When using docker compose,) all logs are available with docker compose logs, and all config is contained in one directory.

It is more a case-by-case thing whether an application is easier to set up and maintain with or without docker.

source
- Jakeroxs@sh.itjust.works ⁨13⁩ ⁨hours⁩ ago
  For logs dozzle is also fantastic, and you can do “agents” if you have multiple docker nodes and connect them togetherb
  
  source
renegadespork@lemmy.jelliefrontier.net ⁨1⁩ ⁨day⁩ ago
Do you host on more than one machine? Containerization / virtualization begins to shine most brightly when you need to scale / migrate across multiple servers. If you’re only running one server, I definitely see how bare metal is more straight-forward.

source
- zod000@lemmy.dbzer0.com ⁨13⁩ ⁨hours⁩ ago
  This is a big part of why I don’t use VMs or containers at home. All of those abstractions only start showing their worth once you scale them out.
  
  source
  - renegadespork@lemmy.jelliefrontier.net ⁨12⁩ ⁨hours⁩ ago
    Hm, I don’t know about that either. While scale is their primary purpose, another core tenant of containerization is reproducibility. For example
    
    If you are developing any sort of software, containers are a great way to ensure that the environment of your builds remains consistent.
    
    If you are frequently rebuilding a server/application for any reason, containers provide a good way to ensure everything is configured exactly as it was before, and when used with Git, changes are easy to track. There are also other tools that excel at this (like Ansible).
    
    source
    zod000@lemmy.dbzer0.com ⁨9⁩ ⁨hours⁩ ago
    That to me still feels like a variety of “scale”. All of these tools (Ansible is a great example) are of dubious benefit when your scale of systems is small. If you only have a single dev machine or server, having an infrastructure-as-code system or containerized abstraction layer, just feels to me like unnecessary added mental overhead. If this post had been in a community about FOSS development or general programming, I’d feel differently as all of these things can be of great use there. Maybe my idea of selfhosting just isn’t as grandiose as some of the people in here. If you have a room full of server racks in your house, that’s a whole other ballgame.
    
    source
- 30p87@feddit.org ⁨1⁩ ⁨day⁩ ago
  One main server, with backup servers being very easy to get up and running, either by full-restoring the backup, or installing and restoring specific services. As everything’s backed up to a Hetzner Storage Box, I can always restore it (if I have my USB sticks with the keyfiles).
  
  I don’t really see the need for multiple running hosts, apart from:
  
  Router
  
  Workstation which has a 1070 in it, if I need a GPU for something. My 1U server only has space for a low profile and one slot GPU/HPC processor, and one of those would cost way more than its value over my old 1070 would be.
  
  source
towerful@programming.dev ⁨1⁩ ⁨day⁩ ago

especially once a service does fail or needs any amount of customization.

A failed service gets killed and restarted. It should then work correctly.
If it fails to recover after being killed, then it’s not a service that’s fully ready for containerisation.
So, either build your recovery process to account for this… or fix it so it can recover.
It’s often why databases are run separately from the service. Databases can recover from this, and the services are stateless - doesn’t matter how many you run or restart.

As for customisation, if it isn’t exposed via env vars then it can’t be altered.
If you need something beyond the env vars, then you use that container as a starting point and make your customisation a part of your container build processes via a dockerfile (or equivalent)

It’s a bit like saying “chisels are great. But as soon as you need to cut a fillet steak, you need to sharpen a side of the chisel instead of the tip of the chisel”.
It’s using a chisel incorrectly.

source
- 30p87@feddit.org ⁨1⁩ ⁨day⁩ ago
  Exactly. Therefore, docker is not useful for those purposes to me, as using arch packages (or similar) is easier to fulfill my needs.
  
  source
Semi_Hemi_Demigod@lemmy.world ⁨1⁩ ⁨day⁩ ago
You can customize and debug pretty easily, I’ve found. You can create your own Dockerfile based on one you’re using and add customizations there, and exec will get you into the container.

source