عنوان:

‫اجرای کانتینرها در WSL با استفاده از #C: بررسی عمیق ابزار wslc و SDK نیتیو مایکروسافت


نویسنده: وحید نصیری
تاریخ: ۱۴۰۵/۰۴/۱۵ ۰۹:۴۵
آدرس: www.dntips.ir
مایکروسافت در جریان کنفرانس Build 2026، از قابلیت هیجان‌انگیز و بومی WSL Containers پرده برداشت. این ویژگی به توسعه‌دهندگان اجازه می‌دهد کانتینرهای لینوکسی (OCI) را به‌طور مستقیم، بدون نیاز به ابزارهای شخص ثالث مانند Docker Desktop، بر روی ویندوز و از طریق سیستم‌عامل فرعی ویندوز برای لینوکس (WSL) مدیریت و اجرا کنند.
این معماری جدید علاوه بر معرفی یک رابط خط فرمان (CLI) جدید به نام wslc، مجموعه‌ای از SDKها را برای زبان‌های C++ ،C و به‌ویژه #C ارائه داده است. در این مقاله، ابتدا به بررسی این ابزار خط فرمان پرداخته و سپس نحوه مدیریت کانتینرها را از درون کدهای دات‌نت بررسی می‌کنیم.

۱. پیش‌نیازها و راه‌اندازی اولیه
در حال حاضر این قابلیت در فاز پیش‌انتشار (Public Preview) قرار دارد. برای استفاده از آن، ابتدا باید WSL سیستم خود را به آخرین نسخه پیش‌انتشار به‌روزرسانی کنید.
خط فرمان (PowerShell یا CMD) خود را با دسترسی Administrator باز کرده و دستور زیر را اجرا کنید:
wsl --update --pre-release
پس از اتمام به‌روزرسانی، مطمئن شوید که نسخه WSL شما 2.9.3.0 یا بالاتر باشد:
wsl --version
خروجی باید چیزی مشابه زیر باشد:
WSL version: 2.9.3.0
Kernel version: 6.18.35.2-1

۲. آشنایی با wslc CLI: جایگزینی سبک برای کانتینرها
پس از ارتقا، ابزار خط فرمان جدیدی به نام wslc.exe (که به صورت پیش‌فرض با نام مستعار container.exe نیز در دسترس است) به محیط شما اضافه می‌شود. ساختار دستورات این CLI شباهت بسیاری به داکر دارد و کار با آن بسیار سرراست است.
به عنوان مثال، چند نمونه از دستورات پرکاربرد:
# دریافت یک ایمیج از داکر هاب
wslc pull alpine:latest

# اجرای یک دستور درون کانتینر و دریافت خروجی
wslc run alpine:latest cat /etc/alpine-release

# مشاهده لیست ایمیج‌های دانلود شده
wslc images

# مشاهده کانتینرهای فعال
wslc list
نکته: شما حتی می‌توانید سناریوهای پیچیده‌تر، مانند اجرای یک دسکتاپ کامل لینوکس یا اجرای پردازش‌های سنگین یادگیری ماشین متصل به GPU را با wslc انجام دهید:
wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime python -c "import torch; print(torch.cuda.is_available())"

۳. معماری زیرساخت: چه چیزی در پشت صحنه تغییر کرده است؟
مایکروسافت برای افزایش کارایی کانتینرها در WSL، بهبودهای بنیادینی در سطح هسته و سیستم‌عامل اعمال کرده است که شناخت آن‌ها خالی از لطف نیست:
  • فایل‌سیستم virtiofs: این فایل‌سیستم جدید سرعت دسترسی و تبادل فایل بین ویندوز و کانتینر را تا ۲ برابر افزایش می‌دهد.
  • شبکه‌سازی پیشرفته (consomme): این حالت شبکه تجربی، ترافیک لینوکس را مستقیماً از لایه‌های ویندوز عبور می‌دهد. این کار مشکل همیشگی توسعه‌دهندگان با کانتینرها در محیط‌های سازمانی (مانند قطع شدن ارتباط به دلیل تغییرات VPN یا سیستم‌های پروکسی) را کاملاً برطرف می‌کند.
  • مکانیزم بهینه مدیریت حافظه (Memory Reclaim): برخلاف گذشته که WSL بخش زیادی از رم را اشغال نگه می‌داشت، در معماری جدید به محض کاهش مصرف کانتینر، حافظه RAM به سرعت و به صورت پویا به سیستم‌عامل میزبان (ویندوز) بازگردانده می‌شود.

