فصل هفتم: کانتینرها و Docker
بنای زیرساخت‌های مدرن نرم‌افزار
در فصل پیش‌تر یاد گرفتیم که مجازی‌سازی چگونه به ما اجازه می‌دهد چندین سیستم‌عامل کامل را روی یک سخت‌افزار اجرا کنیم. در این فصل یک گام مهم جلوتر می‌رویم: کانتینرها — فناوری‌ای که امروز قلب اکثر اپلیکیشن‌های مدرن است؛ از وب‌سایت‌ها و اپلیکیشن‌های موبایل گرفته تا سرویس‌های هوش مصنوعی و فضای ابری. در این درس یاد می‌گیرید کانتینر دقیقاً چیست، چه تفاوتی با ماشین مجازی دارد، چگونه با Docker ساخته و اجرا می‌شود، و Kubernetes چگونه صدها کانتینر را به‌صورت خودکار مدیریت می‌کند.
🎯 آنچه در این فصل یاد می‌گیرید:
- ✓ کانتینر چیست و چرا نسبت به ماشین مجازی سبک‌تر و سریع‌تر است
- ✓ تفاوت ماشین مجازی (VM) با کانتینر به‌صورت تصویری و در یک جدول
- ✓ کار با Docker: ساخت، اجرا و مدیریت کانتینرها با دستورهای واقعی
- ✓ مفاهیم پایه: Image، Container، Registry و Dockerfile
- ✓ Kubernetes و خودکارسازی مقیاس، بازیابی و توزیع بار
- ✓ کاربردهای واقعی: میکروسرویس، Cloud Native و CI/CD
چرا کانتینرها؟ مشکل قدیمی توسعه‌دهندگان
یک داستان آشنا را تصور کنید: یک برنامه‌نویس روی لپ‌تاپ خودش یک اپلیکیشن وب می‌سازد که بدون مشکل اجرا می‌شود. همان برنامه را برای تیم می‌فرستد؛ روی کامپیوتر هم‌تیمی‌اش خطا می‌دهد، چون نسخه‌ی کتابخانه‌ها فرق دارد. روی سرور تست که نصب می‌شود، باز خطای دیگری می‌دهد؛ چون ساختار سیستم‌عامل سرور متفاوت است. و در پایان، روی سرور اصلیِ شرکت هم دوباره مشکل پیدا می‌شود. این مشکل معروف «روی سیستم من کار می‌کند!» (It works on my machine) سال‌ها دغدغه‌ی تیم‌های نرم‌افزاری بود.
راه‌حل اول، ماشین‌های مجازی بودند: یک VM کامل با سیستم‌عامل و همه‌ی تنظیمات می‌ساختید و آن را جابه‌جا می‌کردید. اما این راه‌حل سنگین است: هر VM یک سیستم‌عامل کامل چند گیگابایتی دارد، بوت شدنش ثانیه‌ها تا دقیقه‌ها طول می‌کشد و روی یک سرور فقط تعداد محدودی VM جا می‌شود.
کانتینرها دقیقاً همین‌جا وارد می‌شوند: با یک ایده‌ی ساده اما هوشمندانه، به‌جای مجازی‌سازی کل سیستم‌عامل، فقط خود برنامه و چیزهایی که برای اجرایش لازم است را در یک بسته‌ی سبک قرار می‌دهند. نتیجه؟ بسته‌ای چند مگابایتی که در کسری از ثانیه بالا می‌آید، همه‌جا یکسان اجرا می‌شود و روی یک سرور صدها تا از آن جا می‌شود. به همین دلیل است که تقریباً تمام شرکت‌های بزرگ دنیا — از گوگل و نتفلیکس تا استارتاپ‌های کوچک — امروز از کانتینرها استفاده می‌کنند.
کانتینر چیست؟
یک کانتینر (به فارسی: ظرف) یک بسته‌ی استاندارد و سبک از یک برنامه است که همه‌ی چیزهایی را که برنامه برای اجرا لازم دارد در خودش جمع می‌کند: کد برنامه، کتابخانه‌ها و وابستگی‌ها، فایل‌های تنظیمات و حتی ابزارهای جانبی. وقتی کانتینر را روی هر سیستمی اجرا می‌کنید، برنامه دقیقاً در همان محیطی اجرا می‌شود که برایش ساخته شده — چه روی لپ‌تاپ شما، چه روی سرور آزمایشی، چه در فضای ابری.
تشبیه ساده: کانتینر را مثل کانتینرهای بارِ کشتی‌های تجاری تصور کنید. پیش از کانتینرهای استاندارد، بارگیری کشتی‌ها آشفته بود: هر جعبه شکلی متفاوت داشت و وقت زیادی تلف می‌شد. اما کانتینر استاندارد بار همه‌چیز را عوض کرد: هر کانتینر ابعاد یکسان دارد، مستقل است، با هر کشتی و هر کامیون و هر قطار سازگار است، و محتوایش با محیط بیرونی اشتباه نمی‌شود. کانتینرهای نرم‌افزاری هم دقیقاً همین نقش را برای برنامه‌ها ایفا می‌کنند: بسته‌ای استاندارد و قابل‌حمل که همه‌جا یکسان رفتار می‌کند.
نکته‌ی کلیدی: کانتینر «ماشین» را مجازی نمی‌کند، بلکه محیط اجرای برنامه را ایزوله می‌کند. کانتینرها هسته‌ی سیستم‌عامل میزبان (Kernel) را با هم به اشتراک می‌گذارند و همین باعث می‌شود سبک و فوق‌سریع باشند.
مزایای اصلی کانتینرها
🏎️ سبک و فوق‌سریع
حجم یک کانتینر معمولاً چند مگابایت است (نه چند گیگابایت!) و در کسری از ثانیه راه‌اندازی می‌شود. برای همین روی یک سرور واحد می‌توان ده‌ها و صدها کانتینر را کنار هم اجرا کرد.
🎯 یکسان در همه‌جا
چون برنامه با تمام وابستگی‌هایش بسته‌بندی شده، روی لپ‌تاپ، سرور تست و فضای ابری دقیقاً یکسان اجرا می‌شود. مشکل «روی سیستم من کار می‌کند» برای همیشه حذف می‌شود.
🔒 ایزوله و امن
هر کانتینر در فضای مجزای خودش اجرا می‌شود. اگر یک کانتینر خراب شود یا هک شود، بقیه‌ی کانتینرها و سیستم میزبان سالم می‌مانند — مثل اتاق‌های جدا در یک هتل.
ماشین مجازی در برابر کانتینر
برای اینکه قدرت کانتینرها را واقعاً حس کنید، آن‌ها را کنار «خواهر بزرگ‌ترشان» — ماشین مجازی — بگذاریم. هر دو هدف یکسانی دارند: ایزوله کردن محیط‌های اجرا. اما از دو راه متفاوت. تفاوت اصلی در لایه‌ی میانی است: ماشین مجازی یک سیستم‌عامل مهمان (Guest OS) کامل روی یک Hypervisor اجرا می‌کند، در حالی که کانتینرها هسته‌ی سیستم‌عامل میزبان را به اشتراک می‌گذارند و فقط برنامه و وابستگی‌هایش را با خودشان حمل می‌کنند.
در تصویر بالا سمت چپ را ببینید: در دنیای VM، برای دو برنامه باید دو سیستم‌عامل کامل (Guest OS ۱ و ۲) نصب شود و یک Hypervisor بین آن‌ها و سخت‌افزار قرار بگیرد. اما سمت راست (کانتینرها) سه برنامه روی یک هسته‌ی مشترک نشسته‌اند و هیچ سیستم‌عامل اضافه‌ای وجود ندارد. دقیقاً همین‌جاست که صرفه‌جویی بزرگ اتفاق می‌افتد.
جدول مقایسه: VM در برابر کانتینر
| ملاک | ماشین مجازی (VM) | کانتینر |
|---|---|---|
| حجم معمول | چند گیگابایت (GB) | چند مگابایت (MB) |
| زمان راه‌اندازی | ثانیه‌ها تا دقیقه‌ها | کسری از ثانیه |
| سیستم‌عامل مهمان | بله — هر VM یک OS کامل | خیر — هسته‌ی میزبان مشترک است |
| مصرف منابع (RAM/CPU) | زیاد | حداقلی |
| مقیاس‌پذیری | محدود — تعداد کم روی هر سرور | بالا — صدها کانتینر روی یک سرور |
| ایزوله‌سازی | قوی‌تر (سطح سخت‌افزار) | خوب (سطح سیستم‌عامل) |
| کاربرد ایده‌آل | اجرای OSهای کاملاً متفاوت، محیط‌های تست سنگین | میکروسرویس‌ها، توسعه‌ی سریع، استقرار ابری |
کدام را انتخاب کنیم؟ این دو رقیب نیستند؛ مکمل‌اند. جایی که نیاز به سیستم‌عامل‌های کاملاً متفاوت یا ایزوله‌سازی سطح سخت‌افزار دارید، VM درست‌تر است. جایی که هدف، اجرای سریع و یکسانِ برنامه‌ها و مقیاس‌پذیری است، کانتینر بهترین انتخاب است — و در عمل، خیلی از شرکت‌ها داخل یک VM کانتینرها را اجرا می‌کنند تا از هر دو دنیا استفاده کنند.
Docker — رایج‌ترین ابزار ساخت کانتینر
حالا که می‌دانیم کانتینر چیست، سؤال طبیعی این است: چطور کانتینر بسازیم؟ Docker شناخته‌شده‌ترین و پرکاربردترین پلتفرم برای ساخت، اجرا و مدیریت کانتینرهاست — به‌قدری معروف که خیلی‌ها فکر می‌کنند Docker و کانتینر یکی هستند! (نیستند: Docker فقط معروف‌ترین ابزارِ کار با کانتینرهاست.) Docker در سال ۲۰۱۳ عرضه شد و با ساده کردن فوق‌العاده‌ی کار با کانتینرها، باعث انقلاب در دنیای نرم‌افزار شد.
سه مفهوم پایه: Image، Container و Registry
قبل از نوشتن اولین دستور Docker، باید این سه مفهوم را کاملاً از هم تفکیک کنید. این سه، ستون فقرات کار با Docker هستند:
📦 Image (تصویر)
نقشه یا قالبِ فقط‌خواندنی برنامه است — مثل دستور پخت کیک یا قالب یخ. Image خودش اجرا نمی‌شود؛ فقط مشخص می‌کند برنامه، کتابخانه‌ها و تنظیمات چگونه کنار هم قرار بگیرند. هر Image از چند لایه (Layer) ساخته شده که لایه‌های مشترک بین Imageها فقط یک‌بار روی دیسک ذخیره می‌شوند.
🚀 Container (کانتینر)
نمونه‌ی فعال و در حال اجرا از یک Image است — کیکی که واقعاً از قالب پخته شده! وقتی می‌گویید «کانتینر را اجرا کن»، یعنی از یک Image یک نمونه‌ی زنده بساز. از یک Image می‌توانید هر تعداد که بخواهید کانتینر مستقل بسازید؛ مثل چند کیک از یک قالب.
📚 Registry (مخزن)
انبار ابریِ Imageها است — مثل فروشگاه اپلیکیشن، اما برای Imageها. معروف‌ترین آن Docker Hub است که صدها هزار Image آماده (نگین، پایتون، MySQL و…) دارد. با دستور pull یک Image را دانلود و با push Image خودتان را منتشر می‌کنید.
در تصویر بالا ساختار لایه‌ای یک Image را می‌بینید: از پایین به بالا، لایه‌ی سیستم‌عامل پایه (Base OS)، لایه‌ی ابزارها، لایه‌ی کتابخانه‌ها و در نهایت لایه‌ی کد برنامه. اگر دو برنامه از یک Base OS یکسان استفاده کنند، Docker آن لایه را فقط یک‌بار ذخیره می‌کند — این یکی از دلایل اصلی سبکی کانتینرهاست. وقتی کانتینر اجرا می‌شود، Image فقط‌خواندنی می‌ماند و تغییرات آن در یک لایه‌ی موقتِ نوشتنی ثبت می‌شود.
Dockerfile: نقشه‌ی ساخت Image
Dockerfile یک فایل متنی ساده است که به Docker می‌گوید Image شما چگونه ساخته شود: از چه سیستم‌عامل پایه‌ای شروع کن، چه چیزهایی نصب کن، چه فایل‌هایی کپی کن و دستور اجرای برنامه چیست. مثال زیر یک Dockerfile واقعی برای یک وب‌اپلیکیشن پایتونی است:
# شروع از ایمیج رسمی پایتون (لایه پایه) FROM python:3.12-slim # تعیین پوشه‌ی کاری داخل کانتینر WORKDIR /app # کپی فایل وابستگی‌ها و نصب آن‌ها COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # کپی باقی کد برنامه COPY . . # دستوری که هنگام اجرای کانتینر انجام می‌شود CMD ["python", "app.py"]
هر خطِ RUN، COPY و FROM در واقع یک لایه‌ی جدید در Image می‌سازد. Docker هنگام ساخت مجدد، فقط لایه‌های تغییرکرده را دوباره می‌سازد — برای همین ساخت Imageها بعد از اولین بار بسیار سریع است.
اولین دستورهای Docker شما
Docker از طریق خط فرمان (Terminal) کار می‌کند. چهار دستور زیر رایج‌ترین کارهای روزمره هستند — همین چهار دستور، شروع خوبی برای تمرین واقعی است:
# ۱) دانلود (pull) یک Image آماده از Docker Hub docker pull nginx # ۲) اجرای یک کانتینر از آن Image در پس‌زمینه (-d) و روی پورت ۸۰ docker run -d -p 80:80 nginx # ۳) ساخت Image از Dockerfile پوشه‌ی فعلی و نام‌گذاری آن docker build -t myapp . # ۴) فهرست کانتینرهای در حال اجرا docker ps
این دستورها را به‌سادگی بخوانید: pull یعنی «دانلود کن»، run یعنی «اجرا کن»، build یعنی «بساز» و ps یعنی «فهرستِ در حال اجراها را نشان بده». اگر Docker روی سیستم‌تان نصب است، همین حالا docker run hello-world را امتحان کنید — اولین کانتینر شما!
Kubernetes — مدیریت خودکار کانتینرها در مقیاس بزرگ
تا اینجا یاد گرفتیم یک کانتینر را چطور بسازیم و اجرا کنیم. اما دنیای واقعی فرق دارد: یک پلتفرم مثل Netflix هم‌زمان هزاران کانتینر روی صدها سرور اجرا می‌کند. حالا تصور کنید یکی از سرورها از کار بیفتد: کدام کانتینرها به کدام سرور منتقل شوند؟ اگر کاربران زیاد شدند، از کجا بفهمیم و چند کانتینر جدید بسازیم؟ مدیریت دستی این کارها غیرممکن است.
Kubernetes (مخفف: K8s) پاسخ این مشکل است: یک سیستم متن‌باز که ابتدا توسط گوگل ساخته شد و امروز استاندارد جهانیِ هماهنگ‌سازی (Orchestration) کانتینرهاست. Kubernetes مانند یک ترافیک‌چیِ هوشمند عمل می‌کند: تصمیم می‌گیرد هر کانتینر روی کدام سرور اجرا شود، اگر سروری خراب شد کانتینرها را خودکار جابه‌جا می‌کند، با افزایش تعداد کاربران به‌صورت خودکار کانتینرهای بیشتری می‌سازد (Scale) و ترافیک را به‌شکل متعادل بین آن‌ها پخش می‌کند.
مفاهیم پایه‌ی Kubernetes
Node (گره)
هر Node یک سرور (فیزیکی یا مجازی) در خوشه است. روی هر Node برنامه‌ی کوچکی به‌نام kubelet اجرا می‌شود که دستورهای Control Plane را اجرا می‌کند.
Pod
کوچک‌ترین واحد اجرا در Kubernetes؛ معمولاً شامل یک کانتینر (گاهی چند کانتینر که باید کنار هم باشند). Kubernetes همیشه با Pod کار می‌کند نه مستقیم با کانتینر.
Deployment
«نسخه‌ی مطلوب» شما: مشخص می‌کند از هر Pod چند نسخه باید اجرا شود (مثلاً ۳ نسخه از وب‌سایت). اگر یکی خراب شود، Kubernetes خودش یکی جدید می‌سازد.
Service
آدرس پایدار ورودی. Podها مدام ساخته و خراب می‌شوند، اما Service مثل یک تلفن‌خانه‌ی ثابت، همیشه در دسترس است و ترافیک را به Podهای سالم می‌رساند.
در تصویر بالا یک خوشه‌ی کوچک سه‌نوده را می‌بینید: Control Plane بالا (مغز تصمیم‌گیر) وضعیت مطلوب را می‌داند و به Nodeها دستور می‌دهد؛ روی هر Node چند Pod (مربع‌های رنگی) اجرا می‌شود. نکته‌ی مهم: Podهای «وب‌سایت» روی دو Node مختلف پخش شده‌اند — Kubernetes عمداً بار را پخش می‌کند تا خرابی یک سرور، کل سرویس را از کار نیندازد.
چرخه‌ی عمر: از کد تا اجرا و مقیاس
حالا همه‌ی آموخته‌های این فصل را در یک تصویر واحد کنار هم بگذاریم. این چرخه، روزمره‌ترین مسیر یک برنامه در دنیای کانتینری است و در واقعیت دقیقاً همین پنج مرحله — معمولاً چند بار در روز — اتفاق می‌افتد:
- 💻 کد: توسعه‌دهنده برنامه را می‌نویسد و کنارش یک Dockerfile می‌سازد — دستور پختی که گفتیم.
- 📦 Build: با
docker buildاز آن کد یک Image ساخته می‌شود — بسته‌ی نهایی و تغییرناپذیر. - 📚 Push: Image به یک Registry (مثل Docker Hub) فرستاده می‌شود تا تیم و سرورها از هر جای دنیا به آن دسترسی داشته باشند.
- ⚙️ Run: روی سرور تولید (یا در خوشه‌ی Kubernetes با
kubectl apply) کانتینرها از همان Image اجرا می‌شوند. - 🌍 Scale: با افزایش کاربران، Kubernetes تعداد کانتینرها را خودکار زیاد و در خلوت کم می‌کند.
شعار معروف این دنیا را به خاطر بسپارید: «یک‌بار بساز، همه‌جا اجرا کن» (Build Once, Run Anywhere) — چون همان Imageِ واحد، بدون حتی یک تغییر، روی لپ‌تاپ شما، سرور تست و سرور اصلی اجرا می‌شود.
کانتینرها در دنیای واقعی
تا اینجا مفاهیم را یاد گرفتیم؛ حالا ببینیم چه کسانی و چگونه از آن‌ها استفاده می‌کنند. این سه الگو، رایج‌ترین شکل استفاده‌ی کانتینرها در صنعت هستند و در مصاحبه‌های کاری هم زیاد پرسیده می‌شوند:
🌐 میکروسرویس‌ها (Microservices)
به‌جای یک برنامه‌ی غول‌پیکر (Monolith)، پلتفرم‌هایی مثل Netflix و Spotify برنامه را به صدها سرویس کوچک مستقل تقسیم می‌کنند — سرویس جست‌وجو، سرویس پرداخت، سرویس پیشنهادها — که هر کدام در کانتینر خودشان اجرا می‌شوند. نتیجه: هر تیم می‌تواند بخش خودش را مستقل توسعه دهد، تست کند و بدون دست زدن به بقیه، منتشر کند.
☁️ فضای ابری (Cloud Native)
سرویس‌های ابری مدرن — AWS، Google Cloud و Azure — همه بر پایه‌ی کانتینر ساخته شده‌اند. وقتی یک سرویس ابری «بدون سرور» (Serverless) استفاده می‌کنید، در پس‌زمینه در واقع کانتینرهایی هستند که چند ثانیه بالا می‌آیند، کار انجام می‌دهند و خاموش می‌شوند — و شما فقط برای همان چند ثانیه پول می‌دهید.
⚙️ DevOps و CI/CD
در خطوط تولید نرم‌افزار مدرن، به‌محض اینکه توسعه‌دهنده کد جدیدی ثبت (commit) می‌کند، سیستم به‌طور خودکار Image می‌سازد، تست می‌کند و منتشر می‌کند — همه‌چیز کانتینری. برای همین انتشار نسخه‌های جدید به‌جای «شبِ تحویل پر استرس»، به یک اتفاق عادی چندبار در هفته تبدیل شده است.
خودآزمایی — چقدر یاد گرفته‌اید؟
قبل از خواندن پاسخ‌ها، خودتان پاسخ را با صدای بلند بگویید؛ سپس بازش کنید و مقایسه کنید. اگر جواب سؤالی را نمی‌دانید، برگردید و همان بخش را دوباره بخوانید.
۱. تفاوت اصلی ماشین مجازی (VM) با کانتینر چیست؟
VM برای هر نمونه یک سیستم‌عامل مهمان کامل (Guest OS) روی Hypervisor اجرا می‌کند و به همین دلیل سنگین و کند است (گیگابایت‌ها، دقیقه‌ها). کانتینر اما هسته‌ی سیستم‌عامل میزبان را به اشتراک می‌گذارد و فقط برنامه و وابستگی‌ها را بسته‌بندی می‌کند — برای همین سبک و فوق‌سریع است (مگابایت‌ها، میلی‌ثانیه‌ها).
۲. سه مفهوم اصلی Docker کدام‌اند و هر کدام چه نقشی دارند؟
Image: قالب فقط‌خواندنی و لایه‌لایه‌ی برنامه (دستور پخت). Container: نمونه‌ی فعال و در حال اجرا از آن Image (کیکِ پخته). Registry: مخزن ابری برای ذخیره و اشتراک Imageها (مثل Docker Hub) که با دستورهای pull و push کار می‌کند.
۳. چرا کانتینرها آن‌قدر سریع راه‌اندازی می‌شوند؟
چون برخلاف VM نیازی به بوت کردن یک سیستم‌عامل کامل ندارند: هسته‌ی سیستم‌عامل از قبل روی میزبان در حال اجراست و کانتینر فقط محیط اجرای برنامه را ایزوله می‌کند. راه‌اندازی کانتینر یعنی فقط «روشن کردن برنامه»، نه «روشن کردن یک کامپیوتر».
۴. Kubernetes چه مشکلی را حل می‌کند و سه کار خودکار آن چیست؟
Kubernetes مشکل مدیریت صدها کانتینر روی ده‌ها سرور را حل می‌کند. سه کار خودکارش: مقیاس‌بندی (Scale) با افزایش/کاهش بار، خوددرمانی (Self-healing) — جایگزینی کانتینرهای خراب — و توزیع بار (Load Balancing) بین کانتینرهای سالم.
۵. معنی «Build Once, Run Anywhere» چیست و چرا مهم است؟
یعنی Imageای که یک‌بار روی لپ‌تاپ ساخته می‌شود، همان بدون هیچ تغییری روی سرور تست و تولید اجرا می‌شود — چون همه‌ی وابستگی‌ها داخل خودش است. این همان چیزی است که مشکل کلاسیک «روی سیستم من کار می‌کند» را برای همیشه حذف می‌کند و اعتماد به انتشارها را بالا می‌برد.
💡 خلاصه فصل هفتم
- ✓ کانتینر = بسته‌ی سبک و استانداردِ برنامه + همه‌ی وابستگی‌هایش، با هسته‌ی مشترک
- ✓ تفاوت اصلی با VM: Guest OS کامل در VM، هسته‌ی مشترک در کانتینر
- ✓ سه مفهوم Docker: Image (قالب)، Container (نمونه‌ی اجرا)، Registry (مخزن)
- ✓ Dockerfile = دستور پخت Image؛ چرخه: کد ← Build ← Push ← Run ← Scale
- ✓ Kubernetes: مقیاس‌بندی، خوددرمانی و توزیع بار به‌صورت خودکار
- ✓ کاربردها: میکروسرویس‌ها، Cloud Native و خطوط CI/CD