runtime پایین‌دست با مدیر image و orchestration یک ابزار نیست. امشب نقش اجزا را ترسیم و یک مسیر rootless را بدون ادعای جداسازی کامل بررسی می‌کنیم.

این جلسه بخشی از دورهٔ لینوکس ۳۰۵ در ۶۰ شب است.

جایگاه در دوره: هدف‌های 352.1 آزمون 305-300.

محیط: مطالعه و VM مستقل runtime؛ همهٔ daemonها را در یک host روی socket مشترک نصب نمی‌کنیم.

جزءمسئولیت
runcاجرای bundle سازگار با OCI و lifecycle process
containerdمدیریت image/content، snapshotter و task؛ با integration مناسب CRI
CRI-Oruntime service برای Kubernetes CRI با OCI runtime
CRI؛ رابط runtime کانتینرAPI kubelet به runtime؛ همان OCI specification نیست
Podman / Buildah / Skopeoاجرای container، ساخت image، inspect/copy artifact با نقش‌های جدا

Docker daemon نیز از اجزای پایین‌دست استفاده می‌کند، ولی CLI docker را به هر socket containerd وصل نمی‌کنیم. نصب containerd به معنی یک cluster آمادهٔ Kubernetes نیست.

در Clone دارای Podman/Skopeo از package توزیع:

podman info
podman run --rm docker.io/library/alpine:3.23 id
skopeo inspect docker://docker.io/library/alpine:3.23

نسخهٔ image نمونه است؛ support و digest واقعی را ثبت کن. rootless نیاز به subordinate UID/GID، user namespace و backend شبکه/storage مناسب دارد. root در user namespace به‌معنی root host نیست؛ در مقابل، rootless هم تمام syscall/kernel risk را حذف نمی‌کند.

runc مستقیم معمولاً OCI bundle با rootfs/config و privilege مناسب می‌خواهد؛ این درس وظیفه/contract آن را توضیح می‌دهد و اجرای bundle ناشناس با root پیشنهاد نمی‌کند. با ابزار نسخهٔ نصب‌شده فقط inventory محدود را inspect کن.

آزمون: owner process host، UID داخل container و mappingها را مقایسه کن. permission bind mount و دسترسی شبکهٔ rootless را با فرض rootful یکسان نگیر.

بازگشت: container –rm بعد exit پاک می‌شود؛ image دریافت‌شده و cache جدا باقی‌اند. فقط artifact مشخص آزمایش را حذف کن.

rkt پروژهٔ legacy، OpenVZ و systemd-nspawn رویکردهای دیگر و BSD Jails متعلق به kernel دیگرند؛ آگاهی آزمون به معنی نصب پروژهٔ منسوخ روی سیستم عملیاتی نیست.

منبع: runc ، containerd ، CRI-O ، Podman rootless .