bytecodealliance / wasmtime

A fast and secure runtime for WebAssembly

Home Page:https://wasmtime.dev/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

run component in docker

erkules opened this issue · comments

I bulid https://github.com/sunfishcode/hello-wasi-http

wasmtime serve works

$ wasmtime serve target/wasm32-wasi/debug/hello_wasi_http.wasm
Serving HTTP on http://0.0.0.0:8080/

I got docker configured to have wasmtime as runtime. works with non-proxy wasm:

$ docker container run --platform=wasi/wasm --runtime wasmtime  erkules/mywasm:v1
12

But I didn't found how to configure the image to tell the runtime to use the subcommand.

Sorry but can you expand the problem you're having a bit more? I think that most of us working on Wasmtime aren't familiar with docker container run or the arguments you're passing. It may be best to report this issue to the maintainers of the wasm/wasmtime support in Docker as they might be able to help more?

Sorry for being so bad.
The basic problem is imho WIT.

wasmtime serve target/wasm32-wasi/debug/hello_wasi_http.wasm

is to prove the gitexample is working.

When I use docker it is similar to use configure containerd/runwasi.

But I got no way to tell the shim (or runwasi) to use the server subcommand.

like in runwasi/containnerd wasmtime is executing the entrypoint of an container/image.
But I need to convince wasmtime to use the server subcommand.

Rephrased: How does wasmtime in docker/runwasi etc. knows it has to run the/a component.

@erkules looking at your Dockerfile on dockerhub, you have this set as the CMD which will be executed:

CMD ["wasmedge" "/main.wasm"]

I'm not sure what you have ENTRYPOINT set to, but I think you want to set CMD to wasmtime serve <path to WASM module>.

Hi @hone, thx for checking.
You looked up the image erkules/wasm-http:imcontainer
This is a ordinary working docker container

            "Cmd": [
                "serve",
                "/http.wasm"
..
            "Entrypoint": [
                "/usr/bin/wasmtime"
        "Architecture": "amd64",

Using the wasmtime (containerd-shim) I need a (wasm) container.
So I build erkules/wasm-http:v1 (don't look the actual image up:)

        "Architecture": "wasm",

This kind of images expect the wasm module as ENTRYPOINT.
i.e.
["serve","/http.wasm"] only ["/http.wasm"] nothing worked.
Having a core module and the ENTRYPOINT pointing to that module everything is working.

So is there a way to tell the shim to use a special subcommand.
How does the wasmtime shim i.e. knows it is a component it hast to spin up?

@erkules did you resolve this? I am looking to do exactly this right now as well. But I think like @alexcrichton this is not a wasmtime issue, it's a docker issue.

@matsbror haven't solved it.
I don't think it is an docker issue. At least Ive got problems with ctr and containerd also.

ctr run --rm --runtime=io.containerd.wasmtime.v1 docker.io/erkules/wasm-http:v1 a 

containerd-logs:

Apr 22 23:19:47 perl3 containerd[3423363]: time="2024-04-22T23:19:47.957073021Z" level=info msg="server listen started"
Apr 22 23:19:47 perl3 containerd[3423363]: time="2024-04-22T23:19:47.957281712Z" level=info msg="server started"
Apr 22 23:19:47 perl3 containerd[3423363]: time="2024-04-22T23:19:47.957314698Z" level=info msg="Shim successfully started, waiting for exit signal..."
Apr 22 23:19:47 perl3 containerd[3423363]: time="2024-04-22T23:19:47.977023213Z" level=info msg="found manifest with WASM OCI image format"
Apr 22 23:19:47 perl3 containerd[3423363]: time="2024-04-22T23:19:47.977646223Z" level=info msg="no WASM layers found in OCI image"
Apr 22 23:19:47 perl3 containerd[3423363]: time="2024-04-22T23:19:47.978939323Z" level=info msg="close_range; preserve_fds=0"
Apr 22 23:19:47 perl3 containerd[3423363]: time="2024-04-22T23:19:47.979583692Z" level=info msg="cgroup manager V2 will be used"
Apr 22 23:19:47 perl3 containerd[3423363]: time="2024-04-22T23:19:47.980169131Z" level=warn msg="Controller rdma is not yet implemented."
Apr 22 23:19:47 perl3 containerd[3423363]: time="2024-04-22T23:19:47.980636981Z" level=warn msg="Controller misc is not yet implemented."
Apr 22 23:19:47 perl3 containerd[3423363]: time="2024-04-22T23:19:47.982457118Z" level=warn msg="Controller rdma is not yet implemented."
Apr 22 23:19:47 perl3 containerd[3423363]: time="2024-04-22T23:19:47.982478878Z" level=warn msg="Controller misc is not yet implemented."
Apr 22 23:19:47 perl3 containerd[3423363]: time="2024-04-22T23:19:47.99490045Z" level=info msg="close_range; preserve_fds=0"
Apr 22 23:19:47 perl3 containerd[3423363]: time="2024-04-22T23:19:47.995551693Z" level=warn msg="intermediate process already reaped"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.001191379Z" level=info msg="starting instance: a"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.002387964Z" level=info msg="calling start function"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.002425554Z" level=info msg="setting up wasi"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.002488088Z" level=info msg="building wasi context"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.314272152Z" level=info msg="instantiating component"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.315334175Z" level=info msg="error running start function: import `wasi:http/types@0.2.0` has the wrong type"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.3210106Z" level=info msg="deleting instance: a"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.32122991Z" level=info msg="cgroup manager V2 will be used"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.322184447Z" level=info msg="Shutting down shim instance"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.322215203Z" level=info msg="close monitor"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.322241327Z" level=error msg="listener accept got Custom { kind: Other, error: "listener shutdown for quit flag" }"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.32229698Z" level=info msg="ttrpc server listener stopped"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.322362134Z" level=info msg="listener thread stopped"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.322389062Z" level=info msg="begin to shutdown connection"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.322412009Z" level=info msg="connections closed"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.323181034Z" level=info msg="reaper thread exited"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.323274325Z" level=info msg="reaper thread stopped"
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.323239141Z" level=info msg="shim disconnected" id=a
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.324789933Z" level=warning msg="cleaning up after shim disconnected" id=a namespace=default
Apr 22 23:19:48 perl3 containerd[3423363]: time="2024-04-22T23:19:48.324921527Z" level=info msg="cleaning up dead shim"

I did some research on this and the problem lies in runwasi which is used by containerd to implement the wasm shims. It does not yet support http-wasi. There is a github issue about it: containerd/runwasi#416

Hey runwasi maintainer here. Yes I agree that this is an runwasi issue, probably not related to wasmtime. As @matsbror mentioned, there is no support for wasi:http at the moment. The only supported world is wasi:cli/run.

I got no way to tell the shim (or runwasi) to use the server subcommand.

You assessment is right. The wasmtime shim in Docker is using the wasmtime SDK directly, and thus there is no subcommand for serving HTTP requests.

How does the wasmtime shim i.e. knows it is a component it hast to spin up?

The shim will parse the first few bytes of the binary and determine whether it's a wasm module, a wasm component, or something else. If it's a wasm component, it assumes the component implmenets the wasi:cli world. And this is why you are seeing the error "import wasi:http/types@0.2.0 has the wrong type" in the containerd log.


In the meantime, if you just want to run hello_wasi_http.wasm component in Docker / Kubernetes, you may want to try the spinkube/containerd-spin-shim which uses the Spin runtime and it does support serving wasi:http requests.