داکر سوارم مدیریت‌شده، به‌سادگی Docker Compose

سوارم وقتی بهترین انتخاب است که از یک سرور بیرون زده‌اید ولی نمی‌خواهید پیچیدگی کوبرنتیز را بپذیرید. نمونه‌های رایج:

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

پس از آماده‌شدن خوشه، از پنل یک فایل متنی دانلود می‌کنید که آدرس نود مدیر و دستورهای آمادهٔ docker swarm join را برای افزودن کارگر یا مدیر جدید دارد. توکن‌ها رمزنگاری‌شده نگه‌داری می‌شوند؛ این فایل را مثل رمز عبور حفظ کنید.

هر نود خوشه یک سرور ابری است و با قیمت پلن خودش ساعتی محاسبه می‌شود. علاوه بر آن، ۲۰٪ قیمت نودها به‌عنوان کارمزد مدیریت خوشه هر ساعت کسر می‌شود. پیش از ساخت، کیف پول باید هزینهٔ ساعت اول همهٔ نودها را پوشش دهد تا خوشه نیمه‌کاره نماند. معادل ماهانه بر مبنای ۷۳۰ ساعت است.

برای محاسبهٔ هزینهٔ کل، قیمت هر نود را در تعداد نودها ضرب کنید. مثلاً خوشه‌ای با یک مدیر و دو کارگر متوسط، سه برابر ستون متوسط هزینه دارد. قیمت سایر سرویس‌ها در قیمت‌گذاری آمده است.

هر سه راه درست‌اند و انتخاب به اندازهٔ پروژه و تجربهٔ تیم بستگی دارد. اگر همه‌چیز روی یک سرور جا می‌شود و قطعی کوتاه هنگام به‌روزرسانی قابل قبول است، یک سرور ابری با Docker Compose ساده‌ترین و ارزان‌ترین گزینه است. اگر به اکوسیستم بزرگ ابزارهای کوبرنتیز نیاز دارید، کوبرنتیز مدیریت‌شده را ببینید.

جدول زیر تفاوت‌های عملی را نشان می‌دهد:

از ساخت خوشه تا اجرای اولین سرویس معمولاً چند دقیقه طول می‌کشد:

سوارم سرویس‌ها را به‌صورت تدریجی به‌روز می‌کند: نسخه‌های قدیمی یکی‌یکی یا دسته‌دسته با نسخهٔ جدید جایگزین می‌شوند. اندازهٔ هر دسته و فاصلهٔ بین آن‌ها را در بخش update_config تعیین می‌کنید. اگر می‌خواهید در صورت خطا نسخهٔ قبلی خودکار برگردد، failure_action را روی rollback بگذارید؛ این گزینه به‌صورت پیش‌فرض فعال نیست.

برای مقیاس‌دهی کافی است تعداد نسخه‌ها را تغییر دهید؛ مثلاً با docker service scale. توجه کنید که مقیاس‌دهی خودکار بر اساس بار در سوارم وجود ندارد و تعداد نسخه‌ها را خودتان یا با اسکریپت تنظیم می‌کنید. اگر منابع نودها کم آمد، نود جدید به خوشه اضافه کنید.

پورت‌های ارتباط داخلی سوارم فقط بین نودهای همان خوشه باز می‌شوند و از بیرون در دسترس نیستند. فایروال هر نود به‌صورت پیش‌فرض اتصال ورودی را مسدود می‌کند؛ بنابراین پورتی که برای یک سرویس منتشر می‌کنید، تا در فایروال قانون مجاز برایش نسازید از اینترنت در دسترس نیست. این پیش‌فرض جلوی باز ماندن ناخواستهٔ پورت دیتابیس یا پنل مدیریت را می‌گیرد.

ترافیک مدیریتی سوارم بین نودها رمزنگاری‌شده است، اما ترافیک داده در شبکهٔ overlay به‌صورت پیش‌فرض رمزنگاری نمی‌شود. اگر سرویس‌ها دادهٔ حساس رد و بدل می‌کنند، شبکهٔ overlay را با گزینهٔ encrypted بسازید. برای اسرار مثل رمز دیتابیس هم از docker secret استفاده کنید، نه متغیرهای محیطی داخل فایل Compose.

