تفاوت کلیدی ایمیج‌ها و کانتینرها (Images vs. Containers)

یکی از چالش‌های رایج در درک مفاهیم زیرساخت مدرن، استفاده نابجا از واژه‌های Image و Container به جای یکدیگر است. این اشتباه مفهومی می‌تواند در معماری سیستم‌های توزیع‌شده به شدت مشکل‌ساز شود. در این بخش، این دو مفهوم به صورت دقیق و ساختاری تفکیک می‌گردند.

۱. تاریخچه و چالش‌های گذشته

یکی از قدیمی‌ترین چالش‌های توسعه نرم‌افزار، عدم تطابق محیط‌های اجرا بین تیم‌های توسعه (Developers) و عملیات (Operations) بود که اغلب به جمله معروف "روی سیستم من کار می‌کرد!" ختم می‌شد.

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

برای حل این چالش، نیاز به راهکاری بود تا نرم‌افزار به همراه تمامی پیش‌نیازهای اجرایی آن (تنظیمات، فایل‌ها و وابستگی‌ها) به صورت یک بسته کاملاً مهروموم شده و استاندارد منتقل شود؛ این نیاز منجر به پیدایش مفهوم Image گردید.

۲. واژه‌نامه تخصصی

• ایمیج (Image): یک فایل بسته‌بندی شده، ثابت و غیرقابل تغییر است که شامل کدهای برنامه و تمامی پیش‌نیازهای لازم برای اجرای آن می‌شود.
• کانتینر (Container): زمانی که یک Image در محیط سیستم‌عامل اجرا (Run) می‌شود، به یک موجودیت فعال و زنده به نام Container تبدیل می‌گردد.
• تغییرناپذیر (Immutable): یکی از مهم‌ترین مفاهیم زیرساخت مدرن است. این مفهوم بیان می‌کند که وقتی یک فایل (مانند Image) ساخته شد، محتوای آن دیگر هرگز قابل ویرایش نیست.
• رجیستری (Registry): یک مخزن یا انبار آنلاین (مانند Docker Hub) است که مهندسان ایمیج‌های خود را در آن بارگذاری کرده و به اشتراک می‌گذارند.

۳. مفهوم اصلی و مدل ذهنی

برای درک بهتر این دو مفهوم، می‌توان از مدل ذهنی ساختمان‌سازی استفاده کرد:

• Image مشابه «نقشه معماری» (Blueprint) است: نقشه صرفاً یک دستورالعمل روی کاغذ است و نمی‌توان در آن زندگی کرد. نقشه تغییرناپذیر (Immutable) است؛ پس از تایید نهایی، جزئیات آن به صورت دستی روی همان کاغذ ویرایش نمی‌شود.
• Container مشابه «ساختمان فیزیکی» (House) است: زمانی که ساختمان از روی نقشه ساخته می‌شود، یک موجودیت قابل استفاده به وجود می‌آید (برنامه در حال اجرا).

نکته کلیدی: از روی یک نقشه (Image) می‌توان هزاران ساختمان کاملاً مشابه (Container) ایجاد کرد. در صورت تخریب یکی از ساختمان‌ها (Crash)، جای نگرانی نیست؛ زیرا با در اختیار داشتن نقشه اصلی، می‌توان به سرعت ساختمان جدیدی را دقیقاً با همان مشخصات بنا کرد.

۴. تفاوت محیط‌های آزمون و دنیای واقعی (GitOps/CI-CD)

• در آزمون‌های رسمی (مانند CKA): عموماً ایمیج‌ها از پیش آماده شده‌اند و تمرکز بر اجرای دستوراتی است که از روی آن‌ها، کانتینرهایی با تنظیمات خاص (مانند پورت‌های متفاوت) ساخته شود.
• در دنیای واقعی (GitOps و CI-CD): فرآیندها اتوماتیک هستند. با هر تغییر در کد برنامه، پایپ‌لاین‌ها (Pipelines) یک Image جدید تولید کرده، برچسب نسخه جدید (مثلاً v2.0) روی آن قرار می‌دهند و در Registry ذخیره می‌کنند تا برای اجرا در سرورهای محیط Production آماده شود.

۵. اصول حرفه‌ای در معماری ابری

