دنیای همیشه در حال گسترش Wasm

در کنار هم قرار دادن کانتینرهای WebAssembly و OCI می‌تواند به ما امکان دهد تصویر محفظه یکسانی را روی هر سخت‌افزار یا سیستم‌عاملی که می‌خواهیم اجرا کنیم – هر کجا که بهترین، سریع‌ترین یا ارزان‌ترین اجرا است.

وقتی به واسم فکر می‌کنم—و دارم به واسم زیاد فکر می‌کنم—مثل آن کپسول‌های رشد جادویی که در کودکی داشتید تصور می‌کنم: فقط روی یکی از کپسول‌ها آب بریزید. و به چندین برابر اندازه خود، در اشکال و رنگ های مختلف گسترش می یابد.

به همین ترتیب، Wasm – یا WebAssembly، همانطور که به طور رسمی شناخته می‌شود – به‌عنوان یک فرمت دستورالعمل باینری برای یک ماشین مجازی مبتنی بر پشته، که در ابتدا برای مرورگر در نظر گرفته شده بود، «کوچک» شروع شد. هنوز هم همینطور است، اما همانطور که توسعه دهندگان «آب را روی آن می ریزند»، من انتظار دارم که شاهد رشد و تغییر شکل آن به هر شکلی باشیم – نه کم اهمیت، به عنوان راهی برای یک بار نوشتن برنامه ها و استقرار آنها بر روی تعداد فزاینده سخت افزار. و پلتفرم های نرم افزاری که (گاهی اوقات به معنای واقعی کلمه) زندگی ما را هدایت می کنند.

جنبه سخت‌افزاری به‌طور نسبی شاهد رونق ویژه‌ای است. زمانی نه چندان دور بود که اینتل به پردازنده های سخت افزاری مانند Kleenex برای بافت صورت می پرداخت. امروزه، این یک دنیای سخت افزاری چند زبانه است. Arm، RISC-V، Apple M1/M2، AWS Graviton، Ampere، Fujitsu، و دیگران به پردازنده‌های اینتل و AMD به عنوان اهداف توسعه برای مجموعه‌ای از موارد استفاده جدید، از لامپ‌ها گرفته تا ماشین‌ها تا برنامه‌های کاربردی سازمانی، و به‌ویژه سرورهای وب، پیوسته‌اند. که همه چیز را در دنیای مدرن به هم می چسباند. همه این معماری‌های سخت‌افزاری، به غیر از چیزهای قدیمی که هنوز در کمین هستند، باید سال‌ها در کنار هم زندگی کنند.

زبان های مختلف زیادی نیز وجود دارد. جاوا و .NET، البته، به توسعه دهندگان این امکان را داده اند که یک برنامه را یک بار بنویسند و آن را در هر جایی اجرا کنند، اما با مقداری سربار و محدودیت. با جاوا و دات نت، این درک ضمنی وجود دارد که کل اکوسیستم نرم افزار شما در جاوا و دات نت نوشته می شود. اگرچه دات نت از چند زبان مختلف پشتیبانی می کند، اما هرگز واقعاً به مفسر پیش فرض و چند زبانه برای هیچ زبانی تبدیل نشد. با جاوا و دات نت همیشه یک جدایی قابل درک بین سیستم عامل، که فرآیندهای چند زبانه (Python، Ruby، Perl، C، C++، و غیره) را مدیریت می کرد، و VM، که فرآیندهای نوشته شده و مستقر در در را مدیریت می کرد وجود داشت. em> اکوسیستم نرم افزار (جاوا، دات نت).

تلاش‌هایی برای گسترش ماشین مجازی جاوا (JVM) با JRuby، Jython و موارد دیگر صورت گرفته است، اما هرگز نتوانسته‌اند کاملاً به آن توجه کنند. این سیستم عامل همیشه از طریق کتابخانه‌های استاندارد C که تقریباً هر زبانی از آن استفاده می‌کند، به این هدف عمل کرده است، اما اشتراک‌گذاری کتابخانه‌ها بین زبان‌ها، برای مثال پایتون و روبی، هرگز آسان نبوده است. شاید آن چیزی که همیشه مورد نیاز بوده، فرمت باینری جهانی باشد!؟!؟

