چرا باید از Docker و کانتینرهای OCI استفاده کنید

یاد بگیرید چگونه کانتینرهای سیستم‌عامل سبک، قابل حمل و خودکفا بهبود توسعه نرم‌افزار، استقرار برنامه‌ها و چابکی کسب‌وکار را به ارمغان می‌آورند.

کتابی منتشر شده در سال ۱۹۸۱ به نام میخ زدن ژله به درخت نرم‌افزار را «ابری و دشوار برای درک ثابت» توصیف می‌کند. این در سال ۱۹۸۱ درست بود و چهار دهه بعد هم به همان اندازه صحیح است. نرم‌افزار، چه برنامه‌ای که خریداری کرده‌اید یا چه برنامه‌ای که خودتان ساخته‌اید، همچنان برای استقرار، مدیریت و اجرا سخت است.

Docker containers، و استاندارد OCI برای کانتینرها و زمان‌های اجراشان، روشی برای درک نرم‌افزار فراهم می‌کنند. می‌توانید از کانتینرها برای بسته‌بندی یک برنامه به‌گونه‌ای استفاده کنید که مشکلات استقرار و زمان اجرا—مانند نحوه در دسترس‌قرار دادن آن روی شبکه، نحوه مدیریت استفاده آن از ذخیره‌سازی، حافظه و ورودی/خروجی، و نحوه کنترل دسترسی‌ها—خارج از خود برنامه اداره شوند و به‌صورتی سازگار در تمام برنامه‌های «کانتینریزه» باشد. می‌توانید کانتینر خود را روی هر میزبان سازگار با لینوکس یا ویندوز که زمان اجرای کانتینر نصب شده داشته باشد اجرا کنید.

کانتینرها مزایای بسیاری علاوه بر محاط‌سازی، ایزوله‌سازی، قابلیت حمل و کنترل ارائه می‌دهند. کانتینرها نسبت به ماشین‌های مجازی کوچک هستند و به‌صورت مگابایت در مقابل گیگابایت قابل اندازه‌گیری‌اند. آن‌ها بلافاصل شروع می‌شوند. مکانیزم‌های داخلی خود را برای نسخه‌گذاری و استفاده مجدد از مؤلفه‌ها دارند. می‌توان آن‌ها را به‌راحتی از طریق مسیرهایی مانند Docker Hub عمومی یا مخزن خصوصی به اشتراک گذاشت.

کانتینرها همچنین غیرقابل تغییر هستند، که هر دو مزایای امنیتی و عملیاتی دارد. هر تغییری در یک کانتینر باید به‌عنوان یک کانتینر کاملاً جدید و با نسخه متفاوت مستقر شود.

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

زندگی قبل از کانتینرها

به‌مدت سال‌ها، نرم‌افزارهای سازمانی معمولاً یا روی «سخت‌افزار خالص» (یعنی نصب روی سیستم‌عاملی که کنترل کامل بر سخت‌افزار زیرین دارد) یا در یک ماشین مجازی (نصب روی سیستمی که سخت‌افزار زیرین را با سایر سیستم‌های «مهمان» به اشتراک می‌گذارد) مستقر می‌شدند. طبیعتاً نصب روی سخت‌افزار خالص باعث می‌شد نرم‌افزار به‌طرزی دردناک برای جابجایی و به‌روزرسانی دشوار باشد—دو محدودیتی که واکنش سریع آی‌تی به تغییرات نیازهای تجاری را دشوار می‌کرد.

سپس مجازی‌سازی ظاهر شد. پلتفرم‌های مجازی‌سازی (که به‌عنوان ابرنظام‌ها نیز شناخته می‌شوند) امکان اشتراک‌گذاری یک سیستم فیزیکی توسط چندین ماشین مجازی را فراهم کردند، به‌طوری که هر ماشین مجازی رفتار یک سیستم کامل را شبیه‌سازی می‌کرد—شامل سیستم‌عامل، ذخیره‌سازی و ورودی/خروجی خود—به‌صورت ایزوله. آی‌تی حالا می‌توانست به‌طور مؤثرتری به تغییرات نیازهای تجاری واکنش نشان دهد، زیرا ماشین‌های مجازی می‌توانستند کلون، کپی، مهاجرت یا بالا و پایین شوند تا با تقاضا هماهنگ یا منابع را صرفه‌جویی کنند.

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

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

