6 ms·

Personal opinion, a home lab is the perfect place to learn how to actually configure things and properly set them up: no docker, no ansible, no salt… take off t

Personal opinion, a home lab is the perfect place to learn how to actually configure things and properly set them up: no docker, no ansible, no salt… take off the training wheels and learn it. Then, learn to write your own playbooks, your own compose files, etc. Additionally, if people think that learning how to configure and deploy stuff is too tedious and/or too difficult, write software that has better UI, not more layers of configuration and administration. Final thought, git is better than ansible/salt/chef/puppet, and containers are silly.

xyst 3y ago
I personally like learning this way. Have a single server with at least 20 physical cores available. Use qemu to create VMs. Personally, had nixOS (minimal) installed on the VMs. Scripted the setup (live cd created with my ssh key so I can remotely setup the VM such as disk partitioning). Then had a nix configuration to setup environment. A bit of a learning curve but the benefit here is repeatable environments. Was even able to learn more about k8s using a small mini cluster. Host machine was the controller node while VMs were nodes. By injecting latency between nodes to distance between different data center regions (ie, us-east vs us-west), actually able to reproduce some distributed app issues. All of this while not having to give up $$$ to the major server resellers (or "cloud" providers). No worries about forgetting to tear down the cluster and receiving a surprise bill at the end of the month.
ghnws 3y ago
"Containers are silly" What a silly take
ktosobcy 3y ago
I love containers - I have tiny RPi under the desk, run debian in it and everything is in containers - I don't have to deal that some software requires some version and other different. Or if something crashes it brings everything else with it. I have some space to toy with it, but for the purpose of running something utterly low maintenance, docker and containers are awesome.
apitman 3y ago
I think this is good advice for technical people, but I also think we need to drastically lower the barrier of entry for people who would benefit from owning their compute and data but don't have the skills or interest necessary.
- filmgirlcw 3y ago
  I agree we need to do that, but I would argue at this point, the best option for the people without the skills/interest is probably buying a Synology. It would be awesome if there was a free OSS solution that people could just follow instructions and deploy on an inexpensive miniPC and not have to worry about anything and have auto-updates and zero problems, but I don't know if that is realistic. If we do ever see it, I feel confident it won't be free. I see tools like this as a really good middle ground between piecing all the different parts together and managing runbooks and whatnot and buying an off-the-shelf appliance like a Synology or other consumer/prosumer/SMB NAS.
  - ocdtrekkie 3y ago
    Sandstorm does this, although we are badly in need of funding, contributors, and all the things needed to meaningfully run an open source project. Our updates are generally evergreen but we are currently blocked on offering that while we establish a new community-run infrastructure and development process. The problem is you do need to reinvent everything to do this right, and reinventing everything is hard and a bit of a slog. Some problems are also just... still hard, there's no secure and good way to help someone open a port on their home router.
    - adr1an 3y ago
      Open ports? Nowadays people just use tailscale.. AFAIK
      - ocdtrekkie 3y ago
        I mean I suppose it depends on how you want to limit your server setup, and what limitations you have (i.e. CGNAT). Considering I regularly share things on my server with others, and I let other people who are less technically inclined use my server, having to use a VPN service to access it would be extremely suboptimal for that. I also don't want to have to host a proxy server out on a public provider.
planb 3y ago
Don’t do this to learn if you really want to use the servers for important data and expose them to the internet. You can shoot your foot with docker containers, but you can shoot your face by blindly installing dozens of packages and their dependencies on a single box.
- eternauta3k 3y ago
  You can keep them separate with Docker. I'm not sure what the workflow looks like, however: you make a simple image with just (say) alpine + apache, you run a shell there, set everything up, and when it works you basically try to replicate all the things you did manually in the Dockerfile? So in the end, you have to do everything twice?
eddd-ddde 3y ago
I always just use a systemd or open rc service to run my stuff, pretty much a shell script and voilá. As long as you know to set proper firewall rules and run things as non-root your pretty much ready.
- watermelon0 3y ago
  Not only does using Docker avoid dependency hell (which is IMO the biggest problem when running different software on a single machine), it has good sandboxing capabilities (out-of-the-box, no messing with systemd-nspawn) and UX that's miles ahead of systemd.
  - discardedrefuse 3y ago
    There's a compromise to be made here. I use systemd to run podman containers! It's great, built-in to podman, and easy. podman generate systemd --new --files --name mypod And now you have a bunch of systemd service files ready to copy over and load.