جایی که Wasm در آن جای می گیرد

کنسرسیوم جهانی وب (W3C) اولین بار Wasm، یعنی WebAssembly را در سال ۲۰۱۵ معرفی کرد و آن را در سال ۲۰۱۸ منتشر کرد. Wasm in-the-weeds که در ابتدا صرفاً برای استفاده در مرورگر طراحی شده بود، به عنوان یک بالقوه مورد توجه قرار گرفته است. مانع شکن در محیط های سخت افزاری و نرم افزاری مختلف. چشم انداز اصلی Wasm یک ابزار امنیتی بود که به توسعه دهندگان این امکان را می داد که به طور ایمن از زبان های کامپایل شده مانند C، C++ یا Rust در مرورگر استفاده کنند و در عین حال از تسلط کد بر روی ماشین کاربر جلوگیری کند.

از آن زمان، این چشم انداز به چیزی شبیه به جاوا یا دات نت تبدیل شده است، اما برای هر زبانی، توسعه دهندگان را قادر می سازد تا هر زبانی را در یک باینری کامپایل کنند که می تواند بر روی هر پلتفرمی از طریق مفسر Wasm اجرا شود، چه در مرورگر، چه در دسکتاپ، مستقیماً روی سرور، در لبه یا حتی به عنوان یک چارچوب افزونه در سایر نرم افزارها. چشم انداز به قابلیت حمل واقعی در طیف گسترده ای از موارد استفاده تبدیل شده است. اگرچه هنوز آنجا نیست.

موارد استفاده خاصی وجود دارد که Wasm برای امروز کاملاً منطقی است، از جمله برنامه‌ها و افزونه‌های مبتنی بر مرورگر. اما Wasm شروع به گسترش می کند تا بتواند چیزهایی مانند Python را در یک Wasm باینری کامپایل کند که سپس می تواند روی یک مفسر Wasm اجرا شود. اکنون می‌توانید برنامه‌های پایتون من را اجرا کنید زیرا مفسر پایتون در آن قالب کامپایل شده است، و اکنون آن مفسر پایتون می‌تواند روی هر قطعه سخت‌افزاری که مفسر Wasm دارد اجرا شود. علاوه بر این، ما شاهد تکامل Wasm به گونه‌ای هستیم که همان برنامه پایتون می‌تواند از کتابخانه‌های زبان‌های دیگری که در مفسر Wasm اجرا می‌شوند، استفاده کند. ما شاهد فشاری برای گسترش قابلیت حمل در هر دو بخش سخت افزاری و نرم افزاری به طور همزمان هستیم.

در حال حاضر، محبوب ترین زبان مورد استفاده با Wasm Rust است. مردم در حال کامپایل کردن Rust در این باینری‌های Wasm هستند و از آن‌ها در سراسر جهان استفاده می‌کنند. ما آن را در افزونه‌های فوق‌الذکر، اما همچنین در موارد استفاده بسیار خاص مانند Envoy، پراکسی شبکه محبوب، و در Krustlet، که برنامه‌ای طراحی شده برای جایگزینی Kubernetes Kubelet است، می‌بینیم. به جای کانتینرهای OCI، Krustlet فقط باینری های Wasm را اجرا می کند.

فراتر از Rust، ما شروع به دیدن افرادی می کنیم که از C، C++، Ruby و Python استفاده می کنند، بنابراین پشتیبانی چند زبانه در سمت نرم افزار نیز شکل می گیرد. علاوه بر این، ما همچنین شاهد هستیم که ابزارهایی مانند Podman و CRI-O برای استفاده از کانتینرهای OCI و Wasm با هم، به جای جایگزینی OCI، تکامل می‌یابند. به طور معمول، با کانتینرهای OCI، باینری ها در تصویر کانتینر مستقیماً روی هسته میزبان کانتینر زیرین اجرا می شوند. این محدودیت دارد که باینری در کانتینر باید برای معماری سخت‌افزار کامپایل شود.

