در این مقاله، نمای جامعی از نحوه مدیریت بارهای کاری در سیستم‌های حالت Image و تنظیم یک Pipeline ساخت برای خودکارسازی تجربه ساخت، استقرار و مدیریت سیستم‌های لینوکس در مقیاس بزرگ ارائه می‌دهیم.
Containerهای قابل بوت یا Bootable
مستندات منبع Containerهای قابل بوت را با عنوان به‌روزرسانی‌های سیستم‌عامل ترنسکشنال و به‌روزرسانی‌های سیستم‌عامل در محل با استفاده از OCI container Images خلاصه کرده است. به عبارت دیگر، به‌روزرسانی‌های سیستم‌عامل به‌صورت Image Container ارسال می‌شوند. این بدین معناست که هسته لینوکس، لودر بوت، درایورها و غیره، همه جزئی از Image Container هستند که آن را قابل بوت می‌سازد.
در قلب و مرکز عملکرد Containerهای قابل بوت، ابزار خط فرمان Bootc قرار دارد. این ابزار است که Image سیستم‌عامل داخل Container را به یک میزبان کامل تبدیل می‌کند. در RHEL معمولاً این Image را Image Bootc می‌نامیم.
برای بیش از یک دهه، Containerها به یک استاندارد صنعتی برای بسته‌بندی، ارسال و استقرار برنامه‌ها تبدیل شده‌اند. Containerهای قابل بوت، تکامل طبیعی فناوری‌های Container هستند. مانند Containerهای برنامه معمولی OCI، شما می‌توانید Containerهای قابل بوت را با استفاده از فناوری‌های Container موجود مانند Containerfiles و ابزارهایی مانند Podman، Docker یا Buildkit بسازید. شما می‌توانید Image را در هر رجیستری Container مانند Quay.io، Docker Hub، GitHub Container Registry یا هر رجیستری Container داخلی ذخیره کنید. شکل زیر تفاوت بین یک Container برنامه و یک Container قابل بوت یا Bootable را نشان می‌دهد.
در شکل بالا می توان گفت برخلاف Containerهای برنامه، Image Container قابل بوت شامل هسته لینوکس هستند.
Containerهای قابل بوت که بر اساس این فناوری‌های موجود ساخته شده‌اند، Containerها را به‌گونه‌ای گسترش می‌دهند که شامل سیستم‌عامل کامل به همراه هسته لینوکس می‌شوند تا امکان داشتن یک جریان کار و تجربه کاربری بومی Container کامل را فراهم کنند.
بیشتر بخوانید: چرا باید Linux Red Hat Enterprise را ارتقا دارد؟ بررسی مزایای نسخه های جدید RHEL
بروزرسانی سیستم‌های حالت Image
چرخه حیات یک Image Bootc شامل مراحل مختلفی است. مشابه با Containerهای برنامه، یک Image Bootc از طریق یک Container file و ابزارهای استاندارد ساخت Container ساخته می‌شود. یک جریان کار معمول برای نصب محتوای یک Image Bootc روی یک ماشین فیزیکی یا مجازی، تبدیل Image Container به Image دیسک است تا در نهایت آن را در محیط هدف مستقر کنیم.
ابزار Bootc -Image-builder مسئول این تبدیل است و از فرمت‌های مختلف Image دیسک مانند qcow2، AMI یا Image دیسک آمازون، ISO، VMDK برای vSphere و سایر فرمت‌ها پشتیبانی می‌کند. Bootc -Image-builder به راحتی می‌تواند با هر pipeline ساخت موجود یکپارچه شود و همچنین توسط افزونه Podman Desktop Bootc برای مدیریت و ساخت Image دیسک استفاده می‌شود. شکل زیرفرایند بروزرسانی یک سیستم در حالت Image را نشان می‌دهد.
بروزرسانی یک سیستم در حالت Image الگوی مشابهی با Containerهای برنامه دنبال می‌کند: یعنی ساخت یک Image جدید و ارسال آن به رجیستری. پس از ارسال، Bootc می‌تواند Image بروزرسانی شده را از رجیستری بارگیری کرده و سیستم را به Image جدید راه‌اندازی کند.
چندین روش برای بروزرسانی یک سیستم فردی وجود دارد:
به طور پیش‌فرض، سیستم‌های حالت Image بروزرسانی‌های زمانی را از طریق تایمر systemd انجام می‌دهند.
برای بروزرسانی‌های مبتنی بر رویداد، می‌توان سرویس Bootc -fetch-apply-updates.service را فعال کرد.
بروزرسانی‌های دستی با اجرای دستور Bootc -upgrade و راه‌اندازی مجدد سیستم قابل انجام است.
همراه با بروزرسانی و مدیریت سیستم، Bootc از قابلیت‌های بازگشت به وضعیت قبلی یا Rollback و ویژگی‌های مفید دیگر پشتیبانی می‌کند.
بیشتر بخوانید: پلتفرم Red Hat Enterprise Linux AI یا RHEL AI چیست و چه قابلیت هایی دارد؟
بروزرسانی‌های Image پایه RHEL
در حالی که حالت Image برای RHEL یک پارادایم جدید از نحوه مدیریت و بروزرسانی سیستم‌ها را معرفی می‌کند، محتوای Image پایه همچنان به صورت بسته‌های RPM ارسال می‌شوند. در واقع، این همان بسته‌هایی هستند که سیستم‌های مبتنی بر RPM سنتی را تشکیل می‌دهند که به آن‌ها سیستم‌های حالت بسته نیز گفته می‌شود.
این بدین معناست که حالت Image برای RHEL از همان چرخه‌های بروزرسانی و پشتیبانی مشابه سیستم‌های حالت بسته پیروی می‌کند. نسخه‌های جدید همزمان منتشر و بروزرسانی‌ها هر 6 هفته یکبار ارسال می‌شوند. اصلاحات مربوط به CVEهای با شدت بالا ممکن است در هر زمانی ارسال شوند. اما چون چنین اصلاحات فوری نادر هستند، می‌توانید انتظار داشته باشید که هر 6 هفته یک بار یک Image پایه جدید منتشر شود. در نظر گرفتن این برنامه زمانی برای برنامه‌ریزی بروزرسانی سیستم‌های مبتنی بر Image که برای تکمیل بروزرسانی نیاز به راه‌اندازی مجدد دارند، مفید است.
حالت Image و تغییرناپذیری یا Immutability
یک ویژگی مهم حالت Image برای RHEL، تغییرناپذیری است. یک سیستم‌عامل تغییرناپذیر از یک پارادایم متفاوت نسبت به سیستم‌های سنتی مبتنی بر بسته پیروی می‌کند. پس از استقرار، تمام سیستم فایل‌ها، به جز /etc و /var، به صورت فقط خواندنی Mount می‌شوند. این بدین معناست که حتی کاربر Root نیز دسترسی نوشتن ندارد. بروزرسانی‌های سیستم از طریق بارگیری نسخه جدید Image Bootc از یک رجیستری Container و سپس راه‌اندازی مجدد به حالت جدید اعمال می‌شوند. این رویکردی متفاوت نسبت به استفاده از یک مدیر بسته برای بروزرسانی سیستم در زمان اجرا است. این امر شما را مجبور می‌کند که در مورد تغییرات در سیستم‌عامل آگاهانه عمل کنید و کنترل کامل بر روی آن داشته باشید و همینکه امنیت سیستم را افزایش می‌دهد.
پارادایم جدید حالت Image به ما کمک می‌کند که به سیستم‌های لینوکس با نگاهی تازه بنگریم. ما به شدت معتقدیم که بیشتر Workloads نباید مستقیماً روی میزبان اجرا شوند، بلکه باید به‌عنوان Containerهای برنامه روی میزبان اجرا شوند. این امر جداسازی واضحی را بین تأمین و مدیریت منابع سیستم یعنی میزبان و Workload و منطق برنامه یعنی همان کانتینر فراهم می‌آورد. علاوه بر این، از آلوده شدن سیستم میزبان با برنامه‌های در حال تغییر مداوم جلوگیری می‌کند. در زمینه فنی، ما همچنین از نیاز به راه‌اندازی مجدد کل سیستم برای بروزرسانی‌های برنامه‌ها جلوگیری می‌کنیم.
مدیریت Workloads در حالت تصویر
در این بخش، چندین گزینه برای مدیریت Workloads در سیستم‌های حالت Image را بررسی خواهیم کرد. همانطور که قبلاً ذکر شد، ما Containerکردن Workloads را برای کاهش نگرانی‌ها پیشنهاد می‌کنیم.
Quadlet: Workloads Container در systemd
اجرای Workloads Container در systemd روشی ساده اما قدرتمند برای استقرارهای قابل اعتماد و مستحکم است. Podman یکپارچگی عالی با systemd به صورت Quadlet دارد. Quadlet ابزاری برای اجرای Containerهای Podman در Systemd به صورت بهینه و اعلامی است.
ممکن است شما درباره فواید اجرای Workloads Container در systemd کنجکاو باشید این فواید زیاد هستند. اولاً، systemd مرجع کنترل مرکزی در سیستم‌های مدرن لینوکس است. از جمله کارهای دیگر، این ابزار سرویس‌های سیستم و کاربر و وابستگی‌های میان آن‌ها را مدیریت می‌کند. systemd قابلیت‌های زیادی از جمله سیاست‌های پیچیده برای راه‌اندازی مجدد دارد. بنابراین، یکپارچگی Podman با systemd نقطه عطف مهمی برای ادغام مهارت‌های مدیران سیستم لینوکس با فناوری‌های مدرن کانتینر بود.
دوم اینکه این سازه بدون دیمون Podman به طور کامل با systemd یکپارچه می‌شود. مدیریت فرآیند پیچیده systemd به آن اجازه می‌دهد که یک Container را نظارت کرده و در صورت نیاز آن را مجدداً راه‌اندازی کند. ترکیب systemd و Podman این امکان را فراهم آورد که به استفاده‌های جدیدی دست یابیم که در آن‌ها دخالت انسانی همیشه ممکن نیست، به عنوان مثال می‌توان Edge Computing و اینترنت اشیاء یا IoT را نام برد. علاوه بر این، Quadlet سیستمی یکپارچه برای systemd است که آن را برای مدیران بسیار قابل دسترس می‌سازد.
بیایید نگاهی دقیق‌تر به Quadlet بیاندازیم و فایل نمونه Quadlet .container زیر را بررسی کنیم:
همانطور که گفته شد، Quadlet ویژگی‌های خاص Podman را به واحدهای systemd اضافه می‌کند. Quadlet .container یک جدول یا Container اضافه می‌کند که در آن می‌توانیم گزینه‌های خاص Container مانند تصویر، دستور و نام Container را اعلام کنیم، اما همچنین می‌توانیم حجم‌ها و شبکه‌هایی که باید استفاده کند را نیز مشخص کنیم. Quadlet سیستمی است که در هنگام بوت یا بارگذاری مجدد دیمون systemd اجرا می‌شود. اگر می‌خواهید مثال بالا را آزمایش، می‌توانید فایل را در دایرکتوری خانگی خود ایجاد کنید.
