فرق داکر و کوبرنتیز در سطحی است که هر کدام روی آن کار می کند. داکر ایمیج برنامه را می سازد و کانتینر را روی یک سرور اجرا می کند. کوبرنتیز روی چند سرور تصمیم می گیرد هر کانتینر کجا اجرا شود، اگر از کار افتاد دوباره بالا بیاید، ترافیک بین نسخه ها پخش شود و به روزرسانی بدون قطعی انجام شود.
این دو جای هم را نمی گیرند. معمولاً ایمیج با داکر ساخته می شود و همان ایمیج روی کوبرنتیز اجرا می شود. پس باید دید پروژه شما از Docker Compose روی یک سرور بزرگ تر شده یا نه.
هر کدام چه کاری می کند
| موضوع | داکر و Docker Compose | کوبرنتیز (Kubernetes) |
|---|---|---|
| محدوده | یک سرور | کلاستری از چند سرور (نود) |
| ساخت ایمیج | بله، با Dockerfile | نه؛ ایمیج آماده را از رجیستری می گیرد |
| تعریف سرویس ها | فایل compose.yaml | فایل های YAML برای Deployment، Service، Ingress و غیره |
| کانتینر از کار افتاده | با restart policy روی همان سرور دوباره اجرا می شود | روی همان نود یا نود سالم دیگر دوباره اجرا می شود |
| خرابی کل سرور | همه سرویس ها قطع می شوند | کانتینرها روی نودهای دیگر بالا می آیند |
| به روزرسانی | معمولاً چند ثانیه قطعی هنگام جایگزینی کانتینر | Rolling Update بدون قطعی و امکان برگشت به نسخه قبل |
| مقیاس پذیری | دستی و محدود به یک سرور | خودکار بر اساس مصرف (HPA) |
| پیچیدگی راه اندازی و نگه داری | کم | زیاد؛ کنترل پلین، شبکه، ذخیره ساز و مانیتورینگ |
کوبرنتیز از نسخه 1.24 بدون Docker Engine کار می کند
از نسخه 1.24 کوبرنتیز، لایه ای که Docker Engine را به عنوان محیط اجرا پشتیبانی می کرد (dockershim) حذف شد و کلاسترها با containerd یا CRI-O کار می کنند. این تغییر برای کاربر تقریباً نامرئی بود، چون ایمیج هایی که با داکر ساخته می شوند استاندارد OCI دارند و روی همه این محیط ها اجرا می شوند. داکر هنوز ابزار اصلی ساختن ایمیج و اجرای محلی برنامه روی لپ تاپ توسعه دهنده است.
Docker Compose برای این پروژه ها کافی است
برای بسیاری از شرکت ها کوبرنتیز زودتر از موقع انتخاب می شود. اگر شرایط شما این است، یک سرور با Docker Compose کارتان را راه می اندازد:
- برنامه روی یک سرور جا می شود و چند سرویس دارد (مثلاً وب، دیتابیس، Redis و یک worker).
- چند ثانیه قطعی هنگام استقرار نسخه جدید قابل قبول است یا استقرار را بیرون از ساعت کاری انجام می دهید.
- تیم فنی کوچک است و کسی تمام وقت روی زیرساخت کار نمی کند.
یک فایل Compose ساده همه سرویس ها را با یک دستور بالا می آورد:
services:
web:
image: registry.example.com/shop:1.4.2
ports: ["127.0.0.1:8080:8080"]
restart: unless-stopped
redis:
image: redis:7
restart: unless-stoppedاگر یک پله بیشتر از Compose لازم دارید ولی کوبرنتیز کامل سنگین است، Docker Swarm (که داخل خود Docker Engine هست) یا k3s (نسخه سبک کوبرنتیز) گزینه های میانی اند. نصب داکر و نوشتن Compose را در آموزش نصب داکر توضیح داده ایم.
نشانه هایی که وقت کوبرنتیز رسیده
- برنامه به بیش از یک سرور نیاز دارد، یا خاموش شدن یک سرور نباید سرویس را قطع کند.
- تعداد سرویس ها زیاد شده و چند تیم مستقل نسخه های خودشان را منتشر می کنند.
- بار در ساعت هایی از روز چند برابر می شود و می خواهید ظرفیت خودکار بالا و پایین برود.
- استقرار باید بدون قطعی باشد و در صورت مشکل با یک دستور به نسخه قبل برگردد.
هزینه این امکانات را هم در نظر بگیرید. کلاستری که در دسترس پذیری بالا ساخته شود حداقل سه نود کنترل پلین می خواهد، و شبکه کلاستر، ذخیره ساز دائمی، مدیریت گواهی ها، مانیتورینگ و به روزرسانی نسخه ها هر کدام کار جداگانه ای است. در کوبرنتیز همان برنامه با فایل هایی مثل این تعریف می شود:
apiVersion: apps/v1
kind: Deployment
metadata:
name: shop
spec:
replicas: 3
selector:
matchLabels: {app: shop}
template:
metadata:
labels: {app: shop}
spec:
containers:
- name: web
image: registry.example.com/shop:1.4.2
ports: [{containerPort: 8080}]ساخت کلاستر با kubeadm را در آموزش نصب کوبرنتیز قدم به قدم نوشته ایم.
Docker Swarm، Podman و گزینه های دیگر
Docker Swarm داخل خود Docker Engine است و با docker swarm init چند سرور را به یک کلاستر تبدیل می کند. همان فایل Compose را با docker stack deploy روی کلاستر اجرا می کند، کانتینر از کار افتاده را دوباره بالا می آورد و به روزرسانی مرحله ای دارد. یادگیری اش برای کسی که Compose بلد است چند ساعت کار است. در مقابل، اکوسیستم ابزارهایش خیلی کوچک تر از کوبرنتیز است و مقیاس پذیری خودکار ندارد.
Podman ابزاری از Red Hat برای اجرای کانتینر است که دستورهایش تقریباً همان دستورهای داکر است، اما سرویس دائمی (daemon) ندارد و کانتینرها را می شود بدون دسترسی root اجرا کرد. روی AlmaLinux و Rocky Linux ابزار پیش فرض کانتینر است. Podman جایگزین داکر روی یک سرور است و کاری به هماهنگ سازی کلاستر ندارد.
اگر تصمیم گرفته اید سراغ کوبرنتیز بروید ولی نمی خواهید کنترل پلین را خودتان نگه دارید، بعضی ارائه دهندگان ابری کوبرنتیز مدیریت شده دارند. در این حالت نگه داری کنترل پلین با ارائه دهنده است و شما فقط نودها و برنامه ها را مدیریت می کنید.
تفاوت داکر و ماشین مجازی
این سؤال هم کنار همین مقایسه زیاد پرسیده می شود. ماشین مجازی (VM) یک کامپیوتر کامل شبیه سازی شده است، با سیستم عامل و کرنل خودش، که روی لایه مجازی سازی مثل VMware یا Proxmox اجرا می شود. کانتینر داکر کرنل سیستم میزبان را به اشتراک می گذارد و فقط برنامه و کتابخانه هایش را جدا نگه می دارد.
- کانتینر در چند ثانیه اجرا می شود و رم و دیسک کمتری مصرف می کند؛ ماشین مجازی باید کل سیستم عامل را بوت کند.
- ماشین مجازی جداسازی قوی تری دارد و می تواند سیستم عامل متفاوتی داشته باشد، مثلاً ویندوز روی میزبان لینوکسی.
- این دو معمولاً کنار هم استفاده می شوند: کانتینرها داخل ماشین های مجازی اجرا می شوند و نودهای کوبرنتیز هم معمولاً خودشان ماشین مجازی اند.
اگر قصد دارید ساخت و استقرار را خودکار کنید، CI/CD چیست مراحل و ابزارها را توضیح می دهد.
از کجا شروع کنیم
برای شروع، نمونه فایل و دستورهای روزمره را در Docker Compose چیست ببینید.
منابع و مستندات رسمی
اگر برنامه تان هنوز کانتینری نشده، قدم اول داکر است: نوشتن Dockerfile، جدا کردن تنظیمات از کد و اجرای برنامه با Compose. همین قدم به تنهایی استقرار را قابل تکرار می کند و راه مهاجرت بعدی به کوبرنتیز را باز می گذارد. جزئیات این کار در راه اندازی داکر آمده است. اگر نشانه های بالا را دارید، طراحی و ساخت کلاستر و مهاجرت سرویس ها در راه اندازی کلاستر کوبرنتیز آمده است.
