Why docker

Submitted ⁨⁨3⁩ ⁨months⁩ ago⁩ by ⁨Shimitar@feddit.it⁩ to ⁨selfhosted@lemmy.world⁩

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.

source

Comments

Sort:hotnew top

beta_tester@lemmy.ml ⁨3⁩ ⁨months⁩ ago
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
source
- redcalcium@lemmy.institute ⁨3⁩ ⁨months⁩ ago
  
  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.
  
  source
  - droolio@feddit.uk ⁨3⁩ ⁨months⁩ ago
    Thank you for posting this, hadn’t heard of it before.
    
    source
- TCB13@lemmy.world ⁨3⁩ ⁨months⁩ ago
  It doesn’t really matter if there are truly open-source and open ecosystems of containerization technologies because in the end people/companies will pick the proprietary / closed option just because “it’s easier to use” or some other specific thing that will be good on the short term and very bad on the long term. This happened with CentOS vs Debian is currently unfolding with Docker vs LXC/RKT/Podman and will happen with Ubuntu vs Debian for all those who moved from CentOS to Ubuntu.
  
  source
  - ericjmorey@programming.dev ⁨3⁩ ⁨months⁩ ago
    It cuts both ways. Less commercial interest means only hobby level development (which can be high quality, but is typically slow and unpolished for users).
    
    So you can spend your energy on making up the gap between the ease of use of the commercially supported software or you can have free time for things you’re more interested in and jump ship when they squeeze too hard for cash.
    
    source
    -> View More Comments
  - beta_tester@lemmy.ml ⁨3⁩ ⁨months⁩ ago
    What’s the issue with podman?
    
    source
    -> View More Comments
  - lemmyvore@feddit.nl ⁨3⁩ ⁨months⁩ ago
    I mean, “it’s easier to use” is a pretty good quality to have. People tend to pick the most user-friendly and time-saving solution, should we really be surprised? On the contrary, I think FOSS should strive to be easier to use.
    
    source
    -> View More Comments
- Molecular0079@lemmy.world ⁨3⁩ ⁨months⁩ ago
  Out of curiosity, what reverse proxy docker do you use that can run rootless in podman? My main issue, and feel free to correct me if I am wrong, is that most of them require root. And then its not possible to easily connect those containers into the same network as your rootless containers so then your other containers have to be root anyways. I don’t really want my other containers to be host accessible, I want them to be only accessible from within the podman network that the reverse proxy has access to.
  
  And then there’s issues where you have to enable lingering processes for normal users and also let it access ports < 1024, makes using docker-compose a pain, etc. I haven’t really found a good solution for rootless, but I really want to eventually move that way.
  
  source
  - vzq@lemmy.blahaj.zone ⁨3⁩ ⁨months⁩ ago
    www.reddit.com/r/…/rootless_reverse_proxy/
    
    source
  - beta_tester@lemmy.ml ⁨3⁩ ⁨months⁩ ago
    Tbo, I’ve got a pi that runs only the reverse proxy and it works and I don’t touch it until it breaks
    
    source
- Shimitar@feddit.it ⁨3⁩ ⁨months⁩ ago
  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?
  
  source
  - beta_tester@lemmy.ml ⁨3⁩ ⁨months⁩ ago
    You can run docker rootless 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
    
    source
    -> View More Comments
  - null@slrpnk.net ⁨3⁩ ⁨months⁩ ago
    
    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.
    
    source
- QuikxSpec@lemmy.world ⁨3⁩ ⁨months⁩ ago
  Do you have a preferred resource? I’m setting up my NAS and starting to prepare for setting up containers. In the meantime it’s just static storage until I get comfortable
  
  source
  - beta_tester@lemmy.ml ⁨3⁩ ⁨months⁩ ago
    No, just general documentation and arch wiki
    
    source
shalva97@lemmy.world ⁨3⁩ ⁨months⁩ ago
Life is too short to install everything on baremetal.

source
- purplemonkeymad@programming.dev ⁨3⁩ ⁨months⁩ ago
  For real, at the minimum use a virtual machine.
  
  source
  - spookedbyroaches@lemm.ee ⁨3⁩ ⁨months⁩ ago
    Use lxc/lxd to get all of the performance benefits of docker and all the freedom of a vm
    
    source
umbrella@lemmy.ml ⁨3⁩ ⁨months⁩ ago
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.

source
- million@lemmy.world ⁨3⁩ ⁨months⁩ ago
  Quick addition, I think for the messy argument the way I would articulate it for folks running servers is it helps you move from pets to cattle.
  
  source
Moonrise2473@feddit.it ⁨3⁩ ⁨months⁩ ago
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 then docker 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

