Stream: wasmtime

Topic: Running wasm container with ctr/docker

view this post on Zulip Sangeeta Kakati (Sep 08 2024 at 16:32):

I am trying to run an image which I built using buildx and platform wasi/wasm (It works well locally using docker desktop). But when I try to tun it in a server, using the docker ce, wasmtime shim (built runwasi), I get this
for platform in manifest: not found", error="failed to extract layer / operating system is not supported

view this post on Zulip Ralph (Sep 09 2024 at 10:18):

if you're going to use docker-ce, you need to configure it to use containerd/runwasi manually, I believe. https://docs.docker.com/engine/daemon/alternative-runtimes/

Alternative container runtimes
Docker Engine uses runc as the default container runtime, but you can specify alternative runtimes using the CLI or by configuring the daemon

view this post on Zulip Ralph (Sep 09 2024 at 10:18):

have you done that?

view this post on Zulip Sangeeta Kakati (Sep 09 2024 at 14:40):

Ralph said:

have you done that?

Yes, I built runwasi to get the shims,
I have this in my containerd's config.toml:

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.spin]
runtime_type = "io.containerd.spin.v2"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.wasmtime]
runtime_type = "io.containerd.wasmtime.v1"
runtime_engine = "/usr/local/bin/containerd-shim-wasmtime-v1"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.wasmedge]
runtime_type = "io.containerd.wasmedge.v1"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.wasmer]
runtime_type = "io.containerd.wasmer.v1"

And the docker daemon config is:

{
"runtimes": {
"io.containerd.wasmtime.v1": {
"path": "/usr/local/bin/containerd-shim-wasmtime-v1"
}
}
}

I have it placed in /usr/local/bin

And I am using this to run :
docker run --runtime=io.containerd.wasmtime.v1 --platform=wasm sangeetakakati/rust-matrix-wasm:wasm

view this post on Zulip Ralph (Sep 09 2024 at 14:57):

and it is now working?

view this post on Zulip Ralph (Sep 09 2024 at 14:57):

I noticed that Jorge answered in slack about this

view this post on Zulip Ralph (Sep 09 2024 at 14:59):

https://cloud-native.slack.com/archives/C04LTPB6Z0V/p1725882112321519?thread_ts=1722864811.543829&cid=C04LTPB6Z0V

view this post on Zulip Sangeeta Kakati (Sep 09 2024 at 15:10):

Ralph said:

I noticed that Jorge answered in slack about this

Yes I followed that, It works on my arm64 server in a jetson nano, but not in an aws server i am using with amd64 :(
I am lost for where I am going wrong here to be getting this :
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: unable to retrieve OCI runtime error (open /run/containerd/io.containerd.runtime.v2.task/moby/35b160456e14a1e941a662792b3c69e621d857ef5cfc805fe8256ee4efbe68ee/log.json: no such file or directory): /usr/local/bin/containerd-shim-wasmtime-v1 did not terminate successfully: exit status 101: unknown.

Is this related to the config file for containerd?

view this post on Zulip Ralph (Sep 09 2024 at 15:11):

yeah, bring that problem to Jorge over in slack. This is really a containerd conversation.

view this post on Zulip Sangeeta Kakati (Sep 17 2024 at 09:25):

Will using a non-default runtime (io.containerd.wasmtime.v1) introduce some additional overhead in terms of startup time of container or pull time from an oci?

view this post on Zulip Ralph (Sep 18 2024 at 12:14):

each implementation does its own pulling, so no DEFAULT overhead no, and generally the pulls will be much faster than container images due to size alone

view this post on Zulip Ralph (Sep 18 2024 at 12:15):

however, there's the manifest pull to locate the layer/component, and then there's the component pull. That's about it.

view this post on Zulip Ralph (Sep 18 2024 at 12:15):

those are the same with containers, basically

Last updated: Dec 23 2024 at 13:07 UTC