erkules opened issue #8411:
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.
alexcrichton commented on issue #8411:
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?
erkules commented on issue #8411:
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.
hone commented on issue #8411:
@erkules looking at your
Dockerfile
on dockerhub, you have this set as theCMD
which will be executed:CMD ["wasmedge" "/main.wasm"]
I'm not sure what you have
ENTRYPOINT
set to, but I think you want to setCMD
towasmtime serve <path to WASM module>
.
erkules commented on issue #8411:
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?
matsbror commented on issue #8411:
@erkules did you resolve this? I am looking to do exactly this right now as well.
matsbror edited a comment on issue #8411:
@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.
erkules commented on issue #8411:
@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"
matsbror commented on issue #8411:
I did some research on this and the issue lies in
runwasi
which is used bycontainerd
to implement the wasm shims. It does not yet support http-wasi. There is a github issue about it: https://github.com/containerd/runwasi/issues/416
matsbror edited a comment on issue #8411:
I did some research on this and the problem lies in
runwasi
which is used bycontainerd
to implement the wasm shims. It does not yet support http-wasi. There is a github issue about it: https://github.com/containerd/runwasi/issues/416
Mossaka commented on issue #8411:
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 iswasi: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.0has 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 servingwasi:http
requests.
erkules commented on issue #8411:
thx @Mossaka and @matsbror
Last updated: Dec 23 2024 at 12:05 UTC