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

121–130 of 293 posts

Re: Run More Stuff in Docker

#121

Post by cratermoon »

manigandham wrote: post #108
andrewprock wrote: post #102

Earlier quoted context omitted.

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.

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 environment built on the principle of least privilege.

Re: Run More Stuff in Docker

#122

Post by Spivak »

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…

The only reason it works so well on Linux is because containers are bog standard Linux processes running with no real overhead sans the kernel structures needed to maintain the namespacing. Entries in the VFS are cheap.

Once you need a hypervisor most of the benefits are gone. But if you need the hypervisor anyway which might be the case for software that doesn’t have Mac builds then it starts to look attractive.

Re: Run More Stuff in Docker

#123

Post by Spivak »

infogulch wrote: post #117
manigandham wrote: post #108

Earlier quoted context omitted.

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.

Isolation and reproducibility

Not the most useful for software intended to be used on your local machine. You don’t get the isolation benefits because the whole point is to give the container broad privilege so you can use it as if it was a native utility. Docker also doesn’t make a non-reproducible build process reproducible.

At the end of the day if you have a precompiled self-contained artifact Docker is just a convoluted way of calling exec.

Re: Run More Stuff in Docker

#124

Post by edbob »

cratermoon wrote: post #121
manigandham wrote: post #108

Earlier quoted context omitted.

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.

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 still be the proper tool for securely isolating processes, and should perhaps be the recommendation for the other 99.9%.

A few comments on how insecure the typical Docker recommendations are:

> Sandboxed - security claims about Docker have always been controversial. Simple Unix/BSD constructs like chroot/jails are far simpler and they are reliable

https://news.ycombinator.com/item?id=25547629

> However, I don’t agree with using it for sandboxing for security. Especially if you are giving it access to the X11 socket, as the author does in the examples. It might not be obvious, but the app will have access to all your other open windows.

https://news.ycombinator.com/item?id=25547551

> Fun fact, most docker hosts will allow access to all your files anyway! (specially true on docker for mac, which all the cool kids(tm) here are using). Even if you restrict container host-FS access to a source repo dir, mind rogue code changing your .git hook scripts in there or you might run code outside of the container when committing ;) > Another slightly relevant fun fact, USB is a bus. That means that any device can listen in on any other device. And USB access is given by default to some X-enabled docker (--tty something), and to most virtualbox machines (including the hidden one running the fake docker linux host on docker-for-mac), and more recently Google-Chrome. ;)

https://news.ycombinator.com/item?id=25547833

Re: Run More Stuff in Docker

#125

Post by visarga »

antoinealb wrote: post #26
qmmmur wrote: post #23

Earlier quoted context omitted.

That just seems insane to be running black inside a container. Why dont you just configure your environment properly?

Serious question: Why do you believe that to be insane? The Dockerfile for a simple application such as black must be very short (probably 3-4 lines), the alias is probably quite short and the container overhead time is minimal for native docker (the story might be different for things like docker mac). On the other hand, you get some benefits from installing black through docker rather than through the system packag…

But can you still trigger the containerized Black from VS Code?

Re: Run More Stuff in Docker

#126

Post by gorgoiler »

If you are reading this with interest then I encourage you to give it a go.

However, Docker is like a kitchen machine: good for getting something done in a particular way (stand mixer for kneading dough) but less useful for understanding what’s actually happening (when is pizza dough ready?)

On Linux, picking apart LXC stuff at the command line is very much worth your time if you’re interested in how things work. (Not LXD though which is more useful as a tool than as a teaching aid.)

If you have some IPv6 allocation to play with you can make some interesting infrastructure and have it do something useful on the Internet without relying on the lxc-net crutches of an automatically built bridge with NAT. It all feels very well designed as a bag of tools to let one make things rather than a complete system that guides you in only one particular direction.

I use stand mixers and Docker all the time; sometimes it’s fun to get into the details too.

Re: Run More Stuff in Docker

#128

Post by thefunnyman »

alphachloride wrote: post #111

I find that the time taken to get everything working means I have less time to get work done. The busywork does give me a sense of achievement, but that is not the achievement that matters. It's premature optimization to sandbox an application by default unless there is a pressing reason to do so. For e.g. zoom and hugo don't really change the filesystem or OS settings beyond the folders they output to. I don't see a…

Isn’t that precisely a use case for sand boxing? If I know zoom doesn’t need file system, I can deny it access and guarantee it doesn’t use the file system without me knowing about it.

Re: Run More Stuff in Docker

#129

Post by strogonoff »

mikepurvis wrote: post #91
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…

I also suspect OS package managers are underused when it comes to deployments. I am guilty of that too, some irrational wariness of end-user tools being fit to deal with developer workflows.

That aside, there is one slight possible pitfall in discarding one tech because it is less mature than the other: if we assume maturity only increases with time, the oldest product (e.g. apt/dkpg) will always be “best”. Made a note for myself to prefer “not mature enough for my needs” over “less mature than X”.

Re: Run More Stuff in Docker

#130

Post by zapita »

gcb0 wrote: post #45
lrossi wrote: post #21

The advantage of running apps in docker is that you avoid the risk of breaking your system by adding 3rd party package repos or even worse, curl | sudo bash. Cleanup/uninstall is very simple as well. However, I don’t agree with using it for sandboxing for security. Especially if you are giving it access to the X11 socket, as the author does in the examples. It might not be obvious, but the app will have access to all…

> It might not be obvious, but the app will have access to all your other open windows. Fun fact, most docker hosts will allow access to all your files anyway! (specially true on docker for mac, which all the cool kids(tm) here are using). Even if you restrict container host-FS access to a source repo dir, mind rogue code changing your .git hook scripts in there or you might run code outside of the container when com…

> and to most virtualbox machines (including the hidden one running the fake docker linux host on docker-for-mac)

docker-for-mac does not use virtualbox.

Post reply on HN