پروژه بلوفین و آینده سیستم عامل ها

یک پروژه لینوکس دسکتاپ نسبتا مبهم به آینده سیستم عامل کانتینری اشاره دارد که برای محاسبات سازمانی کاملاً منطقی است.

حتی با وجود همه پیشرفت‌ها در فناوری اطلاعات، خواه سخت‌افزار مدولار، منابع عظیم محاسبات ابری یا دستگاه‌های لبه‌ای با ضریب فرم کوچک، فناوری اطلاعات همچنان مشکل مقیاس دارد. از نظر فیزیکی نه – اضافه کردن جعبه‌های بیشتر، فضای ذخیره‌سازی بیشتر و «موارد» بیشتر از این نظر آسان است. چالش مقیاس این است که عملیات شما مطابق با هدف در آن سطح کار کند، و با اطمینان از اینکه می توانید برنامه ها را به طور موثر و کارآمد در حین رشد بسازید، استقرار و نگهداری کنید، شروع می شود. این به این معنی است که بلوک اصلی devops، سیستم عامل، نیاز به مقیاس‌بندی سریع، هموار و یکپارچه دارد.

این را از قبل می گویم: این سخت است. خیلی سخت است.

اما ما ممکن است وارد عصر (دیگری) روشنگری برای سیستم عامل شده باشیم. من دیدم که آینده سیستم‌های عامل در مقیاس چه می‌تواند باشد، و با Project Bluefin شروع می‌شود. اما چگونه یک دسکتاپ جدید و نسبتا مبهم لینوکس پروژه مدل محاسباتی سازمانی بعدی را پیشگویی می کند؟ سه کلمه: سیستم عامل کانتینری.

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

Project Bluefin چیست؟

ظرف‌های لینوکس وقتی نوبت به توسعه بومی ابری و استقرار برنامه‌های ابری ترکیبی می‌رسید، بازی را تغییر دادند و اکنون این فناوری آماده است تا همین کار را با سیستم‌عامل‌های سازمانی انجام دهد. برای روشن بودن، پروژه محصول شرکتی نیست این یک پلتفرم دسکتاپ است که تا حد زیادی برای گیمرها طراحی شده است – اما من معتقدم که این یک منادی چیزهای بزرگتر در آینده است.

خورخه کاسترو، بنیانگذار بلوفین، در طی ویدئو در کنفرانس ContainerDays سال گذشته. “این یک لینوکس برای رایانه شما با ترفندهای ویژه است که ما به صورت اتمی در بالا به روشی منحصر به فرد در بالا قرار داده ایم که احساس می کنیم بسیاری از مشکلاتی را که دسکتاپ لینوکس را آزار می دهد حل می کند.”

در واقع، با هر محیط لینوکس، کاربران کارهایی را انجام می دهند تا آن را مال خود کنند. این ممکن است به دلایل مختلفی از جمله تمایل به افزودن یا تغییر بسته ها یا حتی به دلیل قوانین خاص تجاری باشد. به عنوان مثال، فدورا قوانینی در مورد ادغام فقط محتوای متن باز بالادستی دارد. اگر می‌خواهید مثلاً درایورهای Nvidia را اضافه کنید، باید آن‌ها را خودتان به فدورا بچسبانید و سپس آن را اجرا کنید. Project Bluefin این نوع سس ویژه را زودتر از موعد اضافه می کند تا سیستم عامل (در این مورد، فدورا) را آسان تر کند.

