floof.org
Everytime I look up advice/details of how to do something on Linux and the project/guide doesn't explain what to do, but instead has a docker image, my resolve to never use docker increases a little bit more.
I get why docker exists and I'm not saying that it's not useful but wow I really do not want the question "How do I do x" to be answered with "Use this docker image"
Honestly if you like docker then that's great but here me out:
Docker on enterprise servers? β
Yep
Docker instead of VMs? β
Sure why not?
Docker because you want to? β
Of course!
Docker on a single board computer for one job? β Nonononono please just tell me the steps involved so I can learn how the system works!
@garrwolfdog Sorry I didn't mean to come across as "never use docker at all" but that I dislike that answers have in some cases become "use this docker image"
For example I want a SBC to monitor the temperature of my hot water tank. The first guide I found said that I should use multiple docker images to provide Prometheus and Grafana, and other guides were similar.
In the end Darac pointed me to Munin and that's exactly what I want. :)
@garrwolfdog Like in your case if you're already au fait with docker and it fits into your network then it makes sense, but for me who's still running servers with multiple services for an internal home network I'd prefer to have the details of how to configure it myself :)
It wouldn't be an issue if it was "here's how to do it from scratch but also there's a docker image if you want" but I keep seeing guides that are "you must use docker"
@garrwolfdog Sorry let me clarify; I know nothing about docker and the first time I tried to follow one of these guides I ran into a problem with no way of being able to troubleshoot the fault. I couldn't find an easy answer of how to look at the logs or files within the docker so I had no idea what was going on.
That one did have all the code/scripts/etc not in a docker image and the first time I ran all that I found the fault straight away just by looking at the system logs.
@garrwolfdog That's how I've seen a lot of people using it for small projects, hence my aversion to it in small projects.
I've always seen it as one of those things that you have to know/be invested in learning before you use it in a production environment but some people are treating it like FlatPak/AppImage
@pippin part of the point of the containers is to avoid the very issue it sounds like you're worried they cause. There are potential Escape Routes (usually if run with too many permissions) but the idea is almost more "I don't trust this to _not_ get compromised so I'm isolating this with limited connections for networking/data out of it" with the added benefit of "I also don't have to worry about package collisions or it fucking with local packages".
Outside of official containers I tend not to trust ones where I can't see the Dockerfile, and can read to see how the container image was built and what it'll do inside itself. Useful sometimes for writing my own Dockerfile stuff like for the mastodon image I use.
But yeah the dual purpose is definitely "contain" first, hence the name, with the benefit of "isolate libraries" second meaning if your container ever goes sideways you can just tear it down, and not have to worry about "alright what files got fucked up by building or package management?" And kinda making the data a little more portable. Definitely makes migrating/moving stuff a lot less painful.
@Kay Ohtie @Epoxy / Renby ππ³οΈββ§οΈ I don't drive recklessly just because I'm wearing a seatbelt, though. π€·ββοΈ
I'm just very dubious about the benefits, haven't had the time and motivation to spend to learn this whole new thing, and haven't had any problems doing it the way I've always done it.
(I'm probably in the "anything invented after you turn 30 is newfangled trash" phase, too.)
I'm the same with snap/flatpak/appimages, for local desktop use I want a bloody package I can keep up to date with standard utilities.
Docker is for remote systems IMO.
