6 ms·

"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 s

"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 Compose application. We do also offer the possibility to package Wasm apps within an OCI image, with an embedded Wasm runtime (WasmEdge) so you can a) easily share these via an image registry like Docker Hub, AWS ECR, etc. and b) easily run this anywhere you’d run a container. That said it’s not mandatory, and if you want the benefits of (a) without the benefits of (b) you can easily unpack the image to just get the Wasm payload and run that however you want. We dove into the details of the approach at Kubecon today, and the video should be coming out shortly.

stoplying1 4y ago
This seems like a good way to muddle the remaining value prop that docker has. I have zero idea why I'd want wasm via docker tooling vs what exists, especially as people more more and more to not-docker for building and running their containers. I think I see what someone is trying to do, but I don't know any dev looking for this or having a problem solved by it.
- timanglade 4y ago
  > 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.
  - heavyset_go 4y ago
    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.
    - timanglade 4y ago
      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 https://news.ycombinator.com/item?id=33324093 [1]: https://docs.docker.com/desktop/wasm/ https://docs.docker.com/desktop/wasm/
      - jammaloo 4y ago
        As a heads up, the download links to the technical preview builds of Docker seem to be incorrect on that page https://docs.docker.com/desktop/wasm/ https://docs.docker.com/desktop/wasm/. The Windows, Mac OS Intel and Silicon each point to https://www.docker.com/download/wasm-preview/linuxamd64deb https://www.docker.com/download/wasm-preview/linuxamd64deb which is the linux build. The article linked by the OP has the correct links.
        deleted 4y ago
        [deleted]
      - heavyset_go 4y ago
        Your second link answered my questions well, thanks.
        deleted 4y ago
        [deleted]
