کشف سرویس و انباره های پیکربندی‌ توزیع یافته در اکوسیستم داکر (Docker) —راهنمای جامع

کانتینرها راه‌حلی عالی برای طراحی و انتشار اپلیکیشن‌ها در مقیاس گسترده محسوب می‌شوند. با این که داکر فناوری عملی کانتینری کردن را ارائه می‌کند؛ اما پروژه‌های زیاد دیگری نیز هستند که به توسعه ابزارهای مورد نیاز برای بوت‌استرپ کردن صحیح و ایجاد ارتباط در محیط توزیع کمک می‌کنند.  یکی از فناوری‌های اصلی که بسیاری از محیط‌های داکر از آن بهره می‌گیرند، فناوری کشف سرویس (service discovery) است.

کشف سرویس به یک اپلیکیشن یا کامپوننت، امکان کشف اطلاعاتی در مورد محیط و همسایه‌هایش را می‌دهد. این وضعیت معمولاً به صورت یک انباره کلید-مقدار توزیع یافته صورت می‌پذیرد که می‌تواند به عنوان یک محل عمومی برای تعیین جزییات پیکربندی نیز استفاده شود. پیکربندی یک ابزار کشف سرویس، امکان جداسازی پیکربندی‌های زمان اجرا از کانتینر واقعی را فراهم می‌کند. این امکان به نوبت خود باعث می‌شود که بتوانیم از برخی image ها در محیط‌های مختلف استفاده کنیم.

در این راهنما به بررسی مزیت‌های کشف سرویس درون محیط داکر کلاستر شده می‌پردازیم. ما به طور عمده بر روی مفاهیم کلی متمرکز هستیم، اما مثال‌های مشخص‌تری را نیز به تناسب ارائه خواهیم کرد.

انباره‌های کشف سرویس و پیکربندی‌های با دسترسی عمومی

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

فیلم آموزش داکر (Docker) برای توسعه دهندگان (رایگان) در فرادرس

کلیک کنید

با این که هدف اصلی کشف سرویس ارائه جزییات اتصال برای لینک کردن کامپوننت‌ها به همدیگر است؛ اما می‌توان از آن‌ها در مقیاسی کلی‌تر برای ذخیره‌سازی هر نوع پیکربندی استفاده کرد. بسیاری از توزیع‌ها از این ابزار برای نوشتن داده‌های پیکربندی در ابزار کشف استفاده می‌کنند و در صورتی که کانتینرها طوری پیکربندی شده باشند که بدانند باید به دنبال این جزییات باشند، در این صورت می‌توانند بر اساس آنچه مشاهده می‌کنند پیکربندی خود را تغییر دهند.

کشف سرویس چگونه عمل می‌کند؟

هر ابزار کشف سرویسی یک API دارد که از آن برای تنظیم یا بازیابی داده‌ها استفاده می‌شود. به همین دلیل برای هر کامپوننت، آدرس کشف سرویس یا باید در خود اپلیکیشن/کانتینر به صورت hard code نوشته شده باشد و یا این که به صورت گزینه‌ای در زمان اجرا ارائه شود. به طور معمول کشف سرویس به صورت یک انباره کلید-مقدار پیاده‌سازی می‌شود که با استفاده از متدهای استاندارد HTTP قابل دسترسی است.

روش عملکرد پورتال کشف سرویس این است که هر سرویس، زمانی که آنلاین می‌شود، خود را در ابزار کشف ثبت می‌کند. این ابزار تمام اطلاعاتی که به کامپوننت مربوط است و ممکن است جهت استفاده از سرویس لازم باشد، ثبت می‌کند. برای هر وهله یک پایگاه داده MySQL می‌تواند آدرس IP و پورتی که daemon اجرا می‌شود و همچنین به صورت اختیاری نام کاربری و اطلاعات احراز هویت مورد نیاز برای ورود به آن را ذخیره سازد.

زمانی که یک مصرف‌کننده سرویس آنلاین می‌شود، می‌تواند به رجیستری کشف سرویس کوئری زده و اطلاعات را در یک نقطه از پیش تعریف شده دریافت کند. سپس بر اساس اطلاعاتی که دریافت می‌کند، با کامپوننت‌ها ارتباط برقرار می‌کند. یک مثال خوب برای این وضعیت سرور توزیع بار (load balancer) است. سرور توزیع بار به این روش می‌تواند همه سرورهای بک‌اند را که باید ترافیک آن‌ها را تأمین کند بیابد. این سرور به پورتال کشف سرویس کوئری می‌زند و بر اساس اطلاعات دریافتی پیکربندی‌اش را تنظیم می‌کند.