۴. مدیریت برنامه‌نویسی کانتینرها با Microsoft.WSL.Containers SDK
یکی از جذاب‌ترین بخش‌های این به‌روزرسانی، امکان کنترل کامل چرخه حیات کانتینرها از درون کدهای #C است. برای این کار یک پکیج نیوگت (NuGet) رسمی ارائه شده است.

تنظیمات فایل پروژه (.csproj)
نکته بسیار مهمی که باید به آن توجه کنید این است که این پکیج از مکانیسم C#/WinRT Projection استفاده می‌کند. در نتیجه، پروژه دات‌نت شما باید حتماً پلتفرم هدف (Target Framework) خود را نسخه‌های ویندوزی مشخص کند. استفاده از پلتفرم خام مانند net11.0 خطا ایجاد خواهد کرد.
پیکربندی نمونه برای یک پروژه .NET 11:
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net11.0-windows10.0.19041.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.WSL.Containers" Version="2.9.3" />
  </ItemGroup>

</Project>

نمونه کد پیاده‌سازی
کد زیر نحوه ایجاد یک نشست (Session) ایزوله، دانلود ایمیج، نمونه‌سازی از کانتینر و اجرای یک دستور را نشان می‌دهد:
using Microsoft.WSL.Containers;

const string imageName = "alpine:latest";
var storagePath = Path.Combine(AppContext.BaseDirectory, "WslcStorage");

// ۱. ایجاد و شروع یک Session (یک ماشین مجازی سبک و ایزوله اختصاصی)
Console.WriteLine("[wslc] Starting session...");
using var session = new Session(new SessionSettings("DotNetUpSession", storagePath));
session.Start();

// ۲. دانلود ایمیج درون خطی به داخل این Session
Console.WriteLine("[wslc] Pulling image...");
session.PullImage(new PullImageOptions(imageName));

// ۳. پیکربندی و ساخت کانتینر
using Container container = session.CreateContainer(new ContainerSettings(imageName)
{
    InitProcess = new ProcessSettings { CommandLine = ["/bin/sleep", "infinity"] },
    EnableAutoRemove = true,
});

// ۴. استارت کانتینر
container.Start();

// ۵. اجرای یک دستور و خواندن خروجی از Standard Output به صورت رویدادمحور
using var waitHandle = new ManualResetEventSlim();
using Stream stdout = Console.OpenStandardOutput();

using Process process = container.CreateProcess(new ProcessSettings
{
    CommandLine = [
        "/bin/sh",
        "-c",
        "echo \"Hello from a WSL container running Alpine $(cat /etc/alpine-release)\""
    ],
    OutputMode = ProcessOutputMode.Event,
});

process.OutputReceived += data => stdout.Write(data, 0, data.Length);
process.Exited += _ => waitHandle.Set();

process.Start();
waitHandle.Wait(); // منتظر ماندن تا پایان اجرای دستور درون کانتینر

// ۶. پایان دادن به کار Session و آزادسازی منابع
Console.WriteLine("\n[wslc] Terminating session...");
session.Terminate();
Console.WriteLine("[wslc] Done.");

یک نکته معماری مهم درباره ایزولاسیون (Isolation)
محیطی که شما از طریق کد و با ساخت یک Session ایجاد می‌کنید، کاملاً جدا و مستقل از کانتینرهایی است که به صورت عمومی در wslc CLI سیستم مشاهده می‌کنید.
اگر تمایل دارید کانتینرها یا ایمیج‌های ساخته شده توسط کد دات‌نتی خود را از طریق خط فرمان ویندوز بررسی یا دیباگ کنید، باید نام سشن خود را به ساختار دستور پاس دهید:
wslc --session DotNetUpSession images
wslc --session DotNetUpSession container list

