اگر که یک برنامه نویس یا مدیر سیستم [ ] هستید اما هنوز مهارت و تجربه کار با فناوری را در رزومه خودتون ندارید، بدون شک در این برهه از زمان لازمه که این مهارت ضروری را کسب و به رزومه تون اضافه کنید. شما هم ممکنه مثل من همکاران یا دوستان برنامه نویسی داشته باشید که با حرارت خاصی از داکر صحبت می کنند و اینکه فلان پروژه را اصطلاحا [ ] کرده اند و چه و چه. ولی وقتی بخواهند داکر را به صورت قابل فهم برای یک فرد که سطح متوسطی از دانش فناوری اطلاعات رو داره توضیح بدن، دچار مضیقه می شوند. در این مقاله می خواهم از داکر و تمام عظمت آن به طور خلاصه و قابل فهم رمز زدایی کرده و آن را برایتان تبیین کنم. احتمالا شما نیز این جمله را زیاد از برنامه نویس های مختلف شنیده باشید که: " ". یکی از اهدافی که در روندهای جدید پروژه های توسعه نرم افزار دنبال می شود، آن است که بتوان نرم افزارها را به سرعت، به راحتی و قابل اعتماد [ ] (یعنی بدون خرابی [ ] ) در پلتفرم [ ] ها و محیط (شامل توسعه، بتا/تست، و عملیاتی) های مختلف توسعه داد، تست کرد، استقرار [ ] داد و اجرا نمود. یکی از راه‌کارهای تحقق این هدف استفاده از فناوری ماشین مجازی است. ماشین های مجازی به کمک [ ] (مدیر ماشین های مجازی) این امکان را به ما می دهند که یک سرور فیزیکی را به چندین سرور مجازی مجزا تقسیم کنیم به گونه ایکه هر ماشین مجازی می تواند یک کپی کامل از یک سیستم عامل را داشته باشد. با وجود اینکه ماشین های مجازی مزیت بزرگ امکان اجرای چندین سیستم عامل مختلف یا نسخه های مختلف یک سیستم عامل بر روی یک زیرساخت فیزیکی را فراهم می آورند اما مشکلاتی هم دارند. از جمله اینکه ماشین های مجازی نیاز به فضای ذخیره سازی بزرگی (چند گیگابایت) دارند، منابع محاسباتی زیادی را می توانند مصرف کنند، و زمان بوت شدن آن ها نیز طولانی (چند دقیقه) است. راه کار دیگر که امروزه بسیار محبوب و پرطرفدار است استفاده از فناوری است. کانتینر مستقیما در کرنل [ ] سیستم عامل اجرا می شود. از آنجاییکه که کانتینر ها در عین حالیکه در پروسه های ایزوله اجرا می شوند، می توانند هسته سیستم عامل را بین یکدیگر به اشتراک بگذارند بنابراین چندین کانتینر مختلف می توانند به طور همزمان بر روی یک سیستم عامل میزبان اجرا شوند. کانتینرها نسبت به ماشین های مجازی فضای ذخیره سازی کمتر (معمولا چند مگابایت) نیاز دارند، منابع محاسباتی کمتری را مصرف کنند، و زمان بوت شدن آن ها نیز کوتاه (چند ثانیه) است. بنابراین به کمک کانتینرها می توان حداکثر تعداد نرم افزارها را بر روی حداقل تعداد سرور ها اجرا نمود و در مصرف منابع محاسباتی صرفه جویی گسترده ای را رقم زد. با وجود مزایا و معایب هر یک از فناوری های مورد بحث در بالا، استفاده از کانتینرها و ماشین های مجازی با هم می تواند انعطاف پذیری ویژه ای را برای استقرار و مدیریت نرم افزارها به ارمغان آورد. چیست؟ به عبارت خیلی ساده یعنی: درست مثل اینکه بگوییم یک واحد آپارتمان یا یک دستگاه اتومبیل. اما در یک تعریف کامل تر، کانتینر [ ] نرم افزاری کوچک، سبک (با کمترین میزان استفاده از منابع محاسباتی) و سریع است که به کمک آن می توان کد یک نرم افزار را به همراه تمامی وابستگی ها و جزییات پیکربندیش در قالب یک بسته استاندارد شده و قابل حمل جمع آوری نمود به گونه ایکه به سرعت، به راحتی و قابل اعتماد (یعنی بدون خرابی) بتوان آن را در پلتفرم ها و محیط (شامل توسعه، بتا/تست، و عملیاتی) های مختلف توسعه داد، تست کرد، استقرار داد و اجرا نمود. باید توجه داشته باشید که کانتینرها جزیی از اکوسیستم لینوکس هستند نه ویندوز. لینوکس سیستم عامل بهتری نسبت به ویندوز است، و معماری آن خصوصا کرنل و سیستم فایلش بسیار بهتر از ویندوز است. استفاده از کانتینرها برای استقرار اپلیکیشن ها را اصطلاحا می نامند. کانتینریزاسیون به طور فزاینده ای درحال محبوب شدن است چونکه کانتینرها: : پیچیده ترین اپلیکیشن ها را نیز می توان کانتینریزه نمود، کانتینرها از هسته سیستم عامل ماشین میزبان استفاده می کنند و آن را در بین خود به اشتراک می گذارند، لذا نسبت به ماشین های مجازی از لحاظ منابع سیستمی مورد نیاز کارآمدترند، می توانید آن ها را در محیط لوکال خود بسازید، در زیرساخت ابری استقرار دهید، و در هر جایی اجرایشان کنید. را دارند: کانتینرها کاملا کپسوله [ ] و بسیار خود بسنده [ ] هستند، لذا شما می توانید یکی از آن ها را بدون مختل کردن عملکرد سایر کانتینرها جایگزین کنید یا ارتقا [ ] دهید، ند: می توان نسخه های المثنی [ ] برای کانتینرها ایجاد نمود و به طور خودکار آن ها را در یک دیتاسنتر نوعی توزیع و توزین نمود، کانتینرها برای ایزوله سازی فرایند ها محدودیت های اجباری [ ] را به کار می برند بدون اینکه نیاز باشد هیچگونه پیکر بندی خاصی توسط کاربر انجام شود. داکر چیست؟ داکر [ ] یک پلتفرم متن باز کانتینریزاسیون است. علاوه بر پلتفرم بودن، داکر یک مجموعه ابزار هم دارد که برنامه نویسان و مدیران سیستم [ ] را قادر می سازد تا به کمک دستورات ساده و فرآیندهای خودکار اقدام به مدیریت چرخه حیات کانتینرها و به طور دقیق تر اقدام به ساخت، استقرار، اجرا، توقف، بروز رسانی، و حذف کانتینرها نمایند. هر چند که بدون داکر هم می توان مجموعه عملیات مذکور را انجام داد، اما داکر انجام آن ها را آسان تر، ساده تر، و ایمن تر می کند. یک کاربرد نوعی از داکر را می توان در قالب سناریوی زیر بیان کرد: توسعه دهندگان کد نرم افزار را در محیط توسعه لوکال خودشان می نویسند و کارشان را با استفاده از کانتینرهای داکر با سایر همکارانشان به اشتراک می گذارند، برای اجرای انواع تست های خودکار و غیرخودکار بر روی نرم افزار، تنها کافیست تا کانتینر مربوط را از محیط توسعه به محیط بتا/تست منتقل کرده و با استفاده از داکر آن را در آنجا استقرار دهند، اگر توسعه دهندگان، اشکال نرم افزاری خاصی را پیدا کنند، می توانند آن را در محیط توسعه لوکال خود برطرف کرده و مجددا کانتینر مربوط را به محیط تست منتقل، و آزمون های اعتبار سنجی لازم را بر روی آن اجرا کنند، تست نرم افزار که تمام شد، تحویل آن به مشتری به سادگی انتقال کانتینر به روز رسانی شده به محیط عملیاتی و نهایتا استقرار آن توسط داکر است. ماهیت سبک و قابل حمل داکر، مدیریت پویای بار و ظرفیت کاری [ ] سیستم های نرم افزاری را بسیار ساده می کند، طوریکه می توان بر اساس نیاز های کسب و کار و به صورت تقریبا بلادرنگ، ظرفیت اپلیکیشن ها و سرویس ها را افزایش یا کاهش داد. کانتینر چیز جدیدی نیست، اما استفاده از آن برای استقرار آسان اپلیکیشن ها جدید است. نخستین فناوری های مرتبط با کانتینر سال ها و حتی دهه ها پیش از سال که داکر به صورت یک پروژه متن باز به نام " [ ] " و تحت لیسانس Apache . برای عموم منتشر شود، وجود داشتند. در بین آن فناوری ها به طور ویژه می توان از ( LXC ( inu ontainers که در سال در کرنل لینوکس پیاده سازی شده بود و امکان مجازی سازی کامل یک نمونه [ ] از سیستم عامل لینوکس را فراهم می کرد، نام برد. در نسخه های اولیه داکر منحصرا از فناوری LXC استفاده می شد اما داکر خیلی زود فناوری اختصاصی کانتینریزاسیون خود را با ویژگی های منحصر به فرد توسعه داد. هر چند که در حال حاضر داکر محبوب ترین فناوری کانتینریزاسیون است، اما از دیگر گزینه های موجود برای کار با کانتینرها می توان به RKT از CoreOS ، LXC ، LXD از Canonical ، OpenVZ ، Jails ، و کانتینرهای ویندوزی اشاره نمود. موتور داکر یک اپلیکیشن کلاینت - سروری و شامل مولفه های اصلی زیر می باشد: یک پروسه [ ] که برای مدت طولانی در زمینه [ ] در حال اجراست و وظیفه اش ساخت و مدیریت آبجکت های داکر مثل ایم ج [ ] ها، کانتینرها، شبکه ها، و توده های داده [ ] می باشد. به این پروسه اصطلاحا دیمن [ ] داکر می گویند (دستور dockerd ) که نقش قلب موتور داکر را ایفا می کند، واسط لازم برای صحبت کردن با دیمن داکر و فرمان دادن به آن را تعیین می کند، یک اپلیکیشن از نوع واسط خط فرمان [ ] است که آن را Docker CLI می نامند (دستور docker ) ما برای کنترل یا تعامل با دیمن داکر، از طریق دستورات مستقیم یا اسکریپت [ ] نویسی با کلاینت صحبت می کنیم، کلاینت هم به نوبه خود با REST API صحبت می کند، نهایتا REST API هم با دیمن داکر صحبت می کند. Docker CLI کلاینت رسمی داکر برای برقراری ارتباط با دیمن داکر است اما علاوه بر آن کلاینت های غیر رسمی دیگری مثل ترمینال Dry نیز برای این منظور وجود دارد که بعضا امکانات بیشتری هم نسبت به کلاینت رسمی داکر دارند مثل امکان مانیتورینگ کانتینرها در ترمینال. معماری داکر داکر از یک معماری کلاینت - سرور بهره می برد. کلاینت داکر با دیمن که کار سنگین ساخت، اجرا و توزیع کانتینرهای داکر را به دوش دارد، صحبت می کند. کلاینت و دیمن داکر می توانند هر دو روی یک ماشین اجرا شوند، یا اینکه کلاینت داکر می تواند به یک دیمن ریموت متصل شود. داکر برای صحبت کردن با دیمن یک REST API و همچنین SDK - هایی مخصوص زبان های برنامه نویسی GO و Python (برای سایر زبان های برنامه نویسی نیز کتابخانه های غیر رسمی وجود دارد که توسط داکر تست نشده اند) فراهم کرده است. در صورتیکه زبان های برنامه نویسی GO و Python مناسب کار شما نیست می توانید مستقیما REST API را بر روی سوکت های [ ] UNIX یا سوکت های [ ] TCP / IP استفاده کنید. برای فراخوانی این API می توان از یک کلاینت HTTP مثل wget یا curl ، و یا از یک کتابخانه HTTP که امروزه دیگر بخشی از اکثر زبان های مدرن برنامه نویسی است، استفاده نمود. در ادامه به طور خلاصه به معرفی هر یک از مولفه های موجود در معماری داکر مطابق شکل زیر می پردازیم: دیمن داکر ( dockerd ) به درخواست های فراخوانی API گوش می دهد و کار مدیریت آبجکت های داکر مثل ایم ج ها، کانتینرها، شبکه ها، و توده های داده را انجام می دهد. یک دیمن همچنین می تواند به منظور مدیریت سرویس های داکر، با دیمن های دیگر ارتباط برقرار کند. کلاینت داکر ( docker ) اصلی ترین مکانیزمی است که اکثر کاربران برای تعامل با دیمن داکر از آن استفاده می کنند. وقتی دستوراتی مثل docker run را در کلاینت وارد می کنیم، کلاینت نیز آن دستورات را برای اجرا شدن به dockerd ارسال می کند. دستور docker از API داکر استفاده می کند. یک کلاینت داکر همچنین می تواند با بیش از یک دیمن ارتباط برقرار کند. وظیفه یک رجیستری داکر ذخیره ایم ج های داکر است. هاب داکر [ ] یک رجیستری عمومی است که هر شخصی می تواند از آن استفاده کند. برای توسعه دهندگان نرم افزارها، هاب داکر نقطه شروع است. با ایجاد یک حساب کاربری در هاب داکر می توانید از میلیون ها ایم ج داکر در دسترس از انجمن رسمی داکر و نیز ناشران مورد تایید آن استفاده نمایید یا اینکه ایم ج های خودتان را با سایرین به اشتراک بگذارید. داکر طوری پیکر بندی شده است که به طور پیش فرض ایم ج ها را در هاب داکر جستجو کند. اما علاوه بر رجیستری عمومی داکر می توانیم رجیستری خصوصی نیز برای خود داشته باشیم. وقتی از دستور docker pull یا docker run استفاده می کنید، ایم ج های مورد نیاز از رجیستری پیکر بندی شده توسط شما، واکشی خواهند شد. وقتی هم که از دستور docker push استفاده می کنیم، ایم ج مورد نظر در رجیستری پیکر بندی شده توسط شما قرار داده خواهد شد. زمانیکه از داکر استفاده می کنیم، در حقیقت در حال ساخت و استفاده از ایم ج ها، کانتینرها، شبکه ها، توده های داده، پلاگین ها، و سایر آبجکت های داکر هستیم. ایم ج یک قالب از نوع فقط - خواندنی [ ] است و دستورالعمل های ساخت یک کانتینر داکر را در خود جای می دهد. غالبا یک ایم ج نوعی، نسخه سفارشی سازی شده از یک ایم ج پایه دیگر است. به عنوان مثال، ممکن است شما یک ایم ج بر پایه ایم ج سیستم عامل ابونتو [ ] بسازید، اما در آن وب سرور آپاچی و اپلیکیشن تان را به همراه جزییات پیکر بندی مورد نیاز جهت اجرا شدن آن نیز نصب نمایید. بنابراین ایم ج یک بسته سبک، مستقل، و قابل اجرا از یک نرم افزار است و تمام مواردیکه برای اجرای آن نرم افزار نیاز است مثل کد، محیط اجرا [ ] ، ابزارهای سیستمی، کتابخانه ها و تنظیمات سیستمی، و فایل های پیکربندی را در خود دارد. ممکن است شما بخواهید ایم ج خودتان را بسازید یا اینکه فقط از ایم ج های ساخته شده و منتشر شده توسط دیگران بر روی یک رجیستری خاص داکر استفاده نمایید. برای ساخت ایم ج خودتان باید با استفاده از یک نحو [ ] ساده مراحل مورد نیاز برای ساخت و اجرای ایم ج را به صورت یک فایل داکر [ ] که یک فایل متنی خاص است، ایجاد کنید. هر دستورالعمل در فایل داکر، یک لایه مجزا در ایم ج ایجاد می کند. وقتی که تغییری در فایل داکر می دهید و آن ایم ج را بازسازی [ ] می کنید، فقط لایه های تغییر داده شده از نو ساخته خواهند شد. این قابلیت جزیی از چیزیست که باعث می شود ایم ج ها نسبت به سایر فناوری های مجازی سازی سبک تر، کوچک تر، و سریع تر باشند. کانتینر یک نمونه قابل اجرا از یک ایم ج است. شما می توانید با استفاده از API داکر یا CLI اقدام به ساخت، راه اندازی، توقف، جابجایی یا حذف یک کانتینر نمایید. یک کانتینر را می توان به یک یا چند شبکه متصل نمود، فضای ذخیره سازی به آن اضافه نمود، یا حتی ایم ج دیگری را بر اساس وضعیت کنونی آن ایجاد نمود. به طور پیش فرض، یک کانتینر به طور کامل از سایر کانتینرها و نیز ماشین میزبانش ایزوله است. شما می توانید چگونه ایزوله بودن شبکه، فضای ذخیره سازی یا حتی زیر سیستم های یک کانتینر از سایر کانتینرها یا از ماشین میزبان را کنترل کنید. یک کانتینر از روی ایم ج اش و نیز هر گونه پیکر بندی که موقع ساخت یا اجرا کردنش برایش فراهم می کنیم، تعریف می شود. وقتی کانتینری حذف می شود، هر گونه تغییری در وضعیت آن که بر روی فضای ذخیره سازی نگهداری نشده باشد، از بین خواهد رفت. گاهی از اوقات اصطلاحات کانتینر داکر و ایم ج داکر اشتباهی به جای یکدیگر استفاده می شوند، در صورتیکه با هم فرق دارند. همانطور که در بالا گفته شد کانتینر یک نمونه از ایم ج در محیط اجراست یعنی ایم ج ها وقتی توسط موتور داکر اجرا شوند تبدیل به کانتینر می شوند و در حافظه [ ] قرار می گیرند. بنابراین به طور خلاصه وقتیکه فایل داکر نوشته شد با آن می توان ایم ج را ساخت و از روی ایم ج می توان کانتینر را ساخت و اجرا نمود که همه این کارها توسط موتور داکر انجام می شود. docker run دستور زیر یک کانتینر Ubuntu را اجرا می کند، و آن را به سشن [ ] خط فرمان تان الصاق و مرتبط می کند، و/ bin / bash که شل [ ] پیش فرض برای لاگین کاربر به لینوکس است را اجرا می کند: زمانیکه این دستور را اجرا می کنید، موارد زیر رخ می دهند (فرض بر این است که شما در پیکر بندی تان از رجیستری پیش فرض داکر یعنی داکر هاب استفاده می کنید) : . در صورتیکه ایم ج ubuntu را در لوکال خودتان نداشته باشید، داکر ابتدا آن را از رجیستری پیکر بندی شده ی شما واکشی می کند، درست مثل اینکه خودتان به طور دستی دستور docker pull ubuntu را اجرا کرده باشید. . داکر یک کانتینر جدید می سازد، درست مثل اینکه خودتان به طور دستی دستور docker container create را اجرا کرده باشید. . داکر یک سیستم فایل با قابلیت خواندن - نوشتن را، به عنوان لایه پایانی به آن کانتینر اختصاص می دهد. این کار یک کانتینر در حال اجرا را قادر می سازد تا فایل ها و دایرکتوری ها را در سیستم فایل لوکال خودش ایجاد یا دست کاری کند، . از آنجاییکه قبلا هیچ گزینه ای را برای پیکر بندی شبکه آن کانتینر مشخص ننموده اید، داکر برای آن یک واسط شبکه جهت اتصال به شبکه پیش فرض را ایجاد می کند. این عمل داکر شامل اختصاص آی پی به آن کانتینر هم می شود. به طور پیش فرض، کانتینرها می توانند از طریق ارتباط شبکه ای ماشین میزبان به شبکه های بیرونی نیز متصل شوند. . داکر کانتینر را راه اندازی کرده و/ bin / bash را اجرا می کند. از آنجاییکه کانتینر به صورت تعاملی در حال اجراست و ترمینال تان هم به آن متصل است (به خاطر پرچم های i - و t - ) ، شما می توانید از طریق صفحه کلید به آن ورودی بدهید و لاگ [ ] خروجی را در ترمینال مشاهده نمایید. . زمانیکه دستور exit را برای خاتمه دادن به/ bin / bash بنویسید، کانتینر متوقف می شود ولی حذف نخواهد شد. شما می توانید مجددا آن را راه اندازی یا حذف کنید. سرویس ها به شما این امکان را می دهند که کانتینرها را در چندین دیمن داکر یا اصطلاحا نود [ ] داکر توزین [ ] کنید، در این حالت همه دیمن ها با هم به صورت یک کل به نام [ ] (بخوانید اس وارم) کار خواهند کرد و بهره بردار سرویس آن را به صورت یک اپلیکیشن واحد خواهد دید. هر دیمن داکر در حالت swarm یک نود مدیر [ ] یا یک نود کارگزار [ ] یا هر دوی آن ها خواهد بود. سرویس در حقیقت عبارتست از تعریف وظایفی [ ] که باید در نودهای مدیر یا کارگزار اجرا شوند. کاربر می تواند به طور پویا یک نود را از نوع کارگزار به نوع مدیر ارتقا دهد یا اینکه یک نود از نوع مدیر را به نوع کارگزار تقلیل دهد. در سرویس علاوه بر خود وظایف، نحوه اجرا و به روز رسانی آن ها نیز تعریف می شود. سرویس ساختار مرکزی سیستم swarm و نقطه اصلی تعامل کاربر با آن می باشد. داخل swarm دیمن ها از طریق API داکر با هم صحبت می کنند. مکانیزم بومی و مخصوص [ ] خود داکر برای هماهنگی [ ] و مدیریت یک گروه [ ] از موتور های داکر (یا اصطلاحا نود های داکر) است. [ ] ابزار غیر بومی اما متن باز دیگریست که توسط شرکت گوگل توسعه داده شده است و معمولا در سناریوهای پیچیده مدیریت و هماهنگی گروهی از نودهای داکر استفاده می شود. از طریق سرویس ها می توان جزء به جزء حالت موردنظر را تعریف کرد. وقتی یک سرویس را ایجاد می کنیم در حقیقت حالت بهینه آن را تعریف می کنیم مثل تعداد نسخه های المثنی که بایستی در هر زمانی در دسترس باشند، منابع شبکه و ذخیره سازی که در دسترسش خواهد بود، پورت هاییکه برای بیرون باید باز باشد، و. به طور پیش فرض، اجرای سرویس بین تمام نودهای کارگزار توزیع بار می شود. نکته پایانی اینکه موتور داکر حالت swarm را در نسخه . به بعد داکر پشتیبانی می کند. قبل تر ذیل عنوان داکر توضیح داده شد که سال های پیش از آنکه داکر برای استفاده عموم منتشر شود فناوری های مرتبط با داکر وجود داشتند. در این قسمت به طور خلاصه به آن می پردازیم. داکر با زبان GO نوشته شده است و برای ارایه کارکردهایش از قابلیت های مختلف هسته سیستم عامل لینوکس بهره می برد. داکر برای فراهم نمودن فضاهای کاری ایزوله یا همان کانتینر، از یک فناوری به نام namespaces استفاده می کند. وقتی کانتینری را اجرا می کنید، داکر مجموعه ای از فضاهای نام را برای آن کانتینر ایجاد می کند. این فضاهای نام یک لایه ایزوله ایجاد می کنند. هر جنبه از یک کانتینر در یک فضای نام مجزا و با دسترسی محدود به آن اجرا می شود. موتور داکر از فضاهای نام لینوکسی زیر استفاده می کند: فضای نام pid : ایزوله سازی پروسه ها ( PID : Process ID ) فضای نام net : مدیریت واسط های شبکه ( NET : Networking ) فضای نام ipc : مدیریت دسترسی به منابع IPC یا همان منابع سیستم عامل مثل صف های پیام [ ] ، حافظه مشترک [ ] ، و سمافورها [ ] ( IPC : Inter - Process Communication ) فضای نام mnt : مدیریت نقاط یا دایرکتوری های معرفی [ ] سیستم فایل به سیستم عامل ( MNT : Mount ) فضای نام uts : به اشتراک گذاری هسته سیستم عامل بین فرآیندهای مختلف ( UTS : Unix Timesharing System ) موتور داکر در لینوکس به فناوری دیگری به نام cgroups نیز متکی است. این فناوری در سال توسط مهندسان گوگل در سیستم عامل لینوکس ابداع شد. یک cgroup ، یک اپلیکیشن را محدود به مجموعه خاصی از منابع می کند. گروه های کنترلی، موتور داکر را قادر می سازند تا منابع سخت افزاری موجود را بین کانتینرها به اشتراک بگذارد و به طور انتخابی محدودیت ها و قیدهایی را نیز برایشان الزام کند. به عنوان مثال شما می توانید ظرفیت حافظه در دسترس یک کانتینر خاص را محدود کنید. سیستم فایل های از نوع مجتمع یا اصطلاحا UnionFS ، سیستم فایل هایی هستند که با مکانیزم لایه سازی عمل می کنند ویژگی ایکه آن ها را بسیار سبک و سریع می کند. به طور خیلی ساده سیستم فایل مجتمع از یک سری لایه تشکیل شده است و هر زمانیکه تغییری در سیستم فایل (مثلا تغییر نام یک فایل یا دایرکتوری خاص) به وجود آید، آن تغییر در یک لایه جدید در بالای تمام لایه های دیگر ثبت می شود. به کمک این نوع از سیستم فایل می توان فایل ها و دایرکتوری های سیستم فایل های مجزا از هم را در اختیار گرفت و از محتوای آن ها یک اجتماع منسجم در بالاترین لایه ایجاد نمود به این صورت که در این لایه تمامی فایل ها و دایرکتوری های با نام و مسیر یکسان در سیستم فایل های مختلف، در یک مسیر جدید در بالاترین لایه ادغام و جایگزین خواهند شد. موتور داکر نیز در مولفه های تشکیل دهنده ی کانتینرها از UnionFS استفاده می کند (همانطور که ذیل عنوان ایم ج ها توضیح داده شد، هر دستورالعمل در فایل داکر، یک لایه مجزا در ایم ج ایجاد می کند، و زمانیکه تغییری در فایل داکر می دهید و آن ایم ج را بازسازی می کنید، فقط لایه های تغییر داده شده از نو ساخته خواهند شد) موتور داکر استفاده از چندین نوع UnionFS مختلف شامل AUFS ، btrfs ، vfs ، و DeviceMapper را پشتیبانی می کند. موتور داکر به منظور تعریف استاندارد مشخصات پیکر بندی کانتینرها و نیز مدیریت چرخه حیات آن ها، از ترکیب فضاهای نام، گروه های کنترلی و سیستم فایل مجتمع در قالب یک پوشش [ ] جدید به نام Container Format استفاده می کند. در حال حاضر، libcontainer گزینه پیش فرض داکر برای این منظور است. در آینده ممکن است داکر با هم افزایی فناوری هایی مثل BSD Jails یا Solaris Zones ، فرمت های دیگری را نیز پشتیبانی کند. آنچه در مقاله بعدی خواهید خواند: [ ] Sysadmin [ ] Dockerize [ ] Reliable [ ] Failure Free [ ] پلتفرم متفاوت از زبان برنامه نویسی است و می تواند یک نرم افزار مثل مرورگر وب، سخت افزار، نرم افزار - سخت افزار، سیستم عامل، ماشین مجازی، ماشین فیزیکی، زیرساخت ابری، و یا هر ترکیبی از این موارد باشد. [ ] Deploy [ ] Hypervisor [ ] Kernel [ ] Container [ ] Containerization [ ] Loosely Coupled [ ] Encapsulated [ ] Self Sufficient [ ] Upgrade [ ] Scalable [ ] Replica [ ] Aggressive Constraints [ ] Docker [ ] Sysadmin [ ] Workload [ ] Docker Engine [ ] Instance [ ] Process [ ] Background [ ] Image [ ] Data Volume [ ] Daemon [ ] Command Line Interface [ ] اسکریپت‌ها برنامه‌های کوچکی هستند که به کمک آن‌ها به راحتی می‌توان برخی از وظایف تکراری و یا طولانی را به طور خودکار انجام داد. [ ] سوکت یونیکس یا IPC Socket یک نوع درگاه مخابراتی داده است که از آن می توان برای انتقال داده ها به صورت دو طرفه بین دو فرایند که هر دو بر روی یک سیستم عامل میزبان اجرا می شوند، استفاده نمود. [ ] سوکت TCP / IP یک نوع درگاه مخابراتی داده است که از آن می توان برای انتقال داده ها به صورت دو طرفه بین دو فرایند بر روی شبکه، استفاده نمود. در برخی مواقع می توان برای انتقال داده ها بین دو فرایند که هر دو بر روی یک سیستم عامل میزبان اجرا می شوند نیز ازین نوع سوکت ها بهره برد اما توصیه می شود در این حالت از سوکت های یونیکس که به دلایل مختلف سریع تر هستند استفاده نمود. [ ] Docker Hub [ ] Read Only [ ] Ubuntu [ ] Runtime [ ] Syntax [ ] Docker file [ ] Rebuild [ ] Memory [ ] Session [ ] Shell [ ] Log [ ] Node [ ] Scale [ ] به فارسی یعنی خوشه، گروه [ ] Manager [ ] Worker [ ] Tasks [ ] Native [ ] Orchestration [ ] Cluster [ ] Kubernetes [ ] Namespaces [ ] Message Queue [ ] Shared Memory [ ] به انگلیسی Semaphore و به فارسی اصطلاحا نشانبر. یکی از ساده ترین مفاهیم سیستم عامل است و به متغیری گفته می شود که در محیط های همروند از آن برای کنترل دسترسی فرآیندها به منابع مشترک استفاده می شود. [ ] Mount [ ] Control Groups [ ] Union File Systems [ ] Wrapper