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

Run More Stuff in Docker

jonathan.bergknoff.com

Post reply on HN
Print view View original

91–100 of 293 posts

Re: Run More Stuff in Docker

#91

Post by mikepurvis »

the_duke wrote: post #13

For end user devices, I much prefer Nix/NixOS [1] for this kind of thing. With Flakes [2] (experimental feature), you get full reproducibility. The documentation is spotty and there is a considerable learning curve, but I've switched to NixOS on my laptop and desktop early this year and am mostly very happy with it. That doesn't cover sandboxing though. I would actually agree that sandboxing / restricting application…

I've examined this a number of times over the years for deploying a ROS (Robot Operating System) workspace to robots and laptops. Some of our competitors use snaps or various container technologies for this, but I've always felt that the isolation/sandboxing would be more of a barrier than a help— it's one more layer of udev rules and other indirection to have to punch through with another set of config files (and to no benefit as we're not trying to run multiple independent "apps" or anything).

So currently at my org we use basically the same scheme I advocated for at a developer conference in 2016 [1]: we just build it all into a gigantic bundled debian package, and deploy that to the host system with apt.

I keep revisiting these various technologies and all of them seem less mature than apt/dpkg, and mostly in service of features and capabilities which don't apply to my particular needs. Obviously I'm a bit of a niche case, and my needs aren't everyone's, but of all of them, nix is the one that seems to be doing the most that is truly interesting and different; being able to send a new nightly build out to users with requiring them to re-downloading an entirely new asset would be a major win.

[1]: https://vimeo.com/187705228

Re: Run More Stuff in Docker

#92

Post by mikepurvis »

ris wrote: post #44
the_duke wrote: post #13

For end user devices, I much prefer Nix/NixOS [1] for this kind of thing. With Flakes [2] (experimental feature), you get full reproducibility. The documentation is spotty and there is a considerable learning curve, but I've switched to NixOS on my laptop and desktop early this year and am mostly very happy with it. That doesn't cover sandboxing though. I would actually agree that sandboxing / restricting application…

Absolutely. Most Dockerfiles I come across are very much not written in a robustly reproducible way. The stacking filesystems model is really not very flexible (if you want to compose two docker images with dissimilar bases to be used together you have to resort to manually specifying which files to copy across from each base). Use of OS features to achieve its ends means the docker daemon itself requires far more pr…

Yeah, any Docker file that starts with `apt update; apt dist-upgrade` is an instant fail.

You might be interested in this fascinating exploration of attempting to bend Docker into better caching and composition by injecting blocks of Nix packages as individual layers:

https://grahamc.com/blog/nix-and-layered-docker-images

Re: Run More Stuff in Docker

#93

Post by bob1029 »

hendry wrote: post #30

Just some counter arguments to @jbergknoff's well put together page! Docker is the best medium for distributing - A static file is far easier to share / distribute. Cross-platform - You need an arguably complex and unstable Linux interface to run Docker images, cgroups et al Sandboxed - security claims about Docker have always been controversial. Simple Unix/BSD constructs like chroot/jails are far simpler and they a…

This is what we do. One binary output that has all native dependencies built-in. We also use SQLite so we don't have to waste time with administering hosted SQL instances.

Ramping new developers and environments is incredibly trivial with our stack, and we do not rely on any containerization tech. Just .NET Core, visual studio, Git[Hub] and SQLite.

Re: Run More Stuff in Docker

#94

Post by josephg »

peteretep wrote: post #88
josephg wrote: post #87

Earlier quoted context omitted.

Sharing dynamically linked 3rd party frameworks on macos is relatively rare. But all the system built-in frameworks are shared via dynamic linking in userspace. (Eg Cocoa, UIKit, Foundation, etc). Native macos apps feel native because they dynamically link to the system's standard set of UI libraries. (And more recently font sets like SF Symbols.) For many reasons, none of that is available via docker. The GP is also…

> none of that is available via docker I'd expect someone building many tools like the author of the original piece is using the same shared image as the base for most of them?

The base shared image can't embed macos's system & UI libraries because:

- They're proprietary. Copying them from macos onto docker hub violates the macos software license.

- They change with each version of MacOS. You can't mix & match them.

I guess you could mount them into docker's filesystem, but then whats the point of using docker? And even if you did that:

- They're macos mach executable files. Linux (and therefore docker) doesn't know how to run mach executable files.

- Even if you could somehow embed them and get them to run, the libraries wouldn't work because they expect to be making syscalls to Darwin. They can't do that from inside a linux virtual machine.

You could probably make a weird RPC proxy involving a native macos process receiving network commands. But it should take a herculean effort to make it work at all, and even if you got it working it would probably be buggy (since everything would suddenly become async) and slow.

Re: Run More Stuff in Docker

#95

Post by systemvoltage »

josephg wrote: post #90
systemvoltage wrote: post #49

Earlier quoted context omitted.

Jumping from 73 MB -----> 500 MB or whatever. Have you been running Docker on your system? Have you tried running: `docker system prune -a`? It's gonna print something like Total reclaimed space: 31.2GB .

Its worse than just the size jump. Every application would also need to run all its code inside a linux VM. So that means: - Dedicated RAM for all your docker apps (which you have to partition manually) - Slow startup time for the first docker app you run each time you reboot, as it boots the linux VM. - All syscalls run through the VM's emulation layer, which is way slower than native - No access to the system's nat…

That's absolutely terrifying. Thanks for the insight.

Re: Run More Stuff in Docker

#96

Post by ed25519FUUU »

ridiculous_fish wrote: post #85

Docker is intimately tied to Linux. It it only "cross platform" in that it can use a VM (Mac, WSL2) or flaky compat layers (FreeBSD). If software embraces Docker, it effectively excludes other OSes, like Windows, BSDs, Haiku, Fuschia, etc.

Even though it doesn’t run cross platform natively, it does run cross platform acceptably. I have no issue developing, building, and shipping images on my Mac that are deployed to production.

Re: Run More Stuff in Docker

#98

Post by chii »

ed25519FUUU wrote: post #96
ridiculous_fish wrote: post #85

Docker is intimately tied to Linux. It it only "cross platform" in that it can use a VM (Mac, WSL2) or flaky compat layers (FreeBSD). If software embraces Docker, it effectively excludes other OSes, like Windows, BSDs, Haiku, Fuschia, etc.

Even though it doesn’t run cross platform natively , it does run cross platform acceptably. I have no issue developing, building, and shipping images on my Mac that are deployed to production.

in that case, why is it that docker is considered superior when you could virtualize the windows api and run native windows apps in linux instead?

Re: Run More Stuff in Docker

#99

Post by mongol »

I am surprised that systemd portable services is so little known. It solves many of the same problems as Docker does but is comparatively simpler. It also requires more plumbing on top but I prefer it.

Re: Run More Stuff in Docker

#100

Post by keyle »

josephg wrote: post #90
systemvoltage wrote: post #49

Earlier quoted context omitted.

Jumping from 73 MB -----> 500 MB or whatever. Have you been running Docker on your system? Have you tried running: `docker system prune -a`? It's gonna print something like Total reclaimed space: 31.2GB .

Its worse than just the size jump. Every application would also need to run all its code inside a linux VM. So that means: - Dedicated RAM for all your docker apps (which you have to partition manually) - Slow startup time for the first docker app you run each time you reboot, as it boots the linux VM. - All syscalls run through the VM's emulation layer, which is way slower than native - No access to the system's nat…

I am so glad I can read something like this in public.

When I say stuff like this in job interviews, I get eye rolls and don't end up getting a job.

The industry is so far up its ass lately, no one even dare stating the facts in public. /rant

Post reply on HN