۵. قابلیت‌های سازمانی و توسعه تیمی
مایکروسافت این ویژگی را صرفاً برای استفاده‌های شخصی طراحی نکرده، بلکه هماهنگی کاملی با ابزارهای سازمانی به وجود آورده است:
  • مدیریت امنیت با Microsoft Defender for Endpoint (MDE): افزونه MDE در ویندوز اکنون تمام رویدادهای امنیتی درون این کانتینرها را مانیتور می‌کند.
  • اعمال سیاست با اینتون (Intune / GPO): مدیران شبکه می‌توانند استفاده از کانتینرهای WSL را محدود کرده یا یک لیست مجاز (Allowlist) از رجیستری‌های معتبر (مانند کانتینر رجیستری اختصاصی شرکت در Azure یا GitHub) تعریف کنند تا توسعه‌دهندگان نتوانند ایمیج‌های غیرمجاز را دانلود کنند.
  • پشتیبانی در VS Code Dev Containers: از نسخه 0.462.0-pre-release افزونه Dev Containers در VS Code، شما می‌توانید با تغییر تنظیمات Docker Path به wslc، محیط‌های توسعه ایزوله خود را مستقیماً روی کانتینرهای نیتیو ویندوز بالا بیاورید.

نتیجه‌گیری
آیا کانتینرهای بومی WSL قرار است به این زودی‌ها جایگزین داکر دسکتاپ شوند؟ پاسخ قطعاً منفی است. داکر دسکتاپ اکوسیستم بسیار وسیع‌تر و ابزارهای مدیریت بصری پیشرفته‌تری دارد. با این حال، معرفی wslc و SDK بومی دات‌نت، یک گزینه فوق‌العاده سبک، سریع و ادغام‌شده با سیستم‌عامل را در اختیار ما قرار می‌دهد. این ابزار کارایی بالایی در سناریوهایی نظیر خودکارسازی تست‌های نرم‌افزاری (Integration Tests)، اجرای خطوط لوله CI/CD محلی، یا توسعه ابزارهایی دارد که نیاز دارند به صورت برنامه‌نویسی‌شده فرآیندهای لینوکسی را در محیطی امن و ایزوله روی ویندوز اجرا کنند.

