wagi
runwasi
Our great sponsors
wagi | runwasi | |
---|---|---|
14 | 8 | |
867 | 970 | |
1.3% | 4.8% | |
1.8 | 9.6 | |
almost 2 years ago | 3 days ago | |
Rust | Rust | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
wagi
-
Reminiscing CGI Scripts
WAGI and WCGI are the WASM based spiritual successors.
https://github.com/deislabs/wagi
https://wasmer.io/posts/announcing-wcgi
-
A simple web server written in Awk
Compile a CGI program in any language to WASI, then use https://github.com/deislabs/wagi to run it.
-
Running WASI binaries from your HTML using Web Components
Yeah of course! They've got STDIN/STDOUT/STDERR and I've built a Virtual Filesystem. But if you're using WASI binaries locally they don't have that restriction.
You might be interested in WAGI: https://github.com/deislabs/wagi
And to catch up on WASI: https://xeiaso.net/talks/unix-philosophy-logical-extreme-was...
-
Waggy, the library for writing WAGI API handlers in Go
As I'm sure you've heard, WASM has been growing in popularity and use over the past few years. And with the creation of WASI (Web Assembly System Interface) and WAGI (Web Assembly Gateway Interface), WASM is starting to venture outside of running just in the browser. And in the case of WAGI, if you've been programming since the earlier days of the internet, it might feel very similar to CGI programming (and that's because it's based on CGI1.1!) WAGI provides a way for developers to define handlers for HTTP requests and route them to specific functions inside of, or entire, WASM modules. It does so by piping the headers of the incoming request to os.Args[1:], piping the body of the incoming request to os.Stdin, and writing the response to os.Stdout. (To learn more about configuring, routing, compiling, and deploying WAGI routes, as well as the limitations of WAGI routes, please consult the WAGI docs and the TinyGo WASM docs)
-
Rethinking Virtualization for Back Ends
What do you think of WAGI [1], which is basically CGI for WASM modules.
[1]: https://github.com/deislabs/wagi/blob/main/docs/writing_modu...
- Isolates, MicroVMs, and WebAssembly (In 2022)
-
The Promise of WASM
as serverless functions (https://github.com/deislabs/wagi)
-
Single Page Applications using Rust (with WASM)
I'm experimenting with WASM & Rust but with a different framework named wagi, there's a great video by Rainer Stropek & Stefan Baumgartner that gives a little introduction to it [0]
[0]: https://www.youtube.com/watch?v=9NDwHBjLlhQ
[1]: https://github.com/deislabs/wagi
-
Building a WebAssembly-powered serverless platform
Krustlet and WAGI are two such projects.
-
Introduction to Hippo: The WebAssembly PaaS
It does support it, the runtime we are currently using enables that -- see https://github.com/deislabs/wagi/blob/main/docs/writing_modu...
Good point on the docs, I will open an issue and add some information about it, thanks!
runwasi
-
Howto: WASM runtimes in Docker / Colima
cpu: 4 disk: 60 memory: 12 arch: host hostname: colima autoActivate: true forwardAgent: false # I only tested this with 'docker', not 'containerd': runtime: docker kubernetes: enabled: false version: v1.24.3+k3s1 k3sArgs: [] network: address: true dns: [] dnsHosts: host.docker.internal: host.lima.internal # Added: # - containerd-snapshotter: true (meaning containerd will be used for pulling images) docker: features: buildkit: true containerd-snapshotter: true vmType: vz rosetta: true mountType: virtiofs mountInotify: false cpuType: host # This provisioning script installs build dependencies, WasmEdge and builds the WASM runtime shims for containerd. # NOTE: this takes a LOOONG time! provision: - mode: system script: | [ -f /etc/docker/daemon.json ] && echo "Already provisioned!" && exit 0 echo "Installing system updates:" apt-get update -y apt-get upgrade -y echo "Installing WasmEdge and runwasi build dependencies:" # NOTE: packages curl, git and python3 already installed: apt-get install -y make gcc build-essential pkgconf libtool libsystemd-dev libprotobuf-c-dev libcap-dev libseccomp-dev libyajl-dev libgcrypt20-dev go-md2man autoconf automake criu pkg-config libdbus-glib-1-dev libelf-dev libclang-dev libzstd-dev protobuf-compiler apt-get clean -y - mode: user script: | [ -f /etc/docker/daemon.json ] && echo "Already provisioned!" && exit 0 # # Setting vars for this script: # # Which WASM runtimes to install (wasmedge, wasmtime and wasmer are supported): WASM_RUNTIMES="wasmedge wasmtime wasmer" # # Location of the containerd config file: CONTAINERD_CONFIG="/etc/containerd/config.toml" # # Target location for the WASM runtimes and containerd shims ($TARGET/bin and $TARGET/lib): TARGET="/usr/local" # # Install rustup: # echo "Installing rustup for building runwasi:" curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- --default-toolchain none -y source "$HOME/.cargo/env" # # Install selected WASM runtimes and containerd shims: # [[ -z "${WASM_RUNTIMES// /}" ]] && echo "No WASM runtimes selected - exiting!" && exit 0 git clone https://github.com/containerd/runwasi echo "Installing WASM runtimes and building containerd shims: ${WASM_RUNTIMES}:" sudo mkdir -p /etc/containerd/ containerd config default | sudo tee $CONTAINERD_CONFIG >/dev/null for runtimeName in $WASM_RUNTIMES; do case $runtimeName in wasmedge) echo "Installing WasmEdge:" curl -sSfL https://raw.githubusercontent.com/WasmEdge/WasmEdge/master/utils/install.sh | sudo bash -s -- -p $TARGET echo echo "`wasmedge -v` installed!" ;; wasmtime) echo "Installing wasmtime:" curl -sSfL https://wasmtime.dev/install.sh | bash sudo cp .wasmtime/bin/* ${TARGET}/bin/ rm -rf .wasmtime echo "`wasmtime -V` installed!" ;; wasmer) echo "Installing wasmer:" curl -sSfL https://get.wasmer.io | sh sudo cp .wasmer/bin/* ${TARGET}/bin/ sudo cp .wasmer/lib/* ${TARGET}/lib/ rm -rf .wasmer echo "`wasmer -V` installed!" ;; *) echo "ERROR: WASM runtime $runtimeName is not supported!" exit 1 ;; esac cd runwasi echo "Building containerd-shim-${runtimeName}:" cargo build -p containerd-shim-${runtimeName} --release echo "Installing containerd-shim-${runtimeName}-v1:" sudo install ./target/release/containerd-shim-${runtimeName}-v1 ${TARGET}/bin sudo ln -sf ${TARGET}/bin/containerd-shim-${runtimeName}-v1 ${TARGET}/bin/containerd-shim-${runtimeName}d-v1 sudo ln -sf ${TARGET}/bin/containerd-shim-${runtimeName}-v1 ${TARGET}/bin/containerd-${runtimeName}d echo "containerd-shim-${runtimeName} installed." cd .. echo "[plugins.\"io.containerd.grpc.v1.cri\".containerd.runtimes.${runtimeName}]" | sudo tee -a $CONTAINERD_CONFIG >/dev/null echo " runtime_type = \"io.containerd.${runtimeName}.v1\"" | sudo tee -a $CONTAINERD_CONFIG >/dev/null done echo "containerd WASM runtimes and shims installed." # # Restart the systemctl services to pick up the installed shims. # NOTE: We need to 'stop' docker because at this point the actual daemon.json config is not yet provisioned: # echo "Restarting/reloading docker/containerd services:" sudo systemctl daemon-reload sudo systemctl restart containerd sudo systemctl stop docker sshConfig: true mounts: [] env: {}
-
Using enums to represent state in Rust
I wish Go had (real) enums.
https://github.com/containerd/runwasi/blob/ba5ab5ada5a401762...
- Containerd now supports WasmEdge as a container runtime, via the runwasi project
- WasmEdge supported as a container runtime in containerd via the runwasi project
-
WebAssembly: Docker Without Containers
On Windows the shim is called runhcs (io.containerd.runhcs.v1).
The docker solution mentioned in the article modifies the "wasmtime" shim from https://github.com/containerd/runwasi so that it uses "wasmedge" instead.
-
Is it possible to run a containerized SvelteKit/Node-based website as WASM module?
Instead of serving it inside a container, I would like to run it as WASM module (if that makes sense, I'm very new to WASM. Maybe this a silly idea). The reason for this is to check out reduced instantiation time and effortless multi-arch support (no need to build container image for every arch), for example using the wasmedge runtime: https://docs.docker.com/desktop/wasm/. I currently manage the container through Kubernetes (among other things), and I'm considering runwasi as containerd shim: https://github.com/containerd/runwasi.
- Isolates, MicroVMs, and WebAssembly (In 2022)
- Show HN: Run WASM in Containerd
What are some alternatives?
wasi-experimental-http - Experimental outbound HTTP support for WebAssembly and WASI
runwasi - Facilitates running Wasm / WASI workloads managed by containerd
wasmer-python - 🐍🕸 WebAssembly runtime for Python
runwasi - [Moved to: https://github.com/deislabs/runwasi]
wasm-to-oci - Use OCI registries to distribute Wasm modules
krustlet - Kubernetes Rust Kubelet [Moved to: https://github.com/krustlet/krustlet]
wizer - The WebAssembly Pre-Initializer
wasmtime - A fast and secure runtime for WebAssembly
dioxus - Fullstack GUI library for web, desktop, mobile, and more.
cheats.rs - Rust Language Cheat Sheet - https://cheats.rs
wasi-vfs - A virtual filesystem layer for WASI.
k8s-WASM-demo - PoC created to measure the performance provided by WASM