
در قسمت اول مقاله در مورد در مورد این توضیح دادیم که Containerها به یک استاندارد صنعتی برای بستهبندی، ارسال و استقرار برنامهها تبدیل شدهاند. Containerهای قابل بوت، تکامل طبیعی فناوریهای Container هستند. مانند Containerهای برنامه معمولی OCI، شما میتوانید Containerهای قابل بوت را با استفاده از فناوریهای Container موجود مانند Containerfiles و ابزارهایی مانند Podman، Docker یا Buildkit بسازید. حال به ادامه مقاله خواهیم پرداخت.
بارگذاری مجدد دیمون و ایجاد سرویس Quadlet
بارگذاری مجدد دیمون باعث اجرای Quadlet و ایجاد یک سرویس systemd به نام test.service خواهد شد که سپس میتوانید آن را با دستور systemctl –user start test.service شروع کنید.
ماهیت اعلامی Quadlet آن را به یک گزینه عالی برای نصب و گنجاندن Workloads در Image mode برای RHEL تبدیل میکند. بیایید ابتدا بررسی کنیم که چگونه این کار را انجام دهیم.
گنجاندن Workloads در Image mode برای RHEL
یک روش ساده و کارآمد برای گنجاندن Quadlet در Image mode این است که آن را با استفاده از یک Containerfile بخشی از Image کنید. همانطور که در زیر نشان داده شده است، فایل Quadlet .container را میتوان به سادگی به Image rhel-Bootc کپی کرد.

توجه داشته باشید که استفاده از Quadlet در زمان بوت ممکن است روند بوت را به طور قابل توجهی به تأخیر بیاندازد. اما برای این مشکل راهحلی وجود دارد که با استفاده از logically-bound Images انجام میشود که در طول یک بهروزرسانی از پیش بارگذاری خواهند شد.
Quadlet همچنین از اجرای Pods و Workloads Kubernetes پشتیبانی میکند، میتواند حجمها، شبکهها و Image را مدیریت کند و از ساخت Image نیز پشتیبانی میکند.
بهروزرسانیهای خودکار Podman
استفاده از Quadlet به ما این امکان را میدهد که Workload را از میزبان جدا کنیم و بهروزرسانیهای Workload نیازی به بهروزرسانی سیستم میزبان نخواهند داشت. اما چگونه میتوانیم بهروزرسانیهای Workload را بهطور مؤثر مدیریت کنیم؟ بهویژه زمانی که در edge اجرا میشوند، باید تا حد امکان این فرایند را خودکار کنیم.
یک روش آسان و مستقیم برای مدیریت بهروزرسانیهای کانتینر بارهای کاری استفاده از بهروزرسانیهای خودکار Podman است. به طور پیشفرض، Podman با سرویس systemd به نام podman-auto-update.service عرضه میشود که مسئول بهروزرسانی Image و راهاندازی مجدد سرویسهای systemd یعنی Quadletها برای استفاده از Image بهروزرسانی شده است. این سرویس یکبار در روز توسط تایمر podman-auto-update.timer فعال میشود که میتوان آن را با نیازهای شما پیکربندی کرد. اگر بهروزرسانی مبتنی بر رویداد را ترجیح میدهید، میتوانید سرویس را شروع کنید یا مستقیماً دستور podman auto-update را اجرا کنید. برای پیکربندی یک Quadlet .container برای بهروزرسانی خودکار، گزینه AutoUpdate=registry را به جدول Container اضافه کنید، میتوانید ار خط دستوری که در زیر آمده است استفاده کنید:

