داکر به زبان آدمیزاد

اگر که یک برنامه نویس یا مدیر سیستم[1] هستید اما هنوز مهارت و تجربه کار با فناوری داکر را در رزومه خودتون ندارید، بدون شک در این برهه از زمان لازمه که این مهارت ضروری را کسب و به رزومه تون اضافه کنید. شما هم ممکنه مثل من همکاران یا دوستان برنامه نویسی داشته باشید که با حرارت خاصی از داکر صحبت می کنند و اینکه فلان پروژه را اصطلاحا داکریزه[2] کرده اند و چه و چه. ولی وقتی بخواهند داکر را به صورت قابل فهم برای یک فرد که سطح متوسطی از دانش فناوری اطلاعات رو داره توضیح بدن، دچار مضیقه می شوند. در این مقاله می خواهم از داکر و تمام عظمت آن به طور خلاصه و قابل فهم رمز زدایی کرده و آن را برایتان تبیین کنم.

احتمالا شما نیز این جمله را زیاد از برنامه نویس های مختلف شنیده باشید که : «برنامه در کامپیوتر من کار می کنه ها، نمی دونم چرا در کامپیوتر شما کار نمی کنه». یکی از اهدافی که در روندهای جدید پروژه های توسعه نرم افزار دنبال می شود، آن است که بتوان نرم افزارها را به سرعت، به راحتی و قابل اعتماد[3] (یعنی بدون خرابی[4]) در پلتفرم[5]ها و محیط(شامل توسعه، بتا/تست، و عملیاتی) های مختلف توسعه داد، تست کرد، استقرار[6] داد و اجرا نمود.

یکی از راه‌ کارهای تحقق این هدف استفاده از فناوری ماشین مجازی است. ماشین های مجازی به کمک هایپروایزر[7] (مدیر ماشین های مجازی) این امکان را به ما می دهند که یک سرور فیزیکی را به چندین سرور مجازی مجزا تقسیم کنیم به گونه ایکه هر ماشین مجازی می تواند یک کپی کامل از یک سیستم عامل را داشته باشد.

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

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

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

کانتینر چیست؟

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

اما در یک تعریف کامل تر، کانتینر[9] نرم افزاری کوچک، سبک(با کمترین میزان استفاده از منابع محاسباتی) و سریع است که به کمک آن می توان کد یک نرم افزار را به همراه تمامی وابستگی ها و جزئیات پیکربندیش در قالب یک بسته استاندارد شده و قابل حمل جمع آوری نمود به گونه ایکه به سرعت، به راحتی و قابل اعتماد (یعنی بدون خرابی) بتوان آن را در پلتفرم ها و محیط(شامل توسعه، بتا/تست، و عملیاتی) های مختلف توسعه داد، تست کرد، استقرار داد و اجرا نمود.

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

استفاده از کانتینرها برای استقرار اپلیکیشن ها را اصطلاحا کانتینریزاسیون[10] می نامند.

کانتینریزاسیون به طور فزاینده ای درحال محبوب شدن است چونکه کانتینرها :

• انعطاف پذیرند: پیچیده ترین اپلیکیشن ها را نیز می توان کانتینریزه نمود،
• سبک اند: کانتینرها از هسته سیستم عامل ماشین میزبان استفاده می کنند و آن را در بین خود به اشتراک می گذارند، لذا نسبت به ماشین های مجازی از لحاظ منابع سیستمی مورد نیاز کارآمدترند،
• قابل حمل اند: می توانید آن ها را در محیط لوکال خود بسازید، در زیرساخت ابری استقرار دهید، و در هر جایی اجرایشان کنید.
• حداقل کوپل شدگی[11] را دارند: کانتینرها کاملا کپسوله[12] و بسیار خود بسنده[13] هستند، لذا شما می توانید یکی از آن ها را بدون مختل کردن عملکرد سایر کانتینرها جایگزین کنید یا ارتقا[14] دهید،
• مقیاس پذیر[15] ند: می توان نسخه های المثنی[16] برای کانتینرها ایجاد نمود و به طور خودکار آن ها را در یک دیتاسنتر نوعی توزیع و توزین نمود،
• ایمن اند: کانتینرها برای ایزوله سازی فرایند ها محدودیت های اجباری[17] را به کار می برند بدون اینکه نیاز باشد هیچگونه پیکر بندی خاصی توسط کاربر انجام شود.

