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

141–150 of 293 posts

Re: Run More Stuff in Docker

#141

Post by remexre »

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…

> A static file is far easier to share / distribute.

Does glibc work with static linking these days? My understanding was that even with statically linked glibc, things tend to break when the host system has a different libc / a sufficiently newer glibc.

Also, how do you do OpenGL/Vulkan/etc statically? x11docker handles them more-or-less fine, but I'm fairly certain the GPU gods send you to Tartarus if you start trying to statically link in various vendors' libGLs...

> Simple Unix/BSD constructs like chroot/jails are far simpler and they are reliable.

_Fully_ agree about jails, especially nice since they're persistent. Though, for an X11-using application, I think you're screwed any way it comes out, since afaik there's no permissions difference between being able to create a window, and being able to steal keystrokes + send keystrokes to a terminal. Maybe the Qubes people have something?

Re: Run More Stuff in Docker

#142

Post by rhn_mk1 »

FartyMcFarter wrote: post #67
foolmeonce wrote: post #63

Earlier quoted context omitted.

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 colle…

The distinction is meant to depend not on the way of linking, but how intimately the pieces are joined together:

https://softwareengineering.stackexchange.com/a/167781

> If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins.

To extend this to archives of independent programs, they would be loosely bound, and therefore not form a single program. A docker container that exists only to package up libraries some executable is using would be closer to a single program than a collection of independent components.

Re: Run More Stuff in Docker

#143

Post by remexre »

cpuguy83 wrote: post #112
zachrose wrote: post #107

Earlier quoted context omitted.

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

What? Why would it prompt this? Docker supports SELinux.

I don't know the specific issue, but RH's been trying to push Podman fairly hard...

Re: Run More Stuff in Docker

#144

Post by akhilcacharya »

I think the reasoning is perfectly sound for doing this but the performance penalty is too much to bear for most use cases - what's preventing nixpkg/guix from being used fully for this use case? Lack of available packages?

Re: Run More Stuff in Docker

#145

Post by remexre »

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…

> Its called a statically linked executable. They work great.

Doesn't this make OpenGL, Vulkan, and parts of glibc break?

Re: Run More Stuff in Docker

#146

Post by lloeki »

TimTheTinker wrote: post #115

> 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. In my opinion, this is a big enough issue as to throw the whole idea of “Docker as cross-platform platform/target” into major question. When running more than a few containers on macOS, the performance is so bad it be…

Volumes to macOS host performance has nothing to do with bind mounts. It’s the VM folder sharing that’s crap, doubled with the attempt at Docker for Mac to translate filesystem events from fseventsd to inotify and back.

Changing solutions (e.g Docker for Mac -> VirtualBox or Fusion via e.g docker-machine) makes a world of difference.

Re: Run More Stuff in Docker

#147

Post by knowhy »

systemvoltage wrote: post #42

Let's not. I don't want to install Chrome which is already 73 MB, now bloated up with a whole lotta bullshit that's 500 MB+ image. Imagine downloading every application as a docker container. WTF. Docker is for distribution of applications when deploying them to servers. As a developer, it's amazing at that and have brought peace and joy in devops. Let's leave it there, shall we?

Docker has a layer file system. Meaning if you do it right, that Chrome container will share the same 500 MB base image layer with the Gimp container, or whatever, making it less bloated than it appears when looking only at the footprint of the first image.

I'm not stating that I believe it is a good idea to run desktop apps in Docker containers. It is not a good idea. But it is also not true that if someone would do it, it would necessary lead to a bloated filesystem.

Docker will use a lot of disk space when using multiple base images.

Re: Run More Stuff in Docker

#148

Post by mulmen »

jcelerier wrote: post #140
sjy wrote: post #133

Earlier quoted context omitted.

> You can't really reproduce that with any popular desktop operating system. If you’re running Docker, you’re running Linux, and you can use the same kernel features as Docker to sandbox applications yourself. This way, you only incur the overhead of a separate network namespace and filesystem if you actually need it. Services can be sandboxed with a few lines of configuration in a drop-in unit, and applications can…

> If you’re running Docker, you’re running Linux As slow as it is some people apparently enjoy running docker from win / mac

Docker needs Linux to work. On Mac/Windows containers run in a Linux virtual machine.

Re: Run More Stuff in Docker

#149

Post by cratermoon »

edbob wrote: post #124
cratermoon wrote: post #121

Earlier quoted context omitted.

For all the other reasons the author notes: the main one being that the application running in the docker image has no access to the host system other than what the user explicitly gives it. It's a very minimal sandbox and often all the application needs. You can't really reproduce that with any popular desktop operating system. Even if you could the interesting thing about docker is that starts with a default deny e…

I'm not an expert in this area, but I've seen plenty of accounts of how Docker can be very insecure. Perhaps it's possible to configure Docker so that it is very secure, but even Google has had people break out of their containers, so these claims about container security should probably come with a disclaimer: "Docker is very secure as long as you are one of the top 0.1% in the field and never mess up". VMs seem to…

I think the experts in docker would note that sandboxing and privilege isolation are technical features which have many uses, but that is not at all the same as making broad-based claims about the security of docker or the virtual machine and host operating system technology upon which it runs.

Re: Run More Stuff in Docker

#150

Post by indemnity »

klodolph wrote: post #134
pram wrote: post #110

Earlier quoted context omitted.

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

I had a conversation a couple months ago where some guy was telling me that I should run my personal website using Kubernetes. It’s a static website served with Nginx! I just about lost my mind trying to talk to this guy, and he kept trying to convince me to try Kubernetes for my personal website.

Why even run nginx? My personal website is served out of a private S3 bucket, with CloudFront sitting in front of it.

As a former sysadmin, the less actual admin I need to do the better.

Post reply on HN