استراتژیهای بهروزرسانی خودکار و تگگذاری
Image زمانی بهروزرسانی شده محسوب میشود که Digest آن در رجیستری تغییر کند. بنابراین، نحوه نامگذاری و تگگذاری Image نقش مهمی در بهروزرسانی خودکار دارد. ما استفاده از تگ latest را که معمولاً برای جدیدترین Image استفاده میشود، توصیه نمیکنیم. Semantic Versioning یک استراتژی بسیار بیانگرتر برای تگگذاری Image است. Semantic Versioning مانند یک قرارداد با مصرفکنندگان Image است و فرمت آن به شکل X.Y.Z است، که در آن افزایش هر بخش معنای خاصی دارد:
X: افزایش نسخه اصلی با تغییرات ناسازگار با نسخههای قبلی.
Y: افزایش نسخه فرعی با عملکرد جدید و تغییرات سازگار با نسخههای قبلی.
:Zافزایش نسخه Patch با اصلاح اشکالات، بدون اضافه کردن عملکرد جدید و بهصورت سازگار با نسخههای قبلی.
بهروزرسانی خودکار Podman
بهروزرسانی خودکار Podman ابزار قدرتمندی برای بهروز نگه داشتن Workloads ما فراهم میکند. اما گاهی اوقات مشکلاتی پیش میآید، برای مثال، زمانی که به اشتباه یک Image خراب ارسال میشود. چنین تصاویری میتوانند باعث شوند که Containerهای Quadlet پس از بهروزرسانی دچار مشکل شوند. بهروزرسانیهای خودکار Podman از بازگشت به نسخه قبلی به طور پیشفرض پشتیبانی میکنند. اگر راهاندازی مجدد یک سرویس Quadlet پس از بهروزرسانی Image آن ناموفق باشد، Podman به نسخه قبلی که مطمئن از عملکرد درست آن است، باز خواهد گشت و سرویس را مجدداً راهاندازی خواهد کرد.
بیشتر بخوانید: ادغام قابلیت اسکن امنیتی Linux Container در RHEL
برای اینکه بازگشت به نسخه قبلی عمل کند، Workload داخل Container باید تصمیم بگیرد که چه زمانی استارت بزند و پیام READY را از طریق DBUS ارسال کند. برای انجام این کار، نیاز است که گزینه Notify=true در جدول Container فایل Quadlet .container تنظیم شود. اگر systemd پیام READY را به موقع دریافت نکند، راهاندازی مجدد سرویس ناموفق خواهد بود و Podman بازگشت به نسخه قبلی را انجام میدهد.
بررسی سلامت
بازگشت به نسخه قبلی روش خوبی برای شناسایی زمانی است که یک سرویس به درستی راهاندازی یا شروع نمیشود. اما در مورد خرابیها پس از راهاندازی موفقیتآمیز سرویس چه باید کرد؟
برای شناسایی خرابیها در زمان اجرا، Podman از اقدامهای سفارشی بررسی سلامت پشتیبانی میکند. بررسی سلامت، دستورات قابل تنظیم توسط کاربر هستند که با یک فرکانس خاص در یک Container اجرا میشوند تا بر سلامت Workload نظارت کنند. نسخه 4.3، Podman از گسترش بررسیهای سلامت پشتیبانی میکند و به آن اجازه میدهد در صورت بروز مشکل در یک کانتینر، اقدامی انجام دهد، مانند راهاندازی مجدد، توقف یا ازبین بردن کانتینر.
یکپارچهسازی تجربه بهروزرسانی خودکار
برای یکپارچهسازی تجربه بهروزرسانی خودکار، مراحل زیر باید در نظر گرفته شود. پس از بهروزرسانی یک Image در رجیستری Podman ،Image جدید را بارگیری کرده و در نهایت سرویسهای systemd را با استفاده از Image خاص راهاندازی مجدد خواهد کرد. برای فعالسازی تجربه کاملاً خودکار و بدون دخالت، Podman در صورتی که یک سرویس به درستی راهاندازی نشود، به نسخه قبلی Image بازگشت خواهد گرداند. اگر به درستی پیکربندی شده باشد، بررسیهای سلامت اطمینان میدهند که Workloads سالم هستند و در غیر این صورت مجدداً راهاندازی خواهند شد.
بیشتر بخوانید: بررسی آینده داده های امنیتی Red Hat
Ansible
اگر به رویکردی پویا برای مدیریت Workloads در سیستمهای خود نیاز دارید، Ansible ممکن است ابزار انتخابی شما باشد. یک Ansible System Role برای Podman وجود دارد که امکان استقرار و مدیریت Workloads Container را فراهم میکند. ویژگیهای جدید Podman System Role در RHEL 9.5 عبارتند از:
پشتیبانی از فایلهای گواهینامه و کلید برای اتصال به رجیستریها با استفاده از TLS که این امکان را میدهد که دایرکتوری را پیکربندی کنید.
پشتیبانی از تنظیم نام کاربری و رمز عبور برای رجیستریها که شما میتوانید این موارد را برای تمام رجیستریهای مشخص شده یا به صورت جداگانه برای هر رجیستری تنظیم کنید.
پشتیبانی از تنظیم اعتبارنامهها در فایل auth.json یک کانتینر که به شما امکان میدهد انواع مختلف احراز هویت رجیستری مثلاً احراز هویت مبتنی بر توکن را پیکربندی کنید.
حالت Image پارادایمی جدید برای کاربران معرفی میکند که در آن بهروزرسانیهای میزبان به طور اتمی انجام میشود و معمولاً نیاز به راهاندازی مجدد دارد. استفاده از Containerهای برنامهای این امکان را فراهم میکند که این جداسازی صورت گیرد تا برنامهها بتوانند به طور مستقل از میزبان بهروزرسانی و مدیریت شوند.