درک اینکه کانتینرها واقعاً چه هستند – بین تاریخ و زمان اجرا

با مطالعه کوبرنتس، زمان زیادی را صرف تلاش برای درک بسیاری از مفاهیم کردم، به عنوان مثال، هر جا که در مورد آن صحبت می کنیم سازگار با OCI، جستجوها OCI و شما را به زمان اجرا، به دنبال زمان اجرا می گردد و شما را به کانتینر، runc، تصویر-spec، cgroups، فضاهای نام و غیره می برد. شما می توانید روزها را صرف جستجو کنید، و زمانی که از آن دسته افرادی هستید که می خواهید به طور کامل کارها را درک کنید، بسیار بیشتر است.

آنچه که CNCF به من فروخت در مقابل آنچه من واقعاً به دست می‌آورم pic.twitter.com/X5pygpSE2W

— memenetes (@memenetes) 20 مارس 2023

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

اصول اولیه

هدف کانتینرها ایجاد یک محیط مجازی است جدا شده که به راحتی قابل توزیع و استقرار است. فرآیندهای مختلفی می توانند در داخل کانتینر اجرا شوند، که باید از سایر فرآیندهای در حال اجرا بر روی میزبان جدا شود.

هسته لینوکس قابلیت های مختلفی را ارائه می دهد که امکان ایجاد این محیط ها را فراهم می کند، دو جزء اصلی وجود دارد که شاید هسته تمام کانتینرها باشد.

فضاهای نام لینوکس

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

چه منابعی را می توان پارتیشن بندی کرد؟خب، این بستگی به نوع فضای نامی دارد که استفاده می شود، به عنوان مثال، فضای نام شبکه به ما اجازه می دهد منابع مرتبط با شبکه، مانند رابط ها، جداول مسیر و غیره را کپسوله کنیم. به این ترتیب می توانیم یک شبکه مجازی در فضای نام خود ایجاد کنیم.

این پست کمی بیشتر با جزئیات در مورد فضاهای نام توضیح می دهد.

cgroups

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

cgroups عملکردی از هسته لینوکس است که به شما امکان می دهد فرآیندها را به صورت سلسله مراتبی سازماندهی کنید و منابع (cpu، حافظه، شبکه، ذخیره سازی) را در آن سلسله مراتب توزیع کنید.

پیکربندی cgroup‌ها می‌تواند کمی پیچیده باشد، در مورد من، من چندین پست در مورد این موضوع را مطالعه می‌کردم و درک کامل نحوه عملکرد آن کمی زمان می‌برد. در این سری از پست‌های ایجاد شده توسط RedHat، ما در مورد cgroup‌ها و پیکربندی آن‌ها از طریق systemd صحبت می‌کنیم، اما اگر می‌خواهید وارد جزئیات شوید، مستندات لینوکس می‌تواند کمک کند.

cgroup ها و namespace ها به اجزای مخفی در Containerization تبدیل می شوند، namespace ها در سطح منبع ایزوله می کنند و cgroup ها به شما اجازه می دهند محدودیت های آن منابع را کنترل کنید.

خوشبختانه امروز با یک خط می‌توانیم یک کانتینر بسازیم، نیازی نیست وارد پیکربندی فضاهای نام یا cgroup‌ها شویم، بیایید کمی سیر تکامل کانتینرها را ببینیم و به این ترتیب چیزهای خاصی را روشن کنیم.

کمی تاریخچه

داکر اولین کسی بود که کانتینرها را رایج کرد، ارتباط مستقیم کانتینرها با داکر رایج بود (یا هست)، اما قبل از آن چیزی به نام LXC (ظروف لینوکس) وجود داشت که می‌توان آن را ارائه‌دهنده محیط‌های مجازی در لینوکس دانست که از اجزای خاصی استفاده می‌کند. از Linux-Kernel برای ایجاد محیط های ایزوله (ظروف).

LXC داخل فضای کاربر است، یعنی ما با LXC تعامل داریم و وظیفه تعامل با اجزای هسته را بر عهده دارد تا امکان ایجاد کانتینرها را فراهم کند. در اینجا ویدیویی وجود دارد که در آن می توانید LXC را در عمل مشاهده کنید.

استفاده کنید: قبل از LXC، جایگزین های دیگری برای ایجاد کانتینرها مانند OpenVZ و Linux Vserver قبلاً توسعه داده شده بود. LXC در ابتدا ذکر شده است زیرا نزدیکترین چیز به Docker است که نرم افزاری است که بسیاری از ما با کانتینرها تعامل برقرار می کنیم.

ورود داکر

