- SUSE의 Hackweek 22에서 저자의 프로젝트에 대한 기사, WebAssembly를 실행하는 unikernel을 구축했다.
- 저자는 unikernels와 WebAssembly를 결합하는 잠재적 이점 등 여러 이유로 이 프로젝트를 선택했다.
- 애플리케이션 개발자의 관점에서, 애플리케이션과 그 종속성이 대상 unikernel을 지원해야 하므로 unikernel로 애플리케이션을 이식하거나 작성하는 것이 어려울 수 있다.
- Unikernel 관리자들도 사용자 애플리케이션에서 활용할 수 있는 알려지지 않은 시스템 기본 요소로 인해 그들의 플랫폼에서 어떤 애플리케이션도 원활하게 실행되도록 보장하는 데 어려움을 겪는다.
- 그러나 WebAssembly 플랫폼을 대상으로 할 때, 애플리케이션은 WebAssembly 런타임에 의해 제공되어야 하는 명확한 기능 집합을 가지고 있다.
- 저자는 Rust로 작성된 unikernel인 RustyHermit 프로젝트를 unikernel 애플리케이션의 기반으로 사용했다.
- 저자는 선호하는 런타임인 Wasmtime이 RustyHermit 위에 구축되지 않기 때문에 WebAssembly 런타임과 관련된 어려움을 겪었다. 결국 그들은 순수 Rust WebAssembly 런타임인 wasmi를 찾아 사용했다.
- 저자는 또한 Spiderlightning에서 WebAssembly Component Model 제안의 사용에 대해 논의하며, 이를 통해 WebAssembly 게스트에게 기능을 제공하고 호스트가 WebAssembly 게스트에 의해 제공되는 기능을 사용할 수 있게 한다.
- 저자는 .wit 파일에서 호스트/게스트 코드를 생성하는 cli 도구인 wit-bindgen을 확장하여 wasmi WebAssembly 런타임을 지원해야 했다.
- 저자는 Spiderlightning http-server 데모를 실행하는 unikernel 애플리케이션의 녹화와 함께 게시물을 마무리하며, 다음 여정의 일부에서 Rust async, Redis, 그리고 일부 오류에 대해 다룰 것을 약속한다.