یک برنامه وب ممکن است روی لپ‌تاپ توسعه‌دهنده بدون مشکل اجرا شود، اما در محیط استقرار به‌دلیل تفاوت نسخه‌های نرم‌افزار، وابستگی‌ها یا تنظیمات شکست بخورد. وقتی تعداد سرویس‌ها و نمونه‌های در حال اجرا بیشتر می‌شود، مسئله دیگری هم شکل می‌گیرد: چگونه آن‌ها را مستقر کنیم، ترافیک را میانشان توزیع کنیم و در صورت خرابی، سرویس را دوباره در دسترس قرار دهیم؟
Docker و Kubernetes به این دو دسته مسئله پاسخ می‌دهند، اما نقش یکسانی ندارند. Docker ابزارهایی برای ساخت و اجرای کانتینر فراهم می‌کند؛ Kubernetes اجرای برنامه‌های کانتینری را در یک کلاستر مدیریت می‌کند. شناخت این مرز، برای انتخاب ابزار مناسب و جلوگیری از پیچیدگی غیرضروری اهمیت دارد.
Docker چیست و برای توسعه وب چه کاربردی دارد؟
Docker به شما کمک می‌کند برنامه و وابستگی‌های لازم برای اجرای آن را در قالب یک ایمیج کانتینر بسته‌بندی کنید. سپس می‌توانید از روی این ایمیج، یک یا چند کانتینر بسازید.
برای مثال، یک API نوشته‌شده با Node.js ممکن است به نسخه مشخصی از محیط اجرای جاوااسکریپت، چند بسته نرم‌افزاری و تنظیمات اتصال به پایگاه داده نیاز داشته باشد. ایمیج می‌تواند محیط اجرا، بسته‌ها و کد برنامه را در خود داشته باشد؛ تنظیمات وابسته به محیط، مانند نشانی پایگاه داده، معمولاً هنگام اجرا به آن داده می‌شوند.
مزیت اصلی، تکرارپذیرتر شدن محیط اجراست. البته کانتینرسازی تمام تفاوت‌ها را حذف نمی‌کند: معماری پردازنده، سرویس‌های بیرونی، مجوز فایل‌ها و تنظیمات شبکه همچنان می‌توانند بر رفتار برنامه اثر بگذارند.
تفاوت کانتینر و ماشین مجازی
ماشین مجازی معمولاً سیستم‌عامل مهمان و کرنل مستقل خود را دارد. کانتینرها از کرنل میزبان استفاده می‌کنند و فرایندها، شبکه و فایل‌سیستم آن‌ها با سازوکارهای سیستم‌عامل از یکدیگر جدا می‌شود.
در نتیجه، کانتینرها معمولاً سربار کمتری نسبت به ماشین‌های مجازی دارند؛ اما این جداسازی را نباید معادل یک مرز امنیتی مطلق دانست. همچنین اجرای کانتینرهای لینوکسی روی macOS یا Windows معمولاً به یک محیط لینوکسی واسط، مانند ماشین مجازی، متکی است.
مفاهیم اصلی Docker که باید بشناسید
برای شروع، چند مفهوم بیشترین کاربرد را در توسعه وب دارند:
- Image یا ایمیج: بسته‌ای شامل برنامه، وابستگی‌ها و اطلاعات لازم برای اجرای کانتینر.
- Container یا کانتینر: نمونه اجرایی ساخته‌شده از روی ایمیج، با فایل‌سیستم قابل‌نوشتن و تنظیمات مخصوص خود.
- Dockerfile: فایل دستورالعمل ساخت ایمیج؛ مثلاً تعیین ایمیج پایه، نصب وابستگی‌ها و تعریف فرمان اجرا.
- Registry یا رجیستری: محل نگهداری و توزیع ایمیج‌ها، به‌صورت عمومی یا خصوصی.
- Volume یا والیوم: سازوکاری برای نگهداری داده مستقل از چرخه عمر کانتینر.
- Network یا شبکه: بستری برای ارتباط کانتینرها با یکدیگر و سرویس‌های بیرونی.
تمایز ایمیج و کانتینر مهم است: ایمیج را می‌سازید و منتشر می‌کنید؛ کانتینر را از روی آن اجرا، متوقف یا جایگزین می‌کنید.
پورت و ذخیره‌سازی؛ دو نقطه خطای رایج
گوش‌دادن برنامه روی یک پورت داخل کانتینر، به‌تنهایی آن را از بیرون قابل‌دسترسی نمی‌کند. باید پورت لازم منتشر شود و برنامه نیز روی رابط شبکه مناسب گوش دهد. گوش‌دادن صرفاً روی 127.0.0.1 داخل کانتینر می‌تواند دسترسی از بیرون را مختل کند.
از طرف دیگر، داده‌ای که فقط در لایه قابل‌نوشتن کانتینر ذخیره شده باشد، با حذف آن کانتینر از بین می‌رود. فایل‌های پایگاه داده، بارگذاری کاربران و سایر داده‌های ماندگار باید محل ذخیره‌سازی مناسبی داشته باشند.
Docker Compose برای محیط توسعه
یک پروژه وب معمولاً فقط یک فرایند نیست. ممکن است به بک‌اند، پایگاه داده، Redis و یک پردازشگر کارهای پس‌زمینه نیاز داشته باشد. مدیریت دستی این اجزا با فرمان‌های جداگانه، مستعد خطاست.
Docker Compose امکان تعریف سرویس‌ها، شبکه‌ها، والیوم‌ها و تنظیمات اجرا را در یک فایل فراهم می‌کند. اعضای تیم می‌توانند با همین تعریف، محیط محلی مشابهی راه‌اندازی کنند.
برای نمونه، سرویس بک‌اند می‌تواند از طریق نام سرویس پایگاه داده در شبکه Compose به آن متصل شود. داخل کانتینر بک‌اند، localhost به خود همان کانتینر اشاره می‌کند، نه کانتینر پایگاه داده.
در توسعه، اتصال پوشه کد میزبان به کانتینر با bind mount برای مشاهده سریع تغییرات مفید است. در استقرار، معمولاً کد در ایمیج قرار می‌گیرد تا نسخه منتشرشده مشخص و تکرارپذیر باشد.
یک نکته مهم: ترتیب شروع سرویس‌ها لزوماً به معنی آماده‌بودن آن‌ها نیست. برنامه باید قطع یا تأخیر اتصال به پایگاه داده را مدیریت کند؛ بررسی سلامت سرویس نیز می‌تواند به هماهنگی راه‌اندازی کمک کند.
Kubernetes چیست و چه چیزی به Docker اضافه می‌کند؟
Kubernetes یک سامانه ارکستراسیون کانتینر است. به‌جای اجرای دستی کانتینرها روی سرورها، وضعیت مطلوب برنامه را تعریف می‌کنید و Kubernetes تلاش می‌کند وضعیت واقعی را با آن هماهنگ نگه دارد.
مثلاً مشخص می‌کنید که سه نمونه از API باید اجرا شوند. اگر یکی از آن‌ها از کار بیفتد، کنترلر مربوط می‌تواند نمونه جایگزین ایجاد کند؛ البته به شرط وجود منابع کافی و نبود مشکلاتی مانند ایمیج نامعتبر یا تنظیمات اشتباه.
Kubernetes مسئولیت‌هایی مانند زمان‌بندی اجرا روی سرورها، کشف سرویس‌ها، مدیریت انتشار و هماهنگی منابع ذخیره‌سازی را بر عهده می‌گیرد. بااین‌حال، کد برنامه، طراحی پایگاه داده یا معماری نامناسب را اصلاح نمی‌کند.
Kubernetes برای اجرای کانتینرها به Docker Engine وابسته نیست. معمولاً از runtimeهای سازگار با رابط CRI، مانند containerd یا CRI-O، استفاده می‌کند. ایمیج‌های ساخته‌شده با Docker همچنان در این محیط‌ها قابل‌استفاده‌اند، مشروط به سازگاری ایمیج و محیط اجرا.
اجزای Kubernetes در یک برنامه وب
کلاستر Kubernetes از بخش کنترل و ماشین‌های اجرایی یا Nodeها تشکیل می‌شود. بخش کنترل وضعیت کلاستر را مدیریت می‌کند و Nodeها محل اجرای بارهای کاری هستند.
| مفهوم | نقش در توسعه و استقرار وب |
|---|---|
| Pod | کوچک‌ترین واحد قابل‌استقرار؛ شامل یک یا چند کانتینر مرتبط |
| Deployment | مدیریت نمونه‌های برنامه و انتشار نسخه‌های جدید |
| Service | ایجاد نقطه دسترسی پایدار به مجموعه‌ای از Podها |
| Ingress | تعریف قواعد مسیریابی HTTP و HTTPS به سرویس‌ها |
| ConfigMap | نگهداری تنظیمات غیرمحرمانه |
| Secret | نگهداری داده‌های حساس با کنترل دسترسی مناسب |
| PersistentVolumeClaim | درخواست فضای ذخیره‌سازی ماندگار |
Pod، Deployment و Service چه ارتباطی دارند؟
برای یک API بدون وضعیت، معمولاً از Deployment استفاده می‌شود. Deployment نمونه‌های برنامه را مدیریت می‌کند و Podها محیط اجرای آن نمونه‌ها هستند.
Podها ممکن است حذف و دوباره ساخته شوند؛ بنابراین نشانی شبکه آن‌ها مبنای مناسبی برای اتصال پایدار نیست. Service یک نقطه دسترسی نسبتاً پایدار ایجاد می‌کند و ترافیک را به Podهای منتخب می‌رساند.
دسترسی کاربران از بیرون کلاستر
برای هدایت درخواست‌هایی مانند example.com/api به بک‌اند، می‌توان از Ingress استفاده کرد. اما تعریف منبع Ingress به‌تنهایی کافی نیست؛ باید یک Ingress Controller مناسب نیز نصب و تنظیم شده باشد.
Gateway API هم گزینه‌ای برای تعریف مسیریابی است، ولی انتخاب آن به امکانات و پیاده‌سازی موجود در کلاستر بستگی دارد. در هر دو حالت، DNS، گواهی TLS و تنظیمات شبکه باید درست مدیریت شوند.
مسیر عملی از کد تا استقرار
یک مسیر قابل‌فهم برای پروژه وب می‌تواند این مراحل را داشته باشد:
- برنامه را برای اجرای قابل‌پیش‌بینی آماده کنید. تنظیمات را از کد جدا کنید، لاگ‌ها را به خروجی استاندارد بفرستید و توقف کنترل‌شده را پیاده‌سازی کنید.
- Dockerfile بنویسید. وابستگی‌های لازم را نصب کنید و فرمان اجرای مشخصی داشته باشید. فایل‌های محرمانه یا غیرضروری را وارد ایمیج نکنید.
- محیط محلی را با Compose اجرا کنید. ارتباط بک‌اند، پایگاه داده و سرویس‌های جانبی را بررسی کنید.
- در خط CI ایمیج بسازید و آزمایش کنید. اجرای آزمون‌ها و بررسی امنیتی ایمیج، در صورت پشتیبانی ابزارهای پروژه، بخشی از این مرحله است.
- ایمیج را در رجیستری منتشر کنید. از شناسه نسخه مشخص استفاده کنید؛ ارجاع با digest می‌تواند محتوای دقیق ایمیج را تثبیت کند.
- منابع Kubernetes را تعریف کنید. Deployment، Service، تنظیمات، داده‌های حساس و مسیر دسترسی بیرونی را متناسب با نیاز برنامه بسازید.
- انتشار را پایش کنید. علاوه بر وضعیت Podها، نرخ خطا، زمان پاسخ و عملکرد واقعی برنامه را بررسی کنید.
برای ساخت فرانت‌اند یا برنامه‌های کامپایل‌شونده، ساخت چندمرحله‌ای مفید است: ابزارهای ساخت در یک مرحله استفاده می‌شوند و فقط خروجی لازم به ایمیج نهایی منتقل می‌شود. این روش می‌تواند اندازه ایمیج و نرم‌افزارهای غیرضروری محیط اجرا را کاهش دهد.
سلامت برنامه، منابع و مقیاس‌پذیری
Kubernetes برای تصمیم‌گیری درست به نشانه‌های قابل‌اعتماد از برنامه نیاز دارد:
- Readiness probe: آیا این نمونه آماده دریافت ترافیک است؟
- Liveness probe: آیا وضعیت برنامه نیازمند راه‌اندازی مجدد است؟
- Startup probe: آیا راه‌اندازی اولیه برنامه کامل شده است؟
این بررسی‌ها را نباید یکسان طراحی کرد. مثلاً وابسته‌کردن liveness به دسترس‌بودن یک سرویس بیرونی ممکن است هنگام خرابی آن سرویس، باعث راه‌اندازی مجدد بی‌فایده همه نمونه‌ها شود.
در تعریف منابع نیز request برای زمان‌بندی Pod اهمیت دارد و limit مصرف منابع را محدود می‌کند. محدودیت نامناسب حافظه می‌تواند به خاتمه فرایند منجر شود؛ محدودیت CPU نیز ممکن است باعث محدودشدن توان پردازش و افزایش تأخیر شود.
افزایش تعداد Podها الزاماً ظرفیت کل سامانه را افزایش نمی‌دهد. پایگاه داده، صف پیام یا سرویس بیرونی ممکن است گلوگاه باشد. مقیاس‌گذاری خودکار هم به تنظیمات، معیارهای مناسب و ظرفیت کلاستر نیاز دارد.
داده، امنیت و انتشار نسخه‌ها
برای مقیاس‌پذیری وب، بهتر است نمونه‌های برنامه تا حد امکان بدون وضعیت محلی باشند. نگهداری نشست کاربر یا فایل بارگذاری‌شده فقط در یک Pod، با جایگزینی آن یا توزیع ترافیک میان چند نمونه مشکل ایجاد می‌کند. ذخیره‌سازی مشترک یا سرویس بیرونی مناسب می‌تواند راه‌حل باشد.
اجرای پایگاه داده در Kubernetes امکان‌پذیر است، اما والیوم ماندگار به‌تنهایی پشتیبان‌گیری، بازیابی، تکثیر و دسترس‌پذیری را حل نمی‌کند. سرویس مدیریت‌شده ممکن است برای برخی تیم‌ها بار عملیاتی کمتری داشته باشد.
در امنیت، اجرای برنامه با کاربر غیرریشه، به‌روزکردن ایمیج پایه و محدودکردن دسترسی‌ها مهم‌اند. Secret نیز صرفاً با رمزگذاری Base64 امن نمی‌شود؛ کنترل دسترسی و تنظیمات حفاظت از داده باید بررسی شوند.
انتشار تدریجی با Deployment می‌تواند اختلال را کاهش دهد، اما تضمین «بدون قطعی» نیست. آمادگی صحیح، ظرفیت کافی، پایان کنترل‌شده درخواست‌ها و سازگاری تغییرات پایگاه داده تعیین‌کننده‌اند. بازگرداندن نسخه برنامه نیز الزاماً تغییرات داده را برنمی‌گرداند.
چه زمانی Kubernetes انتخاب مناسبی نیست؟
اگر برنامه‌ای کوچک، روی یک سرور و با تعداد محدودی سرویس دارید، Docker به‌همراه روش استقرار ساده‌تر ممکن است کافی باشد. Kubernetes هزینه یادگیری، نگهداری، پایش و عیب‌یابی دارد.
وقتی چند سرویس، انتشارهای پرتکرار، نیاز به مدیریت چند ماشین و تیمی با توان عملیاتی مناسب دارید، ارزش آن روشن‌تر می‌شود. انتخاب ابزار باید از نیاز پروژه شروع شود، نه از محبوبیت آن.
سوالات متداول
آیا برای یادگیری Kubernetes باید ابتدا Docker را یاد بگیرم؟
یادگیری ایمیج، کانتینر، شبکه و ذخیره‌سازی پیش‌نیاز عملی خوبی است. لازم نیست همه قابلیت‌های Docker را بشناسید، اما بدون درک کانتینرها، عیب‌یابی Kubernetes دشوار می‌شود.
آیا Docker Compose جایگزین Kubernetes است؟
برای برخی محیط‌های محلی یا استقرارهای ساده می‌تواند کافی باشد. اما مدیریت بارهای کاری در یک کلاستر و هماهنگ‌کردن وضعیت آن‌ها، حوزه اصلی Kubernetes است.
آیا کانتینرسازی برنامه را سریع‌تر می‌کند؟
نه لزوماً. هدف اصلی، بسته‌بندی و مدیریت محیط اجراست. سرعت برنامه بیشتر به کد، منابع، پایگاه داده و تنظیمات وابسته است.
آیا Kubernetes برنامه را خودکار مقیاس‌پذیر می‌کند؟
فقط با پیکربندی مناسب می‌تواند تعداد نمونه‌ها را تغییر دهد. برنامه باید قابلیت اجرای چند نمونه را داشته باشد و وابستگی‌های آن نیز ظرفیت لازم را فراهم کنند.
از یک سرویس ساده شروع کنید
برای یادگیری عملی، ابتدا یک API کوچک را کانتینری کنید، سپس پایگاه داده را با Compose کنار آن اجرا کنید. بعد همان API را با Deployment و Service در یک محیط آموزشی Kubernetes مستقر کنید. این مسیر، تفاوت بسته‌بندی برنامه با مدیریت اجرای آن را روشن می‌کند و کمک می‌کند فقط پیچیدگی موردنیاز پروژه را بپذیرید.