نظرات

  • مجید شهاب فر در ۱۴۰۵/۰۴/۲۰ ۰۰:۲۱
    آیا همچنان همه اینها در محیط توسعه استفاده می شوند؟
    مثلا در یک محیط Production آن هم بر روی یک سرور ویندوزی می توان از آن استفاده کرد؟
    • وحید نصیری در ۱۴۰۵/۰۴/۲۰ ۰۷:۵۴
      پاسخ کوتاه این است: بله، از نظر فنی می‌توانید از WSL Containers و SDK آن در محیط Production روی ویندوز سرور استفاده کنید، اما این کار با محدودیت‌ها و ملاحظات معماری مهمی همراه است که باید پیش از تصمیم‌گیری به آن‌ها توجه کنید:

      ۱. پشتیبانی در ویندوز سرور (Windows Server)
      از آنجا که این قابلیت بر پایه لایه‌های مدرن WSL (نسخه ۲) بنا شده است، برای استفاده از آن در Production، سرور شما باید از نسخه‌های جدیدتر ویندوز سرور (مانند Windows Server 2022 یا Windows Server 2025 با آخرین آپدیت‌ها) استفاده کند که از معماری کامل WSL 2 پشتیبانی می‌کنند. از آنجا که این ویژگی فعلاً در وضعیت Preview (پیش-انتشار) است، مایکروسافت آن را برای محیط‌های حیاتی (Mission-Critical) توصیه نمی‌کند تا زمانی که به وضعیت GA (عرضه عمومی) برسد.
      ۲
      . مقایسه معماری: چرا از کانتینرهای نیتیو ویندوز یا لینوکس استفاده نکنیم؟
      در یک محیط لینوکسی، کانتینرها مستقیماً روی هسته (Kernel) سیستم‌عامل اجرا می‌شوند و هیچ لایه اضافه‌ای وجود ندارد. اما در یک سرور ویندوزی، برای اجرای کانتینر لینوکس سه راهکار وجود دارد:
      • راهکار سنتی داکر (Docker EE / Mirantis): که عمدتاً برای اجرای کانتینرهای خودِ ویندوز (Windows Containers) مناسب است.
      • یک ماشین مجازی لینوکس مجزا (Hyper-V VM): که داکر یا ابزارهای دیگر روی آن نصب شده‌اند.
      • معماری جدید WSL Containers: که مایکروسافت ارائه داده است.
      مزیت بزرگ روش سوم (WSL) در محیط Production سرورهای ویندوزی، سبک بودن فوق‌العاده و مدیریت خودکار منابع است. به لطف قابلیت‌هایی مانند شبکه‌سازی consomme و سیستم مدیریت حافظه جدید، این کانتینرها سربار بسیار کمتری نسبت به یک ماشین مجازی کامل Hyper-V دارند.

      ۳. سناریوهای طلایی برای استفاده در Production روی ویندوز
      در چه مواردی استفاده از این فناوری در محیط عملیاتی (Production) ویندوز منطقی و بسیار کاربردی است؟
      • ادغام کدهای قدیمی و جدید (Legacy Integration): فرض کنید یک اپلیکیشن بزرگ سازمانی دارید که با دات‌نت فریم‌ورک قدیمی (مثلاً .NET Framework 4.8) نوشته شده و حتماً باید روی ویندوز سرور اجرا شود. حالا می‌خواهید یک سرویس جدید هوش مصنوعی یا پردازش تصویر لینوکسی (که فقط پایتون و لینوکس را پشتیبانی می‌کند) به آن اضافه کنید. با استفاده از این SDK، اپلیکیشن ویندوزی شما می‌تواند به صورت برنامه‌نویسی‌شده، آن پردازشگر لینوکسی را در یک کانتینر WSL در پشت صحنه مدیریت، اجرا و متوقف کند.
      • ابزارهای مانیتورینگ و خطوط لوله (Internal Tools & Pipelines): اگر روی سرور ویندوزی خود ابزارهای اتوماسیون داخلی یا سرویس‌های خط لوله (مثل رانرهای CI/CD) دارید، این ابزار یک جایگزین فوق‌العاده سریع و سبک برای اجرای جاب‌های لینوکسی است.
      • سرویس‌های ایزوله‌شده محلی (Micro-Services Architecture): برای سناریوهایی که نیاز دارید بخش‌هایی از پردازش برنامه دات‌نت خود را به دلایل امنیتی یا محدودیت منابع، در یک محیط کاملاً ایزوله (Sandbox) لینوکسی پیش ببرید.

      ۴. چالش‌ها و محدودیت‌ها در محیط Production
      اگر قصد دارید یک وب‌سایت با ترافیک بسیار بالا (High-Traffic Web Application) را به صورت کانتینری در Production بالا بیاورید، کانتینرهای WSL بهترین انتخاب نیستند. دلایل آن عبارتند از:
      • عدم هماهنگی با ارکستراتورها: ابزارهای مدیریت کانتینر در مقیاس بزرگ مانند کوبرنتیز (Kubernetes) یا Swarm به صورت نیتیو با wslc سازگار نیستند. برای کارهای بزرگ سازمانی، کوبرنتیز روی سرورهای لینوکس خام (Bare-metal) همچنان استاندارد اول دنیاست.
      • مایگریشن و جابجایی کانتینرها: پکیج‌های استاندارد داکر به راحتی جابجا می‌شوند، اما پکیج Microsoft.WSL.Containers وابستگی شدیدی به سیستم‌عامل میزبان (ویندوز و سشن‌های WSL آن) دارد که پورت‌پذیری (Portability) برنامه شما را محدود می‌کند.

      نتیجه‌گیری نهایی
      این فناوری صرفاً یک ابزار محیط توسعه نیست و پتانسیل بالایی برای محیط Production دارد؛ اما نه به عنوان بستری برای هاست کردن کانتینرهای عمومی وب‌سایت‌ها، بلکه بیشتر به عنوان یک پل ارتباطی قدرتمند و نیتیو (Native Bridge) برای برنامه‌نویسان دات‌نت تا بتوانند قدرت لینوکس و کانتینرها را مستقیماً از داخل کدهای #C در سرورهای ویندوزی به خدمت بگیرند.