Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why would anyone choose Docker over fat binaries?

smashcompany.com

Post reply on HN
Print view View original

161–170 of 180 posts

Re: Why would anyone choose Docker over fat binaries?

#161

Post by esteban85 »

notyourday wrote: post #61
friend-monoid wrote: post #48

* If my colleagues don't have to understand how do deploy applications properly, their work is simplified greatly. If I can just take their work, put it in a container, no matter the language or style, my work is greatly simplified. I don't have to worry about how to handle crashes, infinite loops, or other bad code they write. * We have a whole lot of HTTP services in a range of languages. Managing them all with fat…

> * If my colleagues don't have to understand how do deploy applications properly, their work is simplified greatly. If I can just take their work, put it in a container, no matter the language or style, my work is greatly simplified. I don't have to worry about how to handle crashes, infinite loops, or other bad code they write. Of course you do, you just moved the logic into the "orchestration" and "management" lay…

clearly you never had to reengineer some crappy code whilst making the current live system operate.

Docker nowadays at least for me is essential for encapsulating st

Re: Why would anyone choose Docker over fat binaries?

#162

Post by funnelsgun »

falcolas wrote: post #69
jchw wrote: post #52

Well, the author is definitely missing the point. In scenario 1, I put a Go binary onto a server and make a systemd unit file. In scenario 2, I put a Go binary in a docker container and launch it on a Kubernetes cluster. Scenario 2 is wasting a ton more cycles and RAM, but other than that, what's the difference? * With containers I can put a Python app right alongside my binary but with total isolation. No need to fu…

> but other than that, what's the difference? The need to configure, manage, monitor and maintain a whole extra set of programs. Also, systemd can just as easily start the binary in a cgroup, eliminating most of the following concerns. > The isolation is broken Worth noting that behind the scenes, Linux is using the same in-memory versions of libc, even for containers. That isolation you speak of already doesn't exis…

We moved our infrastructure from scheduling containers with configuration management to scheduling containers with Nomad... and it is so much better.

We no longer have the concern of defining static ports for each app, configuring App A with the port for App B, autoscaling when traffic increases 3x as someone attempts a L7 DDOS... I could go on!

Re: Why would anyone choose Docker over fat binaries?

#163

Post by mschuster91 »

xorcist wrote: post #146
mschuster91 wrote: post #60

Earlier quoted context omitted.

> It's just a process with a fancy chroot. Don't believe all the docker hype. Sensible admins have been doing something similar for years. You can easily break out of a chroot jail: http://pentestmonkey.net/blog/chroot-breakout-perl Thats not possible in Docker (okay, it is if you're running a container in privileged mode but that's another can of worms and you shouldn't do it unless absolutely neccessary). Also, Doc…

> Thats not possible in Docker Believe this at your own peril.