داکر چیست؟

داکر[18] یک پلتفرم متن باز کانتینریزاسیون است. علاوه بر پلتفرم بودن، داکر یک مجموعه ابزار هم دارد که برنامه نویسان و مدیران سیستم[19] را قادر می سازد تا به کمک دستورات ساده و فرآیندهای خودکار اقدام به مدیریت چرخه حیات کانتینرها و به طور دقیق تر اقدام به ساخت، استقرار، اجرا، توقف، بروز رسانی، و حذف کانتینرها نمایند. هر چند که بدون داکر هم می توان مجموعه عملیات مذکور را انجام داد، اما داکر انجام آن ها را آسان تر، ساده تر، و ایمن تر می کند.

یک کاربرد نوعی از داکر را می توان در قالب سناریوی زیر بیان کرد:

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

ماهیت سبک و قابل حمل داکر، مدیریت پویای بار و ظرفیت کاری[20] سیستم های نرم افزاری را بسیار ساده می کند، طوریکه می توان بر اساس نیاز های کسب و کار و به صورت تقریبا بلادرنگ، ظرفیت اپلیکیشن ها و سرویس ها را افزایش یا کاهش داد.

کانتینر چیز جدیدی نیست، اما استفاده از آن برای استقرار آسان اپلیکیشن ها جدید است. نخستین فناوری های مرتبط با کانتینر سال ها و حتی دهه ها پیش از سال 2013 که داکر به صورت یک پروژه متن باز به نام «موتور داکر[21]» و تحت لیسانس Apache 2.0 برای عموم منتشر شود، وجود داشتند. در بین آن فناوری ها به طور ویژه می توان از (LXC (LinuX Containers که در سال 2008 در کرنل لینوکس پیاده سازی شده بود و امکان مجازی سازی کامل یک نمونه[22] از سیستم عامل لینوکس را فراهم می کرد، نام برد. در نسخه های اولیه داکر منحصرا از فناوری LXC استفاده می شد اما داکر خیلی زود فناوری اختصاصی کانتینریزاسیون خود را با ویژگی های منحصر به فرد توسعه داد.

هر چند که در حال حاضر داکر محبوب ترین فناوری کانتینریزاسیون است، اما از دیگر گزینه های موجود برای کار با کانتینرها می توان به RKT از CoreOS، LXC، LXD از Canonical، OpenVZ، Jails، و کانتینرهای ویندوزی اشاره نمود.

موتور داکر

موتور داکر یک اپلیکیشن کلاینت-سروری و شامل مؤلفه های اصلی زیر می باشد:

• سرور: یک پروسه[23] که برای مدت طولانی در زمینه[24] در حال اجراست و وظیفه اش ساخت و مدیریت آبجکت های داکر مثل ایمِج[25] ها، کانتینرها، شبکه ها، و توده های داده[26] می باشد. به این پروسه اصطلاحا دیمن[27] داکر می گویند (دستور dockerd) که نقش قلب موتور داکر را ایفا می کند،
• واسط REST API: واسط لازم برای صحبت کردن با دیمن داکر و فرمان دادن به آن را تعیین می کند،
• کلاینت: یک اپلیکیشن از نوع واسط خط فرمان[28] است که آن را Docker CLI می نامند (دستور docker). ما برای کنترل یا تعامل با دیمن داکر، از طریق دستورات مستقیم یا اسکریپت[29] نویسی با کلاینت صحبت می کنیم، کلاینت هم به نوبه خود با REST API صحبت می کند، نهایتا REST API هم با دیمن داکر صحبت می کند. Docker CLI کلاینت رسمی داکر برای برقراری ارتباط با دیمن داکر است اما علاوه بر آن کلاینت های غیر رسمی دیگری مثل ترمینال Dry نیز برای این منظور وجود دارد که بعضا امکانات بیشتری هم نسبت به کلاینت رسمی داکر دارند مثل امکان مانیتورینگ کانتینرها در ترمینال.

معماری داکر

داکر از یک معماری کلاینت-سرور بهره می برد. کلاینت داکر با دیمن که کار سنگین ساخت، اجرا و توزیع کانتینرهای داکر را به دوش دارد، صحبت می کند. کلاینت و دیمن داکر می توانند هر دو روی یک ماشین اجرا شوند، یا اینکه کلاینت داکر می تواند به یک دیمن ریموت متصل شود. داکر برای صحبت کردن با دیمن یک REST API و همچنین SDK-هایی مخصوص زبان های برنامه نویسی GO و Python (برای سایر زبان های برنامه نویسی نیز کتابخانه های غیر رسمی وجود دارد که توسط داکر تست نشده اند) فراهم کرده است. در صورتیکه زبان های برنامه نویسی GO و Pythonمناسب کار شما نیست می توانید مستقیما REST API را بر روی سوکت های [30] UNIX یا سوکت های [31] TCP/IP استفاده کنید. برای فراخوانی این API می توان از یک کلاینت HTTP مثل wget یا curl، و یا از یک کتابخانه HTTP که امروزه دیگر بخشی از اکثر زبان های مدرن برنامه نویسی است، استفاده نمود. در ادامه به طور خلاصه به معرفی هر یک از مؤلفه های موجود در معماری داکر مطابق شکل زیر می پردازیم:

دیمن داکر

دیمن داکر (dockerd) به درخواست های فراخوانی API گوش می دهد و کار مدیریت آبجکت های داکر مثل ایمِج ها، کانتینرها، شبکه ها، و توده های داده را انجام می دهد. یک دیمن همچنین می تواند به منظور مدیریت سرویس های داکر، با دیمن های دیگر ارتباط برقرار کند.

کلاینت داکر

کلاینت داکر (docker) اصلی ترین مکانیزمی است که اکثر کاربران برای تعامل با دیمن داکر از آن استفاده می کنند. وقتی دستوراتی مثل docker run را در کلاینت وارد می کنیم، کلاینت نیز آن دستورات را برای اجرا شدن به dockerd ارسال می کند. دستور docker از API داکر استفاده می کند. یک کلاینت داکر همچنین می تواند با بیش از یک دیمن ارتباط برقرار کند.

رجیستری های داکر

وظیفه یک رجیستری داکر ذخیره ایمِج های داکر است. هاب داکر[32] یک رجیستری عمومی است که هر شخصی می تواند از آن استفاده کند. برای توسعه دهندگان نرم افزارها، هاب داکر نقطه شروع است. با ایجاد یک حساب کاربری در هاب داکر می توانید از میلیون ها ایمِج داکر در دسترس از انجمن رسمی داکر و نیز ناشران مورد تایید آن استفاده نمائید یا اینکه ایمِج های خودتان را با سایرین به اشتراک بگذارید. داکر طوری پیکر بندی شده است که به طور پیش فرض ایمِج ها را در هاب داکر جستجو کند. اما علاوه بر رجیستری عمومی داکر می توانیم رجیستری خصوصی نیز برای خود داشته باشیم.

وقتی از دستور docker pull یا docker run استفاده می کنید، ایمِج های مورد نیاز از رجیستری پیکر بندی شده توسط شما، واکشی خواهند شد. وقتی هم که از دستور docker push استفاده می کنیم، ایمِج مورد نظر در رجیستری پیکر بندی شده توسط شما قرار داده خواهد شد.

آبجکت های داکر

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

ایمِج ها

ایمِج یک قالب از نوع فقط-خواندنی[33] است و دستورالعمل های ساخت یک کانتینر داکر را در خود جای می دهد. غالبا یک ایمِج نوعی، نسخه سفارشی سازی شده از یک ایمِج پایه دیگر است. به عنوان مثال، ممکن است شما یک ایمِج بر پایه ایمِج سیستم عامل ابونتو[34] بسازید، اما در آن وب سرور آپاچی و اپلیکیشن تان را به همراه جزئیات پیکر بندی مورد نیاز جهت اجرا شدن آن نیز نصب نمائید. بنابراین ایمِج یک بسته سبک، مستقل، و قابل اجرا از یک نرم افزار است و تمام مواردیکه برای اجرای آن نرم افزار نیاز است مثل کد، محیط اجرا[35]، ابزارهای سیستمی، کتابخانه ها و تنظیمات سیستمی، و فایل های پیکربندی را در خود دارد.

ممکن است شما بخواهید ایمِج خودتان را بسازید یا اینکه فقط از ایمِج های ساخته شده و منتشر شده توسط دیگران بر روی یک رجیستری خاص داکر استفاده نمائید. برای ساخت ایمِج خودتان باید با استفاده از یک نحو[36] ساده مراحل مورد نیاز برای ساخت و اجرای ایمِج را به صورت یک فایل داکر[37] که یک فایل متنی خاص است، ایجاد کنید. هر دستورالعمل در فایل داکر، یک لایه مجزا در ایمِج ایجاد می کند. وقتی که تغییری در فایل داکر می دهید و آن ایمِج را بازسازی[38] می کنید، فقط لایه های تغییر داده شده از نو ساخته خواهند شد. این قابلیت جزئی از چیزیست که باعث می شود ایمِج ها نسبت به سایر فناوری های مجازی سازی سبک تر، کوچک تر، و سریع تر باشند.

کانتینرها

کانتینر یک نمونه قابل اجرا از یک ایمِج است. شما می توانید با استفاده از API داکر یا CLI اقدام به ساخت، راه اندازی، توقف، جابجایی یا حذف یک کانتینر نمائید. یک کانتینر را می توان به یک یا چند شبکه متصل نمود، فضای ذخیره سازی به آن اضافه نمود، یا حتی ایمِج دیگری را بر اساس وضعیت کنونی آن ایجاد نمود.

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

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

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

مثالی از دستور docker run

دستور زیر یک کانتینر Ubuntu را اجرا می کند، و آن را به سشن[40] خط فرمان تان الصاق و مرتبط می کند، و /bin/bash که شل[41] پیش فرض برای لاگین کاربر به لینوکس است را اجرا می کند:

$ docker run -i -t ubuntu /bin/bash

زمانیکه این دستور را اجرا می کنید، موارد زیر رخ می دهند(فرض بر این است که شما در پیکر بندی تان از رجیستری پیش فرض داکر یعنی داکر هاب استفاده می کنید):

1. در صورتیکه ایمِج ubuntu را در لوکال خودتان نداشته باشید، داکر ابتدا آن را از رجیستری پیکر بندی شده ی شما واکشی می کند، درست مثل اینکه خودتان به طور دستی دستور docker pull ubuntu را اجرا کرده باشید.

2. داکر یک کانتینر جدید می سازد، درست مثل اینکه خودتان به طور دستی دستور docker container create را اجرا کرده باشید.

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

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

5. داکر کانتینر را راه اندازی کرده و /bin/bash را اجرا می کند. از آنجاییکه کانتینر به صورت تعاملی در حال اجراست و ترمینال تان هم به آن متصل است (به خاطر پرچم های i- و t-)، شما می توانید از طریق صفحه کلید به آن ورودی بدهید و لاگ[42] خروجی را در ترمینال مشاهده نمائید.

6. زمانیکه دستور exit را برای خاتمه دادن به /bin/bash بنویسید، کانتینر متوقف می شود ولی حذف نخواهد شد. شما می توانید مجددا آن را راه اندازی یا حذف کنید.

سرویس ها

سرویس ها به شما این امکان را می دهند که کانتینرها را در چندین دیمن داکر یا اصطلاحا نود[43] داکر توزین[44] کنید، در این حالت همه دیمن ها با هم به صورت یک کل به نام [45] swarm(بخوانید اس وارم) کار خواهند کرد و بهره بردار سرویس آن را به صورت یک اپلیکیشن واحد خواهد دید. هر دیمن داکر در حالت swarm یک نود مدیر[46] یا یک نود کارگزار[47] یا هر دوی آن ها خواهد بود. سرویس در حقیقت عبارتست از تعریف وظایفی[48] که باید در نودهای مدیر یا کارگزار اجرا شوند. کاربر می تواند به طور پویا یک نود را از نوع کارگزار به نوع مدیر ارتقا دهد یا اینکه یک نود از نوع مدیر را به نوع کارگزار تقلیل دهد. در سرویس علاوه بر خود وظایف، نحوه اجرا و به روز رسانی آن ها نیز تعریف می شود.

سرویس ساختار مرکزی سیستم swarm و نقطه اصلی تعامل کاربر با آن می باشد. داخل swarm دیمن ها از طریق API داکر با هم صحبت می کنند. swarm مکانیزم بومی و مخصوص[49] خود داکر برای هماهنگی[50] و مدیریت یک گروه[51] از موتور های داکر (یا اصطلاحا نود های داکر) است. کوبرنتیز[52] ابزار غیر بومی اما متن باز دیگریست که توسط شرکت گوگل توسعه داده شده است و معمولا در سناریوهای پیچیده مدیریت و هماهنگی گروهی از نودهای داکر استفاده می شود.

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

فناوری های بنیادین و زیربنایی داکر

قبل تر ذیل عنوان داکر توضیح داده شد که سال های پیش از آنکه داکر برای استفاده عموم منتشر شود فناوری های مرتبط با داکر وجود داشتند. در این قسمت به طور خلاصه به آن می پردازیم. داکر با زبان GO نوشته شده است و برای ارائه کارکردهایش از قابلیت های مختلف هسته سیستم عامل لینوکس بهره می برد.

فضاهای نام[53]

داکر برای فراهم نمودن فضاهای کاری ایزوله یا همان کانتینر، از یک فناوری به نام namespaces استفاده می کند. وقتی کانتینری را اجرا می کنید، داکر مجموعه ای از فضاهای نام را برای آن کانتینر ایجاد می کند.

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

موتور داکر از فضاهای نام لینوکسی زیر استفاده می کند:

• فضای نام pid : ایزوله سازی پروسه ها (PID: Process ID)
• فضای نام net : مدیریت واسط های شبکه (NET: Networking)
• فضای نام ipc : مدیریت دسترسی به منابع IPC یا همان منابع سیستم عامل مثل صف های پیام[54]، حافظه مشترک[55]، و سمافورها[56] (IPC: Inter-Process Communication)
• فضای نام mnt : مدیریت نقاط یا دایرکتوری های معرفی[57] سیستم فایل به سیستم عامل (MNT: Mount)
• فضای نام uts : به اشتراک گذاری هسته سیستم عامل بین فرآیندهای مختلف (UTS: Unix Timesharing System)

گروه های کنترلی[58]

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

سیستم فایل های مجتمع[59]

سیستم فایل های از نوع مجتمع یا اصطلاحا UnionFS، سیستم فایل هایی هستند که با مکانیزم لایه سازی عمل می کنند ویژگی ایکه آن ها را بسیار سبک و سریع می کند. به طور خیلی ساده سیستم فایل مجتمع از یک سری لایه تشکیل شده است و هر زمانیکه تغییری در سیستم فایل (مثلا تغییر نام یک فایل یا دایرکتوری خاص) به وجود آید، آن تغییر در یک لایه جدید در بالای تمام لایه های دیگر ثبت می شود. به کمک این نوع از سیستم فایل می توان فایل ها و دایرکتوری های سیستم فایل های مجزا از هم را در اختیار گرفت و از محتوای آن ها یک اجتماع منسجم در بالاترین لایه ایجاد نمود به این صورت که در این لایه تمامی فایل ها و دایرکتوری های با نام و مسیر یکسان در سیستم فایل های مختلف، در یک مسیر جدید در بالاترین لایه ادغام و جایگزین خواهند شد. موتور داکر نیز در مؤلفه های تشکیل دهنده ی کانتینرها از UnionFS استفاده می کند (همانطور که ذیل عنوان ایمِج ها توضیح داده شد، هر دستورالعمل در فایل داکر، یک لایه مجزا در ایمِج ایجاد می کند، و زمانیکه تغییری در فایل داکر می دهید و آن ایمِج را بازسازی می کنید، فقط لایه های تغییر داده شده از نو ساخته خواهند شد). موتور داکر استفاده از چندین نوع UnionFS مختلف شامل AUFS، btrfs، vfs، و DeviceMapper را پشتیبانی می کند.

فرمت کانتینر

موتور داکر به منظور تعریف استاندارد مشخصات پیکر بندی کانتینرها و نیز مدیریت چرخه حیات آن ها، از ترکیب فضاهای نام، گروه های کنترلی و سیستم فایل مجتمع در قالب یک پوشش[60] جدید به نام Container Format استفاده می کند. در حال حاضر، libcontainer گزینه پیش فرض داکر برای این منظور است. در آینده ممکن است داکر با هم افزایی فناوری هایی مثل BSD Jails یا Solaris Zones، فرمت های دیگری را نیز پشتیبانی کند.

آنچه در مقاله بعدی خواهید خواند:

• کانتینر ویندوزی یا کانتینر لینوکسی؟ داکر زیر ذره بین

[1] Sysadmin

[2] Dockerize

[3] Reliable

[4] Failure Free

[5] پلتفرم متفاوت از زبان برنامه نویسی است و می تواند یک نرم افزار مثل مرورگر وب، سخت افزار، نرم افزار-سخت افزار، سیستم عامل، ماشین مجازی، ماشین فیزیکی، زیرساخت ابری، و یا هر ترکیبی از این موارد باشد.

[6] Deploy

[7] Hypervisor

[8] Kernel

[9] Container

[10] Containerization

[11] Loosely Coupled

[12] Encapsulated

[13] Self Sufficient

[14] Upgrade

[15] Scalable

[16] Replica

[17] Aggressive Constraints

[18] Docker

[19] Sysadmin

[20] Workload

[21] Docker Engine

[22] Instance

[23] Process

[24] Background

[25] Image

[26] Data Volume

[27] Daemon

[28] Command Line Interface

[29] اسکریپت‌ها برنامه‌های کوچکی هستند که به کمک آن‌ها به راحتی می‌توان برخی از وظایف تکراری و یا طولانی را به طور خودکار انجام داد.

[30] سوکت یونیکس یا IPC Socket یک نوع درگاه مخابراتی داده است که از آن می توان برای انتقال داده ها به صورت دو طرفه بین دو فرایند که هر دو بر روی یک سیستم عامل میزبان اجرا می شوند، استفاده نمود.

[31] سوکت TCP/IP یک نوع درگاه مخابراتی داده است که از آن می توان برای انتقال داده ها به صورت دو طرفه بین دو فرایند بر روی شبکه، استفاده نمود. در برخی مواقع می توان برای انتقال داده ها بین دو فرایند که هر دو بر روی یک سیستم عامل میزبان اجرا می شوند نیز ازین نوع سوکت ها بهره برد اما توصیه می شود در این حالت از سوکت های یونیکس که به دلایل مختلف سریع تر هستند استفاده نمود.

[32] Docker Hub

[33] Read Only

[34] Ubuntu

[35] Runtime

[36] Syntax

[37] Docker file

[38] Rebuild

[39] Memory

[40] Session

[41] Shell

[42] Log

[43] Node

[44] Scale

[45] به فارسی یعنی خوشه، گروه

[46] Manager

[47] Worker

[48] Tasks

[49] Native

[50] Orchestration

[51] Cluster

[52] Kubernetes

[53] Namespaces

[54] Message Queue

[55] Shared Memory

[56] به انگلیسی Semaphore و به فارسی اصطلاحا نشانبر. یکی از ساده ترین مفاهیم سیستم عامل است و به متغیری گفته می شود که در محیط های همروند از آن برای کنترل دسترسی فرآیندها به منابع مشترک استفاده می شود.

[57] Mount

[58] Control Groups

[59] Union File Systems

[60] Wrapper