Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly: Docker Without Containers

wasmlabs.dev

Post reply on HN
Print view View original

101–110 of 313 posts

Re: WebAssembly: Docker Without Containers

#101

Post by cmeacham98 »

Thaxll wrote: post #93
cmeacham98 wrote: post #87

Earlier quoted context omitted.

There are serious attempts at secure container runtimes (see gVisor) and runtimes that run container images in a real VM (see Firecracker). This meme that containers are inherently insecure just because Docker doesn't attempt to be a security product needs to die. Docker hasn't been the only player in the container runtime space for a long time.

Insecure is a very strong word, world has been running on Docker for sometime and it works fine and is not as insecure has you seem to think.

I agree that Docker actually has a relatively good track record, but it is true that Docker will never be on the same level as a VM hypervisor that was designed from the ground up to be a security barrier.

Thus, when people bring up "Docker is insecure" I try not to get down in the weeds arguing about the specifics, and instead point out alternative projects that are designed with security in mind. I find it's a much stronger counterargument.

Re: WebAssembly: Docker Without Containers

#102

Post by nine_k »

ClumsyPilot wrote: post #77
nine_k wrote: post #65

Earlier quoted context omitted.

This sounds incredible, as if the co-founder of Docker fails to understand the crucial value proposition of Docker (hence Docker's financial troubles, maybe). The point of Docker is the ability to take the existing Rube-Goldberg-machine configurations of software, in any and many languages (including the gluing bash scripts), and put it basically unchanged into a controlled, isolated, replicated, shippable environmen…

Except there is no secure docker runtime, and there never will be. If you want secure, you have tp put it in a VM , which gives you a performance penalty again. Secure means you can run arbitrary untrusted code, and webassembly cam do that, and docker can't.

Oh shucks. Docker's value proposition is emphatically not security. If you want really good insulation, run a proper VM.

Docker's value proposition is convenient. reproducible, self-contained packaging of software. It's the ability to deploy pieces of existing, battle-tested, gnarly and imperfect software next to each other, and care not about their conflicting or missing dependencies. It's more like Flatpak or AppImage, only more popular and easy.

This packaging also includes a kind of network insulation, exposing only the desired ports, making it easy to have VLANs between containers that do not interfere, etc. This is, again, not a serious security mechanism, but more of a convenience, but a very valuable convenience.

Re: WebAssembly: Docker Without Containers

#103

Post by orf »

pjmlp wrote: post #75
bzzzt wrote: post #74

Earlier quoted context omitted.

Dealing with the XML spaghetti from most Java EE containers isn't much better though.

- Schema validation - IDE code completion - Can be machine generated/updated via the GUI management administration and graphical tooling on IDEs Good luck doing that with YAML.

Literally every single one of those are well supported by Kubernetes and YAML.

1 and 3 are actually foundational to how k8s works.

Forgive me for saying this, but I’m getting a “i don’t want to invest any effort understanding anything and so Kubernetes is bad” vibes from these comments.

Re: WebAssembly: Docker Without Containers

#104

Post by _boffin_ »

pjmlp wrote: post #75
bzzzt wrote: post #74

Earlier quoted context omitted.

Dealing with the XML spaghetti from most Java EE containers isn't much better though.

- Schema validation - IDE code completion - Can be machine generated/updated via the GUI management administration and graphical tooling on IDEs Good luck doing that with YAML.

I’m failing to see why you can’t do that with yaml. Please enlighten me.

Re: WebAssembly: Docker Without Containers

#105

Post by mike_hearn »

orf wrote: post #95
mike_hearn wrote: post #88

Earlier quoted context omitted.

Can you actually compile an arbitrary program to WASM? I thought they had to be ported to WASI first and can't use any operating system APIs. Otherwise, how can it be sandboxed? Arbitrary programs can call into arbitrary OS-native APIs and execute arbitrary native code outside the bounds of the WASM VM, including things like JITing native code.

It depends on the program being compiled, but yes you can. You can run Postgres using WASM in two different ways[1][2]. That’s a non-trivial codebase. 1. https://www.crunchydata.com/blog/learn-postgres-at-the-playg... 2. https://supabase.com/blog/postgres-wasm

That works by compiling some sort of Linux VM into WASM as well, which isn't arbitrary programs (that would have to include Windows and macOS programs too).

Re: WebAssembly: Docker Without Containers

#106

Post by treis »

orf wrote: post #96
treis wrote: post #84

Earlier quoted context omitted.

>single VM type (WASM), that’s very different from being locked into the JVM. Why is that different?

You can’t run Postgres on the JVM. WASM is pretty different to the JVM. The JVM deals with a lot of higher level constructs like objects, constructors, virtual methods, the GC etc. Which is fine if the language you’re hosting works in that way. WASM is more like assembly - the raw intrinsics used by a hypothetical WASM CPU. So you can compile a lot more stuff to it, because it’s a more natural target than a much, muc…

But there's not much point to running Postgres in WASM. It's written in C to avoid the performance overhead of a VM in the first place.

Re: WebAssembly: Docker Without Containers

#107

Post by paulgb »

OJFord wrote: post #94

> [...] take a look at WebAssembly as the 'successor' to containers and the next logical step in infrastructure deployment [and so on about containers] Surely it replaces/is an alternative to images , not containers? If I have a wasm binary, there's still value in specifying the environment in which it runs, volumes it has access to, networking, etc.?

It seems this is replacing both, in that the wasm module is not run inside of a traditional linux container (at least as far as cgroups go).

> Each traditional container gets its own control group as in docker/ee44.... On the other hand, Wasm containers are included as part of the podruntime/docker control group and one can indirectly observe their CPU or Memory consumption.

Re: WebAssembly: Docker Without Containers

#108

Post by mike_hearn »

orf wrote: post #96
treis wrote: post #84

Earlier quoted context omitted.

>single VM type (WASM), that’s very different from being locked into the JVM. Why is that different?

You can’t run Postgres on the JVM. WASM is pretty different to the JVM. The JVM deals with a lot of higher level constructs like objects, constructors, virtual methods, the GC etc. Which is fine if the language you’re hosting works in that way. WASM is more like assembly - the raw intrinsics used by a hypothetical WASM CPU. So you can compile a lot more stuff to it, because it’s a more natural target than a much, muc…

Although that's true (ish... you can run WASM on the JVM now, and also LLVM bitcode), that takes you into the realm of why you'd want to.

On the browser side, you could maybe make a ChromeOS style argument of just wanting to run everything in a browser no matter what, it's nice for it to be sandboxed etc. But if you look at what your Postgres is doing it's sort of a Linux VM, and you can run those already at full speed: that's WSL and there are various solutions on macOS like Docker Desktop.

On the server side, the reason nobody bothered trying to run Postgres on the JVM before Graal is that it's unclear what the benefit is. Security? Processes and kernel isolation seems to work well enough on the server, and anyway Postgres is a highly trusted component anyway. CPU independence? That hasn't been useful since stuff like SPARC died, we are now just starting to see ARM chips appear on the server, but compiling native code for both intel and arm isn't hard and Linux distros have the infrastructure to do it for a long time already. For custom servers, well, not many are writing them in C/C++/Rust anyway these days. RISC-V remains mostly theoretical.

To what extent is this doing it because it can be done, vs delivering real benefits? My mind is open but the low level nature of the WASM instruction set also means the VM can't offer many benefits to the programs inside it, nor the users outside it.

Re: WebAssembly: Docker Without Containers

#109

Post by goodpoint »

_0w8t wrote: post #52

Despite the sandboxing one still cannot run untrsuted WASM code in the same process as trusted code due to hardware bugs. CPU vendors are not going to fix those anytime soon. Their message is to always use separated address space for security isolation. And since one need an external process in any case, native containers wins as they are faster by factor of two over WASM. EDIT: It does not even make sense to use WAS…

No post body was provided.

Re: WebAssembly: Docker Without Containers

#110

Post by cube2222 »

ClumsyPilot wrote: post #77
nine_k wrote: post #65

Earlier quoted context omitted.

This sounds incredible, as if the co-founder of Docker fails to understand the crucial value proposition of Docker (hence Docker's financial troubles, maybe). The point of Docker is the ability to take the existing Rube-Goldberg-machine configurations of software, in any and many languages (including the gluing bash scripts), and put it basically unchanged into a controlled, isolated, replicated, shippable environmen…

Except there is no secure docker runtime, and there never will be. If you want secure, you have tp put it in a VM , which gives you a performance penalty again. Secure means you can run arbitrary untrusted code, and webassembly cam do that, and docker can't.

Isn't gVisor a secure docker runtime?

Sure, it doesn't reuse the kernel, but it's not a VM either.

Post reply on HN