استقرار و مدیریت کلاستر چندنودی با Docker Swarm

Docker Swarm گروهی از نودهای داکر را به یک کلاستر امن و بسیار در دسترس با قابلیت ارکستریشن داخلی تبدیل می‌کند. این مقاله ساخت یک swarm چندنودی، استقرار یک اپلیکیشن میکروسرویس به‌صورت اعلانی و انجام به‌روزرسانی‌های تدریجی بدون از دست دادن سازگاری با وضعیت مطلوب را بررسی می‌کند.

Docker Swarmارکستریشن کانتینرRolling Update

~4 دقیقه مطالعه · آخرین به‌روزرسانی ۱۴ شهریور ۱۴۰۵

مقدمه

Docker Swarm هم یک کلاستر امن از نودهای داکر و هم یک ارکستریتور هوشمند اپلیکیشن است. در حالی که Kubernetes به پلتفرم غالب ارکستریشن تبدیل شده، Swarm همچنان جایگزینی سبک و مناسب برای محیط‌های کوچک‌تری است که نیازی به پیچیدگی و منحنی یادگیری یک محیط کامل Kubernetes ندارند.

Manager و Worker

یک swarm شامل نودهای manager است که سرویس‌های control plane و منطق ارکستریشن را اجرا می‌کنند، و نودهای worker که بارهای کاری اپلیکیشن را اجرا می‌کنند و اختیاری هستند. هر دو نوع می‌توانند ماشین فیزیکی، ماشین مجازی یا نمونه ابری باشند، به شرطی که داکر اجرا کنند و بتوانند به‌صورت پایدار روی شبکه ارتباط برقرار کنند. به‌طور پیش‌فرض، managerها نیز بارهای کاری اپلیکیشن را اجرا می‌کنند، هرچند محیط‌های تولیدی معمولاً آن‌ها را صرفاً به وظایف control plane اختصاص می‌دهند.

ساخت یک Swarm

یک swarm روی اولین نودی که قرار است manager باشد راه‌اندازی می‌شود:

docker swarm init

این دستور یک دستور docker swarm join شامل یک توکن تولید می‌کند که می‌توان آن را روی نودهای دیگر برای افزودن آن‌ها به‌عنوان worker اجرا کرد:

docker swarm join --token SWMTKN-1-... 172.31.40.192:2377

برای دسترس‌پذیری بالا، swarmهای تولیدی معمولاً سه manager اجرا می‌کنند تا کلاستر بتواند از دست رفتن یکی از آن‌ها را تحمل کند. یک توکن پیوستن جداگانه برای managerها با دستور زیر تولید می‌شود:

docker swarm join-token manager

وضعیت کلاستر را در هر زمان می‌توان با دستور زیر بررسی کرد:

docker node ls

همیشه یک manager به‌عنوان Leader نشان داده می‌شود و بقیه با وضعیت Reachable علامت‌گذاری می‌شوند، که بازتاب مدل دسترس‌پذیری بالای active/passive در Swarm است.

استقرار یک اپلیکیشن

اپلیکیشن‌های Swarm با استفاده از یک فایل Compose تعریف می‌شوند که با تنظیمات اختصاصی deploy در Swarm، مانند تعداد replica، رفتار به‌روزرسانی و سیاست‌های ریستارت، گسترش یافته است. یک تعریف معمول سرویس ممکن است چهار replica درخواست کند، دوتا دوتا آن‌ها را به‌روزرسانی کند با تأخیر بین دسته‌ها، و در صورت خرابی به‌طور خودکار rollback کند.

مفهوم اصلی پشت Swarm، وضعیت مطلوب (Desired State) است — آنچه فایل Compose مشخص می‌کند اپلیکیشن باید چگونه باشد. استقرار یک اپلیکیشن با دستور زیر انجام می‌شود:

docker stack deploy -c compose.yaml ddd

سپس Swarm تلاش می‌کند وضعیت مشاهده‌شده کلاستر را با این وضعیت مطلوب مطابقت دهد و replicaها را به‌طور یکنواخت بین نودهای موجود توزیع می‌کند. وضعیت یک اپلیکیشن مستقرشده با دستورات زیر قابل بررسی است:

docker stack ps ddd
docker stack services ddd

مدیریت اعلانی اپلیکیشن‌ها

اپلیکیشن‌های Swarm را می‌توان به دو روش مدیریت کرد: امری (Imperative)، با اجرای مستقیم دستورات CLI، یا اعلانی (Declarative)، با ویرایش فایل Compose و استقرار مجدد. روش اعلانی به‌شدت ترجیح داده می‌شود، زیرا تغییرات امری — مانند مقیاس‌دهی دستی یک سرویس — ممکن است در استقرار بعدی فایل Compose به‌طور خاموش بازنویسی شوند، چرا که Swarm همیشه کلاستر را به آنچه فایل توصیف می‌کند بازمی‌گرداند.

به‌روزرسانی یک اپلیکیشن، مانند مقیاس‌دهی replicaها و تغییر به نسخه جدید ایمیج، کاملاً با ویرایش فایل Compose و اجرای مجدد دستور زیر انجام می‌شود:

