تفاوت Docker Image و Container چیست؟

در گفتگوهای تیم اغلب کسی می‌گوید «Container را آپلود کردم» در حالی که منظورش Image است، یا «Image را ری‌استارت کردم» در حالی که Image اجرا نمی‌شود — Container اجرا می‌شود. این جابه‌جایی واژه‌ها فقط زبانی نیست؛ باعث اشتباه در نسخه‌گذاری، Rollback و پاک کردن داده می‌شود.

طبق مستندات Docker، Image یک بستهٔ استاندارد شامل فایل‌ها، باینری‌ها، کتابخانه‌ها و پیکربندی لازم برای اجرای یک Container است. Container فرایند ایزوله‌ای است که از روی آن Image ساخته می‌شود. Image را می‌سازید، ذخیره و توزیع می‌کنید؛ Container را start/stop/delete می‌کنید.

این صفحه دو مفهوم را جدا می‌کند، لایه‌ها و تغییرناپذیری را توضیح می‌دهد، و نشان می‌دهد دادهٔ پایدار کجا باید باشد تا با حذف Container از بین نرود.

پاسخ کوتاه

Image = قالب فقط‌خواندنی (مثل کلاس یا نصب‌کنندهٔ نسخه‌دار). Container = نمونهٔ در حال اجرا یا متوقف‌شده از آن قالب (مثل آبجکت یا فرایند زنده). از یک Image می‌توانید چند Container بسازید. تغییر داخل Container در حال اجرا روی Image اصلی نوشته نمی‌شود؛ برای ماندگار کردن وضعیت جدید باید Image تازه commit/build کنید یا داده را در Volume بیرون بگذارید.

در مسیر حرفه‌ای: CI Image می‌سازد و به Registry می‌فرستد؛ محیط اجرا Container را از digest مشخص بالا می‌آورد. اگر این جمله برایتان روشن است، بقیهٔ جزئیات ابزار است.

Image را نسخه‌گذاری کنید؛ Container را مشاهده و عوض کنید. برعکسش یعنی هر ری‌استارت می‌تواند «نسخه» را گم کند.

Image: بستهٔ تغییرناپذیر لایه‌ای

دو اصل مهم Image از مستندات Docker:

1. تغییرناپذیری (immutable): بعد از ساخته شدن Image را «ویرایش» نمی‌کنید؛ Image جدید می‌سازید یا لایه روی آن اضافه می‌کنید.
2. ساختار لایه‌ای: هر لایه مجموعه‌ای از تغییرات فایل‌سیستم است (اضافه، حذف، تغییر).

برای اپ Python می‌توانید از Image رسمی Python شروع کنید و لایه‌هایی برای نصب وابستگی و کپی کد اضافه کنید. تمرکز روی اپ می‌ماند نه روی نصب دوبارهٔ runtime. لایه‌ها باعث می‌شوند rebuild فقط بخش‌های تغییرکرده را دوباره بسازد و کش build مفید باشد.

از کجا Image می‌آید؟

Docker Hub بازار پیش‌فرض عمومی است؛ Imageهای رسمی و ناشران تأییدشده نقطهٔ شروع رایج‌اند. تیم‌ها برای Production معمولاً Registry خصوصی دارند. `docker pull` لایه‌ها را می‌گیرد؛ `docker image history` لایه‌ها و فرمان ساخت را نشان می‌دهد.

تگ مثل `myapp:1.4` برچسب انسانی است؛ digest (مثلاً sha256:…) اثر انگشت محتواست. برای استقرار مطمئن، digest را قفل کنید تا تگ جابه‌جا نشود.

Container: نمونهٔ اجرایی

Container را با API یا CLI می‌سازید، شروع و متوقف می‌کنید، به شبکه وصل می‌کنید یا حذف می‌کنید. هنگام اجرا، Docker معمولاً یک لایهٔ خواندن/نوشتن روی Image فقط‌خواندنی می‌گذارد تا Container بتواند فایل بسازد یا عوض کند. با حذف Container، تغییراتی که در Volume پایدار ذخیره نشده‌اند از بین می‌روند — نکته‌ای که مستندات overview هم تأکید می‌کند.

