Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

run component in docker #8411

Open
erkules opened this issue Apr 19, 2024 · 9 comments
Open

run component in docker #8411

erkules opened this issue Apr 19, 2024 · 9 comments

Comments

@erkules
Copy link

erkules commented Apr 19, 2024

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
Copy link
Member

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
Copy link
Author

erkules commented Apr 20, 2024

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
Copy link

hone commented Apr 22, 2024

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

@erkules
Copy link
Author

erkules commented Apr 22, 2024

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
Copy link

matsbror commented Apr 22, 2024

@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
Copy link
Author

erkules commented Apr 22, 2024

@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
Copy link

matsbror commented Apr 29, 2024

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

@Mossaka
Copy link
Member

Mossaka commented May 1, 2024

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.

@erkules
Copy link
Author

erkules commented May 6, 2024

thx @Mossaka and @matsbror

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants