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

191–200 of 313 posts

Re: WebAssembly: Docker Without Containers

#191

Post by pie_flavor »

nikeee wrote: post #190

One important thing about containers is that they isolate the process and it can not access files it is not explicitly allowed to. If I'm getting this right, WASI is basically just POSIX for WASM. This means that it does not provide some level of sandboxing that - for example - Deno has done. When running a Deno program, you have to actively allow network access or write access to the disk. It uses the built-in stuff…

No, you are not getting this right, and these permissions are built into the WASI standard.

Re: WebAssembly: Docker Without Containers

#192

Post by angelmm »

nikeee wrote: post #190

One important thing about containers is that they isolate the process and it can not access files it is not explicitly allowed to. If I'm getting this right, WASI is basically just POSIX for WASM. This means that it does not provide some level of sandboxing that - for example - Deno has done. When running a Deno program, you have to actively allow network access or write access to the disk. It uses the built-in stuff…

That's how WASI is designed. You need to specifically mount a specific folder so it can be accessed by the module. The sockets support is not ready yet, that's the reason there's no specific limitation around networking.

For me, the most interesting part is the component-model. It's still a proposal, but it will allow developers to specify the permissions for other modules (libraries) a main Wasm module may use. With this, you can give access to a folder to a module and that module may call another one without giving them those permissions. In other ecosystems, any library used by the "main" logic gets the same permissions.

Re: WebAssembly: Docker Without Containers

#193

Post by pbecotte »

ridruejo wrote: post #23
pjmlp wrote: post #5

Earlier quoted context omitted.

Well, those that act like WebAssembly is reinvinting the world kind of do. And applications get tied to the WebAssembly ecosystem, it is also a single one.

One way of looking at it that helped me wrap my head of why “this time is different”, is that Wasm is not so much as a language but a compilation target (as say x86) so it can really run anything

It can run "anything" ... so long as someone has set up that project to correctly compile to a wasm target. "docker build" lets you build a package out of any software, without having to know much about it. "setting up a compiler for a new project, given the source code and maybe a separate toolchain for some other target that works", is a much more involved task.

There is no world where people are just grabbing an existing app and saying "hey, I'm gonna drop this into my wasm runtime real quick"

Re: WebAssembly: Docker Without Containers

#194

Post by vidarh »

pjmlp wrote: post #56
threeseed wrote: post #7

Earlier quoted context omitted.

a) Kubernetes is far simpler and more consistent to me than WebSphere/EAR. b) Kubernetes is the platform as well as the application server.

The amount of YAML spaghetti I have to deal with says otherwise.

The yaml for my home test cluster takes up more lines than the full orchestrator and config I wrote at one of my past jobs to manage a 1000 VM cluster. Kubernetes might well make sense "at scale" but for anything of moderate size I can't help but feel it's massive overkill.

Re: WebAssembly: Docker Without Containers

#195

Post by forty »

kllrnohj wrote: post #134
jeroenhd wrote: post #117

What I'm missing in these articles is a performance comparison. All WASMed tools I've tried were really cool proofs of concept, but the performance was always lacking at the very least. I see several languages moving towards more and more WASM but on a technical level I don't see the benefit of WASM over something like Firecracker. Docker and other sandboxes have to deal with shared kernels and all the risks associat…

> Fast - it can offer native-like speed via the JIT/AOT capabilities of most runtimes. No cold starts, unlike booting a VM or starting a container. What do you mean? This bullet point had a rocket emoji! Surely you don't actually want evidence to support a rocket emoji?!?

Yeah, when I read this sentence, my thought was: how much slower does "fast" mean? :)

Re: WebAssembly: Docker Without Containers

#196

Post by yjftsjthsd-h »

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.

runq exists, and gvisor can be used as a docker runtime, so yes docker absolutely can.

Re: WebAssembly: Docker Without Containers

#197

Post by pbecotte »

lucideer wrote: post #18
pulse7 wrote: post #9

Earlier quoted context omitted.

If this statement is true, there is no need for Docker, because JVM+JAR existed in 2008! Docker can do more than WASM or JVM+JAR: it can run non-WASM and non-JVM apps like PostgreSQL, etc...

> JVM+JAR existed JVM can only run apps written for it: Docker & WASM don't have that limitation. > it can run non-WASM and non-JVM apps like PostgreSQL, etc... but WASM can run Postgres

JVM can run apps _compiled_ for it. WASM has the _exact same_ limitation.

Someone put in the effort to get Postgres to compile for WASM. That's great :) Maybe someday every application will compile to WASM as the preferred choice over the linux interface.

Compiling apps for different targets is VERY MUCH not a simple, low effort task though. Something like a database that must have an incredible number of optimizations in the way it makes syscalls, will have to a full stream of work to keep each target running well.

It can be done. But if "one of these thigns is not like the other" with your three things- Docker is the odd duck out.

Re: WebAssembly: Docker Without Containers

#198

Post by angelmm »

nashashmi wrote: post #188

I once imagined a time in a far, faraway land where the new OS secretly in development was nothing more than a thin interface between the hardware and the software. And the software was a VM. And this was codenamed Fuchsia. And was being worked on by Google. They took away the lessons learned from CHromeOS with its LXC containers and Android Container. And realized the new OSs of the future can be anything and everyt…

Actually, Wasm goes into the direction you are pointing. A Wasm runtime should add a little overhead to the requirements of the Wasm module.

However, it's true Wasm is not on that point yet. There are open threads about deallocate Wasm memory [1]. However, I expect these features, as well as Garbage Collection [2] will come to the stardard over time. This will allow modules and runtimes to properly manage memory usage.

[1] https://stackoverflow.com/a/51544868

[2] https://github.com/WebAssembly/gc

Re: WebAssembly: Docker Without Containers

#199

Post by drdaeman »

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.

How many folks out there need to run arbitrary untrusted code on their systems? I think most of the time, the code they run is either their own or from a trusted third party.

And for those use cases, where secure containment of running applications is not a goal at all (beyond maybe taking some basic precautions), I fail to see any value to recompile it to WASM, CLR, JVM, Z80 bytecode or whatever else.

Those who need isolation - yeah, WASM could be a very solid alternative to having a VM. But it's a pretty niche use case.

Re: WebAssembly: Docker Without Containers

#200

Post by ridruejo »

kllrnohj wrote: post #134
jeroenhd wrote: post #117

What I'm missing in these articles is a performance comparison. All WASMed tools I've tried were really cool proofs of concept, but the performance was always lacking at the very least. I see several languages moving towards more and more WASM but on a technical level I don't see the benefit of WASM over something like Firecracker. Docker and other sandboxes have to deal with shared kernels and all the risks associat…

> Fast - it can offer native-like speed via the JIT/AOT capabilities of most runtimes. No cold starts, unlike booting a VM or starting a container. What do you mean? This bullet point had a rocket emoji! Surely you don't actually want evidence to support a rocket emoji?!?

No cold-starts means no overhead of starting a process to answer a request like most container-based serverless environments (without having to keep pre-warmed instances which kind of defeats the purpose) A couple references regarding cold-starts and performance in serverless environments.

https://www.fastly.com/blog/lucet-performance-and-lifecycle https://arxiv.org/abs/2010.07115

Post reply on HN