ساخت و اجرای اپلیکیشن‌های WebAssembly به‌عنوان کانتینر داکر

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

WebAssemblyکانتینر WasmDocker Desktop

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱۴ شهریور ۱۴۰۵

مقدمه

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

Wasm چیست

Wasm یک معماری ماشین مجازی است که زبان‌های برنامه‌نویسی می‌توانند به آن کامپایل شوند، به‌جای هدف قرار دادن یک سیستم‌عامل و معماری CPU خاص مانند لینوکس روی ARM یا AMD. یک باینری Wasm در هر جایی که Wasm runtime در دسترس باشد قابل اجراست. Docker Desktop با چندین runtime از این نوع عرضه می‌شود، از جمله io.containerd.spin.v2، که به containerd امکان استقرار و مدیریت کانتینرهای Wasm — باینری‌های Wasm در حال اجرا داخل کانتینرهای حداقلی scratch — را می‌دهد.

Wasm در حال حاضر در بارهای کاری‌ای مانند inference هوش مصنوعی، توابع serverless، پلاگین‌ها و محاسبات لبه (edge) عملکرد خوبی دارد، اما برای اپلیکیشن‌هایی با نیازهای سنگین I/O یا شبکه‌بندی پیچیده مناسب نیست — هرچند انتظار می‌رود این موضوع با بلوغ اکوسیستم بهبود یابد.

آماده‌سازی محیط

کار با Wasm نیازمند Docker Desktop با فعال بودن ویژگی Wasm، Rust با نصب هدف کامپایل Wasm، و Spin، یک فریم‌ورک برای ساخت و اجرای اپلیکیشن‌های Wasm است. هدف Wasm برای Rust با دستور زیر اضافه می‌شود:

rustup target add wasm32-wasip1

نوشتن یک اپلیکیشن Wasm

یک اپلیکیشن وب مبتنی بر Wasm جدید را می‌توان با Spin ساخت:

spin new hello-world -t http-rust

این دستور یک اپلیکیشن ساده وب با Rust تولید می‌کند. پس از ویرایش متن پاسخ و کامپایل آن، Spin یک باینری .wasm تولید می‌کند:

spin build

باینری تولیدشده را می‌توان پیش از کانتینری کردن، به‌صورت محلی تست کرد:

spin up

کانتینری کردن اپلیکیشن

بسته‌بندی یک اپلیکیشن Wasm به‌عنوان ایمیج کانتینری همچنان از یک Dockerfile استفاده می‌کند، اما بر پایه ایمیج خالی scratch، زیرا اپلیکیشن‌های Wasm به سیستم‌عامل لینوکس نیازی ندارند:

FROM scratch
COPY /target/wasm32-wasip1/release/hello_world.wasm .
COPY spin.toml .

سپس ایمیج با فلگ پلتفرم مخصوص Wasm ساخته می‌شود:

docker build --platform wasi/wasm --provenance=false -t nigelpoulton/ddd-book:wasm .

ایمیج حاصل ظاهر و رفتاری مانند یک ایمیج معمولی داکر دارد، فقط به‌طور چشمگیری کوچک‌تر است — اغلب فقط چند صد کیلوبایت. این ایمیج را می‌توان با دستور معمول docker push به Docker Hub یا هر رجیستری دیگر سازگار با OCI ارسال کرد.

اجرای یک کانتینر Wasm

اجرای اپلیکیشن کانتینری‌شده نیازمند مشخص کردن صریح runtime مخصوص Wasm است:

docker run -d --name wasm-ctr \
  --runtime=io.containerd.spin.v2 \
  --platform=wasi/wasm \
  -p 5556:80 \
  nigelpoulton/ddd-book:wasm /

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

نتیجه‌گیری

پشتیبانی داکر از Wasm به این معناست که توسعه‌دهندگان می‌توانند دقیقاً از همان ابزارها — docker build، docker push، docker run و رجیستری‌های استاندارد OCI — برای بسته‌بندی و توزیع اپلیکیشن‌های Wasm استفاده کنند که پیش‌تر برای کانتینرهای سنتی به کار می‌بردند. با تداوم بلوغ اکوسیستم Wasm، این یکپارچگی داکر را در جایگاهی قرار می‌دهد که بتواند از هر دو مدل به‌طور هم‌زمان پشتیبانی کند و به تیم‌ها اجازه دهد ابزار مناسب را برای هر بار کاری انتخاب کنند.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

داکر چگونه از فناوری‌های امنیتی لینوکس استفاده می‌کند

مدل امنیتی داکر بر پایه دفاع چندلایه ساخته شده و فناوری‌های شناخته‌شده kernel لینوکس را با تنظیمات پیش‌فرض معقول ترکیب می‌کند. این مقاله توضیح می‌دهد که namespaceها، control groupها، capabilityها، Mandatory Access Control و seccomp چگونه در کنار هم کانتینرها را ایزوله و ایمن می‌کنند.

ادامه

مدیریت داده‌های ماندگار در داکر با Volume

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

ادامه

شبکه‌های Overlay در داکر چگونه کار می‌کنند؛ نگاهی به VXLAN

شبکه‌های overlay امکان می‌دهند کانتینرهای روی هاست‌های مختلف طوری با هم ارتباط برقرار کنند که گویی یک شبکه مسطح مشترک دارند، و ستون فقرات بیشتر اپلیکیشن‌های میکروسرویس ابرمحور را تشکیل می‌دهند. این مقاله نحوه ساخت، رمزنگاری و تست یک شبکه overlay داکر روی یک کلاستر Swarm را بررسی کرده و فناوری تونل‌زنی VXLAN پشت آن را توضیح می‌دهد.

ادامه

اتصال کانتینرهای داکر به VLAN و توزیع بار با Swarm

فراتر از شبکه‌های ساده bridge، داکر امکاناتی برای اتصال مستقیم کانتینرها به VLANهای فیزیکی موجود، تفکیک خودکار نام سرویس‌ها و توزیع ترافیک در سراسر یک کلاستر Swarm ارائه می‌دهد. این مقاله درایور macvlan، سرویس داخلی Service Discovery و مکانیزم Ingress Load Balancing در Swarm را بررسی می‌کند.

ادامه

شبکه‌سازی در داکر؛ آشنایی با CNM، Libnetwork و شبکه‌های Bridge

شبکه‌سازی در داکر بر پایه یک طراحی باز به نام Container Network Model ساخته شده که توسط libnetwork پیاده‌سازی و با درایورهای قابل‌جایگزینی گسترش می‌یابد. این مقاله تئوری پشت شبکه داکر را بررسی کرده و نحوه ساخت و تست شبکه‌های bridge تک‌هاست، از جمله تفکیک نام و نگاشت پورت را توضیح می‌دهد.

ادامه

استقرار و مدیریت کلاستر چندنودی با Docker Swarm

Docker Swarm گروهی از نودهای داکر را به یک کلاستر امن و بسیار در دسترس با قابلیت ارکستریشن داخلی تبدیل می‌کند. این مقاله ساخت یک swarm چندنودی، استقرار یک اپلیکیشن میکروسرویس به‌صورت اعلانی و انجام به‌روزرسانی‌های تدریجی بدون از دست دادن سازگاری با وضعیت مطلوب را بررسی می‌کند.

ادامه