- บทความเกี่ยวกับโปรเจกต์ของผู้เขียนใน Hackweek 22 ของ SUSE ซึ่งได้สร้าง unikernel ที่สามารถรัน WebAssembly ได้
- ผู้เขียนเลือกโปรเจกต์นี้ด้วยเหตุผลหลายประการ รวมถึงประโยชน์ที่อาจเกิดขึ้นจากการผสาน unikernel กับ WebAssembly
- จากมุมมองของนักพัฒนาแอปพลิเคชัน การพอร์ตแอปพลิเคชันไปยังหรือเขียนแอปสำหรับ unikernel อาจเป็นเรื่องยาก เพราะทั้งแอปพลิเคชันและ dependencies ของมันต้องรองรับ unikernel เป้าหมาย
- ฝั่งผู้ดูแล unikernel เองก็มีความยากลำบากในการรับประกันว่าแอปพลิเคชันใด ๆ จะทำงานบนแพลตฟอร์มของตนได้อย่างราบรื่น เนื่องจากมี primitive ของระบบที่ไม่เป็นที่รู้จักซึ่งแอปพลิเคชันของผู้ใช้อาจนำไปใช้
- แต่เมื่อกำหนดให้แพลตฟอร์มเป้าหมายเป็น WebAssembly แอปพลิเคชันจะมีชุดความสามารถที่ชัดเจนซึ่ง WebAssembly runtime ต้องเป็นผู้จัดเตรียม
- ผู้เขียนใช้โปรเจกต์ RustyHermit ซึ่งเป็น unikernel ที่เขียนด้วย Rust เป็นฐานสำหรับแอปพลิเคชัน unikernel
- ผู้เขียนพบความยากลำบากที่เกี่ยวข้องกับ WebAssembly runtime เพราะ Wasmtime ซึ่งเป็น runtime ที่ตนชอบนั้นไม่ได้ถูกสร้างให้ทำงานบน RustyHermit สุดท้ายจึงไปพบและเลือกใช้ wasmi ซึ่งเป็น WebAssembly runtime ที่เขียนด้วย Rust ล้วน
- ผู้เขียนยังกล่าวถึงการใช้งานข้อเสนอ WebAssembly Component Model ใน Spiderlightning ซึ่งช่วยมอบความสามารถให้กับ WebAssembly guest และทำให้โฮสต์สามารถใช้ความสามารถที่ WebAssembly guest จัดเตรียมไว้ได้
- ผู้เขียนต้องขยาย
wit-bindgen ซึ่งเป็นเครื่องมือ CLI ที่สร้างโค้ดฝั่งโฮสต์/guest จากไฟล์ .wit เพื่อให้รองรับ WebAssembly runtime อย่าง wasmi
- ผู้เขียนปิดท้ายโพสต์ด้วยวิดีโอการทำงานของแอปพลิเคชัน unikernel ที่รันเดโม http-server ของ Spiderlightning พร้อมบอกว่าในตอนถัดไปของเส้นทางนี้จะพูดถึง Rust async, Redis และข้อผิดพลาดบางส่วน
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News