اما یک زمان اجرای کانتینر که معمولاً توسط Podman و CRI-O استفاده می‌شود، شامل یک ویژگی آزمایشی است که باینری‌های Wasm را داخل تصویر کانتینر شناسایی می‌کند و این باینری‌ها را روی یک مفسر Wasm نصب شده در میزبان اجرا می‌کند. اجرای کانتینرهای Wasm و OCI با هم می‌تواند یک لایه امنیتی اضافی و همچنین توانایی اجرای همان کانتینرها را در هر تعداد معماری سخت‌افزاری و نسخه‌های سیستم عامل فراهم کند.

مسدود کننده های Wasm

در حالی که پتانسیل زیادی برای Wasm وجود دارد، هنوز برخی مسدود کننده ها وجود دارد.

برای یک چیز، پشتیبانی از زبان باید گسترش یابد، اما، همانطور که اشاره شد، APIها برای موارد استفاده بیشتر و بیشتر (شبکه به شدت وجود ندارد)، در زبان‌های بیشتر، در حین صحبت اضافه می‌شوند.

شاید یک مشکل بزرگتر این باشد که Wasm، یک معماری مجموعه دستورالعمل بسیار خاص، در حال حاضر با POSIX سازگار نیست، بنابراین نمی توانید از آن برای انجام بسیاری از کارهای استانداردی که توسعه دهندگان انتظار دارند استفاده کنید (به چیزهایی مانند باز کردن فکر کنید. یک فایل یا یک سوکت شبکه). دوستان Wasm در حال اضافه کردن یک API اضافی به نام WASI هستند که به Wasm اجازه می دهد برخی از این کارهای محاسباتی کلی را انجام دهد، اما ، تا زمانی که این اتفاق نیفتد، استفاده Wasm محدود خواهد بود.

با این گفته، این مشابه چیزی است که با Node.js و جاوا اسکریپت اتفاق افتاد، زمانی که آنها را از استفاده در مرورگر برای استفاده در قسمت پشتی آوردیم. ما می‌توانیم همین نوع تکامل را طی پنج سال آینده با Wasm و WASI ببینیم.

آینده Wasm

در حال حاضر بحث‌های زیادی در مورد پتانسیل Wasm وجود دارد، نه اینکه میلیون‌ها دلار سرمایه‌گذاری خطرپذیر در شرکت‌هایی که برای تکامل فناوری سرمایه‌گذاری می‌شوند، ذکر کنیم. من این را به‌عنوان پولی می‌دانم که به خوبی خرج شده است، زیرا می‌توانم زمانی را در آینده نزدیک تصور کنم که یک توسعه‌دهنده که روی یک ایستگاه کاری مک، ویندوز یا RHEL کار می‌کند یا لپ‌تاپ می‌تواند برنامه‌ای را برای لبه، اینترنت اشیا، ابر یا خودرو کامپایل کند. پلتفرم، و آنها این کار را با استفاده از Wasm انجام خواهند داد. امروزه، آن گردش کار به کامپایل متقابل یا شبیه سازی نیاز دارد که ناخوشایند است و/یا عملکرد پایین تری دارد.

توسعه‌دهنده نمی‌خواهد کد را متقاطع کامپایل کند. آنها فقط می خواهند آن را کامپایل کنند، آن را به صورت محلی اجرا کنند، آن را آزمایش کنند، آن را به هر کجا منتقل کنند، و فقط کار کند. Wasm، از نظر تئوری، می تواند این اتفاق را بیاندازد.

Wasm همچنین برای ساختن ظروف قابل حمل تر و قدرتمندتر است.