داکر LXC را در ابزاری بسته بندی کرد که کانتینرسازی را بسیار آسان تر کرد. با به دست آوردن محبوبیت، بهبودهایی ایجاد شد و چند ماه بعد Docker منتشر شد [libcontainer] که به زبان Golang نوشته شده و در اصل جایگزین LXC شده است.

Docker بیشتر بر روی ایجاد کانتینرهای بهینه برای استقرار برنامه ها تمرکز کرد و قابلیت حمل را بهبود بخشید. این پست با جزئیات بیشتر تفاوت های LXC و Docker را توضیح می دهد.

تعریف استاندارد برای ظروف

به عنوان جایگزینی برای Docker، گزینه‌های دیگری شروع به ظهور کردند، CoreOS به نوبه خود rkt (2014) را راه‌اندازی کرد و امنیت بهتری را پیشنهاد کرد، CoreOS استدلال کرد که Docker به صورت یکپارچه ساخته شده است که به‌عنوان ریشه روی میزبان اجرا می‌شود و امکاناتی را برای به خطر انداختن همه میزبان باز می‌کند. در صورت حمله

rkt از appc (محفظه منبع باز) به منظور بهبود عملکرد استفاده می کند، appc هدفش ایجاد یک استاندارد کلی برای ایجاد کانتینرهایی است که به دنبال مستقل از فروشنده و مستقل از سیستم عامل هستند.

ابتکارات دیگری به دلیل محبوبیت بالای کانتینرها شروع به ظهور کردند، به همین دلیل در سال 2015 OCI (ابتکار کانتینر باز) برای تعریف استانداردی برای کانتینرها (زمان اجرا و تصاویر) ایجاد شد.

مشخصات OCI Runtime

مشخصات زمان اجرا پیکربندی (فایل JSON)، محیط و چرخه زندگی یک کانتینر را تعریف می کند. پیکربندی ها در فایلی به نام config.json تعریف می شوند که حاوی ابرداده های لازم برای اجرای کانتینر است، این فایل با توجه به پلتفرم مورد استفاده (ویندوز، لینوکس، سولاریس و غیره) تعریف می شود.

مفهوم دیگری که باید برجسته شود این است بسته سیستم فایل، این مجموعه ای از فایل ها با داده ها و ابرداده ها برای اجرای یک ظرف است. فایل های اصلی که باید حاوی config.json ذکر شده در بالا و rootfs (سیستم فایل لینوکس) باشد، این است بسته سیستم فایل از طریق تصویر ظرف تولید می شود.

تمام مشخصات کانتینر زمان اجرا در اینجا توضیح داده شده است.

مشخصات تصویر OCI

در ابتدا، Docker قبلاً مشخصات ایجاد تصویر Image Manifest 2 Schema Version 2 را تعریف کرده بود، که محبوب‌ترین آنها بود، OCI از این شروع کرد تا یک استاندارد عمومی‌تر ایجاد کند که با فروشنده خاصی مرتبط نبود. مشخصات تصویر نحوه ساخت و بسته بندی تصاویر کانتینر را تعریف می کند، شخصاً من به طور کامل نحوه عملکرد آن را درک نکرده ام، اما در اینجا نشانی اینترنتی مخزن و یک وبلاگ پست است که حاوی اطلاعات بیشتری است.

استفاده از مشخصات تصویر، می توانید یک تصویر ظرف ایجاد کنید که می تواند توسط هر کسی اجرا شود زمان اجرا OCI، این بدان معنی است که از طریق مشخصات تصویر شما می توانید تولید کنید بسته سیستم فایل، که توسط Runtime برای ایجاد و اجرای کانتینر استفاده می شود.

Runtime Specification نحوه اجرای یک “دسته نرم افزاری سیستم فایل” را که روی دیسک باز می شود، توضیح می دهد. در سطح بالا، یک پیاده‌سازی OCI یک تصویر OCI را دانلود می‌کند و سپس آن تصویر را در بسته‌بندی فایل سیستم OCI Runtime باز می‌کند. در این مرحله OCI Runtime Bundle توسط یک OCI Runtime اجرا می شود.

زمان اجرا کانتینر و Kubernetes

در سال 2015 اولین نسخه kubernetes منتشر شد که از Docker به عنوان زمان اجرا استفاده می کرد.

Docker تصمیم می‌گیرد که یکپارچه ایجاد شده را تقسیم کند، libcontainer به OCI اهدا می‌شود و Docker شروع به کار روی پروژه‌ای به نام runC می‌کند، این می‌تواند به عنوان ابزاری باشد که مشخصات OCI را می‌خواند و با libcontainer برای ایجاد کانتینر تعامل دارد. runC مستقل از Docker Engine است و به OCI اهدا می شود.

runC یک زمان اجرا سطح پایین است، بنابراین Containerd نیز توسعه یافته است که مانند یک رابط بین کلاینت و runC است.

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