بدین ترتیب جزییات پیکربندی از کانتینرها خارج می‌شوند. یکی از مزیت‌های این وضعیت آن است که کانتینرهای کامپوننت انعطاف‌پذیری بیشتری می‌یابند و کمتر به پیکربندی‌های خاص وابسته می‌شوند. مزیت دیگر آن است که واکنش کامپوننت‌ها به وهله‌های جدیدی از سرویس‌های مرتبط آسان‌تر می‌شود و امکان پیکربندی دینامیک پدید می‌آید.

ذخیره‌سازی پیکربندی‌ها چه ربطی به کشف سرویس دارد؟

یکی از مزیت‌های کلیدی سیستم‌های کشف سرویس توزیع یافته به صورت سراسری این است که می‌توانند هر نوع از داده‌های پیکربندی که کامپوننت‌ها ممکن است در زمان اجرا نیاز داشته باشند را ذخیره کنند. این بدان معنی است که می‌توان پیکربندی‌های بیشتری را از کانتینر استخراج کرد و با محیط‌های اجرایی وسیع‌تری ارتباط برقرار ساخت.

فیلم آموزش آژور Microsoft Azure تحت وب برای محاسبات ابری در فرادرس

کلیک کنید

به طور معمول برای این که این وضعیت به طرز مؤثری عمل کند، اپلیکیشن‌ها باید مقادیر پیش‌فرض معقولی داشته باشند تا بتوان آن‌ها را با کوئری زدن به انباره پیکربندی در زمان اجرا لغو کرد. بدین ترتیب می‌توان از انباره‌های پیکربندی به روشی همانند استفاده از فلگ‌های دستورات در خط فرمان استفاده کرد. تنها تفاوت این است که با استفاده از یک انباره با دسترسی عمومی می‌توان بی هیچ کار اضافی گزینه‌های یکسانی را به همه وهله‌های کامپوننت ارائه کرد.

ذخیره‌سازی پیکربندی چگونه باعث بهبود مدیریت کلاستر می‌شود؟

یکی از کارکردهای انباره‌های کلید-مقدار در توزیع‌های داکر که شاید در نگاه اول چندان هویدا نباشد، ذخیره‌سازی و مدیریت اعضای کلاستر است. انباره‌های پیکربندی، محیطی عالی برای نگهداری روندهای رخ داده برای اعضای میزبان به منظور ارائه ابزارهای مدیریتی محسوب می‌شود.

برخی از اطلاعاتی که می‌توان در مورد میزبان‌های خاص در یک انباره کلید-مقدار ذخیره کرد به شرح زیر هستند:

• آدرس‌های IP میزبان
• اطلاعات اتصال برای خود میزبان‌ها
• متادیتا و برچسب‌های دلخواه که می‌توان برای تصمیم‌گیری‌های زمان‌بندی هدف‌گذاری کرد.
• نقش میزبان در کلاستر (اگر از مدل پیشرو/پیرو استفاده می‌شود)

البته این جزییات شاید مواردی نباشند که هنگام استفاده از ابزارهای کشف سرویس در یک محیط نرمال به آن‌ها نیاز داشته باشید؛ اما ابزارهای مدیریتی خوبی هستند که با آن‌ها می‌توان در مورد خود کلاستر اطلاعاتی را ذخیره‌سازی کرده و یا مورد جستجو قرار داد.

تشخیص شکست (Failure Detection)

تشخیص شکست به چند روش قابل پیاده‌سازی است. در این مورد دغدغه ما این است که آیا یک کامپوننت از کار افتاده است یا نه و آیا کشف سرویس برای بازتاب این واقعیت به‌روزرسانی شده است یا نه. این نوع اطلاعات برای کاهش از کار افتادن اپلیکیشن یا سرویس بسیار ضروری هستند.

پلتفرم‌های تشخیص شکست زیادی وجود دارند که بر اساس یک timeout قابل پیکربندی، امکان تنظیم دارند. کامپوننت می‌تواند یک timeout تعیین کند و سرویس کشف را در بازه‌های معینی پینگ کند تا این timeout ریست شود. اگر کامپوننت از کار افتاده باشد و timeout سر برسد، اطلاعات اتصال این وهله از انباره حذف می‌شود. طول مدت timeout به مقدار زیادی تابعی از میزان سرعت پاسخ‌دهی اپلیکیشن به از کار افتادن یکی از کامپوننت‌ها مربوط است.

این وظیفه از طریق مرتبط کردن یک کانتینر کمکی (helper) مخصوص به هر کامپوننت که تنها مسئولیت آن بررسی دوره‌ای سلامت کامپوننت و به‌روزرسانی رجیستری در صورت از کار افتادن کامپوننت است نیز قابل انجام است. مشکل این نوع معماری آن است که کانتینر کمکی خود ممکن است از کار بیفتد و منجر به ورود اطلاعات نادرست به انباره پیکربندی شود. برخی سیستم‌ها این مشکل را از طریق تعریف بررسی سلامتی در ابزار کشف سرویس حل کرده‌اند. بدین ترتیب پلتفرم کشف خودش می‌تواند به طور دوره‌ای بررسی کند که آیا کامپوننت‌های ثبت شده همچنان موجود هستند یا نه.

