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

The Docker+WASM Technical Preview

docker.com

Post reply on HN
Print view View original

101–110 of 178 posts

Re: The Docker+WASM Technical Preview

#101

Post by westurner »

westurner wrote: post #26
mikesir87 wrote: post #18

Earlier quoted context omitted.

Great question! There isn't a way to run Docker directly in the browser. But, there are tools (like Play with Docker at play-with-docker.com) that lets you interact with a CLI in the browser to run commands against a remote cloud instance. I personally use this a lot for demos and workshops! But... certainly a neat idea to think about what Wasm-based applications could possibly look like/run in the browser!

Is it possible to sandbox the host system from the guests in WASM? Are there namespaces and cgroups and SECCOMP and blocking for concurrent hardware access in WASM, or would those kernel protections be effective within a WASM runtime? Do WASM runtimes have subprocess isolation?

/? subprocess isolation https://www.google.com/search?q=subprocess+isolation on a PC:

- TIL about teh Endokernel: "The Endokernel: Fast, Secure, and Programmable Subprocess Virtualization" (2021) https://arxiv.org/abs/2108.03705#

> The Endokernel introduces a new virtual machine abstraction for representing subprocess authority, which is enforced by an efficient self-isolating monitor that maps the abstraction to system level objects (processes, threads, files, and signals). We show how the Endokernel can be used to develop specialized separation abstractions using an exokernel-like organization to provide virtual privilege rings, which we use to reorganize and secure NGINX. Our prototype, includes a new syscall monitor, the nexpoline, and explores the tradeoffs of implementing it with diverse mechanisms, including Intel Control Enhancement Technology. Overall, we believe sub-process isolation is a must and that the Endokernel exposes an essential set of abstractions for realizing this in a simple and feasible way.

Re: The Docker+WASM Technical Preview

#102

Post by westurner »

westurner wrote: post #26
mikesir87 wrote: post #18

Earlier quoted context omitted.

Great question! There isn't a way to run Docker directly in the browser. But, there are tools (like Play with Docker at play-with-docker.com) that lets you interact with a CLI in the browser to run commands against a remote cloud instance. I personally use this a lot for demos and workshops! But... certainly a neat idea to think about what Wasm-based applications could possibly look like/run in the browser!

Is it possible to sandbox the host system from the guests in WASM? Are there namespaces and cgroups and SECCOMP and blocking for concurrent hardware access in WASM, or would those kernel protections be effective within a WASM runtime? Do WASM runtimes have subprocess isolation?

Sandbox (computer security) > Implementations https://en.wikipedia.org/wiki/Sandbox_(computer_security)

- [x] Linux containers

- [ ] WASM with or without WASI

eWASM has costed opcodes; basically like dynamic tracing in CPython.

Are there side channels for many or most of these sandboxing methods; even at the CPU level?

Re: The Docker+WASM Technical Preview

#103

Post by Matthias247 »

lolinder wrote: post #52

Does anyone have a good explanation for what Docker+WASM actually is? This announcement explains what WASM is and what Docker is, but I already knew both of those and am still confused about what Docker+WASM is. Is it just wrapping a WASM binary in a Docker container?

I don't really get it either. It's kind of missing which interfaces are actually provided to the WASM script, and how the magic webserver that is described in the docs is working.

Most WASI implementation so far seem to just make a stdin and stdout available for a WASM program - which wouldn't really be enough to run a webserver in it.

Is this example running a non-wasm webserver that then proxies to WASM modules? Is that wasmedge? Or does wasmedge really make syscalls like accept() available to the module?

If it's the latter, how could it actually do something meaningful without threading - given any accept() would block the whole module? Run in non-blocking mode and expect the whole WASM module to be written in async style?

I know these are lots of questions - but they seem rather fundamental to what you could actually use the system for.

Re: The Docker+WASM Technical Preview

#104

Post by corysama »

timanglade wrote: post #92
lolinder wrote: post #89

Earlier quoted context omitted.

I'm still confused. This is the big thing I'm not really getting: > which allows you to build both traditional container apps, as well as Wasm apps I can already do that. Using Rust for the sake of example: `cargo build` can give me a WASM binary, and `docker build` can give me a container. Is Docker+WASM going to replace `cargo build`? Or is it going to wrap the WASM binary produced by cargo in another layer of abst…

> I'm just sincerely confused at what problem this technical preview is intended to solve. This is all good feedback, and we’ll definitely try to explain the added value better in the future. The main advantages we see in this technical preview are: 1. Easy, reproducible dev environment to quickly & reliably develop cloud/edge apps that target Wasm, or code frontend apps that target a Wasm backend (for example, as pa…

I think you are falling into a “deeply-technical explainer” trap. You’ve been so deeply engrossed in the use-cases of this novel technical combo that they are all assumed understood from your POV.

And, this tech is so general that there’s a second trap of “What can it do? It can do anything! Sure, but what can it do??” Again, because I’m your head “anything” is pre-supposed to a narrow set of goals that this tech fulfills very nicely. It cannot, for example, take my dog for a walk. So, it can’t do “anything” ;p It’s hard to get out of that head-space because you’ve been so deep in it for so so long.

But, I and 85% of people here have no idea what narrow set of goals Docker+Wasm fulfills. Something about apps and security something something. Mostly for servers probably.

Some awesome-fit exemplar use cases would help a lot.

Re: The Docker+WASM Technical Preview

#105

Post by corysama »

heavyset_go wrote: post #99
jiggawatts wrote: post #93

