Live data from Hacker News

Run More Stuff in Docker

jonathan.bergknoff.com

101–110 of 293 posts

Re: Run More Stuff in Docker

#101
post #90

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…

> Slow startup time for the first docker app you run each time you reboot, as it boots the linux VM.

This, and the other VM-related criticism, is true, but only on Mac & Windows. Running a Docker container on a native Linux system carries very little overhead.

Re: Run More Stuff in Docker

#102
post #90

Earlier quoted context omitted.

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…

> Slow startup time for the first docker app you run each time you reboot, as it boots the linux VM. This, and the other VM-related criticism, is true, but only on Mac & Windows. Running a Docker container on a native Linux system carries very little overhead.

But the 73m -> 500m is still true, right?

Re: Run More Stuff in Docker

#103

I prefer to just make a big "devbox" docker with all the utilities I need installed, and the home directory as a docker volume. The advantage is i don't have to fiddle with containers for every little program, no startup delay for every program, and my base ubuntu install stays clean and stable (which runs a VM and other services so stability is important). It does have a few warts, the main one being you can't have…

Is it possible to run your IDE within these docker environments? I'd love to set up a do it all docker container for the front end devs at my work.

Re: Run More Stuff in Docker

#104
post #65

Earlier quoted context omitted.

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?

Basic steps. Welcome to the long September of Docker. Whereas most folks who use it regularly know basic maintenance patterns, new users (myself included) must wade through inscrutable documentation or (worse) poorly written blogfarm posts in order to bootstrap up to a level of proficiency that passes interview smell tests.

Re: Run More Stuff in Docker

#105

I prefer to just make a big "devbox" docker with all the utilities I need installed, and the home directory as a docker volume. The advantage is i don't have to fiddle with containers for every little program, no startup delay for every program, and my base ubuntu install stays clean and stable (which runs a VM and other services so stability is important). It does have a few warts, the main one being you can't have…

Is it possible to run your IDE within these docker environments? I'd love to set up a do it all docker container for the front end devs at my work.

I use the Remote Development extension for Visual Studio Code, which, among other things, allows you to attach an editor window to a running container.

https://code.visualstudio.com/docs/remote/containers

Re: Run More Stuff in Docker

#106

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?

If you're building docker images FROM SCRATCH then there's no improvement over a zip file or statically-linked single binary (which is what packages and installers already use).

Meanwhile Docker adds many more restrictions and limitations and is not a good fit for consumer-focused interactive GUI applications which are not the web and console apps that work best with Docker.

Re: Run More Stuff in Docker

#107

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.

And even then trying to run Docker on Fedora will prompt you to turn off Security-Enhanced Linux features or use Podman instead. So it’s really like, what, 1/2 or 2/3 or Linux support

Re: Run More Stuff in Docker

#108

Earlier quoted context omitted.

> Slow startup time for the first docker app you run each time you reboot, as it boots the linux VM. This, and the other VM-related criticism, is true, but only on Mac & Windows. Running a Docker container on a native Linux system carries very little overhead.

But the 73m -> 500m is still true, right?

Depends entirely on how the image is built. You can have a Docker image that contains nothing but the application binaries, but then the question is why use Docker at all.

Re: Run More Stuff in Docker

#109
post #90

Earlier quoted context omitted.

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…

> Slow startup time for the first docker app you run each time you reboot, as it boots the linux VM. This, and the other VM-related criticism, is true, but only on Mac & Windows. Running a Docker container on a native Linux system carries very little overhead.

Yep. My comment was mostly made in the context of running macos desktop apps in docker. Windows would be largely the same, though the existence of WSL might make some things easier.

Linux desktop apps running in docker would work better because there's no VM in between the native environment and the application. You'd still need to forward GUI calls across the LXD container boundary. That used to be easy with X11 forwarding, but AFAIK wayland removed that feature. I don't know enough to guess how difficult that would be to implement.

But, if you solved that it should be mostly smooth sailing. Linux desktop apps distributed via docker would just be the same apps, but unnecessarily bigger, with probably less access to the filesystem. They would be harder to patch for security errata. And they would leave extra junk in your docker images cache. Docker's sandboxing would be nice though.

Re: Run More Stuff in Docker

#110
post #100
post #90

Earlier quoted context omitted.

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

Now talk about deploying something NOT using Kubernetes. The double whammy. Now you're looking like an insane 100 year old graybeard fossil.
Post reply on HN