Why docker

specseaweed, 1 year 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.

vzq, 1 year ago (edited 6 months ago)

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.

scrubbles, 1 year 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.

vzq, 1 year 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.

scrubbles, 1 year ago

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.

vzq, 1 year ago

Everything I wrote is rigorously correct, if a bit tongue in cheek.

Go play with your Dunning Kruger somewhere else.

hedgehog, 1 year 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?

eluvatar, 1 year 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.

Gooey0210, 1 year ago (edited 5 months ago)

Check out Nixos, this is like the next step of docker

Ah, and a side note: docker is not fully open source

avidamoeba, 1 year ago

In short, yes, yes it’s worth it.

corroded, 1 year 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.

Sethayy, 1 year 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

knobbysideup, 1 year 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

aleq, 1 year 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

SpeakinTelnet, 1 year 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.

corsicanguppy, 1 year ago

It looks great on a resume, even if there’s a risk you’ll land a job involving it.

scrubbles, 1 year 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?

ericjmorey, 1 year ago

What makes it make sense in a work environment?