پیکربندی مجدد سرویس‌ها در هنگام تغییر جزییات چگونه صورت می‌گیرد؟

یکی از بهبودهای کلیدی مدل کشف سرویس در زمینه پیکربندی مجدد دینامیک است. با این که کشف سرویس به طور نرمال امکان تأثیرگذاری بر پیکربندی اولیه کامپوننت‌ها با بررسی اطلاعات سرویس در زمان راه‌اندازی اولیه را فراهم می‌سازد؛ اما پیکربندی مجدد دینامیک شامل پیکربندی کامپوننت‌ها برای واکنش به اطلاعات جدید در انباره پیکربندی است. برای نمونه اگر یک سرور توزیع بار را پیاده‌سازی کرده باشید، بررسی سلامت روی سرویس‌های بک‌اند ممکن است نشان دهد که تعدادی از سرورها از کار افتاده‌اند. وهله اجرایی توزیع بار باید از این موضوع اطلاع یافته و بتواند پیکربندی خود را طوری تغییر دهد که قادر باشد بار سرورهای خاموش را به طور متوازنی بازتوزیع کند.

فیلم آموزش داکر (Docker) برای توسعه دهندگان (رایگان) در فرادرس

کلیک کنید

این وضعیت به چند روش قابل انجام است. از آنجا که مثال توزیع بار یکی از ابتدایی‌ترین کاربردهای این امکان است، چند پروژه وجود دارند که به طور انحصاری روی پیکربندی مجدد سرورهای توزیع بار هنگام تشخیص تغییر در پیکربندی سرورها را فراهم ساخته‌اند. تعدیل پیکربندی HAProxy به دلیل شهرتی که در فضای توزیع بار دارد کاملاً متداول است.

پروژه‌های خاصی در این زمینه انعطاف‌پذیری بیشتری ارائه می‌کنند که از این انعطاف‌پذیری می‌توان برای ایجاد تغییراتی در هر نوع نرم‌افزار کمک گرفت. این ابزارها به طور دوره‌ای به ابزار کشف سرویس کوئری می‌زنند و هنگامی که تغییری مشاهده شود، از سیستم‌های قالب‌بندی برای ایجاد فایل‌های پیکربندی استفاده می‌کنند تا مقادیر مشخص شده در ابزار کشف سرویس را در پیکربندی پیاده‌سازی کنند. پس از این که فایل‌های جدید پیکربندی ایجاد شد، سرویس مربوطه مجدداً بارگذاری می‌شود.

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

امنیت

یکی از نخستین دغدغه‌هایی که اکثر افراد هنگام مواجهه با ذخیره‌سازی پیکربندی با دسترسی سراسری دارند، به حق بحث امنیت است. آیا ذخیره‌سازی اطلاعات اتصال در یک مکان که دسترسی عمومی دارد کار درستی است؟

پاسخ به این سؤال تا حد زیادی به چیزی که قرار است ذخیره شود و تعداد لایه‌هایی که برای حفاظت داده مورد نیاز است بستگی دارد. تقریباً همه پلتفرم‌های کشف سرویس امکان رمزنگاری اتصال‌ها با SSL/TLS را ایجاد کرده‌اند. در برخی سرویس‌ها حریم خصوصی اهمیت چندان ضروری ندارد و قرار دادن کشف سرویس روی شبکه خصوصی می‌تواند کافی باشد. با این وجود در اغلب اپلیکیشن‌ها ایجاد امنیت بیشتر مورد نیاز است.

چندین روش مختلف برای حل این مسئله وجود دارند و پروژه‌های مختلفی به این راه‌حل‌ها اختصاص یافته‌اند. یکی از پروژه‌های راه‌حل این مسئله این است که امکان دسترسی به پلتفرم کشف برای همه باز باشد؛ اما داده‌های نوشته شده درون آن رمزنگاری شوند. مصرف‌کننده اپلیکیشن باید کلید مربوطه را برای رمزگشایی و مشاهده داده‌ها در انباره داشته باشد. طرف‌های دیگر نمی‌توانند به داده‌های غیر رمزنگاری شده دسترسی داشته باشند.

در یک رویکرد دیگر، برخی ابزارهای کشف سرویس به فهرست‌های کنترلی دسترسی دارند که فضای کلید را به زون‌های مختلفی تقسیم می‌کند. در این صورت آن‌ها می‌توانند مالکیت یا دسترسی به نواحی مختلف را بر اساس الزامات دسترسی تعریف شده از سوی فضای کلید خاص تخصیص دهند. بدین ترتیب روشی آسان برای ارائه اطلاعات به طرف‌های خاص و همزمان جلوگیری از دسترسی افراد غیرمجاز فراهم می‌شود. هر کامپوننت می‌تواند طوری پیکربندی شود که تنها به اطلاعاتی که مشخصاً نیاز دارد دسترسی داشته باشد.