source
- itsnotits@lemmy.world ⁨3⁩ ⁨months⁩ ago
  
  the program is run* as root
  
  source
haui_lemmy@lemmy.giftedmc.com ⁨3⁩ ⁨months⁩ ago
Imo, yes.

only run containers from trusted sources (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.
source
- invertedspear@lemm.ee ⁨3⁩ ⁨months⁩ ago
  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.
  
  source
  - haui_lemmy@lemmy.giftedmc.com ⁨3⁩ ⁨months⁩ ago
    I havent actually tried that. Might need to check it out. :)
    
    source
- Gooey0210@sh.itjust.works ⁨3⁩ ⁨months⁩ ago
  Even if someone breaks in, they are not a user, but root 🤝
  
  source
  - haui_lemmy@lemmy.giftedmc.com ⁨3⁩ ⁨months⁩ ago
    *in that container, not in the system
    
    source
aniki@lemm.ee ⁨3⁩ ⁨months⁩ ago
1.) No one runs rooted docker in prod. Everything is run rootless. 2.) That’s just patently not true. docker inspect is your friend. Also you can build your own packages. FROM Scratch hub.docker.com/_/scratch/ 3.) I think mess here is subjective. Docker folders makes way more sense than Snap mounts.

source
- eluvatar@programming.dev ⁨3⁩ ⁨months⁩ ago
  1 is just not true sorry. There’s loads of stuff that only work as root and people use them.
  
  source
peter@feddit.uk ⁨3⁩ ⁨months⁩ ago
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

source
MartianSands@sh.itjust.works ⁨3⁩ ⁨months⁩ ago
I find it makes my life easier, personally, because I can set up and tear down environments I’m playing with easily.

As for your user & permissions concern, are you aware that docker these days can be configured to map “root” in the container to a different user? Personally I prefer to use podman though, which doesn’t have that problem to begin with

source
- micka190@lemmy.world ⁨3⁩ ⁨months⁩ ago
  
  I find it makes my life easier, personally, because I can set up and tear down environments I’m playing with easily.
  
  Same here. I self-host a bunch of dev tools for my personal toy projects, and I decided to migrate from Drone CI to Woodpecker CI this week. Didn’t have to worry about uninstalling anything, learning what commands I need to start/stop/restart Woodpecker properly, etc. I just commented-out my Drone CI/Runner services from my docker-compose file, added the Woodpecker stuff, pointed it to my Gitea variables and it ran docker compose up -d.
  
  If my server ever crashes, I can just copy it over and start from scratch.
  
  source
  - aniki@lemm.ee ⁨3⁩ ⁨months⁩ ago
    I really need to get into Woodpecker.
    
    source
Hexarei@programming.dev ⁨3⁩ ⁨months⁩ ago
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.

source
- paws@cyberpaws.lol ⁨3⁩ ⁨months⁩ ago
  I ended up using Docker to set up pict-rs and y’all are making me happy I did
  
  source
ssdfsdf3488sd@lemmy.world ⁨3⁩ ⁨months⁩ ago
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.

source
DeltaTangoLima@reddrefuge.com ⁨3⁩ ⁨months⁩ ago
To answer each question:

You can run rootless containers but, importantly, you don’t need to run Docker as root. Should the unthinkable happen, and someone “breaks out” of docker jail, they’ll only be running in the context of the user running the docker daemon on the physical host.

True but, in my experience, most docker images are open source and have git repos - you can freely download the repo, inspect the build files, and build your own. I do this for some images I feel I want 100% control of, and have my own local Docker repo server to hold them.

It’s the opposite - you don’t really need to care about docker networks, unless you have an explicit need to contain a given container’s traffic to it’s own local net, and bind mounts are just maps to physical folders/files on the host system, with the added benefit of mounting read-only where required.

I run containers on top of containers - Proxmox cluster, with a Linux container (CT) for each service. Most of those CTs are simply a Debian image I’ve created, running Docker and a couple of other bits. The services then sit inside Docker (usually) on each CT.

It’s not messy at all. I use Portainer to manage all my Docker services, and Proxmox to manage the hosts themselves.

Why? I like to play.

Proxmox gives me full separation of each service - each one has its own CT. Think of that as me running dozens of Raspberry Pis, without the headache of managing all that hardware. Docker gives me complete portability and recoverability. I can move services around quite easily, and can update/rollback with ease.

Finally, the combination of the two gives me a huge advantage over bare metal for rapid prototyping.

Let’s say there’s a new contender that competes with Immich. I have Immich hosted on a CT, using Docker, and hiding behind Nginx Proxy Manager (also on a CT).

