Ideally, there’d be a simple RPM installer compatible with Alma 9 that I can point to a samba share that holds all the photos, kind of like what I do with Jellyfin. Also nice if it uses an otherwise unused port or I can easily set what port it uses.
My googling is finding a bunch of docker stuff, which always seems needlessly complicated to me vs an RPM… I’m also using a low powered x86 tiny computer to front JellyFin and would like to host this on the same computer vs needing another server.
They’re also useful because they’re easy to deploy, contain all the dependencies needed, portable, and isolate things breaking from affecting the host or other containers.
Because it’s easier to tell someone “use this docker image” than it is to tell them “go through all of these thousands of steps to get this service working”.
The main reason I use containers for my personal things is easy to setup and to migrate, those are huge points, and the added complexity is not that much, in fact I would argue it’s less complicated to figure out why a docker image is not running than figure out why a service stopped responding.
NixOS packages only work with NixOS system. They’re harder to setup than just copying a docker-compose file over and they do use container technology. If the idea is to remove complexity from the setup, NixOS goes in the opposite direction.
Also without containers you don’t solve the biggest problems such as incompatible database versions between multiple services.
I stand by what I said, I can give a 2 step tutorial on setting up any docker system (copy this compose file, run up on it), anything simpler than that wouldn’t be as robust in terms of configurations.
NixOS packages only work with NixOS system. They’re harder to setup than just copying a docker-compose file over and they do use container technology.
It’s interesting how none of that is true.
Nixpkgs work on practically any Linux kernel.
Whether NixOS modules are easier to set up and maintain than unsustainably copying docker-compose files is subjective.
Neither Nixpkgs nor NixOS use container technology for their core functionality.
NixOS has the nixos-container framework to optionally run NixOS inside of containerised environments (systemd-nspawn) but that’s rather niche actually. Nixpkgs does make use of bubblewrap for a small set of stubborn packages but it’s also not at all core to how it works.
Totally beside the point though; even if you don’t think NixOS is simpler, that still doesn’t mean containers are the only possible mean by which you could possibly achieve “easy” deployments.
Also without containers you don’t solve the biggest problems such as incompatible database versions between multiple services.
Ah, so you have indeed not even done the bare minimum of research into what Nix/NixOS are before you dismissed it. Nice going there.
as robust in terms of configurations
Docker compose is about the opposite of a robust configuration system.
Agreed, sure scaling is one factor, but I don’t think this person has ever really dived into why containers are slick. Why you aren’t tracking down what dependency hell caused your app to crash. Conflicting cuda versions. Two apps using the same port. Trying to decipher a language you’ve never used before
Whenever I hear “containers are too complex” or “I don’t like containers” I read it as “I don’t understand containers”. There are some real flaws to them, but no self respecting ops engineer would ever say “containers have no value beyond scaling”
What are you talking about… Containers make it way easier to setup and operate services, especially multicomponent services like Immich. I just tried Immich and it took me several minutes to get it running. If I wanted to give it permanent storage, I’d have to spend several more to make a directory then add a line in a file and restart it. I’ve been setting up services before Linux containers became a thing and after. I’d never go back to the pre-container times if I have the choice.
Sure, let’s add another layer of complexity for the user to set up their network, storage, and other external resources
And then users go to lemmy and ask for a software that is compatible with Alma 9 instead of getting a single docker-compose.yaml file and running docker compose up - d
If you’re talking about k8s or similar, the initial time investment is heavy. After that though, it’s not very hard to get containers running with HA, better network segmentation and compatibility across run times. Containers are a lot more portable too, and allow granular levels of isolation and security.
Also, I personally think SELinux is somewhat hard to do well.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
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:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
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.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
Wait, you don’t use containers?
deleted by creator
They’re also useful because they’re easy to deploy, contain all the dependencies needed, portable, and isolate things breaking from affecting the host or other containers.
The confidence with which you make this factually incorrect statement is mind bending.
deleted by creator
Because it’s easier to tell someone “use this docker image” than it is to tell them “go through all of these thousands of steps to get this service working”.
The main reason I use containers for my personal things is easy to setup and to migrate, those are huge points, and the added complexity is not that much, in fact I would argue it’s less complicated to figure out why a docker image is not running than figure out why a service stopped responding.
This is a false dichotomy. Just because containers make it easy to ship software, doesn’t mean other means can’t be equally easy.
NixOS achieves a greater ease of deployment than docker-compose and the like without any containers involved for instance.
NixOS packages only work with NixOS system. They’re harder to setup than just copying a docker-compose file over and they do use container technology. If the idea is to remove complexity from the setup, NixOS goes in the opposite direction.
Also without containers you don’t solve the biggest problems such as incompatible database versions between multiple services.
I stand by what I said, I can give a 2 step tutorial on setting up any docker system (copy this compose file, run up on it), anything simpler than that wouldn’t be as robust in terms of configurations.
It’s interesting how none of that is true.
Nixpkgs work on practically any Linux kernel.
Whether NixOS modules are easier to set up and maintain than unsustainably copying docker-compose files is subjective.
Neither Nixpkgs nor NixOS use container technology for their core functionality.
NixOS has the
nixos-containerframework to optionally run NixOS inside of containerised environments (systemd-nspawn) but that’s rather niche actually. Nixpkgs does make use of bubblewrap for a small set of stubborn packages but it’s also not at all core to how it works.Totally beside the point though; even if you don’t think NixOS is simpler, that still doesn’t mean containers are the only possible mean by which you could possibly achieve “easy” deployments.
Ah, so you have indeed not even done the bare minimum of research into what Nix/NixOS are before you dismissed it. Nice going there.
Docker compose is about the opposite of a robust configuration system.
Agreed, sure scaling is one factor, but I don’t think this person has ever really dived into why containers are slick. Why you aren’t tracking down what dependency hell caused your app to crash. Conflicting cuda versions. Two apps using the same port. Trying to decipher a language you’ve never used before
Whenever I hear “containers are too complex” or “I don’t like containers” I read it as “I don’t understand containers”. There are some real flaws to them, but no self respecting ops engineer would ever say “containers have no value beyond scaling”
What are you talking about… Containers make it way easier to setup and operate services, especially multicomponent services like Immich. I just tried Immich and it took me several minutes to get it running. If I wanted to give it permanent storage, I’d have to spend several more to make a directory then add a line in a file and restart it. I’ve been setting up services before Linux containers became a thing and after. I’d never go back to the pre-container times if I have the choice.
And then users go to lemmy and ask for a software that is compatible with Alma 9 instead of getting a single docker-compose.yaml file and running
docker compose up - dIf you’re talking about k8s or similar, the initial time investment is heavy. After that though, it’s not very hard to get containers running with HA, better network segmentation and compatibility across run times. Containers are a lot more portable too, and allow granular levels of isolation and security.
Also, I personally think SELinux is somewhat hard to do well.
Containers have numerous other benefits. Checkout this blog post, it goes into some of them:
https://cosmicbyt.es/posts/demistifying-containers-part-1/
deleted by creator
Containers are useful for a lot more things than scaling. E.g. portability, ease of setup, dependency separation.
No. We exist.