نسخه «پیش‌فرض» Bluefin یک دسک‌تاپ GNOME با یک داک در پایین، نشانگرهای برنامه در بالا، و فروشگاه flathub فعال است. کاسترو گفت: «شما نیازی به انجام هیچ پیکربندی یا کاری ندارید. «شما واقعاً لازم نیست به این اهمیت دهید که آنها از کجا آمده اند. … ما از کدک ها برای شما مراقبت می کنیم، ما یکسری سخت افزار را فعال می کنیم، کنترلر بازی شما کار می کند. مواردی وجود دارد که ممکن است در فدورا پیش‌فرض کار نکنند و سعی می‌کنیم آن‌ها را برطرف کنیم، و همچنین سعی می‌کنیم تا جایی که می‌توانیم چیزهایی را وارد کنیم، از جمله درایورهای Nvidia. دیگر دلیلی وجود ندارد که سیستم عامل شما هر بار که ارتقاء می دهید یک ماژول را کامپایل کند. ما همه این کارها را در CI انجام می دهیم، و عالی است. ما تعمیر و نگهداری دسکتاپ را کاملاً خودکار می کنیم زیرا برای Chromebook عکس می گیریم. … مانند همه دسکتاپ‌های خوب بومی ابری، دارای یک زمان اجرا کانتینر است.

چگونه Bluefin پتانسیل سازمانی را نشان می دهد

شیوه‌ای که کاسترو چگونگی و چرایی ساخت پروژه Bluefin را توضیح می‌دهد، بسیار شبیه به دلایلی است که توسعه‌دهندگان، معماران، sysadmin‌ها و هر کس دیگری که از سیستم‌عامل‌های سازمانی استفاده می‌کند، ساخت‌های اصلی ایجاد می‌کند. و پتانسیل شرکت در آنجا نهفته است، اگرچه اکثر مردم نمی‌دانند که مشکلی که Bluefin حل می‌کند با مشکل تجاری ما در شرکت یکسان است.

همه چیز با “ترفندهای ویژه” که کاسترو ذکر کرد شروع می شود.

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

این در یک سازمان حتی پیچیده تر می شود. متخصصان داخلی متمایز مانند مهندسین امنیت، مدیران شبکه، sysadmins، معماران، مدیران پایگاه داده و توسعه دهندگان با هم همکاری می کنند (یا سعی می کنند، به هر حال) یک پشته نرم افزاری مناسب برای هدف در چارچوب قوانین و دستورالعمل های آن سازمان بسازند. این امر به ویژه برای سیستم عامل در لبه یا با هوش مصنوعی صادق است، جایی که توسعه دهندگان نقش قوی تری در پیکربندی سیستم عامل اصلی دارند. برای درست کردن یک حجم کاری واحد، می‌تواند به ۵۰ تا ۱۰۰ تعامل بین همه این متخصصان نیاز داشته باشد. هر یک از این تعاملات زمان می برد، هزینه ها را افزایش می دهد و حاشیه خطا را افزایش می دهد.

وقتی شروع به اضافه کردن شرکا و مشاوران خارجی می‌کنید، سخت‌تر می‌شود.

امروزه، همه آن متخصصان به زبان‌های مختلفی صحبت می‌کنند. مدیریت پیکربندی و ابزارهایی مانند Kickstart به شما کمک می‌کند، اما وقتی صحبت از همکاری پیچیده و گاهی خصمانه بین سازمان‌ها و درون سازمان‌ها می‌شود، ظریف نیستند. اما اگر بتوانید از کانتینرها به عنوان زبان مادری برای توسعه و استقرار سیستم عامل ها استفاده کنید، چه؟ با این کار همه مشکلات (به خصوص مشکلات افراد) که با کانتینرهای برنامه حل شده بودند، حل می شود، اما شما آن را به سیستم عامل می آورید.

AI و ML برای سیستم‌عامل‌های کانتینری آماده هستند

هوش مصنوعی و یادگیری ماشینی موارد استفاده جالبی برای یک سیستم عامل کانتینری هستند زیرا ماهیت آنها ترکیبی است. یک مدل پایه اغلب توسط مهندسان با کیفیت و در یک برنامه چت بات آموزش دیده، تنظیم شده و آزمایش می شود – همه در مکان های مختلف. سپس، شاید برای تنظیم دقیق تر به عقب برگردد و در نهایت در محیطی متفاوت در تولید مستقر شود. همه اینها برای استفاده از کانتینرها فریاد می زند، اما به شتاب سخت افزاری، حتی در مرحله توسعه، برای استنتاج سریعتر و آزار کمتر نیز نیاز دارد. هرچه یک برنامه سریعتر اجرا شود و حلقه توسعه داخلی کوتاهتر باشد، توسعه دهندگان و مهندسین با کیفیت راضی تر خواهند بود.