whalesalad 3y ago
umm, homelab is also the perfect place to play with docker, ansible, kube, etc. that's the whole point. git and ansible are not mutually exclusive. containers are not silly. you'll come around some day
- alex_lav 3y ago
  In my experience, people that disparage containerization are either forgetting or weren’t around to know about how awful bespoke and project specific build and deploy practices actually were. Not that docker is perfect, but the concept of containerization is so much better than the alternative it’s actually kind of insane.
  - mplewis 3y ago
    Exactly. If containerization solves one thing, it’s installing two pieces of software that e.g. want a different version of system Python installed. I love Debian but it won’t help you much here.
  - evantbyrne 3y ago
    Docker has come a long way. There was a time when the documentation struggled to coherently describe what images were, and other tools were good-enough to not bother. Today there are imagines for most things, the documentation is clear, and support is widespread. But being able to setup a server on a Linux box is still a basic skill that any web administrator should know how to do. People make the mistake of thinking because they use Docker that they should use proprietary cloud hosting. My controversial belief is that the right solution for at least 90% of web services just slapping docker-compose on a VM, running SQLite in WAL backed up by Litestream, and maybe sync logs with Vector if you want to get real crazy. Run a production web service for $30/mo without cloud lock-in or bs. It's kind of funny I built a CD for AWS and it made me disillusioned with the whole thing. But yeah, Docker is good.
    - radus 3y ago
      docker swarm is also a decent solution if you do need to distribute some workloads, while still using a docker compose file with a few extra tweaks. I use this to distribute compute intensive jobs across a few servers and it pretty much just works at this scale. The sharp edges I've come across are related to differences between the compose file versions supported by compose and swarm. Swarm continues to use Compose file version 3 which was used by Compose V1 [1]. 1: https://docs.docker.com/engine/swarm/stack-deploy/ https://docs.docker.com/engine/swarm/stack-deploy/
alex_lav 3y ago
I’m curious how UI impacts software configuration and deployment? Are you using a UI to set your compiler flags or something?
- BirAdam 3y ago
  Configuration, deployment, program initialization/start is all still “user interface” just a different part. Most software feels like that part was largely an after thought and not part of the design process.
  - alex_lav 3y ago
    If that's your take, I'm sort of curious why you'd dislike containerization, whose primary selling point is to standardize and improve the developer experience for, literally exactly, configuration, deployment and program initialization...
jrm4 3y ago
"Containers are silly" might be the literal worst take I've seen in this space, especially if one is at all interested in "onboarding more moderately techy folk" to the idea of homelabs, and self-hosting, which I think is incredibly important. Once you know Docker, you can abstract away SO MUCH and get things up and running incredibly quickly. Let's say you have someone who now hates Spotify. Perfect. Before Docker it was a huge pain to try to set up one and hope you get it right. After Docker? Just TRY ALL OF THEM. Don't like Navidrome/mstream/whatever? Okay, docker-compose down and try the next one.
- watermelon0 3y ago
  TBH, containers are the wrong way of doing things, but they are the least bad solution of shipping software that we currently have.
  - ycombinatrix 3y ago
    scratch containers aren't so bad
  - zer00eyz 3y ago
    This is the truth. Containers as a bag that you put shitty software in to isolate it from the rest of your system and its peers... The whole downstream, vs upstream, who should package what and where do you get software is showing us what the real problem is. Software, should be easy to instal. Containers are a terrible way to do that.
    - stavros 3y ago
      What's easier than containers? It sounds to me like you let your hate of the problem carry over to hating the solution. I have a Python web app, what's a better way to distribute it than containers?
      - apitman 3y ago
        I basically agree with you, but it would be nice if containers were a bit simpler. Apptainer does some really nice things for example.
vundercind 3y ago
Did that for years. Spend so much more time fiddling with computers than getting any actual benefit from them. Now all my shit’s in docker, launched by one shell script per service. I let docker take care of restarts. There’s no mystery about where exactly all of the config and important files for any of the services lives. I barely even have to care which distro I’m running it on. It’s great. What’s funny is that the benefits of docker, for me, have little to do with its notable technical features. 1. It provides a common cross-distro interface for managing services. 2. It provides a cross-disro rolling-release package manager—that actually works pretty well and has well-maintained, and often official, packages. 3. It strongly encourages people building packages for that package manager to make their config more straightforward and to make locations of config files and data explicit and documented thoroughly in a single place. That is, it forces a lot of shitty software to de-shittify itself at the point I’ll interact with it (via Docker).
deleted 3y ago
[deleted]
silverwind 3y ago
Definitely would recommend to use docker though. Can be just a bash script. Running complex software with a lot of dependencies bare-metal is recipe for disaster nowadays, unfortunately.
sp332 3y ago
Why would you write "your own compose files" if you're not running docker?
- BirAdam 3y ago
  My point was, learn it first, then learn docker and Ansible and such.