ابزارهای رایج کشف سرویس کدام هستند؟

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

فیلم آموزش داکر (Docker) برای توسعه دهندگان (رایگان) در فرادرس

کلیک کنید

• etcd – این ابزار از سوی سازندگان CentOS برای ارائه کشف سرویس و پیکربندی‌های توزیع یافته سراسری به کانتینرها و همچنین خود سیستم‌های میزبانی طراحی شده است. این ابزار یک API HTTP پیاده‌سازی کرده و یک کلاینت خط فرمان روی هر ماشین میزبان دارد.
• consul – این پلتفرم کشف سرویس ویژگی‌های پیشرفته زیادی دارد که باعث متمایز شدن آن گشته است. این خصوصیات شامل بررسی‌های سلامت پیکربندی، کارکرد ACL، پیکربندی HAProxy و موارد دیگر هستند.
• zookeeper – این نمونه کمی از دو مورد قبلی قدیمی‌تر است و پلتفرم کامل‌تری را ارائه می‌کند، اما فاقد برخی ویژگی‌های جدیدتر است.

برخی پروژه‌هایی که به بسط پلتفرم‌های کشف سرویس ابتدایی می‌پردازند به شرح زیر هستند:

• crypt – crypt به کامپوننت‌ها امکان می‌دهد اطلاعاتی که می‌نویسند را به وسیله رمزنگاری کلید عمومی محافظت کنند. کامپوننت‌هایی که باید داده‌ها را بخوانند، می‌توانند کلید رمزگشایی را داشته باشند. همه طرف‌های دیگر امکان خواندن داده‌ها را از دست خواهند داد.
• confd – این ابزار پروژه‌های است که به منظور ایجاد مکان پیکربندی مجدد دینامیک اپلیکیشن‌های دلخواه بر اساس تغییراتی که در پورتال کشف سرویس صورت می‌گیرد طراحی شده است. این سیستم شامل یک ابزار برای مشاهده نقاط انتهایی که تغییرات را ثبت می‌کنند، یک سیستم قالب‌بندی برای ساخت فایل‌های پیکربندی جدید بر اساس اطلاعات گردآوری شده و همچنین امکان بارگذاری مجدد اپلیکیشن‌های تغییر یافته است.
• vulcand – این ابزار به عنوان یک سرور توزیع بار برای گروهی از کامپوننت‌ها عمل می‌کند. این ابزار از etcd آگاه است و پیکربندی آن را بر اساس تغییراتی که در انباره تشخیص می‌دهد تغییر می‌دهد.
• marathon – با این که ماراتن به طور عمده یک ابزار زمان‌بندی محسوب می‌شود؛ اما امکان ابتدایی برای بارگذاری مجدد HAProxy پیاده‌سازی کرده است. این وضعیت هنگام تغییر در سرویس‌های موجود که HAProxy باید بین آن‌ها توازن ایجاد کند پیش می‌آید.
• frontrunner – این پروژه به marathon وصل می‌شود و راه‌حلی با ثبات بیشتر برای به‌روزرسانی HAProxy ارائه کرده است.
• synapse – این پروژه یک وهله داخلی از HAProxy ارائه کرده است که می‌تواند ترافیک را به سمت کامپوننت‌ها مسیریابی کند.
• nerve – این پروژه از ارتباط با synapse برای ارائه بررسی‌های سلامت برای وهله‌های منفردی از کامپوننت‌ها کمک می‌گیرد. اگر کامپوننت‌ها ناموجود شوند، nerve اقدام به به‌روزرسانی سیناپس می‌کند تا آن کامپوننت از چرخه سرویس خارج شود.

سخن پایانی

کشف سرویس و انباره‌های پیکربندی سراسری به کانتینرهای داکر این امکان را می‌دهند که با محیط کنونی خود انطباق یابند و به کامپوننت‌های موجود وصل شوند. این یک پیش‌نیاز ضروری برای ایجاد مقیاس‌پذیری و فرایند توزیع ساده و خودکار از طریق ایجاد امکان ردگیری و پاسخ‌دهی کامپوننت‌ها به تغییرات محیطی‌شان است.

اگر این مطلب برایتان مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

• مجموعه آموزش‌های پایگاه داده و سیستم های مدیریت اطلاعات
• آموزش نرم افزار مجازی سازی VMware Workstation
• مجموعه آموزش‌های ابزارها و راهکارهای مدیریت وبسایت‌ها
• ماشین مجازی چیست؟ — هر آنچه باید در این مورد بدانید
• نصب لینوکس روی ویندوز با ماشین مجازی VMware — به زبان ساده

==