deleted 4y ago
[deleted]
lolinder 4y ago
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 abstraction? If the latter, how is this new layer of abstraction different from just using one of the WasmEdge docker containers [0]? I'm not trying to be combative, I'm just sincerely confused at what problem this technical preview is intended to solve. [0] https://wasmedge.org/book/en/quick_start/use_docker.html https://wasmedge.org/book/en/quick_start/use_docker.html
- timanglade 4y ago
  > 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 part of a microservice architecture). This is particularly helpful if you build apps that have a mix of Wasm & container components[0] 2. Easy way to share & deploy Wasm artifacts, using trusted infra like Docker Hub, but also Dockerfiles and Docker Compose 3. Transparent, reliable way to deploy Wasm applications to existing container-based infrastructure such as k8s (via OCI images) — but these apps can also be “unpacked” to run natively on edge infrastructure > is it going to wrap the WASM binary produced by cargo in another layer of abstraction? If the latter, how is this new layer of abstraction different from just using one of the WasmEdge docker containers [0]? Our approach is close to this. First, it was built with the WasmEdge folks, so you’re correct to detect the similarity. Second, it does wrap resulting artifacts into a OCI image, because we believe that can generate a lot of advantages (points #2 and #3 above) BUT you can also easily unpack the Wasm payload from the binary image at deploytime/runtime if you’d rather deploy your app on Wasm-native infrastructure (as opposed to container-native infra) Appreciate the feedback. Hope the above helps. [0]: https://docs.docker.com/desktop/wasm/#running-a-multi-service-application-with-wasm https://docs.docker.com/desktop/wasm/#running-a-multi-servic...
kodah 4y ago
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."
- timanglade 4y ago
  Basically yes: if you get value out of Docker for container apps today, we think you’ll get value out of Docker for Wasm apps tomorrow.
  - kodah 4y ago
    Seems promising. I think, based on what I read in this, that most folks don't know how challenging working with WASM is.
    - timanglade 4y ago
      That’s our experience as well… This Technical Preview is an early downpayment, and we’re definitely looking for feedback on how one may could make the Wasm development experience better!
      - xeonmc 4y ago
        It's still not clear to me, so can you bundle source code into your Dockerfile and just have compilation being part of the docker compose step?
        mikesir87 4y ago
        Great question! In the demo app we showed yesterday (source here - https://github.com/second-state/microservice-rust-mysql https://github.com/second-state/microservice-rust-mysql), the Dockerfile is leveraging a multi-stage build where the first stage builds the Wasm module and the second stage extracts the Wasm module into a "FROM scratch" image. In Compose, the "server" service is running using the image that is produced by that build. It's then handed off to the new Wasm runtime, where the module is extracted and executed. Hope that helps! Feel free to follow up with more questions!
discordance 4y ago
Hi Tim from Docker How about getting docker running in WASM so I can run containers in the browser?
- woleium 4y ago
  that's what I thought this was. I was disappointed.
- Proven 4y ago
cebert 4y ago
I’ve been able to do this with VS Code Dev containers already. What issue is Docker trying to solve?

stoplying1 4y ago

This seems like a good way to muddle the remaining value prop that docker has. I have zero idea why I'd want wasm via docker tooling vs what exists, especially as people more more and more to not-docker for building and running their containers. I think I see what someone is trying to do, but I don't know any dev looking for this or having a problem solved by it.

timanglade 4y ago
> 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.
- heavyset_go 4y ago
  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.
  - timanglade 4y ago
    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 https://news.ycombinator.com/item?id=33324093 [1]: https://docs.docker.com/desktop/wasm/ https://docs.docker.com/desktop/wasm/
    - jammaloo 4y ago
      As a heads up, the download links to the technical preview builds of Docker seem to be incorrect on that page https://docs.docker.com/desktop/wasm/ https://docs.docker.com/desktop/wasm/. The Windows, Mac OS Intel and Silicon each point to https://www.docker.com/download/wasm-preview/linuxamd64deb https://www.docker.com/download/wasm-preview/linuxamd64deb which is the linux build. The article linked by the OP has the correct links.
      - deleted 4y ago
        [deleted]
    - heavyset_go 4y ago
      Your second link answered my questions well, thanks.
      - deleted 4y ago
        [deleted]

deleted 4y ago

[deleted]

lolinder 4y ago

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 abstraction? If the latter, how is this new layer of abstraction different from just using one of the WasmEdge docker containers [0]? I'm not trying to be combative, I'm just sincerely confused at what problem this technical preview is intended to solve. [0] https://wasmedge.org/book/en/quick_start/use_docker.html https://wasmedge.org/book/en/quick_start/use_docker.html

timanglade 4y ago
> 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 part of a microservice architecture). This is particularly helpful if you build apps that have a mix of Wasm & container components[0] 2. Easy way to share & deploy Wasm artifacts, using trusted infra like Docker Hub, but also Dockerfiles and Docker Compose 3. Transparent, reliable way to deploy Wasm applications to existing container-based infrastructure such as k8s (via OCI images) — but these apps can also be “unpacked” to run natively on edge infrastructure > is it going to wrap the WASM binary produced by cargo in another layer of abstraction? If the latter, how is this new layer of abstraction different from just using one of the WasmEdge docker containers [0]? Our approach is close to this. First, it was built with the WasmEdge folks, so you’re correct to detect the similarity. Second, it does wrap resulting artifacts into a OCI image, because we believe that can generate a lot of advantages (points #2 and #3 above) BUT you can also easily unpack the Wasm payload from the binary image at deploytime/runtime if you’d rather deploy your app on Wasm-native infrastructure (as opposed to container-native infra) Appreciate the feedback. Hope the above helps. [0]: https://docs.docker.com/desktop/wasm/#running-a-multi-service-application-with-wasm https://docs.docker.com/desktop/wasm/#running-a-multi-servic...

kodah 4y ago

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."

timanglade 4y ago
Basically yes: if you get value out of Docker for container apps today, we think you’ll get value out of Docker for Wasm apps tomorrow.
- kodah 4y ago
  Seems promising. I think, based on what I read in this, that most folks don't know how challenging working with WASM is.
  - timanglade 4y ago
    That’s our experience as well… This Technical Preview is an early downpayment, and we’re definitely looking for feedback on how one may could make the Wasm development experience better!
    - xeonmc 4y ago
      It's still not clear to me, so can you bundle source code into your Dockerfile and just have compilation being part of the docker compose step?
      - mikesir87 4y ago
        Great question! In the demo app we showed yesterday (source here - https://github.com/second-state/microservice-rust-mysql https://github.com/second-state/microservice-rust-mysql), the Dockerfile is leveraging a multi-stage build where the first stage builds the Wasm module and the second stage extracts the Wasm module into a "FROM scratch" image. In Compose, the "server" service is running using the image that is produced by that build. It's then handed off to the new Wasm runtime, where the module is extracted and executed. Hope that helps! Feel free to follow up with more questions!

discordance 4y ago

Hi Tim from Docker How about getting docker running in WASM so I can run containers in the browser?

woleium 4y ago
that's what I thought this was. I was disappointed.
Proven 4y ago

cebert 4y ago

I’ve been able to do this with VS Code Dev containers already. What issue is Docker trying to solve?