xyst 3y ago

I personally like learning this way. Have a single server with at least 20 physical cores available. Use qemu to create VMs. Personally, had nixOS (minimal) installed on the VMs. Scripted the setup (live cd created with my ssh key so I can remotely setup the VM such as disk partitioning). Then had a nix configuration to setup environment. A bit of a learning curve but the benefit here is repeatable environments. Was even able to learn more about k8s using a small mini cluster. Host machine was the controller node while VMs were nodes. By injecting latency between nodes to distance between different data center regions (ie, us-east vs us-west), actually able to reproduce some distributed app issues. All of this while not having to give up $$$ to the major server resellers (or "cloud" providers). No worries about forgetting to tear down the cluster and receiving a surprise bill at the end of the month.

ghnws 3y ago

"Containers are silly" What a silly take

ktosobcy 3y ago

I love containers - I have tiny RPi under the desk, run debian in it and everything is in containers - I don't have to deal that some software requires some version and other different. Or if something crashes it brings everything else with it. I have some space to toy with it, but for the purpose of running something utterly low maintenance, docker and containers are awesome.

apitman 3y ago

I think this is good advice for technical people, but I also think we need to drastically lower the barrier of entry for people who would benefit from owning their compute and data but don't have the skills or interest necessary.

filmgirlcw 3y ago
I agree we need to do that, but I would argue at this point, the best option for the people without the skills/interest is probably buying a Synology. It would be awesome if there was a free OSS solution that people could just follow instructions and deploy on an inexpensive miniPC and not have to worry about anything and have auto-updates and zero problems, but I don't know if that is realistic. If we do ever see it, I feel confident it won't be free. I see tools like this as a really good middle ground between piecing all the different parts together and managing runbooks and whatnot and buying an off-the-shelf appliance like a Synology or other consumer/prosumer/SMB NAS.
- ocdtrekkie 3y ago
  Sandstorm does this, although we are badly in need of funding, contributors, and all the things needed to meaningfully run an open source project. Our updates are generally evergreen but we are currently blocked on offering that while we establish a new community-run infrastructure and development process. The problem is you do need to reinvent everything to do this right, and reinventing everything is hard and a bit of a slog. Some problems are also just... still hard, there's no secure and good way to help someone open a port on their home router.
  - adr1an 3y ago
    Open ports? Nowadays people just use tailscale.. AFAIK
    - ocdtrekkie 3y ago
      I mean I suppose it depends on how you want to limit your server setup, and what limitations you have (i.e. CGNAT). Considering I regularly share things on my server with others, and I let other people who are less technically inclined use my server, having to use a VPN service to access it would be extremely suboptimal for that. I also don't want to have to host a proxy server out on a public provider.

planb 3y ago

Don’t do this to learn if you really want to use the servers for important data and expose them to the internet. You can shoot your foot with docker containers, but you can shoot your face by blindly installing dozens of packages and their dependencies on a single box.

eternauta3k 3y ago
You can keep them separate with Docker. I'm not sure what the workflow looks like, however: you make a simple image with just (say) alpine + apache, you run a shell there, set everything up, and when it works you basically try to replicate all the things you did manually in the Dockerfile? So in the end, you have to do everything twice?

eddd-ddde 3y ago

I always just use a systemd or open rc service to run my stuff, pretty much a shell script and voilá. As long as you know to set proper firewall rules and run things as non-root your pretty much ready.

watermelon0 3y ago
Not only does using Docker avoid dependency hell (which is IMO the biggest problem when running different software on a single machine), it has good sandboxing capabilities (out-of-the-box, no messing with systemd-nspawn) and UX that's miles ahead of systemd.
- discardedrefuse 3y ago
  There's a compromise to be made here. I use systemd to run podman containers! It's great, built-in to podman, and easy. podman generate systemd --new --files --name mypod And now you have a bunch of systemd service files ready to copy over and load.

whalesalad 3y ago

umm, homelab is also the perfect place to play with docker, ansible, kube, etc. that's the whole point. git and ansible are not mutually exclusive. containers are not silly. you'll come around some day

