آخرین نوشته‌ها
کارگاه توسعه‌ی ایزوله‌ای که Canonical برای برنامه‌نویس‌ها ساخته
با Workshop، ابزار جدید Canonical، آشنا بشید؛ راهی برای ساخت محیط‌های توسعه‌ی ایزوله که مدیریت وابستگی‌ها و اجرای امن‌تر ابزارهای برنامه‌نویسی و هوش مصنوعی رو ساده‌تر می‌کنه.
Workshop؛ کارگاه توسعه‌ی ایزوله‌ای که Canonical برای برنامه‌نویس‌ها ساخته
وقتی روی چند پروژه‌ی مختلف کار می‌کنی، دیر یا زود با یه مشکل آشنا روبه‌رو می‌شی: هر پروژه به نسخه‌ی خاصی از زبان برنامه‌نویسی، یه سری کتابخونه و ابزارهای متفاوت نیاز داره. از طرفی، ممکنه بخوای ابزارهای هوش مصنوعی رو هم وارد فرایند توسعه کنی، بدون اینکه دسترسی نامحدودی به فایل‌های شخصی و سیستم اصلیت داشته باشن.
برای حل چنین مشکلاتی، راهکارهای مختلفی وجود داره؛ از venv و Docker گرفته تا ماشین‌های مجازی. اما Canonical، شرکتی که اوبونتو رو توسعه می‌ده، ابزاری به نام Workshop معرفی کرده که هدفش ساده‌تر کردن ساخت و مدیریت محیط‌های توسعه‌ی ایزوله هست.
ایده‌ی اصلی ساده‌ست: به‌جای اینکه برای هر پروژه دستی محیط توسعه بسازی و نگران وابستگی‌ها و دسترسی‌ها باشی، محیط موردنیازت رو تعریف می‌کنی و Workshop مدیریت بخش مهمی از این فرایند رو برات انجام می‌ده.
اما این ابزار دقیقا چیه، چطور کار می‌کنه و چه تفاوتی با Docker داره؟ بیایم قدم‌به‌قدم بررسیش کنیم.
مشکل از کجا شروع می‌شه؟
فرض کن سه پروژه داری: یکی با Django، یکی با Rust و یکی هم برای کار با مدل‌های هوش مصنوعی محلی.
پروژه‌ی Django به نسخه‌ی مشخصی از Python و تعدادی کتابخونه نیاز داره. پروژه‌ی Rust ابزارهای کامپایل خودش رو می‌خواد و پروژه‌ی هوش مصنوعی هم ممکنه به Ollama، درایور GPU و کتابخونه‌های مربوط به CUDA نیاز داشته باشه.
می‌تونی برای هرکدوم از این پروژه‌ها ابزارهای لازم رو روی سیستم اصلی نصب کنی، اما با بزرگ‌تر شدن پروژه‌ها، مدیریت نسخه‌ها و وابستگی‌ها سخت‌تر می‌شه. تازه اگر بخوای پروژه رو روی سیستم دیگه‌ای اجرا کنی، باید دوباره همه‌چیز رو تنظیم کنی.
از طرف دیگه، ابزارهای هوش مصنوعی که می‌تونن کد بنویسن، دستور اجرا کنن و فایل‌ها رو تغییر بدن، مسئله‌ی امنیت رو هم جدی‌تر می‌کنن. اگر چنین ابزاری به کل سیستم دسترسی داشته باشه، اشتباه یا دستور مخربش می‌تونه به فایل‌های خارج از پروژه هم آسیب بزنه.
Workshop برای مدیریت همین مجموعه از مشکلات طراحی شده: محیط توسعه رو از سیستم اصلی جدا می‌کنه، وابستگی‌ها رو به شکل مشخص تعریف می‌کنه و اجازه می‌ده همون محیط رو دوباره بسازی.
Workshop دقیقا چیه؟
پیش نمایش ابزار Workshop
Workshop یه ابزار متن‌باز از Canonical هست که در ۲۷ مه ۲۰۲۶ معرفی شد. این ابزار به برنامه‌نویس‌ها اجازه می‌ده محیط‌های توسعه‌ی ایزوله و قابل‌بازتولید بسازن و اون‌ها رو از طریق خط فرمان مدیریت کنن.
محیط‌های Workshop داخل System Containerهای مدیریت‌شده با LXD اجرا می‌شن. این کانتینرها برخلاف کانتینرهای ساده‌ی اجرای یک اپلیکیشن، محیطی شبیه یه سیستم لینوکسی کوچک دارن که می‌تونه کاربر، بسته‌های نرم‌افزاری، شبکه و سرویس‌های سیستمی خودش رو داشته باشه.
البته این محیط ماشین مجازی کامل نیست؛ کانتینرهای سیستمی LXD به‌طور معمول کرنل سیستم میزبان رو با اون به اشتراک می‌ذارن. بنابراین، Workshop می‌تونه محیطی جدا برای توسعه فراهم کنه، بدون اینکه برای هر پروژه به یک ماشین مجازی کامل نیاز داشته باشی.
نکته‌ی مهم اینه که Workshop صرفا یه اسکریپت نصب وابستگی‌ها نیست. هدفش مدیریت چرخه‌ی عمر محیط توسعه هم هست؛ از ساخت اولیه و نصب ابزارها گرفته تا به‌روزرسانی، اجرا، توقف و بازگردانی محیط به وضعیت قبلی.
SDK؛ قطعه‌های سازنده‌ی محیط توسعه
یکی از مفاهیم اصلی Workshop، چیزی به نام SDK هست.
اینجا منظور از SDK لزوما همون Software Development Kit سنتی نیست. در Workshop، SDK یک بسته‌ی مستقل از قابلیت‌ها و ابزارهاست که می‌تونه زبان برنامه‌نویسی، فریم‌ورک، کتابخونه یا ابزار موردنیاز محیط رو فراهم کنه.
برای مثال، به‌جای اینکه خودت تمام مراحل نصب و تنظیم Ollama رو از صفر انجام بدی، می‌تونی SDK مربوط به اون رو به محیطت اضافه کنی. همین ایده برای ابزارهایی مثل OpenCode و مجموعه‌ابزارهای محاسباتی NVIDIA CUDA و AMD ROCm هم کاربرد داره.
Workshop Definition
تعریف محیط و انتخاب SDKها
زبان و ابزارها Python، Go و ابزارهای ساخت ابزارهای AI Ollama و OpenCode شتاب‌دهنده‌ها CUDA و ROCm، در صورت نیاز دسترسی‌ها فایل‌ها، دستگاه‌ها و سرویس‌ها محیط توسعه‌ی آماده قابل اجرا، مدیریت و بازسازی این SDKها می‌تونن از طریق فروشگاه SDK یا مخزن اختصاصی یک تیم در دسترس قرار بگیرن. همچنین می‌شه SDKهای اختصاصی ساخت و تنظیماتشون رو کنار کد پروژه نگه داشت.
مزیت چنین رویکردی اینه که لازم نیست هر بار تمام محیط رو از ابتدا تعریف کنی؛ می‌تونی از قطعه‌های آماده استفاده کنی و فقط اجزای موردنیازت رو کنار هم قرار بدی.
چرا فایل YAML اهمیت داره؟
Workshop محیط توسعه رو با یک فایل متنی از نوع YAML تعریف می‌کنه. این فایل مشخص می‌کنه محیط چه نامی داشته باشه، از چه سیستم پایه‌ای استفاده کنه و کدوم SDKها در اون نصب بشن.
برای نمونه، در مستندات رسمی پروژه یک محیط توسعه برای Ollama به این شکل تعریف شده:
فایل yaml برای golang در workshop
این تنظیمات می‌گه محیطی به نام dev ساخته بشه، از پایه‌ی Ubuntu 22.04 استفاده کنه و SDK مربوط به Ollama رو از کانال cpu/stable دریافت کنه. در این مثال، کانال CPU برای اجرای Ollama بدون نیاز به GPU انتخاب شده.
این نمونه برای توضیح ساختار فایل هست؛ اگر بخوای محیطی برای پروژه‌ی واقعی خودت بسازی، باید SDKها و کانال‌های موجود رو در فروشگاه بررسی کنی و نسخه‌ی مناسب رو انتخاب کنی.
تعریف محیط چه فایده‌ای داره؟
فرض کن همین پروژه رو به یکی از اعضای تیمت می‌دی. اگر تعریف Workshop و SDKهای موردنیاز همراه پروژه باشن، اون شخص لازم نیست تمام مراحل نصب و تنظیم رو از روی توضیحات پراکنده انجام بده.
می‌تونه تعریف محیط رو دریافت کنه و با Workshop همون محیط رو بسازه. به این ترتیب، احتمال اینکه دو نفر به خاطر تفاوت نسخه‌ی ابزارها با مشکلات متفاوتی روبه‌رو بشن کمتر می‌شه.
این موضوع برای CI هم کاربرد داره؛ یعنی همون محیطی که برای توسعه استفاده می‌کنی، می‌تونه در فرایندهای خودکار ساخت و آزمایش پروژه هم به کار گرفته بشه. البته این به معنی یکسان بودن کامل محیط توسعه و محیط نهایی اجرا نیست؛ اون بخش همچنان به تنظیمات پروژه و فرایند استقرار بستگی داره.
کار با Workshop از خط فرمان
یکی از ویژگی‌های Workshop اینه که کارهای اصلی رو می‌تونی از ترمینال انجام بدی. بیایم با یک نمونه‌ی ساده ببینیم روند کار چطوریه.
۱. نصب پیش‌نیازها
Workshop برای مدیریت محیط‌ها به LXD نسخه‌ی 6.8 یا جدیدتر نیاز داره. طبق روش پیشنهادی Canonical، نصب از طریق Snap انجام می‌شه:
sudo snap install --channel=6/stable lxd
sudo snap install --classic workshop
دستور اول LXD رو نصب می‌کنه و دستور دوم Workshop رو.
اگر LXD از قبل نصب شده، باید نسخه و وضعیت سرویسش رو بررسی کنی و در صورت نیاز اون رو به نسخه‌ی سازگار ارتقا بدی. همچنین لازمه سرویس LXD به‌درستی راه‌اندازی شده باشه.
۲. ساخت یک پروژه
فرض کنیم می‌خوای یک محیط برای توسعه‌ی API با Go بسازی. ابتدا پوشه‌ی پروژه رو ایجاد کن:
mkdir api
cd api
git init
بعد می‌تونی از دستور workshop init برای ساخت تعریف اولیه‌ی محیط استفاده کنی:
workshop init dev --sdks go/1.25/stable
در این مثال، dev نام محیط و go/1.25/stable SDK و کانال موردنظر هست. نسخه‌ی Go در این دستور صرفا نمونه‌ای از نحوه‌ی انتخاب SDK محسوب می‌شه؛ قبل از استفاده باید موجود بودن همین کانال رو در فروشگاه بررسی کنی.
Workshop تعریف محیط رو در مسیر زیر ایجاد می‌کنه:
api/
├── .git/
└── .workshop/
└── dev.yaml
فایل dev.yaml تنظیمات محیط رو نگه می‌داره و می‌تونی اون رو همراه پروژه در Git ثبت کنی.
۳. ساخت و اجرای محیط
بعد از آماده شدن تعریف محیط، دستور زیر رو اجرا کن:
workshop launch
این دستور محیط رو ایجاد و راه‌اندازی می‌کنه و وابستگی‌های موردنیاز رو دریافت می‌کنه. اولین اجرا ممکنه بسته به اندازه‌ی SDKها، سرعت اینترنت و وضعیت سیستم زمان‌بر باشه.
برای بررسی وضعیت محیط می‌تونی از این دستورها استفاده کنی:
workshop list
workshop info
اولی محیط‌های تعریف‌شده و وضعیتشون رو نشون می‌ده و دومی اطلاعات محیط جاری، از جمله SDKهای نصب‌شده رو نمایش می‌ده.
۴. ورود به محیط و اجرای دستورها
وقتی محیط آماده شد، برای باز کردن یک شل تعاملی می‌تونی اجرا کنی:
workshop shell
از اینجا به بعد، داخل محیط توسعه قرار داری و می‌تونی دستورهای موردنیازت رو اجرا کنی.
اگر فقط می‌خوای یک دستور رو اجرا کنی، نیازی نیست وارد شل بشی:
workshop exec dev -- go version
این دستور نسخه‌ی Go موجود در محیط dev رو نمایش می‌ده.
برای خروج از شل هم کافیه دستور exit رو اجرا کنی.
۵. توقف، شروع مجدد و به‌روزرسانی
لازم نیست محیط توسعه همیشه در حال اجرا باشه. وقتی کارت تموم شد، می‌تونی متوقفش کنی:
workshop stop
و هر زمان دوباره بهش نیاز داشتی، اجراش کنی:
workshop start
تفاوت مهمی بین این دستورها و ساخت مجدد محیط وجود داره. stop فقط اجرای محیط رو متوقف می‌کنه و start همون محیط موجود رو دوباره راه می‌اندازه.
اگر تعریف محیط رو تغییر دادی، مثلا SDK جدیدی اضافه کردی یا کانال یک SDK رو عوض کردی، باید تغییرات رو اعمال کنی:
workshop refresh
یکی از قابلیت‌های جالب Workshop اینه که تغییرات محیط رو به‌صورت مرحله‌ای مدیریت می‌کنه. اگر فرایند به‌روزرسانی شکست بخوره، امکان بازگردانی به وضعیت پایدار قبلی وجود داره. همچنین دستور workshop restore برای بازگرداندن محیط به آخرین وضعیت ذخیره‌شده‌ی موفق به کار می‌ره؛ بنابراین نباید اون رو بدون توجه به تغییراتت اجرا کنی.
بخش مهم ماجرا: امنیت و محیط‌های ایزوله
تا اینجا شاید Workshop شبیه ابزاری برای ساخت کانتینر به نظر برسه، اما یکی از دلایل مهم توسعه‌ی اون، کنترل دسترسی محیط‌های توسعه هست.
وقتی یک برنامه رو در محیط Workshop اجرا می‌کنی، قرار نیست به‌صورت پیش‌فرض تمام منابع سیستم میزبان در اختیارش قرار بگیره. محیط‌ها با کانتینرهای سیستمی غیرممتاز LXD اجرا می‌شن و برای دسترسی به منابع خاص، از سازوکار رابط‌ها یا Interfaces استفاده می‌کنن.
برای مثال، ممکنه یک محیط به این موارد نیاز داشته باشه:
-
دسترسی به پوشه‌ی پروژه برای خواندن و تغییر کدها
-
دسترسی به شبکه برای دریافت وابستگی‌ها یا ارتباط با سرویس‌ها
-
دسترسی به GPU برای اجرای مدل‌های هوش مصنوعی
-
دسترسی به SSH Agent برای احراز هویت در مخازن Git
-
دسترسی به محیط گرافیکی میزبان برای اجرای بعضی برنامه‌ها
Workshop این دسترسی‌ها رو به شکل ساختاریافته مدیریت می‌کنه. به‌جای اینکه همه‌ی منابع رو بدون محدودیت در اختیار محیط قرار بدی، می‌تونی فقط دسترسی‌های لازم رو تعریف کنی. البته جزئیات هر دسترسی به SDK، رابط مورد استفاده و تنظیمات محیط بستگی داره.
چرا این موضوع برای ابزارهای هوش مصنوعی مهمه؟
فرض کن از یک عامل هوش مصنوعی برای توسعه‌ی پروژه استفاده می‌کنی. این عامل می‌تونه کد بنویسه، دستورهای ترمینال اجرا کنه و فایل‌ها رو تغییر بده. اگر ابزار موردنظر دسترسی گسترده‌ای داشته باشه، یک اشتباه ساده ممکنه باعث حذف فایل‌های مهم یا تغییر تنظیمات خارج از پروژه بشه.
با قرار دادن ابزار در یک محیط محدودشده، می‌تونی دامنه‌ی دسترسی اون رو کاهش بدی. برای نمونه، می‌تونی محیطی تعریف کنی که ابزارهای لازم برای توسعه رو داشته باشه، اما دسترسی مستقیم به بعضی منابع میزبان به اون داده نشده باشه.
این دقیقا یکی از کاربردهای موردتوجه Canonical برای Workshop هست: فراهم کردن محیطی مناسب برای توسعه‌ی مبتنی بر عامل‌های هوش مصنوعی، بدون اینکه راحتی کار به معنی دسترسی نامحدود این ابزارها به سیستم باشه.
با این حال، باید یک نکته رو در نظر گرفت: کانتینر ایزوله به معنی امنیت صددرصدی نیست. کانتینرهای سیستمی کرنل میزبان رو به اشتراک می‌ذارن و اگر دسترسی‌های حساس رو در اختیار محیط قرار بدی، بخشی از محدودیت‌های امنیتی رو خودت کنار گذاشتی. بنابراین، Workshop یک لایه‌ی مهم برای کنترل دسترسیه، نه جایگزینی برای بررسی کدها و رعایت اصول امنیتی.
تفاوت Workshop با Docker، Dev Containers و ماشین مجازی
Workshop تنها ابزاری نیست که تلاش می‌کنه محیط توسعه رو قابل‌بازتولید کنه. ابزارهایی مثل Docker، Dev Containers و Nix هم در این حوزه کاربرد دارن؛ با این تفاوت که هرکدوم روی بخش متفاوتی از مسئله تمرکز می‌کنن.
| ابزار | تمرکز اصلی |
|---|---|
| Workshop | مدیریت محیط‌های توسعه‌ی ایزوله با SDKهای قابل‌ترکیب و کنترل دسترسی |
| Docker | ساخت و اجرای کانتینرها و بسته‌بندی سرویس‌ها و برنامه‌ها |
| Dev Containers | تعریف محیط توسعه برای استفاده در ادیتورهایی مثل VS Code |
| Nix | تعریف و بازتولید وابستگی‌ها و محیط‌های نرم‌افزاری با رویکردی مبتنی بر تعریف |
| ماشین مجازی | اجرای یک سیستم‌عامل مهمان با کرنل جدا از میزبان |
این ابزارها لزوما رقیب مستقیم هم نیستن. برای مثال، Docker همچنان انتخاب بسیار مناسبی برای بسته‌بندی یک اپلیکیشن و سرویس‌های موردنیازشه. Dev Containers هم برای تیم‌هایی که محیط توسعه‌شون رو در IDE تعریف می‌کنن، کاربرد زیادی داره.
Workshop بیشتر روی مدیریت یک محیط توسعه‌ی کامل، استفاده از SDKهای مستقل و کنترل دسترسی منابع میزبان تمرکز داره. به همین دلیل، مقایسه‌ی اون با Docker صرفا بر اساس این سؤال که «کدوم کانتینر می‌سازه؟» تصویر کاملی از تفاوتشون نمی‌ده.
آیا Workshop روی هر توزیع لینوکسی اجرا می‌شه؟
این سؤال برای کاربران لینوکس اهمیت زیادی داره، چون همه از اوبونتو استفاده نمی‌کنن.
طبق مستندات رسمی، Workshop روی اوبونتو و توزیع‌های لینوکسی دیگری که از Snap پشتیبانی می‌کنن قابل استفاده هست. همچنین با WSL2 سازگاری داره و در این حالت برای ذخیره‌سازی به‌جای ZFS از Btrfs استفاده می‌کنه.
اما وجود پشتیبانی از Snap به‌تنهایی به این معنی نیست که نصب روی تمام توزیع‌ها بدون مشکل انجام می‌شه. Workshop به LXD نسخه‌ی 6.8 یا جدیدتر و سرویس فعال اون نیاز داره؛ بنابراین باید سازگاری توزیع و روش نصب LXD رو هم بررسی کنی.
اگر از Fedora، Arch یا توزیع دیگری استفاده می‌کنی، بهتره قبل از نصب، راهنمای رسمی Workshop و مستندات LXD رو بخونی. در راهنمای LXD برای Fedora به بسته‌های COPR اشاره شده که غیررسمی هستن و ممکنه به اندازه‌ی روش‌های اصلی آزمایش نشده باشن.
پس اگر سیستم اصلیت Fedora KDE هست، بهتره صرفا به خاطر وجود دستور نصب Snap فرض نکنی که تمام اجزای موردنیاز بدون تنظیم اضافی کار می‌کنن.
چند نکته که قبل از استفاده باید بدونی
Workshop ابزار جالبیه، اما قرار نیست تمام مشکلات توسعه رو به‌صورت خودکار حل کنه.
اول، ساخت محیط اولیه ممکنه زمان‌بر باشه. دریافت ایمیج پایه و SDKهای بزرگ، به‌خصوص ابزارهای هوش مصنوعی، می‌تونه فضای دیسک و اینترنت قابل‌توجهی مصرف کنه.
دوم، تعریف محیط باید نگهداری بشه. اگر از SDKها و کانال‌هایی استفاده کنی که در آینده تغییر می‌کنن، لازم می‌شه وضعیت نسخه‌ها و سازگاری وابستگی‌ها رو بررسی کنی. قابل‌بازتولید بودن به معنی ثابت ماندن همیشگی همه‌ی اجزا نیست؛ انتخاب نسخه‌ها و کانال‌ها اهمیت داره.
سوم، همه‌چیز به‌صورت خودکار در دسترس نیست. اگر پروژه به GPU، دستگاه خاص، سرویس شبکه یا محیط گرافیکی نیاز داشته باشه، ممکنه لازم باشه رابط مناسب رو پیکربندی کنی.
چهارم، محیط توسعه با محیط استقرار یکی نیست. اینکه پروژه داخل Workshop اجرا می‌شه، تضمین نمی‌کنه که روی سرور نهایی هم دقیقا به همان شکل اجرا بشه. برای استقرار همچنان باید به وابستگی‌ها، تنظیمات، سرویس‌ها و زیرساخت مقصد توجه کنی.
در نهایت، ارزش Workshop زمانی بیشتر مشخص می‌شه که محیط توسعه پیچیده باشه، چند نفر روی پروژه کار کنن یا بخوای ابزارهای قدرتمند رو با دسترسی‌های محدود اجرا کنی. برای پروژه‌های ساده، شاید یک محیط مجازی Python یا ابزارهای معمول موجود کاملا کافی باشن.
از کجا شروع کنیم؟
اگر می‌خوای Workshop رو امتحان کنی، بهترین نقطه‌ی شروع مستندات رسمی خود پروژه هست. راهنمای گام‌به‌گام اون، از نصب و تعریف محیط گرفته تا اجرای دستورها و مدیریت SDKها رو توضیح می‌ده.
حرف آخر
Workshop قرار نیست برنامه‌نویسی رو از نو تعریف کنه؛ هدفش اینه که بخش خسته‌کننده‌ی آماده‌سازی و نگهداری محیط توسعه رو ساده‌تر و قابل‌اعتمادتر کنه.
اگر فقط یک پروژه‌ی کوچک داری، احتمالا نیازی به ابزار جدیدی نداری. اما وقتی چند زبان، SDKهای مختلف، ابزارهای هوش مصنوعی و نیاز به کنترل دسترسی وارد ماجرا می‌شن، داشتن محیط‌هایی که بشه اون‌ها رو دقیق تعریف کرد، دوباره ساخت و با خیال راحت‌تری مدیریت کرد، ارزش خودش رو نشون می‌ده.
به‌نظرم مهم‌ترین ایده‌ی Workshop اینه که محیط توسعه هم باید بخشی از پروژه باشه، نه مجموعه‌ای از تنظیمات فراموش‌شده روی کامپیوتر برنامه‌نویس.
گفتگو درباره‌ی این مقاله
پرسش، تجربه یا دیدگاه خود را با دیگران به اشتراک بگذارید.
به گفتگو بپیوندید
برای ارسال دیدگاه وارد حساب کاربری خود شوید.
اولین دیدگاه را شما بنویسید
هنوز دیدگاهی برای این مقاله منتشر نشده است.