کانتینر kernel مستقل VM را ندارد. امشب مرز process، image و runtime را مشخص می‌کنیم تا «سبک‌تر» را با «همان جداسازی VM» یکی ندانیم.

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

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

محیط: VM مستقل containers با Ubuntu 24.04؛ این جلسه نصب runtime اجباری ندارد. مبانی LPIC-303 را برای permission و MAC به یاد بیاور.

system container مانند LXC/LXD محیطی با چند سرویس و lifecycle سیستم می‌دهد؛ application container مانند الگوی رایج Docker حول اجرای برنامه طراحی می‌شود. هر دو از امکانات kernel میزبان استفاده می‌کنند. نام system container به معنی kernel مستقل یا اجازهٔ اجرای همهٔ moduleها نیست.

uname -r
lsns
cat /proc/self/cgroup
cat /proc/self/status

این مشاهده‌ها baseline host را می‌دهند؛ مشابهت uname داخل guest کانتینری معمولاً از kernel مشترک می‌آید. root filesystem و packageهای userspace می‌توانند متفاوت باشند.

مشخصات و اجزا#

OCI یا ابتکار کانتینر باز، مشخصات مشترک image و runtime را تعریف می‌کند. OCI Image Specification layout/manifest/layerهای image را تعریف می‌کند و OCI Runtime Specification config/lifecycle اجرای container را. registry حمل artifact است؛ runtime مانند runc اجرای process را با kernel آماده می‌کند. یک digest image، اعتماد به publisher یا امن بودن برنامه را خودکار ثابت نمی‌کند.

namespace دید را جدا، cgroup مصرف resource را محدود، capability اختیار را خرد و seccomp/MAC عملیات را محدود می‌کنند. هیچ‌کدام به‌تنهایی همهٔ مسئله نیست؛ bind mount writable میزبان می‌تواند مرز فایل را دوباره باز کند.

آزمون: برای یک system container و یک web application container، process اصلی، init، دادهٔ persistent، kernel و مسیر update را بنویس. مفهوم image با یک process running یکی نیست.

بازگشت: تغییر نداریم. محیط Docker و LXD را در Cloneهای جدا می‌سازیم تا ruleهای شبکه و subnetها تصادفی مشترک نشوند.

منبع: OCI image spec ، OCI runtime spec ، namespaceها .