alex_lav 3y ago
In my experience, people that disparage containerization are either forgetting or weren’t around to know about how awful bespoke and project specific build and deploy practices actually were. Not that docker is perfect, but the concept of containerization is so much better than the alternative it’s actually kind of insane.
- mplewis 3y ago
  Exactly. If containerization solves one thing, it’s installing two pieces of software that e.g. want a different version of system Python installed. I love Debian but it won’t help you much here.
- evantbyrne 3y ago
  Docker has come a long way. There was a time when the documentation struggled to coherently describe what images were, and other tools were good-enough to not bother. Today there are imagines for most things, the documentation is clear, and support is widespread. But being able to setup a server on a Linux box is still a basic skill that any web administrator should know how to do. People make the mistake of thinking because they use Docker that they should use proprietary cloud hosting. My controversial belief is that the right solution for at least 90% of web services just slapping docker-compose on a VM, running SQLite in WAL backed up by Litestream, and maybe sync logs with Vector if you want to get real crazy. Run a production web service for $30/mo without cloud lock-in or bs. It's kind of funny I built a CD for AWS and it made me disillusioned with the whole thing. But yeah, Docker is good.
  - radus 3y ago
    docker swarm is also a decent solution if you do need to distribute some workloads, while still using a docker compose file with a few extra tweaks. I use this to distribute compute intensive jobs across a few servers and it pretty much just works at this scale. The sharp edges I've come across are related to differences between the compose file versions supported by compose and swarm. Swarm continues to use Compose file version 3 which was used by Compose V1 [1]. 1: https://docs.docker.com/engine/swarm/stack-deploy/ https://docs.docker.com/engine/swarm/stack-deploy/

alex_lav 3y ago

I’m curious how UI impacts software configuration and deployment? Are you using a UI to set your compiler flags or something?

BirAdam 3y ago
Configuration, deployment, program initialization/start is all still “user interface” just a different part. Most software feels like that part was largely an after thought and not part of the design process.
- alex_lav 3y ago
  If that's your take, I'm sort of curious why you'd dislike containerization, whose primary selling point is to standardize and improve the developer experience for, literally exactly, configuration, deployment and program initialization...

jrm4 3y ago

"Containers are silly" might be the literal worst take I've seen in this space, especially if one is at all interested in "onboarding more moderately techy folk" to the idea of homelabs, and self-hosting, which I think is incredibly important. Once you know Docker, you can abstract away SO MUCH and get things up and running incredibly quickly. Let's say you have someone who now hates Spotify. Perfect. Before Docker it was a huge pain to try to set up one and hope you get it right. After Docker? Just TRY ALL OF THEM. Don't like Navidrome/mstream/whatever? Okay, docker-compose down and try the next one.

watermelon0 3y ago
TBH, containers are the wrong way of doing things, but they are the least bad solution of shipping software that we currently have.
- ycombinatrix 3y ago
  scratch containers aren't so bad
- zer00eyz 3y ago
  This is the truth. Containers as a bag that you put shitty software in to isolate it from the rest of your system and its peers... The whole downstream, vs upstream, who should package what and where do you get software is showing us what the real problem is. Software, should be easy to instal. Containers are a terrible way to do that.
  - stavros 3y ago
    What's easier than containers? It sounds to me like you let your hate of the problem carry over to hating the solution. I have a Python web app, what's a better way to distribute it than containers?
    - apitman 3y ago
      I basically agree with you, but it would be nice if containers were a bit simpler. Apptainer does some really nice things for example.

vundercind 3y ago

Did that for years. Spend so much more time fiddling with computers than getting any actual benefit from them. Now all my shit’s in docker, launched by one shell script per service. I let docker take care of restarts. There’s no mystery about where exactly all of the config and important files for any of the services lives. I barely even have to care which distro I’m running it on. It’s great. What’s funny is that the benefits of docker, for me, have little to do with its notable technical features. 1. It provides a common cross-distro interface for managing services. 2. It provides a cross-disro rolling-release package manager—that actually works pretty well and has well-maintained, and often official, packages. 3. It strongly encourages people building packages for that package manager to make their config more straightforward and to make locations of config files and data explicit and documented thoroughly in a single place. That is, it forces a lot of shitty software to de-shittify itself at the point I’ll interact with it (via Docker).

deleted 3y ago

[deleted]

silverwind 3y ago

Definitely would recommend to use docker though. Can be just a bash script. Running complex software with a lot of dependencies bare-metal is recipe for disaster nowadays, unfortunately.

sp332 3y ago

Why would you write "your own compose files" if you're not running docker?

BirAdam 3y ago
My point was, learn it first, then learn docker and Ansible and such.