I can spin up a Proxmox CT from my own template, use my Ansible playbook to provision Docker and all the other bits, load it in my Portainer management platform, and spin up the latest and greatest Immich competitor, all within mere minutes. Like, literally 10 minutes max.

I have a play with the competitor for a bit. If I don’t like it, I just delete the CT and move on. If I do, I can point my photos… hostname (via Nginx Proxy Manager) to the new service and start using it full-time. Importantly, I can still keep my original Immich CT in place - maybe shutdown, maybe not - just in case I discover something I don’t like about the new kid on the block.
source
- lemmyvore@feddit.nl ⁨3⁩ ⁨months⁩ ago
  
  Should the unthinkable happen, and someone “breaks out” of docker jail, they’ll only be running in the context of the user running the docker daemon on the physical host.
  
  There is no daemon in rootless mode. Instead of a daemon running containers in client/server mode you have regular user processes running containers using fork/exec. Not running as root is part and parcel of this approach and it’s a good thing, but the main motivator was not “what if someone breaks out of the container” (which doesn’t necessarily mean they’d get root on the host, and it would take a kernel exploit which is a pretty tall order). There are many benefits to making running containers as easy as running any kind of process on a Linux host. And it also enabled some cool new features like the ability to run only partial layers of a container, or nested containers.
  
  source
  - DeltaTangoLima@reddrefuge.com ⁨3⁩ ⁨months⁩ ago
    Yep, all true. I was oversimplifying in my explanation, but you’re right. There’s a lot more to it than what I wrote - I was more relating docker to what we used to do with chroot jails.
    
    source
MigratingtoLemmy@lemmy.world ⁨3⁩ ⁨months⁩ ago
Docker can be run rootless. Podman is rootless by default.

I build certain containers from scratch. Very popular FOSS software can be trusted, but if you’re as paranoid, you should probably run the bare-minimum software in the first-place.

It’s a mess if you’re not used to it. But yes, normal unix networking is somewhat simpler (like someone mentioned, LXC containers can be a decent idea). Well, you’ll realise that Docker is not really top-dog in terms of complexity when you start playing with the big boys like full-fledged k8s

source
possiblylinux127@lemmy.zip ⁨3⁩ ⁨months⁩ ago
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.

source
TCB13@lemmy.world ⁨3⁩ ⁨months⁩ ago
Why docker?

Its all about companies re-creating and reconfiguring the way people develop software so everyone will be hostage of their platforms. We see this in everything now Docker/DockerHub/Kubernetes and GitHub actions were the first sign of this cancer.

We now have a generation of developers that doesn’t understand the basic of their tech stack, about networking, about DNS, about how to deploy a simple thing into a server that doesn’t use some Docker or isn’t a 3rd party cloud xyz deploy-from-github service.

oh but the underlying technologies aren’t proprietary

True, but this Docker hype invariably and inevitably leads people down a path that will then require some proprietary solution or dependency somewhere that is only required because the “new” technology itself alone doesn’t deliver as others did in the past. In this particular case is Docker Hub / Kubernetes BS and all the cloud garbage around it.

oh but there are alternatives like podman

It doesn’t really matter if there are truly open-source and open ecosystems of containerization technologies because in the end people/companies will pick the proprietary / closed option just because “it’s easier to use” or some other specific thing that will be good on the short term and very bad on the long term. This happened with CentOS vs Debian is currently unfolding with Docker vs LXC/RKT/Podman and will happen with Ubuntu vs Debian for all those who moved from CentOS to Ubuntu.

lots of mess in the system (mounts, fake networks, rules…)

Yes, a total mess of devices hard to audit, constant ram wasting and worse than all it isn’t as easy change a docker image / develop things as it used to be.

source
- scrubbles@poptalk.scrubbles.tech ⁨3⁩ ⁨months⁩ ago
  This is a really bad take. I’m all for OSS, but that doesn’t mean that there isn’t value with things like Docker.
  
  Yes, developers know less about infra. I’d argue that can be a good thing. I don’t need my devs to understand VLANs, the nuances of DNS, or any of that. I need them to code, and code well. That’s why we have devops/infra people. If my devs to know it? Awesome, but docker and containerization allows them to focus on code and let my ops teams figure out how they want to put it in production.
  
  As for OSS - sure, someone can come along and make an OSS solution. Until then - I don’t really care. Same thing with cloud providers. It’s all well and good to have opinions about OSS, but when it comes to companies being able to push code quickly and scalably, then yeah I’m hiring the ops team who knows kubernetes and containerization vs someone who’s going to spend weeks trying to spin up bare iron machines.
  
  source