docker stack deploy -c compose.yaml ddd

سپس Swarm یک به‌روزرسانی تدریجی کنترل‌شده انجام می‌دهد، replicaها را به‌صورت دسته‌ای طبق قوانین تعریف‌شده در بخش deploy.update_config جایگزین می‌کند و در صورت بروز خرابی به‌طور خودکار rollback می‌کند.

پاک‌سازی

یک اپلیکیشن را می‌توان با دستور زیر حذف کرد:

docker stack rm ddd

توجه داشته باشید که این دستور سرویس‌ها و شبکه‌ها را حذف می‌کند اما volumeها را حذف نمی‌کند، زیرا Swarm عمداً چرخه حیات volumeها را از خود اپلیکیشن جدا می‌کند و برای حذف داده‌های ذخیره‌شده به یک دستور صریح docker volume rm نیاز است.

نتیجه‌گیری

Docker Swarm روشی واقعاً کارآمد، هرچند کمترمحبوب، برای اجرای اپلیکیشن‌های میکروسرویس با دسترس‌پذیری بالا و خودترمیم روی یک کلاستر از نودها ارائه می‌دهد. مدیریت همه‌چیز به‌صورت اعلانی از طریق فایل‌های Compose — که در سیستم کنترل نسخه نگهداری می‌شوند — تضمین می‌کند وضعیت واقعی کلاستر همیشه با آنچه مدنظر است مطابقت داشته باشد، و Swarm را به یک نقطه شروع عملی برای یادگیری پلتفرم‌های پیشرفته‌تر ارکستریشن مانند Kubernetes تبدیل می‌کند.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

داکر چگونه از فناوری‌های امنیتی لینوکس استفاده می‌کند

مدل امنیتی داکر بر پایه دفاع چندلایه ساخته شده و فناوری‌های شناخته‌شده kernel لینوکس را با تنظیمات پیش‌فرض معقول ترکیب می‌کند. این مقاله توضیح می‌دهد که namespaceها، control groupها، capabilityها، Mandatory Access Control و seccomp چگونه در کنار هم کانتینرها را ایزوله و ایمن می‌کنند.

ادامه

مدیریت داده‌های ماندگار در داکر با Volume

کانتینرها به‌طور پیش‌فرض یک لایه نوشتنی موقت دریافت می‌کنند که با حذف کانتینر از بین می‌رود — این برای داده‌های موقتی خوب است، اما برای هر چیزی که ارزش نگهداری دارد ریسک‌آور است. این مقاله توضیح می‌دهد که volumeهای داکر چگونه داده‌های ماندگار را از چرخه حیات کانتینر جدا می‌کنند و نحوه ساخت، استفاده و اشتراک‌گذاری امن آن‌ها را بررسی می‌کند.

ادامه

شبکه‌های Overlay در داکر چگونه کار می‌کنند؛ نگاهی به VXLAN

شبکه‌های overlay امکان می‌دهند کانتینرهای روی هاست‌های مختلف طوری با هم ارتباط برقرار کنند که گویی یک شبکه مسطح مشترک دارند، و ستون فقرات بیشتر اپلیکیشن‌های میکروسرویس ابرمحور را تشکیل می‌دهند. این مقاله نحوه ساخت، رمزنگاری و تست یک شبکه overlay داکر روی یک کلاستر Swarm را بررسی کرده و فناوری تونل‌زنی VXLAN پشت آن را توضیح می‌دهد.

ادامه

اتصال کانتینرهای داکر به VLAN و توزیع بار با Swarm

فراتر از شبکه‌های ساده bridge، داکر امکاناتی برای اتصال مستقیم کانتینرها به VLANهای فیزیکی موجود، تفکیک خودکار نام سرویس‌ها و توزیع ترافیک در سراسر یک کلاستر Swarm ارائه می‌دهد. این مقاله درایور macvlan، سرویس داخلی Service Discovery و مکانیزم Ingress Load Balancing در Swarm را بررسی می‌کند.

ادامه

شبکه‌سازی در داکر؛ آشنایی با CNM، Libnetwork و شبکه‌های Bridge

شبکه‌سازی در داکر بر پایه یک طراحی باز به نام Container Network Model ساخته شده که توسط libnetwork پیاده‌سازی و با درایورهای قابل‌جایگزینی گسترش می‌یابد. این مقاله تئوری پشت شبکه داکر را بررسی کرده و نحوه ساخت و تست شبکه‌های bridge تک‌هاست، از جمله تفکیک نام و نگاشت پورت را توضیح می‌دهد.

ادامه

ساخت و اجرای اپلیکیشن‌های WebAssembly به‌عنوان کانتینر داکر

WebAssembly (Wasm) به‌عنوان جایگزینی سبک‌وزن برای کانتینرهای سنتی در حال ظهور است، و داکر اکنون از ساخت، اشتراک‌گذاری و اجرای اپلیکیشن‌های Wasm با ابزارهای آشنا پشتیبانی می‌کند. این مقاله نوشتن یک اپلیکیشن ساده Wasm با Spin، کانتینری کردن آن با داکر و اجرای آن به‌عنوان کانتینر Wasm را بررسی می‌کند.

ادامه