ایمیج‌های داکر؛ لایه‌ها، تگ‌ها و دایجست چگونه کار می‌کنند

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

ایمیج داکرلایه‌های ایمیجDigest

~4 دقیقه مطالعه · آخرین به‌روزرسانی ۱۴ شهریور ۱۴۰۵

مقدمه

ایمیج (Image) — که گاهی ایمیج داکر، ایمیج کانتینری یا ایمیج OCI نیز نامیده می‌شود — یک بسته فقط‌خواندنی است که شامل هر آنچه برای اجرای یک برنامه لازم است می‌باشد: کد منبع، وابستگی‌ها، حداقلی از اجزای سیستم‌عامل و متادیتا. از یک ایمیج می‌توان چندین کانتینر راه‌اندازی کرد.

ایمیج در مقابل کانتینر

ایمیج‌ها اجزای زمان ساخت (build-time) هستند، در حالی که کانتینرها معادل زمان اجرای (run-time) آن‌ها محسوب می‌شوند — شبیه رابطه یک کلاس با یک شیء، یا یک قالب ماشین مجازی با یک ماشین مجازی در حال اجرا. پس از راه‌اندازی یک کانتینر از روی یک ایمیج، این دو به هم متصل می‌شوند و تا زمانی که تمام کانتینرهای استفاده‌کننده از آن حذف نشوند، امکان حذف ایمیج وجود ندارد.

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

دریافت ایمیج‌ها

دانلود یک ایمیج از رجیستری pulling نامیده می‌شود. ایمیج‌ها به‌صورت محلی در چیزی به نام image cache ذخیره می‌شوند. دستور زیر ایمیج رسمی Redis را دریافت می‌کند:

docker pull redis

به‌طور پیش‌فرض، داکر تگ latest و رجیستری Docker Hub را در نظر می‌گیرد، مگر اینکه چیز دیگری مشخص شود.

رجیستری‌ها و ریپازیتوری‌های ایمیج

ایمیج‌ها در رجیستری‌ها (registries) ذخیره می‌شوند که خود شامل ریپازیتوری‌ها (repositories) هستند و هر ریپازیتوری یک یا چند ایمیج در خود دارد. Docker Hub رایج‌ترین رجیستری است، اما گزینه‌های دیگری از جمله رجیستری‌های خصوصی و on-premises نیز وجود دارند.

ریپازیتوری‌های رسمی (Official Repositories) در Docker Hub، ایمیج‌های بررسی‌شده‌ای هستند که توسط داکر و سازنده برنامه نگهداری می‌شوند و با نشان سبزرنگ و قرارگیری در سطح بالای namespace (مانند nginx، redis) قابل شناسایی‌اند. ریپازیتوری‌های غیررسمی، که با پیشوند نام کاربری یا سازمان مشخص می‌شوند، باید با احتیاط بیشتری استفاده شوند.

نام‌گذاری و تگ‌زنی

یک نام کامل ایمیج شامل رجیستری، سازمان، ریپازیتوری و تگ است. دریافت از یک ریپازیتوری رسمی ساده است:

docker pull redis:8.0-M02

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

ایمیج‌ها و لایه‌ها

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

docker inspect redis:latest

داکر از storage driverها — رایج‌ترین آن‌ها overlay2 — برای ادغام این لایه‌ها در یک نمای یکپارچه استفاده می‌کند. ایمیج‌ها همچنین می‌توانند لایه‌ها را با یکدیگر به اشتراک بگذارند که باعث صرفه‌جویی در فضای دیسک و پهنای باند شبکه هنگام pull می‌شود.

دریافت ایمیج بر اساس Digest

از آنجا که تگ‌ها قابل تغییرند، تضمینی وجود ندارد که هر بار دقیقاً همان ایمیج دریافت شود. برای حل این مشکل، هر ایمیج یک digest ثابت و غیرقابل‌تغییر دارد — یک هش رمزنگاری‌شده از محتوای آن. دایجست‌ها را می‌توان با دستور زیر مشاهده کرد:

docker images --digests alpine

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

ایمیج‌های چندمعماری

یک تگ واحد می‌تواند از چندین معماری CPU از طریق یک manifest list پشتیبانی کند که به منیفست‌های جداگانه برای پلتفرم‌هایی مانند linux/amd64 یا linux/arm64 اشاره می‌کند. این ویژگی باعث می‌شود همان دستور docker pull به‌طور خودکار ایمیج مناسب معماری میزبان را دریافت کند.

اسکن آسیب‌پذیری

ابزارهایی مانند Docker Scout ایمیج‌ها را برای آسیب‌پذیری‌های شناخته‌شده اسکن کرده و راهکارهای رفع مشکل ارائه می‌دهند و مستقیماً با CLI داکر، Docker Desktop و Docker Hub یکپارچه شده‌اند.

حذف ایمیج‌ها

ایمیج‌ها را می‌توان با دستور docker rmi حذف کرد که داده‌های لایه محلی را پاک می‌کند، به شرطی که هیچ کانتینر یا تگ دیگری به آن ایمیج اشاره نکند.

نتیجه‌گیری

درک نحوه ساختار ایمیج‌ها — به‌صورت لایه‌های انباشته که با تگ‌های قابل‌تغییر شناسایی می‌شوند اما با دایجست‌های غیرقابل‌تغییر تضمین می‌شوند — برای کار قابل‌اعتماد با داکر، به‌ویژه در محیط‌های تولیدی که ثبات و امنیت اهمیت بیشتری دارند، ضروری است.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

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

مدل امنیتی داکر بر پایه دفاع چندلایه ساخته شده و فناوری‌های شناخته‌شده kernel لینوکس را با تنظیمات پیش‌فرض معقول ترکیب می‌کند. این مقاله توضیح می‌دهد که namespaceها، control groupها، capabilityها، Mandatory Access Control و seccomp چگونه در کنار هم کانتینرها را ایزوله و ایمن می‌کنند.

ادامه

مدیریت داده‌های ماندگار در داکر با Volume

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

ادامه

شبکه‌های Overlay در داکر چگونه کار می‌کنند؛ نگاهی به VXLAN

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

ادامه

اتصال کانتینرهای داکر به VLAN و توزیع بار با Swarm

فراتر از شبکه‌های ساده bridge، داکر امکاناتی برای اتصال مستقیم کانتینرها به VLANهای فیزیکی موجود، تفکیک خودکار نام سرویس‌ها و توزیع ترافیک در سراسر یک کلاستر Swarm ارائه می‌دهد. این مقاله درایور macvlan، سرویس داخلی Service Discovery و مکانیزم Ingress Load Balancing در Swarm را بررسی می‌کند.

ادامه

شبکه‌سازی در داکر؛ آشنایی با CNM، Libnetwork و شبکه‌های Bridge

شبکه‌سازی در داکر بر پایه یک طراحی باز به نام Container Network Model ساخته شده که توسط libnetwork پیاده‌سازی و با درایورهای قابل‌جایگزینی گسترش می‌یابد. این مقاله تئوری پشت شبکه داکر را بررسی کرده و نحوه ساخت و تست شبکه‌های bridge تک‌هاست، از جمله تفکیک نام و نگاشت پورت را توضیح می‌دهد.

ادامه

استقرار و مدیریت کلاستر چندنودی با Docker Swarm

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

ادامه