This prescient talk "The Birth & Death of JavaScript" by Gary Bernhardt in 2014 is slowly but surely coming true: https://www.destroyallsoftware.com/talks/the-birth-and-death...

I'd love to see this future, but I wonder if a WASM VM can match the performance of something like V8 that is fine-tuned to run a single language well.

That’s pretty much the point of WASM, isn’t it? V8 is a billion dollar investment in running as best as possible a language that is very, very difficult to run performantly. WASM instead opens up options to run well languages that are much easier to run performantly.

Re: The Docker+WASM Technical Preview

#106

Post by westurner »

westurner wrote: post #26
mikesir87 wrote: post #18

Earlier quoted context omitted.

Great question! There isn't a way to run Docker directly in the browser. But, there are tools (like Play with Docker at play-with-docker.com) that lets you interact with a CLI in the browser to run commands against a remote cloud instance. I personally use this a lot for demos and workshops! But... certainly a neat idea to think about what Wasm-based applications could possibly look like/run in the browser!

Is it possible to sandbox the host system from the guests in WASM? Are there namespaces and cgroups and SECCOMP and blocking for concurrent hardware access in WASM, or would those kernel protections be effective within a WASM runtime? Do WASM runtimes have subprocess isolation?

google/gvisor could be useful for this? https://github.com/google/gvisor :

> gVisor is an application kernel, written in Go, that implements a substantial portion of the Linux system surface. It includes an Open Container Initiative (OCI) runtime called runsc that provides an isolation boundary between the application and the host kernel.

Re: The Docker+WASM Technical Preview

#107

Post by timanglade »

heavyset_go wrote: post #97
timanglade wrote: post #83

Earlier quoted context omitted.

> I don't know any dev looking for this or having a problem solved by it. Judging by the reception at KubeCon & elsewhere today, we think at least some folks are excited by it. But it’s still early, and who knows, you may be right in the end. We launched this as a technical preview to test a hypothesis and learn from it, and so far the interactions from this HN thread alone have been greatly helpful.

Why were they excited? What use cases does this address? Is the intention to containerize WASM binaries and manage them with Docker like you would any other container? Genuine questions, I'm just trying to understand what this feature is and why someone would want to use it.

I tried to answer this above[0]. Instead of trying to explain it again, I’d encourage you to give it a try[1], and if after going through the 5-minute tutorial you still don’t get the point then a) maybe we messed up (and I’ll be sorry for having wasted your time!) or b) maybe it’s not for you (and I’ll also be sorry I wasted your time). It took me a while to wrap my head around this Docker+Wasm thing too when I first heard about it internally — then again it took me months to wrap my head around my first demo of Docker, so maybe I’m just dense!

[0]: https://news.ycombinator.com/item?id=33324093

[1]: https://docs.docker.com/desktop/wasm/

Re: The Docker+WASM Technical Preview

#108

Post by dleslie »

timanglade wrote: post #92
lolinder wrote: post #89

Earlier quoted context omitted.

I'm still confused. This is the big thing I'm not really getting: > which allows you to build both traditional container apps, as well as Wasm apps I can already do that. Using Rust for the sake of example: `cargo build` can give me a WASM binary, and `docker build` can give me a container. Is Docker+WASM going to replace `cargo build`? Or is it going to wrap the WASM binary produced by cargo in another layer of abst…

> I'm just sincerely confused at what problem this technical preview is intended to solve. This is all good feedback, and we’ll definitely try to explain the added value better in the future. The main advantages we see in this technical preview are: 1. Easy, reproducible dev environment to quickly & reliably develop cloud/edge apps that target Wasm, or code frontend apps that target a Wasm backend (for example, as pa…

So if I understand you correctly, you want Docker to be a trusted host for wasm binaries as well as container images? Where the tooling you've made is intended to aid users along this path.

It sounds like you're anticipating a new market segment for artifact deployment and want to be its primary service provider.

Re: The Docker+WASM Technical Preview

#109

Post by kodah »

timanglade wrote: post #61
lolinder wrote: post #52

Does anyone have a good explanation for what Docker+WASM actually is? This announcement explains what WASM is and what Docker is, but I already knew both of those and am still confused about what Docker+WASM is. Is it just wrapping a WASM binary in a Docker container?

"Docker+Wasm" is just a shorthand for the Technical Preview build, which allows you to build both traditional container apps, as well as Wasm apps. Behind the scenes, we try to let Wasm apps be developed largely without interference from any container technology — just giving you a good local environment you can use to code against. That said, if you want, we do offer the ability to run Wasm apps within a Docker Comp…

It might be easier if you simplify it to, "We're trying not to be just the app you choose to run containers with. You can now use non-container runtimes like WASM."

Re: The Docker+WASM Technical Preview

#110

Post by [deleted] »

dleslie wrote: post #108
timanglade wrote: post #92

Earlier quoted context omitted.

> I'm just sincerely confused at what problem this technical preview is intended to solve. This is all good feedback, and we’ll definitely try to explain the added value better in the future. The main advantages we see in this technical preview are: 1. Easy, reproducible dev environment to quickly & reliably develop cloud/edge apps that target Wasm, or code frontend apps that target a Wasm backend (for example, as pa…

So if I understand you correctly, you want Docker to be a trusted host for wasm binaries as well as container images? Where the tooling you've made is intended to aid users along this path. It sounds like you're anticipating a new market segment for artifact deployment and want to be its primary service provider.

[deleted]
Post reply on HN