- Shimitar@feddit.it ⁨3⁩ ⁨months⁩ ago
  Is all this true? Its a perspective I didn’t considered, but feels true, don’t know if it is tough.
  
  source
  - lemmyvore@feddit.nl ⁨3⁩ ⁨months⁩ ago
    It’s not true. I mean sure there are companies that try to lock you into their platforms but there’s no grand conspiracy of the lizard people the way OP makes it sound.
    
    Different people want different things from software. Professionals may prefer rootless podman or whatever but a home user probably doesn’t have the same requirements and the same high bar. They can make do with regular docker or with running things on the metal. It’s up to each person to evaluate what’s best for them. There’s no “One True Way” of hosting software services.
    
    source
oranki@sopuli.xyz ⁨3⁩ ⁨months⁩ ago
Portability is the key for me, because I tend to switch things around a lot. Containers generally isolate the persistent data from the runtime really well.

Docker is not the only, or even the best way IMO to run containers. If I was providing services for customers, I would definetly build most container images daily in some automated way. Well, I do it already for quite a few.

The mess is only a mess if you don’t really understand what you’re doing, same goes for traditional services.

source
Semi-Hemi-Demigod@kbin.social ⁨3⁩ ⁨months⁩ ago
I don't run any of my containers as root

Dockerfiles aren't hard to read so you can pretty easily figure out what they're doing

I find managing dependencies for non-containerized services to be worse than one messy docker directory I never look at

Plus having all my services in a couple docker-compose files also means I can move them around incredibly easily.
source
msage@programming.dev ⁨3⁩ ⁨months⁩ ago
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.

source
vzq@lemmy.blahaj.zone ⁨3⁩ ⁨months⁩ ago
How is this meaningfully different than using Deb packages? Or building from since 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.

source
- scrubbles@poptalk.scrubbles.tech ⁨3⁩ ⁨months⁩ ago
  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.
  
  source
  - hedgehog@ttrpg.network ⁨3⁩ ⁨months⁩ ago
    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?
    
    source
  - vzq@lemmy.blahaj.zone ⁨3⁩ ⁨months⁩ ago
    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.
    
    source
    -> View More Comments
specseaweed@lemmy.world ⁨3⁩ ⁨months⁩ ago
I know enough to be dangerous. I know enough to follow faqs but dumb enough to not backup like I should.

So I’d be running my server on bare metal and have a couple services going and sooner or later, shit would get borked. Shit that was miles past my competence to fix. Sometimes I’d set up a DB wrong, or break it, or an update would screw it up, and then it would all fall apart and I’m there cursing and wiping and starting all over.

Docker fixes that completely. It’s not perfect, but it has drastically lowered my time working on my server.

My server used to be a hobby that I loved dumping hours into. Now, I just want shit to work.

source
aleq@lemmy.world ⁨3⁩ ⁨months⁩ ago
the biggest selling point for me is that I’ll have a mounted folder or two, a shell script for creating the container, and then if I want to move the service to a new computer I just move these files/folders and run the script. it’s awesome. the initial setup is also a lot easier because all dependencies and stuff are bundled with the app.

in short, it’s basically the exe-file of the server world

runs everything as root (not many well built images with proper useranagement it seems)

that’s true I guess, but for the most part shit’s stuck inside the container anyway so how much does it really matter?

you cannot really know which stuff is in the images: you must trust who built it

you kinda can, reading a Dockerfile is pretty much like reading a very basic shell script for the most part. regardless, I do trust most creators of images I use. most of the images I have running are either created by the people who made the app, or official docker images. if I trust them enough to run their apps, why wouldn’t I trust their images?

lots of mess in the system (mounts, fake networks, rules…)

that’s sort of the point, isn’t it? stuff is isolated

source
eluvatar@programming.dev ⁨3⁩ ⁨months⁩ ago
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.

source
Gooey0210@sh.itjust.works ⁨3⁩ ⁨months⁩ ago
Check out Nixos, this is like the next step of docker

source
avidamoeba@lemmy.ca ⁨3⁩ ⁨months⁩ ago
In short, yes, yes it’s worth it.

source
corroded@lemmy.world ⁨3⁩ ⁨months⁩ ago
My personal opinion is that Docker just makes things more difficult. Containers are fantastic, and I use plenty of them, but Docker is just one way to implement containers, and a bad one. I have a server that runs Proxmox; if I need to set up a new service, I just spin up a LXC and install what I need to. It gives all the advantages of a full Linux installation without taking up the resources of a full-fledged OS. With Docker, I would need a VM running the docker host, then I’d have to install my docker containers inside this host, then forward any ports or resources between the hypervisor, docker host, and docker container.

