Hi! Question in the title.
I get that its super easy to setup. But its really worthwhile to have something that:
- runs everything as root (not many well built images with proper useranagement it seems)
- you cannot really know which stuff is in the images: you must trust who built it
- lots of mess in the system (mounts, fake networks, rules…)
I always host on bare metal when I can, but sometimes (immich, I look at you!) Seems almost impossible.
I get docker in a work environment, but on self hosted? Is it really worth while? I would like to hear your opinions fellow hosters.
people are rebuffing the criticism already.
heres the main advantage imo:
no messy system or leftovers. some programs use directories all over the place and it gets annoying fast if you host many services. sometimes you will have some issue that requires you to do quite a bit of hunting and redoing things.
docker makes this painless. you can deploy and redeploy stuff easily and quickly, without a mess. updates are painless and quick too, with everything neatly self-contained.
much easier to maintain once you get the hang of things.
I have VMs on my metal, one specific for containers.
Though I use LXC. Docker started with LXC, then grew bigger, and I don’t like how big it is.
If I can set up one simple NAT and run everything inside a container, I don’t need Docker.
Docker’s main advantage is the hub.
Because if you use relative bind mounts you can move a whole docker compose set of contaibera to a new host with docker compose stop then rsync it over then docker compose up -d.
Portability and backup are dead simple.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters DNS Domain Name Service/System Git Popular version control system, primarily for code HTTP Hypertext Transfer Protocol, the Web LXC Linux Containers NAS Network-Attached Storage NAT Network Address Translation VPN Virtual Private Network k8s Kubernetes container management package nginx Popular HTTP server
8 acronyms in this thread; the most compressed thread commented on today has 8 acronyms.
[Thread #423 for this sub, first seen 10th Jan 2024, 18:25] [FAQ] [Full list] [Contact] [Source code]
- Podman solves the root issue
- you can inspect the stuff. You don’t have to, but it helps if you’re not paranoid with popular and widespread images
- I have no mess
It’s great that you do install things on bare metal, I did that in the beginning until I discovered docker and I will never go back. Docker/ podman compose is just so good
you can inspect the stuff. You don’t have to, but it helps if you’re not paranoid with popular and widespread images
Dive is a great tool for inspecting docker images. I wish I found it sooner.
Need to study podman probably, stuff running as root is my main dislike.
Probably if in only used docker images created by me I would be less concerned of losing track of what I am really deploying, but this would deflect the main advantage of easy deploy?
Portability is a point I didn’t considered too… But rebuilding a bare metal server properly compatimentized took me a few hours only, so is that really so important?
You can run docker rootless https://docs.docker.com/engine/security/rootless/ but you have to switch to podman some day anyway, althiugh that might be in a far away future.
If you are concerned about root you may be concerned about the docker port dilemma as well, podman solves that as well
But rebuilding a bare metal server properly compatimentized took me a few hours only, so is that really so important?
Depends on how much you value your time.
Compare a few hours on bare metal to a few minutes with containers. Then consider that you also spend extra time on bare metal cleaning up messes. Containers don’t make a mess in the first place.
About the root problem, as of now new installs are trying to let the user to run everything as a limited user. And the program is ran as root inside the container so in order to escape from it the attacker would need a double zero day exploit (one for doing rce in the container, one to escape the container)
The alternative to “don’t really know what’s in the image” usually is: “just download this Easy minified and incomprehensible trustmeimtotallynotavirus.sh script and run it as root”. Requires much more trust than a container that you can delete with no traces in literally seconds
If the program that you want to run requires python modules or node modules then it will make much more mess on the system than a container.
Downgrading to a previous version (or a beta preview) of the app you’re running due to bugs it’s trivial, you just change a tag and launch it again. Doing this on bare metal requires to be a terminal guru
Finally, migrating to a new fresh server is just
docker compose down, then rsync to new server, and thendocker compose up -d. And not praying to ten different gods because after three years you forgot how did you install the app in bare metal like that.Docker is perfect for common people like us self hosting at home, the professionals at work use kubernetes
Others have addressed the root and trust questions, so I thought I’d mention the “mess” question:
Even the messiest bowl of ravioli is easier to untangle than a bowl of spaghetti.
The mounts/networks/rules and such aren’t “mess”, they are isolation. They’re commoditization. They’re abstraction - Ways to tell whatever is running in the container what it wants to hear, so that you can treat the container as a “black box” that solves the problem you want solved.
Think of Docker containers less like pets and more like cattle, and it very quickly justifies a lot of that stuff because it makes the container disposable, even if the data it’s handling isn’t.
I ended up using Docker to set up pict-rs and y’all are making me happy I did
Life is too short to install everything on baremetal.
For real, at the minimum use a virtual machine.
Use lxc/lxd to get all of the performance benefits of docker and all the freedom of a vm
How is this meaningfully different than using Deb packages? Or building from source without inspecting the build commands? Or even just building from source without auditing the source?
In the end docker files are just instructions for running software to set up other software. Just like every other single shell script or config file in existence since the mid seventies.
Your first sentence proves that it’s different. The developer needs to know it’s going to be a Deb package. What about rpm? What about if it’s going to run on mac? Windows? That means they’ll have to change how they develop to think about all of these different platforms. Oh you run windows - well windows doesn’t have openssl, so we need to do this vs that.
I’d recommend reading up on docker and containerization. It is not a script for setting up software. If that’s what you’re thought is then you really don’t understand containerization and I recommend taking some learnings on it. Like it or not it’s here, and if you’re doing any dev/ops work professionally you will be left behind for not understanding it.
Apparently I was unclear, I was referring to the security implications of using different manifestations of other people’s code. Those are rather similar.
I’d recommend reading up on docker and containerization. It is not a script for setting up software.
I was referring specifically to docker files. Those are almost to the letter scripts for setting up software.
if that’s what you’re thought is then you really don’t understand containerization and I recommend taking some learnings on it.
I find your attitude not just uncharitable, but also rude.
and I find misinformation about topics like this also to be rude. It’s perfectly fine if you don’t understand something, but what I don’t like is you going out of your way to dissuade people from using a product when I don’t think you understand the core concepts of it. If you have valid criticisms like security of docker then that’s a different conversation about securing containers, but it’s hard to take them as valid criticisms if the criticism is based on a fundamental misunderstanding of the product.
I don’t think anyone I have ever talked to professionally or read about docker would ever describe a dockerfile as “scripts for setting up software”. It is much more nuanced then that.
So yes, I’m a bit rude about it. I do this professionally and I’m very tired of people who don’t understand containerization explain to me how containerization sucks.
I don’t think you understood the context of the comment you replied to. As a reply to “Here are all these drawbacks to Docker vs hosting on bare metal,” it makes perfect sense to point out that the risks are there regardless.
Unless I misread your comment and you’re suggesting that you think devs not having to deal with OS-specific code is a disadvantage of Docker. Or maybe you meant your second paragraph to be directed at OP?
Well docker tends to be more secure if you configure it right. As far as images go it really is just a matter of getting your images from official sources. If there isn’t a image already available you can make one.
The big advantage to containers is that they are highly reproducible. You no longer need to worry about issues that arise when running on the host directly.
Also if you are looking for a container runtime that runs as a local user you should check out podman. Podman works very similarly to docker and can even run your containers as a systemd user service.
Removed by mod
1 is just not true sorry. There’s loads of stuff that only work as root and people use them.
Imo, yes.
- only run containers from trusted sources (btw. google, ms, apple have proven they cant be trusted either)
- run apps without dependency hell
- even if someone breaks in, they’re not in your system but in a container
- have everything web facing separate from the rest
- get per app resource statistics
Those are just what was in my head. Probably more to be said.
Also the ability to snapshot an image, goof around with changes, and if you don’t like them restore the snapshot makes it much easier to experiment than trying to unwind all the changes you make.
- Even if someone breaks in, they are not a user, but root 🤝
*in that container, not in the system
Docker is a messy and not ideal but it was born out of a necessity, getting multiple services to coexist together outside of a container can be a nightmare, updating and moving configuration is a nightmare and removing things can leave stuff behind which gets messier and messier over time. Docker just standardises most of the configuration whilst requiring minimal effort from the developer
About the trust issue. There’s no more or less trust than running on bare metal. Sure you could compile everything from source but you probably won’t, and you might trust your distro package manager, but that still has a similar problem.
Check out Nixos, this is like the next step of docker
Ah, and a side note: docker is not fully open source
