طی برگزاری هشتمین کنفرانس شرکت Docker، جامعه‌ی Developerها، کاربران IT، شرکت‌های تجاری و همکاران این کمپانی، با تکیه بر فرضیه‌ی سالومون هایک (به عنوان موسس شرکت )Docker، درخصوص تسهیل استفاده از نرم افزار Container، به‌صورت تصاعدی، به میلیون‌ها نفر رسیده است. Docker امروزه هم مانند روزهای ابتدایی کار این شرکت، ابزار ساده و رویکرد Packaging جامعی تهیه می‌نماید که تمام وابستگی‌های یک برنامه‌ی کاربردی را درون یک Container جمع می‌کند.
مزایای استفاده از Docker Engine برای برنامه‌های کاربردی:
- امکان اجرای برنامه‌های کاربردی به شکلی منسجم بر روی هر زیرساخت و در هر مکان
- حل معضل وابستگی یک نرم‌افزار به دیگر نرم‌افزارها را برای توسعه‌دهندگان و تیم‌های عملیاتی
- از بین بردن مشکل نصب برنامه بر روی PC
در طی دو سال گذشته Codebase موتور Docker Engine بازسازی شده و به‌شکل چندین جزء قابل استفاده درآمده است که مهم‌ترین اجزای آن عبارتند از:
- Containerd به عنوان زمان اجرای Container اصلی Docker Engine
- Buildkit که آن بخش از Docker Engine است که برای ساخت Imageها مورد استفاده قرار می‌گیرد.
Containerd توسط میلیون‌ها کاربر مورد استفاده‌ی قرار گرفته و ده‌ها هزار کمپانی آن را در چرخه‌ی تولید خود استفاده می‌نمایند. شرکت Docker هجده ماه پیش Containerd را به عنوان محصولی جانبی از Docker Engine تولید کرد و به علت هم‌راستایی آن با Kubernetes، gRPC و Prometheus آن را به‌عنوان پروژه‌ای سطح‌بالا به بنیاد Could Native Computing Foundation یا به اختصار CNCF اهدا نمود.
Docker این اهدا را با همکاری و حضور پنج عدد از بزرگ‌ترین شرکت‌های ارائه‌دهنده سرویس Cloud یعنی Alibaba، AWS، Google، IBM و Microsoft انجام داد. هدف این امر بهره‌مندی از راهکاری بود که بتواند به‌صورت On-Premise، بر روی تمام Cloudها، Linux، ویندوز و Mainframeها اجرا گردد.
یکی از اهداف اعطای Containerd این بود که با ارائه‌ی Runtime Container اصلی که دیگر ارائه‌دهندگان خدمات Container و پروژه‌های هماهنگ‌سازی همچون Kubernetes، DC/OS و غیره، بتوانند از آن بهره ببرند، ایجاد فضایی برای نوآوری بیشتر در زمینه‌یContainer ها بود. یکی از مبانی اصلی طراحی Containerd این امر بوده است که پشتیبانی تراز اولی را برای Kubernetes ارائه دهد ولی به‌صورت انحصاری به آن متصل نباشد، چرا که وابستگی یک Runtime Container اصلی به Kubernetes استفاده‌ی آن را فقط به Kubernetes محدود می‌کرد و موارد کاربرد بسیاری را برایContainer ها از جمله Developer Desktop، CI/CD، پیاده‌سازی‌های تک Node، Edge و IoT را از قلم می‌انداخت.
نسخه‌ی Containerd 1.1 که در ماه آوریل معرفی شد، Kubernetes Container Runtime Interface یا به اختصار CRI را پیاده‌سازی می‌نماید تا هم Kubernetes و هم Docker Engine بتوانند مستقیماً از آن استفاده کنند. این نسخه Namespaceها را پیاده‌سازی می‌کند تا Clientهای سرویس‌های Container مختلف (مانند Docker Engine و DC/OS) بتوانند درحالی‌که منطقاً از هم جدا هستند، از یک Instance واحد Containerd بر روی یک سیستم، حداکثر استفاده را نمایند. این نسخه به کاربران اجازه می‌دهد که هر Runtime سازگار با OCI همچون Containerهای Kata، gVisor و غیره را به آن متصل کنند. همچنین این نسخه شامل بهبودهای زیادی در عملکرد همچون کاهش چشمگیر میزان تأخیر (Latency) Pod Start و میزان استفاده‌ی پلاگین CRI از CPU و Memory نیز می‌باشد. این نسخه همچنین برای دست‌یابی به مزیت‌های عملکردی بیشتر، Graphdriverها را با Snapshotterهای کارآمدتری جایگزین می‌نماید که Buildkit برای Build سریع‌تر از آن‌ها استفاده می‌کند. اعضای Kubernetes که بر روی CRI کار می‌کنند در اواسط امسال دسترس‌پذیری کلی Containerd 1.1 را با Kubernetes اعلام نمود.
مایکل کرازبی، یکی از مهندسان شرکت Docker، در سخنرانی خود کلیات ویژگی‌های Containerd 1.1 را مورد بررسی قرار داد که شامل موارد زیر می‌باشد:
- Redirection I/O از Client-Side.
- پیاده‌سازی Namespaceهای Containerd برای استفاده‌ی بهینه از یک Instance از Runtime واحد، با جدایی منطقی از Clientهای متعدد (Kubernetes، Docker Engine و دیگر سیستم‌ها) و همچنین Containerهایی از انواع Golang در هنگام استفاده از Containerd Go Client Library (که خود یادآور پروژه‌ی Metaparticle برندن بورن می‌باشد).
تانیس تیگی، یکی دیگر از مهندسان شرکت Docker، در سخرانی خود تمام بهبودهای عملکرد که به‌وسیله‌ی Buildkit ایجاد شده‌اند و همچنین قابلیت‌هایی که Buildkit به‌دلیل معماری ماژولار خود به Containerd می‌بخشد را توضیح داد. این قابلیت‌ها به توسعه‌دهندگان متن باز (Open Source) که با استفاده‌ی مستقیم از Buildkit، Build Systemهای تازه‌ای می‌سازند، اجازه می‌دهد که Frontendها (ماورای Dockerfiles) و Backendهای (ماورای Docker Images) تازه‌ای برای آن ایجاد نمایند.
Buildkit به‌عنوان یک ویژگی آزمایشی در Docker 18.06 پیاده‌سازی خواهد شد. این ویژگی آزمایشی تازه توسعه‌پذیری Dockerfile را به ارمغان می‌آورد که در نتیجه‌ی آن، توسعه‌دهندگان می‌توانند با استفاده از دستور #syntax directive: # syntax = registry/user/repo:tag ، افزونه‌های مخصوص خود را برای Dockerfile بسازند.
Container Image که این توسعه‌دهندگان ارائه می‌دهند، آگاه خواهد بود که چگونه یک Syntax جدید را در Dockerfile تعبیر نماید. یکی از مثال‌هایی که تانیس تیگی نمایش داد، افزونه‌ای بود که RUN-Mount را درک می‌کند و به کاربران اجازه می‌دهد که یک Volume ،همچون Maven Repository Cache را در Build Time، Mount نمایند که در نتیجه‌ی اینکار عملکرد Buildها تا 33 برابر بهبود می‌یابد. این ویژگی یکی از محبوب‌ترین ویژگی‌های درخواستی برای Docker Build بود.
Containerd و Buildkit هردو درحال گسترش مرزهای کارهایی هستند که با Containerها، هم در Runtime و هم در Build Time، ممکن می‌شود. این امر که هم Containerd و هم Buildkit حالا در Docker Engine پیاده‌سازی شده‌اند، باعث می‌شود که این نوآوری‌ها در پروژه‌های Component، بدون نیاز به ایجاد تغییر در گردش کار خود، در دسترس توسعه‌دهندگان عمومی قرار بگیرد؛ حال چه از آن‌ها بر روی یک لپ‌تاپ در Docker Desktop استفاده نمایند، چه در یک کلاستر تولیدی Kubernetes، چه یک Mainframe که در آن برنامه‌های کاربردی قدیمی با استفاده از نگه‌دارنده‌ها مدرن‌سازی شده‌اند و چه یک دستگاه Raspberry Pi برای سناریوی IoT. توسعه‌دهندگان و اپراتورها فارغ از اینکه از چه سیستمی استفاده می‌نمایند، از قابلیت پورتال بودن (Portability) جریان کار برنامه‌های کاربردی که Docker Engine ارائه می‌دهد، بهره‌مند بوده و قادر خواهند بود که با استفاده از یک Codebase مطمئن واحد، در همه‌جا، نگه‌دارنده‌ها را ساخته و اجرا نمایند.
البته بسیاری دیگر از پروژه‌های متن باز در دو مبحث ساخت و اجرای Containerها وجود دارند که پاسخگوی نیازهای یک بخش خاص هستند:
Runtimeهایی همچون Kata که محیط ایزوله‌ی شده‌ی VMگونه‌ای را برای Containerها فراهم می‌آورند، یا CRIO که Containerهای OCI را در Kubernetes اجرا می‌نماید، خصوصاً در OpenShift بر روی RHEL، Builderهایی همچون Kaniko که Imageهایی را در Kubernetes می‌سازند و یا JIB که Imageهای برنامه‌های کاربردی Java و یا Buildah را می‌سازد. لازم به ذکر است که با استفاده از Containerd و Buildkit که در Docker Engine پیاده‌سازی شده‌اند، کاربران به نسل بعدی اجزای Builder و Runtime به عملکرد بالاتر و قابلیت پیکربندی بیشتری دسترسی خواهند داشت که با یک جریان‌کاری قابل حمل برنامه یک‌پارچه‌سازی شده است که توسعه‌دهندگان و اپراتورها به‌خوبی با آن آشنایی دارند و می‌شود از آن برای هر مورد کاربرد متفاوتی (همچون تک سرور، Runtime تنظیم‌شده، CI/CD، IoT و غیره) استفاده نمود.
در نهایت Containerd، تنها راهکار ممکن برای حصول اطمینان از این امر می‌باشد که یک Runtime Container اصلی، بر روی تمامی تنظیم‌کنندگان (از جمله Kubernetes، Swarm، AWS ECS و غیره)، توزیع‌های Linux، ویندوز و Mainframeها، On-Premiseها و همچنین تمامی سرویس‌های Cloud و x86، ARM و GPUها کار کند. درصورتی که کاربر بخواهد با یک راهکار ساخت Image بهینه‌سازی‌شده برای Containerd به ارزش بیشتری دست یابد، Buildkit که در Docker Engine پیاده‌سازی شده بهترین راهکار می‌باشد.