At least right now, I do not know of a way to break out of a Docker container and the last bug I know of was fixed in 2014 (https://blog.docker.com/2014/06/docker-container-breakout-pr...).

The only ways I know of that can be used to jailbreak are, as documented on https://security.stackexchange.com/a/153016: kernel vulns (which are not inherent to Docker, and can hit you on any kind of Linux environment as soon as you achieve RCE in a hosted application), running a container with --privileged, and being careless with bindmounts - either by bind-mounting /dev, /proc and friends which you shouldn't do in any case unless you're aware of the pitfalls or by bind-mounting the Docker socket file.

The latter is something that I see far too often (especially with docker-in-docker setups for Jenkins slaves), but if you're avoiding this, you're safe from that vector.

Re: Why would anyone choose Docker over fat binaries?

#164

Post by gcb0 »

geofft wrote: post #143
gcb0 wrote: post #92

Earlier quoted context omitted.

and don't forget that crap code == insecure code. but nobody have to worry about it. just start a container the last guy left. /sarcasm

> and don't forget that crap code == insecure code. I don't think I believe that equality is nearly as neat you'd hope. Unless we're willing to call all code crap code, a lot of projects with well-respected code and development practices have had serious zero days, and we've also found that sandboxing software is highly effective. Insecure code in a secure, well-written sandbox can get you a secure deployment , and y…

zero days and the privilege escalation are a luxury.

bad code is often plaged with injection/sql injection. Which sandbox does an absolute NOTHING to protect you from. After all, it is all within the expected side effects of your code.

Re: Why would anyone choose Docker over fat binaries?

#165

Post by jchw »

pmoriarty wrote: post #117
jchw wrote: post #52

Well, the author is definitely missing the point. In scenario 1, I put a Go binary onto a server and make a systemd unit file. In scenario 2, I put a Go binary in a docker container and launch it on a Kubernetes cluster. Scenario 2 is wasting a ton more cycles and RAM, but other than that, what's the difference? * With containers I can put a Python app right alongside my binary but with total isolation. No need to fu…

"Systemd can use Cgroups to limit RAM or CPU, but schedulers like Kubernetes can also use your CPU and RAM limits to schedule containers. As far as I know, there's no equivalent tooling for doing this with fat binaries." They're called cgroups. You don't need systemd, Docker or Kubernetes to use them.

I called them Cgroups. If you're being pedantic about the capitalization, take that up with RedHat as well.

Re: Why would anyone choose Docker over fat binaries?

#166

Post by nickpsecurity »

KaiserPro wrote: post #28
supermatt wrote: post #13

Earlier quoted context omitted.

Google ran all their stuff as fat binaries through Borg? Why would they change to containers with kubernetes if the borg approach is better?

because in borg land, everything apart from the binary is controlled by the scheduler. why is that good? because it means that the thing that knows about resource utilisation has control of what resources it give out. quite patch on the farm? give the low priority jobs more memory/cpu. You also have to remember that borg is part of the secret sauce that makes google tick. Having a single interface to a smart, efficie…

You might find this interesting:

https://www.cl.cam.ac.uk/~rnw24/papers/2016-osdi-firmament.p...

Re: Why would anyone choose Docker over fat binaries?

#167

Post by bm1362 »

gcb0 wrote: post #164
geofft wrote: post #143

Earlier quoted context omitted.

> and don't forget that crap code == insecure code. I don't think I believe that equality is nearly as neat you'd hope. Unless we're willing to call all code crap code, a lot of projects with well-respected code and development practices have had serious zero days, and we've also found that sandboxing software is highly effective. Insecure code in a secure, well-written sandbox can get you a secure deployment , and y…

zero days and the privilege escalation are a luxury. bad code is often plaged with injection/sql injection. Which sandbox does an absolute NOTHING to protect you from. After all, it is all within the expected side effects of your code.

What does this have to do with Docker then?

Re: Why would anyone choose Docker over fat binaries?

#168

Post by senthilnayagam »

but why did a class of developers use inferior open source languages like ruby, python and php over enterprise fat binary java and dotnet stack. if you did not get that change you won't get it this time too.

docker helped alleviate fears of vendor lock-in with cloud providers.

wait some more time and you will see unikernel applications as new thin binaries

Re: Why would anyone choose Docker over fat binaries?

#169

Post by dullgiulio »

rkeene2 wrote: post #155
dullgiulio wrote: post #150

Earlier quoted context omitted.

Go doesn't disregard anything. It tried to parse NSS configuration, if there is no Go implementation available for the user conf it parsed, it falls back to glibc.

Only if you use "cgo", otherwise it doesn't have access to the run-time linker.

No, by default.

Re: Why would anyone choose Docker over fat binaries?

#170

Post by timthelion »

throwanem wrote: post #58
rljy wrote: post #12

Earlier quoted context omitted.

Does it even work well for go or rust executables? I seem to recall that Docker itself was written in golang because "fat binaries1111", but now docker is one of the hardest to install applications that I know of, and certainly isn't simply one executable file to be copied onto the system. Managing resource files in fat binaries is really problematic.

I've never had trouble installing Docker anywhere, whether from package managers or installers. Where have you, and what kind of trouble? If I might run into something similar down the road, better I should know about it now.

It used to be that docker could be installed literally by downloading the docker binary, then it was a single curl command. Now the documentation looks like this: https://www.docker.com/get-docker

You press "get docker community image". Then you find your distro. Go to "download from the docker store", discover that there is no dowload link https://store.docker.com/editions/community/docker-ce-server... then you click on the long form link to the docs. Which gets you here: https://docs.docker.com/engine/installation/linux/docker-ce/...

And then that is not simple at all.

So much for fat binaries making things easy. Good-ness grief.

Post reply on HN