Container و تفاوت آن با Virtual Machine

ساختار Container از پایه

برای فهم Container اول باید یک بخش از سیستم‌عامل را بشناسیم. Kernel هسته اصلی سیستم‌عامل است؛ بخشی که بین نرم‌افزارها و منابعی مثل CPU، Memory، Disk و Network ارتباط برقرار می‌کند. Application معمولاً مستقیم سخت‌افزار را مدیریت نمی‌کند و از امکانات سیستم‌عامل استفاده می‌کند. این تعریف برای این درس کافی است؛ لازم نیست وارد طراحی داخلی Kernel شویم.

در Virtual Machine معمولاً هر VM سیستم‌عامل کامل خودش را دارد و در نتیجه Kernel خودش را هم اجرا می‌کند. Container روش سبک‌تری برای جدا کردن Applicationهاست. چند Container روی یک Host معمولاً Kernel سیستم‌عامل میزبان را مشترک استفاده می‌کنند، اما فایل‌ها، Processها و تنظیمات موردنیاز Application تا حد زیادی از هم جدا نگه داشته می‌شوند. Process یعنی برنامه‌ای که در حال اجراست. همین اشتراک Kernel یکی از دلایلی است که Container معمولاً از VM سبک‌تر است.

برای ساخت Container معمولاً از Image شروع می‌کنیم. Image یک الگوی آماده از فایل‌ها و وابستگی‌های لازم برای اجرای Application است. وقتی از Image یک نمونه در حال اجرا می‌سازی، آن نمونه Container است. مثال ساده: Image مربوط به یک Web Server می‌تواند فایل‌های لازم و تنظیمات پایه را داشته باشد؛ هر بار که آن Image را اجرا می‌کنی یک Container ساخته می‌شود.

نرم‌افزاری که Imageها و Containerها را اجرا و مدیریت می‌کند Container Runtime یا Engine نامیده می‌شود. Runtime یعنی محیط اجرایی. Docker Engine نمونه شناخته‌شده‌ای است. برای CCNA لازم نیست جزئیات داخلی Docker یا Kubernetes را یاد بگیری. هدف این است که وقتی Application داخل Container است، بدانی یک لایه نرم‌افزاری برای ساخت و اتصال آن به Network وجود دارد و مشکل شبکه ممکن است داخل همان لایه باشد.

شبکه Container

Container برای ارتباط به Network نیاز دارد و معمولاً یک Interface مجازی در اختیارش قرار می‌گیرد. Runtime می‌تواند Container را به یک شبکه مجازی متصل کند و برای آن IP Address داخلی تعریف کند. جزئیات دقیق بین Platformها فرق دارد، اما مفهوم کلی شبیه این است که Container مثل یک Endpoint نرم‌افزاری به شبکه‌ای داخل Host وصل می‌شود.

فرض کن روی یک Linux Host دو Container مربوط به Web داریم. هرکدام می‌توانند IP داخلی خودشان را داشته باشند و از طریق یک Bridge نرم‌افزاری با هم یا با Host ارتباط بگیرند. Bridge در اینجا یک جزء نرم‌افزاری برای متصل کردن Interfaceهاست و از نظر نقش پایه به Switch نزدیک است. لازم نیست در این سطح وارد Network Namespace یا Pluginهای پیشرفته شویم؛ این اصطلاح‌ها برای فهم هدف فعلی CCNA ضروری نیستند.

برای اینکه کاربر بیرون Host به Web Server داخل Container برسد، معمولاً باید مشخص شود درخواست ورودی به کدام Port داخل Container هدایت شود. Port اینجا شماره سرویس در TCP یا UDP است، مثل TCP 80 برای HTTP. Runtime می‌تواند Port روی Host را به Port داخل Container نگاشت کند. این کار Port Mapping نام دارد؛ یعنی مثلاً Traffic ورودی TCP/8080 روی Host به TCP/80 داخل Container فرستاده شود.

Client → Host-IP:8080 → Container-Web:80

اگر کاربر به IP Host دسترسی دارد ولی Web Application داخل Container باز نمی‌شود، ممکن است شبکه فیزیکی کاملاً سالم باشد و مشکل در Port Mapping، اجرای خود Container یا Firewall Host باشد. همین موضوع نشان می‌دهد Network Engineer در محیط Container باید قبل از تعویض کابل بداند سرویس در کدام قسمت اجرا می‌شود.

تفاوت معماری VM و Container

حالا می‌توانیم VM و Container را مقایسه کنیم، چون هر دو را جدا فهمیده‌ایم. Virtual Machine یک کامپیوتر مجازی کامل‌تر است. Hypervisor برای آن CPU، RAM، Disk و vNIC مجازی می‌سازد و داخل VM یک Guest OS مستقل اجرا می‌شود. اگر سه VM داشته باشی، معمولاً سه Guest OS جدا هم داری. این جداسازی می‌تواند برای اجرای سیستم‌عامل‌های متفاوت یا نیاز به جداسازی بیشتر مناسب باشد، اما منابع بیشتری مصرف می‌کند.

Container معمولاً Guest OS کامل جدا برای هر Application ندارد. Containerها Kernel Host را به اشتراک می‌گذارند و فقط محیط لازم برای Application را جدا می‌کنند. به همین دلیل ساخت و Start شدن Container معمولاً سریع‌تر است و حجم کمتری نسبت به VM کامل دارد. این به معنی «همیشه بهتر بودن» Container نیست؛ انتخاب به Application، امنیت، سیستم‌عامل موردنیاز و طراحی زیرساخت بستگی دارد.

