Why would anyone choose Docker over fat binaries? • Hacker News Board

Re: Why would anyone choose Docker over fat binaries?

#111

Post by pmoriarty » Sun, Oct 29, 2017, 5:19 PM UTC

2trill2spill wrote: post #108

pmoriarty wrote: post #104

Earlier quoted context omitted.

Those solutions still allow the host and all the other containers to be compromised through a kernel exploit, though, can't they? The most secure isolation is provided with physical separation. Second best is VMs. Containers are a distant third.

> Those solutions still allow the host and all the other containers to be compromised through a kernel exploit, though, can't they? If I keep my boxes up to date I only need to worry about zero day kernel exploits. So if someone comes along and uses a zero day kernel exploit to escape my FreeBSD jail then they were going to get on the box anyway, because any attacker using a zero day is highly skilled and highly targ…

"Virtual machines have significantly more attack surface than either Jails or Zones, think of all the emulated devices."

Nothing prevents you from using jails or zones in your VM.

Re: Why would anyone choose Docker over fat binaries?

#112

Post by wnoise » Sun, Oct 29, 2017, 5:21 PM UTC

siliconc0w wrote: post #103

Even if you build fat binaries, it's helpful for them to run in a container for a bunch of reasons: 0) security 1) container overhead

Where does he say you should run fat binaries in a VM?

Re: Why would anyone choose Docker over fat binaries?

#113

Post by [deleted] » Sun, Oct 29, 2017, 5:23 PM UTC

snarfy wrote: post #36

"A fat binary (or multiarchitecture binary) is a computer executable program which has been expanded (or "fattened") with code native to multiple instruction sets which can consequently be run on multiple processor types. This results in a file larger than a normal one-architecture binary file, thus the name." [1] What does having an x86 and x64 binary in the same executable have to do with dependency management? You…

[deleted]

Re: Why would anyone choose Docker over fat binaries?

#114

Post by 2trill2spill » Sun, Oct 29, 2017, 5:24 PM UTC

pmoriarty wrote: post #111

2trill2spill wrote: post #108

Earlier quoted context omitted.

> Those solutions still allow the host and all the other containers to be compromised through a kernel exploit, though, can't they? If I keep my boxes up to date I only need to worry about zero day kernel exploits. So if someone comes along and uses a zero day kernel exploit to escape my FreeBSD jail then they were going to get on the box anyway, because any attacker using a zero day is highly skilled and highly targ…

"Virtual machines have significantly more attack surface than either Jails or Zones, think of all the emulated devices." Nothing prevents you from using jails or zones in your VM.

> Nothing prevents you from using jails or zones in your VM.

I get that but that's no longer VMs vs containers, Thats VM plus container vs container.

Re: Why would anyone choose Docker over fat binaries?

#115

Post by pmoriarty » Sun, Oct 29, 2017, 5:29 PM UTC

IshKebab wrote: post #91

pjmlp wrote: post #65

Earlier quoted context omitted.

It is super easy to do static binaries with C, I was already doing it in 1992, the first time I actually used C on my life. It only hard if one happens to mix glibc, a specific implementation of the ANSI C standard library, with any implementation of it.

Hahaha that is soooo wrong. You might think you make a static binary with C by passing -static but trust me you do not. I believe it is still actually impossible to link with glibc statically. It's only been possible to do a static binary on Linux since Musl was written and that was not in 1992. In the 2000's there was an attempt to make true static binaries possible on Linux (think it was called Autopackage) but the…

Not only was it possible to do static linking back in those days, it was easy and it was common.

The glibc nss breakage only came later. I'm still unclear why it hasn't been fixed to once again allow easy static linking after all these years.

Re: Why would anyone choose Docker over fat binaries?

#116

Post by noahwilde » Sun, Oct 29, 2017, 5:32 PM UTC

notyourday wrote: post #73

anilakar wrote: post #70

Earlier quoted context omitted.

I think that the main point was that docker skills are transferable, i.e. you can expect a new hire to be productive in less time. Too many companies still have in-house build/deploy systems that are probably great for their purpose but don't offer valuable experience that would be usable outside that company.

In my observation, Docker skills is a modern day ability to type "make", without being able to actually write a Makefile or debug a Makefile.

Writing a dockerfile successfully is maybe that. But learning to make a dockerfile should take someone a day to figure out. What the entire movement is about is creating an ecosystem around a common standard for dev ops.

Re: Why would anyone choose Docker over fat binaries?

#117

Post by pmoriarty » Sun, Oct 29, 2017, 5:36 PM UTC

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.

Re: Why would anyone choose Docker over fat binaries?

#118

Post by pmoriarty » Sun, Oct 29, 2017, 5:42 PM UTC

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…

"Given the context that I am someone currently attempting that hackery - this shit just kinda works, some of the time. And when it fails, it's a morass of conflicting documentation, and responses of "well, you're not using the default distribution for your environment" (no shit, it's no longer supported) and "works on my single node minikube cluster"."

You could make pretty much the exact same set of complaints against all those configuration management tools (ansible/chef/salt/cfengine/puppet). They're all a huge mess of spaghetti and hackery that works when they work and can be a nightmare otherwise.

All these tools need at least a couple of decades more to mature.

Re: Why would anyone choose Docker over fat binaries?

#119

Post by manigandham » Sun, Oct 29, 2017, 5:57 PM UTC

I really don't see how this is an argument - Docker containers are like zip-files for deploying these very same app binaries, whether fat or lean - except containers are very easy to define, are able to run anything inside, can easily be uploaded/downloaded over HTTP, and abstract away all the systemd/init/background service nonsense into a clean API.

That alone is worth it, and it's what makes Kubernetes so powerful, by taking that basic runtime abstraction and further lifting it up beyond the VMs/nodes themselves.

Re: Why would anyone choose Docker over fat binaries?

#120

Post by merb » Sun, Oct 29, 2017, 6:00 PM UTC

manigandham wrote: post #119

I really don't see how this is an argument - Docker containers are like zip-files for deploying these very same app binaries, whether fat or lean - except containers are very easy to define, are able to run anything inside, can easily be uploaded/downloaded over HTTP, and abstract away all the systemd/init/background service nonsense into a clean API. That alone is worth it, and it's what makes Kubernetes so powerful…

> and abstract away all the systemd/init/background service nonsense into a clean API.

hm?! what?!

> That alone is worth it, and it's what makes Kubernetes so powerful, by taking that basic runtime abstraction and further lifting it up beyond the VMs/nodes themselves.

how is a damn yaml file over 40 lines simpler than a 7 lines systemd? (i didn't even count the setup of kubernetes, since you prolly never did)

also anything you actually said makes no sense.... since you actually compared the things that are comparable...

edit: yes, both have pro's and cons, still your things make no sense