Docker و استاندارد OCI

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

Docker، که در سال ۲۰۱۳ راه‌اندازی شد، انجام تمام کارهایی که برای کانتینرسازی برنامه‌ها لازم بود را به‌طور خودکار آسان کرد. موفقیت Docker به‌عنوان یک پروژه، و بعداً به‌عنوان شرکتی که این پروژه را تجاری‌سازی کرد، رویکرد Docker به کانتینرها را به‌عنوان یک استاندارد de facto مطرح کرد. در سال‌های بعد، پذیرش کانتینرها به‌قدر رشدی یافت که پیاده‌سازی‌های رقابتی شروع به ظهور کردند، با ایده‌های متقابلی درباره‌ی بهترین روش پیاده‌سازی آن‌ها.

سرانجام، یک استاندارد مشترک ظهور کرد. مشخصات Open Container Initiative (OCI) که در سال ۲۰۱۷ رسمی شد، شامل مشارکت‌های Docker و رقبا بود. اکنون شرکت Docker بقایای نسخهٔ قبلی خود است، اگرچه محصول Docker و پروژهٔ متن‌باز Docker همچنان زنده‌اند—بنابراین منطقی است که استاندارد OCI به‌تنهایی زنده بماند و پیشرفت کند.

مزایای کانتینرها و کانتینرسازی

کانتینرها کمی شبیه ماشین‌های مجازی عمل می‌کنند، اما به‌گونه‌ای بسیار خاص و جزئی‌تر. آن‌ها یک برنامهٔ واحد و وابستگی‌های آن—تمام کتابخانه‌های نرم‌افزاری خارجی که برنامه برای اجرا نیاز دارد—را هم از سیستم‌عامل زیرین و هم از سایر کانتینرها جدا می‌کنند.

تمام برنامه‌های کانتینریزه یک سیستم‌عامل مشترک (یا لینوکس یا ویندوز) را به‌اشتراک می‌گذارند، اما از یکدیگر و از سیستم کلی جدا هستند. سیستم‌عامل مکانیزم‌های جداسازی مورد نیاز برای این جداسازی را فراهم می‌کند. کانتینرها این مکانیزم‌ها را در یک مجموعهٔ راحت از رابط‌ها و استعاره‌ها برای توسعه‌دهنده می‌پیچند.

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

کانتینرها منابع سیستم را کارآمدتر استفاده می‌کنند

نمونه‌های برنامه‌های کانتینریزه به‌مراتب حافظهٔ کمتری نسبت به ماشین‌های مجازی مصرف می‌کنند، سرعت راه‌اندازی و توقف بیشتری دارند و می‌توانند به‌شدت فشرده‌تر بر روی سخت‌افزار میزبان خود قرار گیرند. همه این موارد منجر به کاهش هزینه‌های آی‌تی می‌شود.

صرفه‌جویی‌های هزینه‌ای بسته به برنامه‌های مورد استفاده و میزان مصرف منابع متفاوت خواهد بود، اما کانتینرها به‌طور دائم به‌عنوان کارآمدتر نسبت به ماشین‌های مجازی شناخته می‌شوند. همچنین می‌توان در هزینهٔ لایسنس نرم‌افزار صرفه‌جویی کرد، زیرا برای اجرای همان بارکاری به‌تعداد کمتری نمونهٔ سیستم‌عامل نیاز است.

کانتینرها چرخه‌های تحویل نرم‌افزار را سریع‌تر می‌کنند

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

کانتینرها این امکان را آسان می‌کنند که نسخه‌های جدید نرم‌افزار، با ویژگی‌های تجاری جدید، به‌سرعت به تولید برسند—و در صورت نیاز به‌سرعت به نسخهٔ قبلی برگردند. همچنین اجرای استراتژی‌هایی مانند استقرار آبی/سبز را ساده‌تر می‌کنند.

کانتینرها قابلیت حمل‌پذیری برنامه‌ها را فراهم می‌کنند