به عنوان مثال، به حجم کاری هوش مصنوعی فکر کنید که به صورت محلی در لپ تاپ توسعه دهندگان، شاید به عنوان یک VM، مستقر شده است. حجم کار شامل یک مدل از پیش آموزش دیده و یک چت بات است. آیا خوب نیست که برای استنتاج سریعتر با شتاب سخت افزاری اجرا شود تا ربات چت سریعتر پاسخ دهد؟

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

ایده این است که شما می‌توانید حجم کار را در همه جا، به همان شیوه، و تنها با کمی تغییرات جزئی مستقر کنید. شما در حال گرفتن این تصویر از سیستم عامل و به اشتراک گذاری آن در لپ تاپ ویندوز یا لینوکس هستید. شما آن را به یک محیط آزمایش توسعه‌دهنده منتقل می‌کنید، آن را بیشتر در CI/CD آموزش می‌دهید، شاید حتی آن را به یک کلاستر آموزشی منتقل می‌کنید که با سخت‌افزارهای تخصصی دیگر کمی اصلاح می‌شود. سپس آن را در یک مرکز داده یا یک مرکز داده مجازی در یک ابر یا در لبه تولید می‌کنید.

وعده و واقعیت فعلی

آنچه که من توضیح دادم در حال حاضر انجام آن چالش برانگیز است. در یک سازمان بزرگ، انجام ساخت‌های اصلی می‌تواند شش ماه طول بکشد. سپس یک به روز رسانی سه ماهه می آید، که سه ماه دیگر برای آماده شدن طول می کشد. پیچیدگی کار، زمان لازم برای عرضه یک محصول جدید به بازار را افزایش می‌دهد، هرگز مهم نیست که «فقط» چیزی را به‌روزرسانی کنید. در واقع، به‌روزرسانی‌ها ممکن است بزرگ‌ترین ارزش پیشنهادی یک مدل سیستم‌عامل کانتینری باشد: می‌توانید پس از تکمیل ساخت هسته، با یک فرمان به‌روزرسانی کنید. به‌روزرسانی‌ها دیگر به خوبی اجرا نمی‌شوند—فقط از نقطه A به نقطه B می‌رفتند. و اگر به‌روزرسانی ناموفق بود، فقط به عقب برگردید. این مدل به ویژه در لبه، جایی که پهنای باند و قابلیت اطمینان مورد توجه است، قانع کننده است.

یک مدل سیستم‌عامل کانتینری‌شده همچنین درهای جدیدی را به روی برنامه‌هایی باز می‌کند که سازمان‌ها تصمیم گرفتند به هر دلیلی آن‌ها را کانتینری نکنند. شما فقط می توانید برنامه ها را در یک تصویر سیستم عامل قرار دهید و تصویر را روی فلز خالی یا در یک ماشین مجازی مستقر کنید. در این سناریو، برنامه ها برخی از مزایای کانتینرها، البته نه همه، را به دست می آورند. شما از مزایای همکاری بهتر بین کارشناسان موضوع، یک بزرگراه استاندارد برای تحویل محموله (تصاویر و رجیستری‌های کانتینر OCI)، و به‌روزرسانی‌ها و بازگردانی‌های ساده در تولید.

یک سیستم‌عامل کانتینری نیز از نظر تئوری مزایای حاکمیت و منشأ را ارائه می‌کند. درست مانند برنامه های کانتینری، همه چیز در یک سیستم عامل کانتینری در GitHub متعهد می شود. می‌توانید یک تصویر را از ابتدا بسازید و دقیقاً بدانید چه چیزی در آن است، سپس سیستم‌عامل را دقیقاً از روی آن تصویر مستقر کنید. علاوه بر این، می‌توانید از زیرساخت‌های آزمایش، پرده‌بندی و اسکن خود، از جمله اتوماسیون در CI/CD استفاده کنید.

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

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

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

—

New Tech Forum مکانی برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.