ایجاد کلاستر الستیک سرچ برای محیط پروداکشن رنچر

رنچر ابزار مورد علاقه من برای داکر ارکستریشن هستش که تو ورژن 1.X و با استانداردی که برای ارکستریشن داشت به اسم cattle حد فاصل بین docker-compose و kubernetes بود که دیپلوی پروژه ها رو خیلی راحت کرده بود ، متاسفانه رنچر تو ورژن جدید خودش 2.x دیگه از cattle پشتیبانی نمیکنه و مستقیما از کوبرنیتیز پشتیبانی میکنه و مثل گذشته هدفش روی راحت تر کردن کاربری کوبرنیتیز گذاشته ، برای درک ارکستریشن باید بدونیم تفاوت آنچنانی بین ابزار ها وجود نداره همه و همه برای ساده تر کردن مدیریت سرویس ها و ایجاد استک ساخته شدن پس وقتی اینجا درمورد پیاده سازی elasticsearch + kibana تو محیط رنچر ورژن 1.6 صحبت میکنم با کمی خلاقیت میشه این رو در swarm یا docker-compose یا mesos و kubernetes در نظر گرفت.

رنچر از catalog برای راحت تر کردن ایجاد سرویس های پرکاربرد استفاده میکنه ، کاتالوگ تو رنچر یه چیزی مثل helm تو kubernetes در واقع بخوایم بگیم اولین بار رنچر بود که این قابلیت رو اضافه کرد و بعد ها جامعه کاربری ks8 ( همون اختصار کوبرنیتیز که از این به بعد اینجوری میگم ) با الگو برداری از این قابلیت پیاده سازی سرویس های پرکاربردی مثل redis sentinel یا mysql replica و ... رو ساده و آسون سازی کرد ، خوشبختانه رنچر تو ورژن 2.x هم از کاتالوگ و هم از helm پشتیبانی میکنه . جامعه کاربری هم برای الستیک سرچ کاتالوگ ساخته ولی همون طور که میدونید ایران تحریم هستش و حتی با docker mirror نمیشه کانتینر های الستیک رو دریافت کرد چون روی سرور های خودش در amazoon هاست میشه که ایران رو تحریم کرده ، پس دو راه حل داریم برای استفاده از کانتینر های الستیک سرچ یا کانتینر رو به وسیله ابزارهای دورن زدن تحریم دانلود کنیم و تگ بزنیم و بفرسیم روی رجیستری پرایوت خودمون ( روش پیشنهادی ) یا اینکه تگ بزنیم و بریزیم روی ریپوی پابلیک خودمون در داکرهاب که میرور دانلود کنه . و سپس کاتالوگ های رنچر رو فورک بگیریم و تفییر بدیم و ادرس ایمیج رو عوض کنیم . متاسفانه مکانیزم عملی که کاتالوگ کامیونیتی الستیک سرچ برای ساخت دیتانود و مستر و پرسیستنس درایور داره مشکل داره و درست عمل نمیکنه حتی در صورت تغییر دادن ادرس ایمیج.

ورژنی که من برای دیپلوی استفاده کردم اخرین ورژن الستیک سرچ در حال حاظر هستش که ورژن 6.3.1 هستش که خوشبختانه از این ورژن به بعد اکثر قابلیت های تجاری که توی پکیج x-pack بود اوپن سورس و رایگان شده ، الستیک سرچ درواقع از این به بعد یک توزیع خواهد داشت و دیگه با تگ های پلاتینیوم و oss رلیز نمیشه.

الستیک سرچ رو معمولا به صورت کلاستر بالا میارن چون هم قابل اعتماد تره هم میتونه به صورت master و data کانفیگ بشه ، به صورت پیشفرض کلاستر اسلتیک master-eligible هستش یعنی هر نود کلاستر مستر میتونه باشه و هم اطلاعات رو ذخیره کنه که به درد کلاستر های کوچیک میخوره ، برای کلاستر های بزرگتر نیاز هستش که یک سری نود ها اطلاعات رو ذخیره ( data nodes ) و یه تعداد دیگه مدیریت رو به عده بگیرن ( master nodes ) که به این مدل Dedicated Master Nodes میگن که من تو این آموزش از این روش استفاده کردم .

مهم ترین موردی که در ارکستریشن بهش برخورد میکنین نحوه مدیریت volume driver ها هستش که معمولا از چند مدل خارج نیست ، یا local driver یا shared driver که انواع مختلفی رو شامل میشن و هرکدوم مزایا و معایب خودشون رو دارن حتی رنچر در اپدیت جدید خودش در 2.x یه بلاک استوریج به اسم longhorn که یه distributed block storage system رو معرفی کرده . برای الستیک سرچ به دلیل فضای زیادی که برای ذخیره سازی نیاز داره پیشنهاد من local driver به جز اینکه شما نمیخواین شبکه داخلیتون درگیر به اشتراک گذاری فایل بین اینستنس های مختلفتون بشه یا تو این کیسی که هست حداقل بار روی شبکه باشه .

رنچر برای دیپولوی استک از docker compose و rancher compose استفاده میکنه که rancher-compose قابلیت های دیگه ای علاوه بر قالبلیت های docker-compose به ارکستریشن اصافه میکنه که در این مقاله نمیگنجه.

داکر و رنچر کامپوزی که برای ایجاد سرویس elasticsearch + kibana استفاده میکنیم اینجوری هستش که روی gist قرار دادم.

برای جدا کردن node های master و data از host label استفاده میکنیم که توی مثالی که روی gist برای شما قرار دادم elk=master و elk=data هستش .

برای سرویس دیسکاوری که elasticsearch استفاده میکنه یا به عبارتی یوینکست میکنه از متغیر

discovery.zen.ping.unicast.hosts: elasticsearch.yourstack,elasticsearchnode.yourstack

استفاده کردم که بر اساس dns سرویس شما دیسکاور میکنه ، تو رنچر dns سرویس به این صورت هست که اول سرویس و بعد استک اینجوری درواقع servicename.stackname برای دیسکاوری فرضا اگرشما استکی به اسم elk میخواین درست کنید چیزی به این صورت میشه elasticsearch.elk . توی کوبرنیتیز قضیه کمی فرق میکنه و dns به این صورت هستش my-svc.my-namespace.svc.cluster.local.

مورد دیگه این هستش که داکر به صورت جادویی تنظیمات sysctl رو برای شما تغیر نمیده پس برای افزایش vm.max_map_count باید sysctl.conf هاست های خودتون رو افزایش بدین بدین صورت

echo "vm.max_map_count=262144" >> /etc/sysctl.conf

sysctl --system

چند نکته اساسی :

برای بهتر بودن و قابل اطمینان بودن سرویس سعی کنید قانون حد نصاب ( Quorum ) رو رعایت کنید و حداقل سه هاست برای دیتا و دو هاست برای مستر داشته باشید

سرویس به صورت گلوبال scale شده پس روی هر هاستی که لیبل elk=master یا elk=data بزنید یه node ساخته میشه

تا قبل از ساخته شدن والیوم ها سرویس رو داون نکنید کراپت میشه تنظیمات کلاستر و مجبور میشین همه رو از اول پاک کنید