چند Container از یک Image می‌توانند هم‌زمان با تنظیمات مختلف (پورت، متغیر محیطی، نام) اجرا شوند. حذف یکی روی بقیه اثر ندارد؛ مستقل مدیریت می‌شوند.

جدول تفاوت عملی

Analogy کوتاه برای غیرتکنیکال

Image مثل دستور پخت چاپ‌شده و ثابت است. Container مثل یک‌بار پختن آن دستور در آشپزخانه است. می‌توانید همزمان چند ظرف از همان دستور بپزید. اگر وسط پخت ادویه عوض کنید، کتاب دستور پخت عوض نشده؛ فقط همان ظرف تغییر کرده. برای نسخهٔ جدید باید دستور پخت تازه چاپ کنید (Image جدید).

Dockerfile، build و رابطه با Container

Dockerfile مراحل ساخت Image را توصیف می‌کند. خروجی build یک Image است نه یک Container در حال سرویس. سپس `docker run` از روی Image یک Container می‌سازد و معمولاً فرایند اصلی را اجرا می‌کند. در CI باید build را از run جدا کنید: تست روی Image ساخته‌شده، Deploy همان digest.

اشتباه رایج: وارد Container شدن، پکیج نصب کردن، و فکر کردن «محیط درست شد» بدون ثبت در Dockerfile. آن تغییر با از بین رفتن Container می‌میرد و روی ماشین همکار تکرار نمی‌شود.

دادهٔ پایدار: Volume و bind mount

اگر دیتابیس یا فایل آپلود کاربر داخل لایهٔ writable Container بماند، با `docker rm` یا جایگزینی نسخه پاک می‌شود. Volume داده را خارج از چرخهٔ عمر Container نگه می‌دارد. Image باید کد و وابستگی را حمل کند؛ حالت و دادهٔ کاربر را نه. این تفکیک همان منطق Build/Release و محیط‌هاست که در استقرار مهم است.

فرمان‌های ذهنی (بدون وابستگی به حفظ کردن همهٔ فلگ‌ها)

• دیدن Imageهای محلی و کشیدن از Registry → کار با Image.
• دیدن فرایندهای در حال اجرا / توقف / لاگ زنده → کار با Container.
• ساخت از Dockerfile → تولید Image.
• run از Image → ایجاد/اجرای Container.

وقتی در چت می‌نویسید «Container را به سرور بفرست»، دقیق‌تر بگویید «Image را push کن و روی سرور Container را از آن digest بالا بیاور». زبان دقیق، عملیات دقیق می‌سازد.

امنیت و بهداشت Image

• از Image پایهٔ معتبر و به‌روز شروع کنید.
• لایهٔ نهایی را مینیمال نگه دارید (multi-stage build در صورت نیاز).
• اسکن آسیب‌پذیری را بخشی از CI کنید.
• Secret را در لایهٔ Image نگذارید.
• تگ شناور `latest` را برای Production مبنا نکنید.

جمع‌بندی برای تصمیم

Image قالب لایه‌ای تغییرناپذیر برای توزیع است؛ Container نمونهٔ اجرایی با لایهٔ نوشتنی موقت. نسخه‌گذاری و Registry متعلق به Image است؛ مشاهده، مقیاس و جایگزینی متعلق به Container. دادهٔ پایدار را از هر دو جدا کنید.

قدم کوچک: برای سرویس اصلیتان یک تگ معنا‌دار و ثبت digest بعد از build در CI؛ Deploy فقط با همان digest. از فردای آن روز بحث «کدام نسخه بالا است» کوتاه‌تر می‌شود.

منابع و مراجع

• Docker Docs — What is an image? — https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-an-image/
• Docker Docs — What is a container? — https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container/
• Docker Docs — What is Docker? (images & containers) — https://docs.docker.com/get-started/docker-overview/

برای مقایسه با VM مقالهٔ ۱۰۶ و برای چندسرویسی با Compose مقالهٔ ۱۰۸ را ببینید.