از دید شبکه، VM معمولاً vNIC دارد که به vSwitch متصل می‌شود. Container هم Interface مجازی دارد، اما مدیریت آن معمولاً توسط Container Runtime و شبکه نرم‌افزاری Host انجام می‌شود. در هر دو حالت، Traffic در نهایت برای خروج از Host باید به NIC فیزیکی و شبکه بیرونی برسد، مگر اینکه مقصد داخل همان Host باشد. تفاوت اصلی در نحوه ساخت محیط اجرایی و اجزای میانی داخل Host است.

مقایسه خوب قرار نیست یک جدول پر از اصطلاح باشد. اگر Application به Windows Server کامل با سرویس‌های سیستم‌عاملی مشخص نیاز دارد، VM ممکن است انتخاب طبیعی‌تری باشد. اگر یک Web Service کوچک Linux داریم که قرار است چندین نمونه سریع و سبک از آن اجرا شود، Container می‌تواند مناسب‌تر باشد. برای CCNA قرار نیست معماری Application را انتخاب کنی؛ باید تشخیص بدهی Workload کجا اجرا می‌شود و Network Path آن چه تفاوتی با Server فیزیکی دارد.

منابع و چرخه اجرای Container

چون Containerها Kernel مشترک دارند، لازم نیست برای هر Container یک سیستم‌عامل کامل Boot شود. به همین دلیل Start شدن آن‌ها معمولاً سریع است. اگر بخواهی ده نسخه از یک سرویس کوچک Web اجرا کنی، ده Container می‌توانند در بسیاری از طراحی‌ها منابع کمتری از ده VM کامل مصرف کنند. باز هم عدد دقیق به Application و محدودیت‌های منابع بستگی دارد.

Image کمک می‌کند محیط Application تکرارپذیر باشد. اگر Image مشخصی را روی چند Host سازگار اجرا کنی، فایل‌های پایه Application یکسان هستند. این ویژگی در Automation و توسعه نرم‌افزار ارزش دارد، اما برای Network Engineer مهم‌ترین بخش آن این است که IP یا Port یک Container ممکن است موقت و پویا باشد. یعنی نباید همیشه مثل Server فیزیکی فرض کنی یک Container خاص برای همیشه همان IP را خواهد داشت.

در محیط‌های بزرگ، ابزارهایی می‌توانند چندین Container را روی چند Host مدیریت کنند. یکی از معروف‌ترین‌ها Kubernetes است. اما جزئیات Kubernetes، Pod، Service و Network Plugin از هدف فعلی CCNA فراتر می‌روند. فقط کافی است بدانی شبکه Container در محیط واقعی می‌تواند چند لایه نرم‌افزاری داشته باشد و در عیب‌یابی باید مشخص کنی کدام قسمت در محدوده مسئولیت توست. اضافه کردن ده اصطلاح جدید بدون نیاز، یادگیری پایه را بهتر نمی‌کند.

مثل VM، کمبود منابع Host می‌تواند روی Container هم اثر بگذارد. اگر CPU Host اشباع باشد، پاسخ Application کند می‌شود. پس «کندی» همیشه از Packet Loss نیست. بررسی Network Counterها باید کنار وضعیت سرویس و منابع Compute انجام شود. تفکیک Network Problem از Application یا Compute Problem مهارتی است که در Troubleshooting بارها به آن برمی‌گردیم.

عیب‌یابی ساده شبکه Container

فرض کن یک Web Application داخل Container اجرا می‌شود. کاربران می‌گویند سایت باز نمی‌شود، اما خود Host Ping می‌شود و سرویس‌های دیگری روی Host سالم‌اند. اول Scope را مشخص می‌کنی: آیا خود Container Running است؟ آیا Application داخل آن روی Port موردنظر Listen می‌کند؟ Listen یعنی برنامه منتظر اتصال ورودی روی آن Port است. آیا Port Mapping بین Host و Container درست تعریف شده؟ آیا Firewall Host اجازه Traffic می‌دهد؟

اگر Container از داخل Host به Gateway دسترسی ندارد، شبکه مجازی Container و Route داخل Host بررسی می‌شوند. اگر Container Gateway را می‌بیند ولی DNS Name Resolve نمی‌شود، تنظیم DNS مربوط به Container یا Host مطرح می‌شود. اگر فقط دسترسی از بیرون مشکل دارد ولی از داخل Host سرویس باز می‌شود، Port Mapping، Firewall و مسیر ورودی بیشتر اهمیت پیدا می‌کنند. هر تست محدوده را کوچک می‌کند.

دوباره سالم بودن Switch فیزیکی را بیش از حد تفسیر نکن. اگر NIC Host up/up است و بقیه Applicationهای همان Host سالم‌اند، تغییر VLAN روی Access Switch برای یک Container خاص باید با دلیل قوی انجام شود. از نزدیک‌ترین نقطه به سرویس شروع کن و کم‌کم به شبکه بیرونی برو. همین ترتیب در VM هم داشتیم؛ فقط اجزای نرم‌افزاری داخل Host متفاوت هستند.

Client
  ↓
Physical Network
  ↓
Host NIC
  ↓
Host / Container Network
  ↓
Port Mapping
  ↓
Container Interface
  ↓
Application

بعد از رفع مشکل، تست واقعی کاربر را تکرار کن. اگر Port Mapping اصلاح شد و صفحه Web باز شد، Log و تنظیم تغییرکرده را ثبت کن. اگر فقط Restart کردن Container سرویس را موقتاً برگرداند ولی علت مشخص نشد، Root Cause هنوز تأیید نشده است و باید این موضوع در Ticket نوشته شود. بازگرداندن سرویس و پیدا کردن علت اصلی دو نتیجه متفاوت هستند.