یک قانون طلایی در مهندسی زیرساخت وجود دارد: هرگز یک کانتینر در حال اجرا را به صورت دستی ویرایش نکنید!

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

۶. کارگاه عملی

برای مشاهده تفاوت این دو مفهوم در سطح سیستم‌عامل، دستورات زیر اجرا می‌شوند.

گام اول: مشاهده لیست ایمیج‌ها (Images)

root@server:~# docker image ls

خروجی مورد انتظار:

REPOSITORY    TAG       IMAGE ID       CREATED        SIZE
nginx         latest    605c77e624dd   2 weeks ago    141MB
ubuntu        20.04     ba6acccedd29   2 months ago   72.8MB

(توضیح: این موارد صرفاً فایل‌های ذخیره شده روی فضای هارد دیسک هستند و هیچ‌کدام در حال اجرا نمی‌باشند.)

گام دوم: مشاهده لیست کانتینرهای در حال اجرا (Containers)

root@server:~# docker ps

خروجی مورد انتظار:

CONTAINER ID   IMAGE          COMMAND                  STATUS          PORTS                  NAMES
e3b0c44298fc   nginx:latest   "/docker-entrypoint.…"   Up 10 minutes   0.0.0.0:80->80/tcp     web-server-1
9b7a456cde12   nginx:latest   "/docker-entrypoint.…"   Up 2 minutes    0.0.0.0:8080->80/tcp   web-server-2

(توضیح: در این مثال، از روی یک ایمیج واحد (nginx:latest)، دو کانتینر کاملاً مجزا و مستقل ایجاد شده است.)

۷. پاسخ به سوالات متداول

سوال ۱: آیا با حذف یک کانتینر، ایمیج آن نیز از روی سرور پاک می‌شود؟ پاسخ: خیر. کانتینر و ایمیج ماهیت‌های کاملاً مستقلی دارند. با حذف کانتینر، فایل ایمیج روی سیستم باقی می‌ماند و می‌توان مجدداً از آن برای ساخت کانتینرهای جدید استفاده کرد.

سوال ۲: حجم ایمیج‌ها در مقایسه با ماشین‌های مجازی (VM) چقدر است؟ پاسخ: ایمیج‌ها بسیار سبک‌تر هستند. از آنجا که کانتینرها نیازی به نصب سیستم‌عامل کامل و کرنل اختصاصی ندارند، حجم اکثر ایمیج‌ها معمولاً بین ۱۰ تا ۲۰۰ مگابایت است.

۸. هشدارهای سطح تولید و ایمیج‌های طلایی (Golden Images)

در محیط‌های حساس (Production)، امنیت سیستم وابستگی مستقیمی به ایمیج‌ها دارد. اگر ایمیج پایه دارای آسیب‌پذیری یا کدهای مخرب باشد، تمامی کانتینرهای ساخته شده از روی آن نیز آلوده خواهند بود. به همین دلیل، در تیم‌های مهندسی قابلیت اطمینان (SRE) همواره از ایمیج‌های تأیید شده و رسمی تحت عنوان Golden Images استفاده می‌شود که پیش از استقرار، توسط ابزارهای امنیتی اسکن و اعتبارسنجی شده‌اند.

۹. چالش مهندسی آشوب و تحلیل خطا

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

لاگ‌های راه‌اندازی مجدد سیستم به شرح زیر است:

[INFO] Server rebooted successfully.
[INFO] Restarting containers...
[INFO] Starting container 'web-frontend' from image 'frontend-app:v1.0'
[SUCCESS] Container 'web-frontend' started successfully.

تحلیل علت ریشه‌ای (Root Cause Analysis): بر اساس اصل تغییرناپذیری (Immutable)، هر کانتینر پس از راه‌اندازی، دقیقاً به وضعیت اولیه‌ای که در Image تعریف شده است بازمی‌گردد. تغییرات دستی درون کانتینر ناپایدار (Ephemeral) هستند و با تخریب یا راه‌اندازی مجدد کانتینر برای همیشه پاک می‌شوند. روش استاندارد مهندسی این است که تغییرات روی کدهای اصلی اعمال شده، یک Image جدید با ورژن بالاتر ساخته شود و کانتینرها بر اساس ایمیج جدید به‌روزرسانی گردند.