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

131–140 of 293 posts

Re: Run More Stuff in Docker

#131

Post by ogre_codes »

> Running a program in a container is a lot like running it normally, but the user doesn’t need to jump through hoops to configure the system, build and install.

Docker is itself a complex build tool which requires a bunch of install steps. If you are going to ship software to end users there is almost always a better way to bundle and ship than send someone a Docker container.

Docker is not a distribution tool, if you are expecting your end users to install Docker, you've already screwed up.

> Downloading a pre-compiled binary is almost like this, except with worse odds. Maybe there’s a build for your architecture. If it was statically linked, you’re golden. Otherwise, use ldd to reverse engineer the fact that you need to install libjpeg.

On Mac and Windows this is almost never an issue. Even on Linux, it's pretty straight forward to statically link your binary if you aren't sure about the environment it's going to be run on. Statically linked binaries are a bit bloated... but not as bloated as a damned Docker image which contains entire dependency trees.

In no case is "Making it into a Docker Image" a simpler/ better distribution mechanic.

Re: Run More Stuff in Docker

#132

Post by ogre_codes »

peteretep wrote: post #46
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?

> 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?

A MacOS App is just what you need to run the app on MacOS. A Docker Image is essentially a mini operating system in a can. Most Docker images contain shells, the entire Python install, an init sequence... piles and piles of redundant stuff.

If you are running a Docker image on MacOS or Windows, you first have to start docker which is itself a Linux Virtual machine.

Docker is a great dev tool, but if you don't need it, it's a ton of bloat.

Re: Run More Stuff in Docker

#133

Post by sjy »

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…

> 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 be run with a shell script that calls `systemd-run`, just like the `docker run` shell scripts suggested in the article.

Re: Run More Stuff in Docker

#134

Post by klodolph »

pram wrote: post #110
keyle wrote: post #100

Earlier quoted context omitted.

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.

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.

Re: Run More Stuff in Docker

#135

Post by saagarjha »

josephg wrote: post #87
peteretep wrote: post #61

Earlier quoted context omitted.

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?

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…

It’s rare, but if apps did want to do this the would typically place things at /Library/Frameworks for this purpose.

Re: Run More Stuff in Docker

#136

Post by saagarjha »

FartyMcFarter wrote: post #71
hendry wrote: post #68

Earlier quoted context omitted.

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

If you're building on Linux, does it usually embed glibc in them? If it does, you'll need to comply with the LGPL when you distribute your statically linked binary.

Doesn’t Go just make syscalls on Linux?

Re: Run More Stuff in Docker

#137

Post by ithkuil »

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?

In many cases you don't need 500mb of base image.

Minimal "distrofull" images are in the 50mb range. But often you don't really need a real distribution inside your docker image.

See https://github.com/GoogleContainerTools/distroless. But distroless is not about one specific tool or base image, it's a paradigm that addresses precisely what you say (without throwing away the whale with the bathwater)

Re: Run More Stuff in Docker

#138

Post by remexre »

sjy wrote: post #133
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…

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

Do you know of a tool that can do this for arbitrary programs? Maybe something like CARE [0] to find what the program should be accessing, then building the appropriate systemd configuration files?

[0]: https://proot-me.github.io/care/

Re: Run More Stuff in Docker

#139

Post by rhn_mk1 »

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…

> You need an arguably complex and unstable Linux interface to run Docker images, cgroups et al

What is unstable about it? As far as I can tell, only the Linux kernel interface is needed, and keeping that stable is an explicit goal of the kernel.

Re: Run More Stuff in Docker

#140

Post by jcelerier »

sjy wrote: post #133
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…

> 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

Post reply on HN