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

61–70 of 293 posts

Re: Run More Stuff in Docker

#61

Post by peteretep »

cowsandmilk wrote: post #55
peteretep wrote: post #46

Earlier quoted context omitted.

> Imagine downloading every application as a docker container. WTF. Help me understand the WTF here, and also how that’s meaningfully different from an OS X app?

OS X apps share frameworks in the user space, while docker images don’t...and docker images have all the constraints everyone hates about sandbox, but only make it worse. E.g. the file open dialog in macOS will grant apps access to the file when the user chooses the file. In docker, I have to manually add a path whenever I want tools to have access.

That doesn’t match my mental model of how that works. Can you give me an example of a shared 3rd party framework that a Mac app bundle will find on the file system rather than just include in the bundle?

Re: Run More Stuff in Docker

#62

Post by GrantZvolsky »

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 also phased out Docker for local, non-isolated workloads in favour of nix. It's saved me many hours of figuring out how to install software whose official packages don't work out of the box / aren't compatible with my distribution.

Re: Run More Stuff in Docker

#63

Post by foolmeonce »

FartyMcFarter wrote: post #34
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…

Static linking is nice, but there are some licenses (notably the GPL and LGPL, which glibc uses) which don't easily allow that for closed-source software. On the technical side, as soon as some code needs to 'dlopen' something (e.g. a plugin or a system driver), you can run into trouble due to multiple instances of glibc or other dependencies running together. But if none of those are a requirement for your use case…

You can statically link whatever you like, you just can't distribute it as one work. One of the crazy one executable docker containers strikes me as one work to whatever extent a static linked binary is.

Re: Run More Stuff in Docker

#64

Post by tracker1 »

I'm not sure I'd reach for this in some of the use cases over snap/flatpak/appimage for GUI applications. For some terminal apps, maybe, but even then I usually just user my dockerfile or docker-compose file to manage these needs.

What's really needed are better/more articles about how to clean off the cruft left by docker after running your builds locally. Especially when you do things like update your base image versions from node:12 to node:14 etc.

Re: Run More Stuff in Docker

#65

Post by fantod »

peteretep wrote: post #50
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 .

wtf are you doing to create such large Docker containers? Are you installing each app on top of a fully-fledged Ubuntu? Are you leaving the build tools in the final container?

I mean it could just be very many containers that add up. And in many cases you'll have loads of images close to 1GB unless you go to great lengths to try and shrink them (e.g. anything that uses Python).

Re: Run More Stuff in Docker

#66

Post by fantod »

peteretep wrote: post #60
cowsandmilk wrote: post #57

Earlier quoted context omitted.

We expect every app developer to suddenly become an expert in efficiently producing docker layers and not just lazily use an Ubuntu desktop image?

I expect anyone distributing their app via Docker to learn how to use their tooling properly, yes?

Agreed, there are many things to get right about using Docker. But if you're just deploying an app to a somewhere, does it really matter if the image is a bit bloated (within reason)?

Re: Run More Stuff in Docker

#67

Post by FartyMcFarter »

foolmeonce wrote: post #63
FartyMcFarter wrote: post #34

Earlier quoted context omitted.

Static linking is nice, but there are some licenses (notably the GPL and LGPL, which glibc uses) which don't easily allow that for closed-source software. On the technical side, as soon as some code needs to 'dlopen' something (e.g. a plugin or a system driver), you can run into trouble due to multiple instances of glibc or other dependencies running together. But if none of those are a requirement for your use case…

You can statically link whatever you like, you just can't distribute it as one work. One of the crazy one executable docker containers strikes me as one work to whatever extent a static linked binary is.

> You can statically link whatever you like, you just can't distribute it as one work.

How do you distribute it then? Let's assume your statically linked binary contains both closed-source code and GPL/LGPL code.

> One of the crazy one executable docker containers strikes me as one work to whatever extent a static linked binary is.

I'm not a lawyer, but that's not my understanding.

A docker image is a glorified collection of files with some metadata, just as a tar file is. I think it's broadly agreed that you're allowed to distribute a tar file with unmodified LGPL dynamic libraries in it without having to open-source all of your code, and I think docker images are treated the same way?

Re: Run More Stuff in Docker

#68

Post by hendry »

FartyMcFarter wrote: post #34
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…

Static linking is nice, but there are some licenses (notably the GPL and LGPL, which glibc uses) which don't easily allow that for closed-source software. On the technical side, as soon as some code needs to 'dlopen' something (e.g. a plugin or a system driver), you can run into trouble due to multiple instances of glibc or other dependencies running together. But if none of those are a requirement for your use case…

Golang makes it pretty painless to build static binaries. go:embed expected in 1.16 even more so.

Re: Run More Stuff in Docker

#69

Post by peteretep »

fantod wrote: post #65
peteretep wrote: post #50

Earlier quoted context omitted.

wtf are you doing to create such large Docker containers? Are you installing each app on top of a fully-fledged Ubuntu? Are you leaving the build tools in the final container?

I mean it could just be very many containers that add up. And in many cases you'll have loads of images close to 1GB unless you go to great lengths to try and shrink them (e.g. anything that uses Python).

I can get an Alpine Linux container running Perl with a chunk of CPAN on it to 60MB by just stripping the build tools once I've installed everything I want. Is Python really a GB bigger, or are people not taking the most basic of steps?

Re: Run More Stuff in Docker

#70

Post by wa1987 »

oauea wrote: post #47
wa1987 wrote: post #11

> On a Mac, there is a major performance hit whenever you do disk IO in a bind mount (i.e. voluming a directory of the host system into the container). Working without bind mounts is extremely limiting. [..] If you’re using Docker on a Mac and you’ve never tried it on Linux, you owe it to yourself to try it on Linux. Or use named volumes. I'm running a dockerized WordPress dev environment on my MacBook with average T…

> Or use named volumes And how do you access these from your host with high performant IO?

There’s no need to in my situation. 99% of the files are dependencies installed through Composer (PHP) while building the Dockerfile. The few directories I need to work on directly are bind mounts and don’t have much impact on overall runtime performance.
Post reply on HN