مهم‌ترین نکتهٔ سوارم این است که volume‌ها محلی‌اند: داده روی دیسک همان نودی می‌ماند که سرویس رویش اجرا شده و اگر سوارم سرویس را به نود دیگری ببرد، داده همراهش نمی‌رود. برای سرویس‌های داده‌دار، آن‌ها را با placement constraint به یک نود مشخص ببندید، یا داده را بیرون از خوشه نگه دارید؛ مثلاً در PostgreSQL مدیریت‌شده یا MySQL مدیریت‌شده که بکاپ روزانه دارند.

برای مهاجرت از یک سرور تکی، فایل Compose فعلی تقریباً بدون تغییر کار می‌کند؛ فقط بخش deploy را اضافه کنید و image‌ها را به‌جای build محلی از یک رجیستری بخوانید تا همهٔ نودها به آن دسترسی داشته باشند. فایل‌های Compose را در Git نگه دارید و از volume‌های مهم نسخهٔ پشتیبان بیرونی، مثلاً در فضای ذخیره‌سازی ابری، بگیرید.

خوشهٔ تحویلی فقط Docker و سوارم را دارد و ابزار اضافه‌ای از پیش نصب نمی‌شود؛ این‌طور منابع نودها کامل برای سرویس‌های خودتان می‌ماند. اگر رابط گرافیکی می‌خواهید، Portainer را خودتان به‌عنوان یک سرویس روی خوشه مستقر کنید تا سرویس‌ها، لاگ‌ها و تعداد نسخه‌ها را از مرورگر ببینید.

برای image‌های خصوصی به رجیستری‌ای نیاز دارید که همهٔ نودها به آن دسترسی داشته باشند؛ مثلاً Gitea روی یک سرور جداگانه که رجیستری بستهٔ داخلی دارد. سرویس رجیستری کانتینر مدیریت‌شدهٔ ایران‌کلاد هنوز عرضه نشده و وضعیتش در همان صفحه آمده است. برای مشاهدهٔ سریع لاگ‌ها هم ابزار سبکی مثل Dozzle کمک می‌کند.

بیشتر مشکلات سوارم با چند دستور ساده روی نود مدیر پیدا می‌شوند. docker node ls وضعیت همهٔ نودها را نشان می‌دهد و اگر نودی Down باشد، اول همان را بررسی کنید. docker service ps نام‌سرویس می‌گوید هر نسخه روی کدام نود است و اگر بالا نیامده، پیام خطای آن چیست؛ رایج‌ترین علت‌ها کمبود حافظه، نبودن image روی رجیستری در دسترس یا محدودیت قرارگیری اشتباه است.

مصرف پردازنده و شبکهٔ هر نود را در صفحهٔ همان سرور در پنل هم می‌بینید. اگر یک نود مدام زیر فشار است و بقیه بیکارند، محدودیت‌های قرارگیری و منابع رزروشدهٔ سرویس‌ها را دوباره بررسی کنید؛ سوارم فقط بر اساس همین تعریف‌ها تصمیم می‌گیرد.

خوشه با یک نود مدیر ساخته می‌شود؛ برای تحمل خطای مدیریتی باید خودتان با توکن مدیر نودهای مدیر دیگری اضافه کنید. همهٔ نودهای ساخته‌شده از پنل هم‌اندازه‌اند و حداکثر ده نود دارند. volume‌ها بین نودها همگام نمی‌شوند و مقیاس‌دهی خودکار بر اساس بار وجود ندارد.

ترافیک هر نود جداگانه ۵۰ گیگابایت در ماه است و بیش از آن بسته می‌خواهد. اندازه و تعداد نودهای خوشه پس از ساخت از پنل تغییر نمی‌کند؛ نود اضافه را باید خودتان با فایل دستورهای پیوستن به خوشه وصل کنید. اگر به امکانات پیشرفته‌تری مثل اکوسیستم Helm نیاز دارید، K3s یا کوبرنتیز مدیریت‌شده را بررسی کنید.