با استفاده از crun، همکار من جوزپه اسکریوانو دو اثبات مفهومی (PoC) انجام داده است که نشان می‌دهد چگونه Wasm باینری را می توان از یک ظرف Docker/OCI با استفاده از Podman/ اجرا کرد crun به عنوان یک ظرف مستقل در لینوکس، یا با استفاده از CRI-O/crun در Kubernetes. در هر صورت، زمان اجرای کانتینر به اندازه کافی هوشمند بود که باینری Wasm را تشخیص داد و آن را با مترجم Wasm اجرا کرد. (در زمان نگارش این مقاله، crun در حال حاضر از WasmEdge، Wasmer و Wasmtime. )

PoC جوزپه نشان می‌دهد که Wasm می‌تواند شما را قادر سازد تا همان تصویر کانتینر را روی هر سخت‌افزاری که می‌خواهید اجرا کنید — یا حداقل، هر جایی که مترجم Wasm وجود دارد. این به راحتی نیاز به کامپایل و ساخت تصاویر کانتینر مختلف برای مثال RISC-V، Arm یا x86 را نفی می کند. امروز، این کاری است که ما مجبور به انجام آن هستیم: اگر به باینری نیاز داریم تا روی سه معماری سخت افزاری مختلف اجرا شود، باید آن را سه بار کامپایل و بسازیم، سه تصویر کانتینر مختلف ایجاد کنیم و همه آنها را به یک سرور رجیستری فشار دهیم. PoC جوزپه نشان می‌دهد که با Wasm، یک توسعه‌دهنده می‌تواند تنها یک بار بسازد و در هر جایی مستقر شود (یکی از رویاهایی که ما همیشه در مورد کانتینرها داشتیم).

اگر بتوانیم این کار را انجام دهیم، این به معنای واقعی کلمه داستان ابر ترکیبی است. یک خوشه Kubernetes را با مقداری RISC-V، مقداری Arm، مقداری Intel، تصور کنید که همگی در دسته ای از گره های مختلف اجرا می شوند. می‌توانم برنامه‌ای را پایین بکشم و آن را در هر جایی که بهترین، سریع‌ترین، ارزان‌ترین یا نزدیک‌ترین به مصرف‌کننده اجرا می‌کند اجرا کنم… 

پتانسیل Wasm بسیار هیجان‌انگیز است، و من فکر می‌کنم که ما می‌توانیم به آنجا برسیم، به خصوص اگر مردم Wasm بتوانند زبان و به خصوص مشکلات POSIX را حل کنند. POSIX بیش از ۲۰ سال است که در سیستم عامل ها وجود دارد و نمی توان دو دهه نرم افزار قدیمی را نادیده گرفت.

جامعه WebAssembly از مسیر Wasm که مردم می بینند و آرزو می کنند بسیار آگاه است. آنها در حال کار بر روی API هایی هستند که برخی از مسدود کننده ها را حذف می کنند و Wasm را به گونه ای گسترش می دهند که برای موارد استفاده بیشتر مفیدتر می شود. با وجود همه این موارد، Wasm بیشتر به یک معماری همه منظوره تبدیل خواهد شد که سازمان ها می توانند از آن برای پشتیبانی و بهینه سازی مدل ابری ترکیبی استفاده کنند.

در Red Hat، اسکات مک کارتی مدیر ارشد محصول RHEL Server است که مسلما بزرگترین تجارت نرم افزار منبع باز در جهان است. مناطق تمرکز شامل ابر، کانتینرها، گسترش حجم کاری و اتوماسیون است. اسکات با همکاری نزدیک با مشتریان، شرکا، تیم‌های مهندسی، فروش، بازاریابی، سایر تیم‌های محصول و حتی در جامعه، تجربه شخصی را با بازخورد مشتری و شریک ترکیب می‌کند تا قابلیت‌های استراتژیک را در لینوکس Red Hat Enterprise افزایش دهد. /p>