I just don’t get the use-case for Docker. As far as I can tell, all it does is add another layer of complexity between the host machine and the container.

source
- Sethayy@sh.itjust.works ⁨3⁩ ⁨months⁩ ago
  Though this is more of a proxmox ease of use issue than docker, personally I swapped from it to pure debian server/host to run a similar manual setup with podman - so everything runs right on the host.
  
  In theory I think you can achieve this with proxmox ssh’ing into the host and just treating it like a usual debian
  
  source
knobbysideup@sh.itjust.works ⁨3⁩ ⁨months⁩ ago
I concur with most of your points. Docker is a nice thing for some use cases, but if I can easily use a package or set up my own configurations, then I will do that instead of use a docker container every time. My main issues with docker:

Containers are not updated with the rest of the host OS

firewall and mounting complexities which make securing it more difficult
source
bluGill@kbin.social ⁨3⁩ ⁨months⁩ ago
Docker gives you a few different things which might or might not matter. Note that all of the following can be gotten in ways other than docker as well. Sometimes those ways are better, but often what is better is just opinion. There are downsides to some of the following as well that may not be obvious.

With docker you can take a container and roll it out to 100s of different machines quickly. this is great for scaling if your application can scale that way.

With docker you can run two services on the same machine that use incompatible versions of some library. It isn't unheard of to try to upgrade your system and discover something you need isn't compatible with the new library, while something else you need to upgrade needs the new library. Docker means each service gets separate copies of what is needs and when you upgrade one you can leave the other behind.

With docker you can test an upgrade and then when you roll it out know you are rolling out the same thing everywhere.

With docker you can move a service from one machine to a different one somewhat easily if needed. Either to save money on servers, or to use more as more power is needed. Since the service itself is in a docker you can just start the container elsewhere and change pointers.

With docker if someone does manage to break into a container they probably cannot break into other containers running on the same system. (if this is a worry you need to do more risk assessment, they can still do plenty of damage)

source
scrubbles@poptalk.scrubbles.tech ⁨3⁩ ⁨months⁩ ago
I’ll answer your question of why with your own frustration - bare metal is difficult. Every engineer uses a different language/framework/dependencies/whathaveyou and usually they’ll conflict with others. Docker solves this be containing those apps in their own space. Their code, projects, dependencies are already installed and taken care of, you don’t need to worry about it.

Take yourself out of homelab and put yourself into a sysadmin. Now instead of knowing how packages may conflict with others, or if updating this OS will break applications, you just need to know docker. If you know docker, you can run any docker app.

So, yes, volumes and environments are a bit difficult at first. But it’s difficult because it is a standard. Every docker container is going to need a couple mounts, a couple variables, a port or two open, and if you’re going crazy maybe a GPU. It doesn’t matter if you’re running 1 or 50 containers on a system, you aren’t going to get conflicts.

As for the security concerns, they are indeed security concerns. Again imagine you’re a sysadmin - you could direct developers that they can’t use root, that they need to be built on OS’s with the latest patches. But you’re at home, so you’re at the mercy of whoever built the image.

Now that being said, since you’re at their mercy, their code isn’t going to get much safer whether you run it bare-iron or containerized. So, do you want to spend hours for each app figuring out how to run it, or spend a few hours now to learn docker and then have it standardized?

source
Decronym@lemmy.decronym.xyz ⁨3⁩ ⁨months⁩ ago
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

LXC Linux Containers

k8s Kubernetes container management package

[Thread #423 for this sub, first seen 10th Jan 2024, 18:25] [FAQ] [Full list] [Contact] [Source code]

source
SpeakinTelnet@sh.itjust.works ⁨3⁩ ⁨months⁩ ago
I’ll say that as someone who stopped using docker and went back to deploying from source in lxc containers: dockers is a great tool for the majority of people and that is exactly what it aims to be, easily reusable in as many different setups as possible.

On the flip side, yes it may happen that you would not benefit from docker for a reason or another. I don’t, in my case docker only adds another layer over my already containerized setup and many of the services I deploy are already built from source in a CI/CD workflow and deployed through ansible.

I do have other issues with docker but those are usually less with the tool and more with how some project use docker as a mean to replace proper deployment documentations.

source
corsicanguppy@lemmy.ca ⁨3⁩ ⁨months⁩ ago
It looks great on a resume, even if there’s a risk you’ll land a job involving it.

source

Fewer Letters	More Letters
DNS	Domain Name Service/System
LXC	Linux Containers
k8s	Kubernetes container management package

-> View More Comments