Live data from Hacker News

Old school Linux administration – my next homelab generation

scholz.ruhr

21–30 of 115 posts

Re: Old school Linux administration – my next homelab generation

#21
I love LXC/LXD for my home server. Far easier to use and maintain than VMs, fast, and use far less resources than VMs. And understanding containers is great foundational knowledge for working with Docker and K8s. They also work great with NextCloud, Plex, PostgreSQL, and Zabbix, and SAMBA. But each are separate, no risk of a library or an OS upgrade taking out an app (and my weekend along with it). Snapshots are the ultimate ctrl-z, and backups are a breeze once you get past the learning curve.

Ansible with ‘pet’ containers is the way to go. Use it to automate the backups and patching. Ansible cookbooks are surprisingly easy to work with. Again, a learning curve, but it pays for itself within months.

Running a single machine with all the apps in a single environment is a recipe for tears as you are always one OS upgrade patch, library requirement change, hard drive failure away from disaster and hours of rebuilding.

Re: Old school Linux administration – my next homelab generation

#22
post #6

Automation is useful, even in homelab environments, since manual configuration introduces human errors, and automation can speed up recovery from disasters. This article is just for the sake of it. The author calls it old administration, but he better call it outdated and inefficient Linux administration.

Automation is still subject to human errors, and can propagate them much farther.

Re: Old school Linux administration – my next homelab generation

#23

Earlier quoted context omitted.

I tried both Docker and Bubblewrap. Containers help with managing dependency creep, but if you avoid that in the first place, you don't need containers.

If you only run your own software and are conscious about your dependencies, then dependency creep is gonna be less of an issue, but don't forget that your dependencies often bring theirs too. And third-party software is very often much less mindful of it. But even besides dependency creep, containers simplify your software env, simplify backups, migrations, permissions(although container are not replacement for secu…

Containers also make performance tuning and optimization a lot harder, and increase resource consumption by a far greater degree than people are willing to admit. On a by-container basis it's not a lot, a few hundred megabytes here and there, but it builds up very rapidly.

This is compounded by containerizing making the ecosystem more complex, which creates a demand for additional containers to manage and monitor all the containers.

I freed up like 20 Gb of RAM by getting rid of everything container-related on my search engine server and switching to running everything on bare-metal debian.

Re: Old school Linux administration – my next homelab generation

#24

Earlier quoted context omitted.

I tried both Docker and Bubblewrap. Containers help with managing dependency creep, but if you avoid that in the first place, you don't need containers.

If you only run your own software and are conscious about your dependencies, then dependency creep is gonna be less of an issue, but don't forget that your dependencies often bring theirs too. And third-party software is very often much less mindful of it. But even besides dependency creep, containers simplify your software env, simplify backups, migrations, permissions(although container are not replacement for secu…

It makes it easier in the sense of "better accessible", not simpler. The docker network setup and namespace management are actually quite complex.

Re: Old school Linux administration – my next homelab generation

#25

Earlier quoted context omitted.

If you only run your own software and are conscious about your dependencies, then dependency creep is gonna be less of an issue, but don't forget that your dependencies often bring theirs too. And third-party software is very often much less mindful of it. But even besides dependency creep, containers simplify your software env, simplify backups, migrations, permissions(although container are not replacement for secu…

Containers also make performance tuning and optimization a lot harder, and increase resource consumption by a far greater degree than people are willing to admit. On a by-container basis it's not a lot, a few hundred megabytes here and there, but it builds up very rapidly. This is compounded by containerizing making the ecosystem more complex, which creates a demand for additional containers to manage and monitor all…

Containers of course add some overhead, however it is negligible in modern world.

I honestly don't know what you have to do to get 20 gigs of overhead with containers, dozens of full ubuntu containers with dev packages and stuff?

Re: Old school Linux administration – my next homelab generation

#26

Earlier quoted context omitted.

Containers also make performance tuning and optimization a lot harder, and increase resource consumption by a far greater degree than people are willing to admit. On a by-container basis it's not a lot, a few hundred megabytes here and there, but it builds up very rapidly. This is compounded by containerizing making the ecosystem more complex, which creates a demand for additional containers to manage and monitor all…

Containers of course add some overhead, however it is negligible in modern world. I honestly don't know what you have to do to get 20 gigs of overhead with containers, dozens of full ubuntu containers with dev packages and stuff?

> Containers of course add some overhead, however it is negligible in modern world.

I feel the people most enthusiastically trying to convince you of this are the infrastructure providers who also coincidentally bill you for every megabyte you use.

> I honestly don't know what you have to do to get 20 gigs of overhead with containers, dozens of full ubuntu containers with dev packages and stuff?

Maybe 5 Gb from the containers alone, they were pretty slim containers, but a few dozen of them in total; but I ran microk8s which was a handful of gigabytes, I could also get rid of kibana and grafana, which was a bunch more.

Re: Old school Linux administration – my next homelab generation

#28
post #21

I love LXC/LXD for my home server. Far easier to use and maintain than VMs, fast, and use far less resources than VMs. And understanding containers is great foundational knowledge for working with Docker and K8s. They also work great with NextCloud, Plex, PostgreSQL, and Zabbix, and SAMBA. But each are separate, no risk of a library or an OS upgrade taking out an app (and my weekend along with it). Snapshots are the…

This sounds like my setup exactly, except instead of LXC/ansible, I’m using FreeBSD jails/saltstack.

I completely agree about the value of isolation. You can update or up-rebuild for a new os version on one service at a time - which I find helpful when pulling in updated packages/libraries. You can also cheaply experiment with a variation on your environment.

Re: Old school Linux administration – my next homelab generation

#30

Earlier quoted context omitted.

Containers of course add some overhead, however it is negligible in modern world. I honestly don't know what you have to do to get 20 gigs of overhead with containers, dozens of full ubuntu containers with dev packages and stuff?

> Containers of course add some overhead, however it is negligible in modern world. I feel the people most enthusiastically trying to convince you of this are the infrastructure providers who also coincidentally bill you for every megabyte you use. > I honestly don't know what you have to do to get 20 gigs of overhead with containers, dozens of full ubuntu containers with dev packages and stuff? Maybe 5 Gb from the c…

>I feel the people most enthusiastically trying to convince you of this are the infrastructure providers who also coincidentally bill you for every megabyte you use.

They don't though? Cloud providers sell VM tiers, not individual megabites, and even then on Linux there is barely any overhead for anything, but memory, and memory one is, again, if you optimize it far enough is negligible.

>but I ran microk8s which was a handful of gigabytes

My k3s with a dozen of pods fits in couple gigs.

Post reply on HN