محل اجرای برنامهٔ سازمانی مهم است—در پشت دیوارهای فایروال برای حفظ نزدیکی و امنیت؛ یا در ابر عمومی برای دسترسی آسان و کشش بالای منابع. چون کانتینرها تمام مواردی را که یک برنامه برای اجرا نیاز دارد (و فقط همان موارد) در خود محصور می‌کنند، امکان انتقال آسان برنامه‌ها بین محیط‌ها را فراهم می‌کنند. هر میزبانی که زمان اجرای کانتینر نصب شده داشته باشد—چه لپ‌تاپ توسعه‌دهنده و چه نمونهٔ عمومی ابر—می‌تواند کانتینری را اجرا کند، به‌شرط اینکه منابع کافی برای آن برنامهٔ کانتینریزه داشته باشد.

کانتینرسازی میکروسرویس‌ها را ساده می‌کند

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

یکی از الگوهای نرم‌افزاری که کانتینرها ساده می‌کنند، میکروسرویس‌ها هستند؛ جایی که برنامه‌ها از اجزای loosely coupled بسیاری تشکیل می‌شوند. با تجزیهٔ برنامه‌های «منیول» به سرویس‌های جداگانه، میکروسرویس‌ها به بخش‌های مختلف یک برنامهٔ خط‌کار تجاری اجازه می‌دهند تا به‌صورت جداگانه مقیاس‌پذیر، تغییر یافته و سرویس‌دهی شوند—توسط تیم‌های مختلف و در جدول زمانی متفاوت، اگر این نیازهای کسب‌وکار باشد.

کانتینرها برای پیاده‌سازی میکروسرویس‌ها الزامی نیستند، اما به‌طور کامل با رویکرد میکروسرویس و فرآیندهای توسعهٔ چابک مطابقت دارند.

مشکلاتی که کانتینرها حل نمی‌کنند

اولین نکته‌ای که باید دربارهٔ کانتینرها در نظر گرفت همان توصیه‌ای است که برای هر فناوری نرم‌افزاری صادق است: این یک گلولهٔ نقره‌ای نیست. کانتینرها به‌تنهایی نمی‌توانند تمام مشکلات را حل کنند. بیایید به چند مشکل خاص که کانتینرها حل نمی‌کنند، نگاهی بیندازیم.

کانتینرها مسائل امنیتی شما را حل نمی‌کنند

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

کانتینرها برنامه‌ها را به میکروسرویس‌ها تبدیل نمی‌کنند

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

اگر یک برنامهٔ قدیمی منیول یا سبک SOA را داخل یک کانتینر بگذارید، در نهایت یک برنامهٔ قدیمی در یک کانتینر خواهید داشت. این امر برنامه را کاربردی‌تر نمی‌کند؛ بالعکس ممکن است کم‌کارآمدتر شود.

کانتینرها به‌تنهایی مکانیزم‌های لازم برای ترکیب برنامه‌های میکروسرویس‑شی را ندارند. برای این کار به یک لایهٔ بالاتر از ارکستراسیون نیاز است. کوبرنتیس رایج‌ترین مثال برای چنین سیستم ارکستراسیونی است. یک راه‌حل حداقلی‌تر، حالت Docker swarm است که می‌تواند بسیاری از کانتینرهای Docker را در چندین میزبان Docker مدیریت کند.

کانتینرها جایگزین ماشین‌های مجازی نمی‌شوند

یکی از افسانه‌های مداوم دربارهٔ کانتینرها این است که آن‌ها ماشین‌های مجازی را منسوخ می‌کنند. بسیاری از برنامه‌هایی که قبلاً در یک VM اجرا می‌شدند، می‌توانند به‌صورت کانتینریزه شوند، اما این به این معنا نیست که همهٔ آن‌ها می‌توانند یا باید منتقل شوند. اگر در صنعتی با الزامات نظارتی سنگین فعالیت می‌کنید، ممکن است نتوانید کانتینرها را به‌جای VM‌ها استفاده کنید، زیرا VM‌ها جداسازی بیشتری نسبت به کانتینرها ارائه می‌دهند.

دلیل استفاده از کانتینرها

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