نوشته های AmirHossein Bahrami

آمار بازدید مطالب من در سال ۹۸

AmirHossein Bahrami — Thu, 26 Mar 2020 01:02:32 +0430

اگر دستاوردی را نتوانم اندازه بگیرم، چیزی در دست ندارم.اشتباه نشود، این به معنای تمایل به بهترین بودن و یا میل به اثبات چیزی نیست، اما تنها چیزی که می‌تواند برای بهتر شدن به من کمک کند یک نقشه راه است، از مسیری که طی کرده‌ام، تا بدانم چه اثری از خود به جا گذاشته‌ام. یک تصویر کلی که بتواند خیلی ساده نشانم دهد تلاش من چه اثری بر جامعه‌ام گذاشته است.ویدیوی آمار مخاطبین من را ببینید: https://cdn.virgool.io/annual-report/1398/tlweufelqjfy-Gn1Ei.mp4 دستاوردهای من در سال ۹۸در سال ۹۸، من در مجموع ۴ پست در ویرگول منتشر کردم و پست‌های من ۱۶۷ مرتبه لایک شدند و افراد ۳۹ بار نظرات خود را روی پست‌های من به اشتراک گذاشتند. امسال ۱۴۳ نفر در ویرگول من را دنبال کردند تا پست‌های بعدیم را بخوانند. اما چیزی که این دستاورد را ارزشمندتر می‌کند اثری است که این پست‌ها از خود به جا گذاشتند.اثر پروانه‌ای منطبق آمار ۳,۸۵۷ بار پست‌های من خوانده شدند و زمانی حدود ۳۴۲,۶۴۵ ثانیه صرف مطالعه آنها شده است، که با توجه به جمعیت ۷۲٬۹۴۰٬۰۰۰ نفری که در ایران به اینترنت دسترسی دارند، من توانستم حدود ۰/۰۰۴۶۹۸ ثانیه، سرانه مطالعه دیجیتال کشور را بالا ببرم. عددی که با تمام کوچک بودنش، اثر بزرگ و ارزشمندی است.اما این عددها فقط توضیحی است از آنچه که برای مخاطبانم به ارمغان آورده‌ام، اثر ارزشمند‌تری که با نوشتن در ویرگول از خود به جا گذاشته‌ام، تلاش پنهانی بوده که برای حفظ محیط زیست کرده‌ام. من با انتشار پست‌های خودم در فضای ویرگول توانستم در مصرف کاغذ صرفه جویی کنم؛ یعنی اگر قرار بود پست‌هایم را چاپ و به دست تک تک خوانندگان برسانم باید ۱۵,۶۱۸ کاغذ مصرف می‌شد.

از ویرگول MySqlای به ویرگول Elasticsearchای - قسمت ۳ (آخرای داستان)

AmirHossein Bahrami — Sun, 29 Dec 2019 14:56:18 +0330

آخرین چیزی که باید تو الستیک انجام می‌دادم، گرفتن نسخه پشتیبان(Backup) بود. شدیدا وجودش نیاز بود چون اگر خدایی نکرده اتفاقی برای دیتای آمار بیفته، هرچی که داریم پریده. هنوز به الستیک عادت نکرده بودیم و نمی‌دونستیم چقدر پایدار هست که بخوایم tracker رو غیر فعال کنیم.رفتم سراغ راه‌های بک‌آپ گرفتن و دیدم الستیک بهش میگه snapshot. روی لپ تاپ خودم تست کردم و همه چی خوب بود و کار می‌کرد. رفتم سراغ اینکه روی پادهای بالا هم بذارمش و پلاگینی که نیاز داشت رو نصب کنم. وقتی اضافه‌ش کردم یهو دیدم پادا از کار افتادن. لاگشون می‌گفت نصب پلاگین به ارور خورده و نمی‌تونه کار کنه. کلی سرچ کردم و به نتیجه نرسیدم. همه لینک‌ها رو خوندم اما چیزی نبود. دیگه به عنوان آخرین راه، رفتم توی پروژه گیت‌هاب پلاگین یه issue باز کردم و براشون مشکلم رو توضیح دادم. اونا هم جواب دادن که مشکل از یک لایه پایین‌تر، یعنی image داکر الستیکه.رفتم سراغشون و براشون ایشو گذاشتم که همچین مشکلی هست و اونا بهم گفتن ما نمی‌تونیم کاری کنیم چون تو اولیت‌هامون نیست ? ولی بهم گفتن که خودم کد رو عوض کنم و بهشون pull request بدم و اونا هم کمک می‌کنن. من که همیشه دوست داشتم تو یک پروژه عمومی فعالیت بکنم ولی هیچ وقت پیش نیومده بود، وقتی بهم اینجوری گفتن خیلی مشتاق شدم و سریع پروژه رو pull کردم و شروع به کار کردم.مشکل از اینجا بود که کدی که زده بودند تا این image ساخته بشه، با فرض این نوشته شده بود که کاربری که قراره که container باهاش کار کنه، کاربر ۱۰۰۱ یا همون elasticsearchه و خب پلاگین snapshot گرفتن نیاز داشت که با کاربر اصلی (root) کار کنه.من شروع کردم به تست گرفتن و عوض کردن کد. تمام حالت‌هایی که می‌شد رو تست کردم. وقتی حساب می‌کنم، بنظرم بیشتر از ۷۰ بار من از پروژه build گرفتم و تست کردم که ببینم کار می‌کنه یا نه. همین بین بود که فهمیدم ‌می‌تونم پلاگین آنالیزر (که تو قسمت اول گفتم) رو هم خودم آپدیت کنم (اگه می‌پرسین چجوری، باید بگم که کافیه فایلاشو دانلود کنید و توی فایل buildش نسخه‌ای که برای الستیک تعیین شده رو عوض کنید و با mvn دوباره build کنید. به همین سادگی?). خلاصه که بعد از یک هفته بالاخره مشکلش رو حل کردم و pull request دادم. اونا هم چندتا تغییر روش خواستن و منم اعمال کردم(البته تو یکیش خیلی گیر کردم، اونم موقعی بود که می‌خواست پورت‌ها رو تصدیق کنه و به مشکل می‌خورد که با کمک خودشون درست شد و یه کد بهم دادن و تست کردم و کار می‌کرد?) و تونستم از imageی که ساخته‌شد توی پادهای خودمون استفاده کنم و پلاگین snapshot رو نصب کنم.البته الان اگه برید توی صفحه اون pull requestای که دادم، می‌بینید که دیگه بسته شده و هیچ وقت merge نشد :)))) چون آخر کار که دیگه همه چی درست شد و گفتم که تائید کنن، بهم گفتن که خطی که باعث می‌شد کاربر از کاربر اصلی به کاربر الستیک تغییر کنه رو برگردونم و وقتی گفتم «بابااااا مشکل اصن از اول همین بود» بهم گفتن که نمی‌شه اینجوری باشه و متاسفیم و بخاطر بعضی پلتفرم‌ها مثل open shift، امکان این وجود نداره که کانتینر با کاربر اصلی اجرا بشه ? خلاصه که بعد از کلی تلاش و با اون همه امید به contribute تو یک پروژه عمومی، تهش فقط مشکل خودمون برطرف شد ☹️بعد از اینکه بک‌آپ گرفتن از الستیک هم درست شد، وقت اون رسید که بعد از ماه‌ها تلاش، بالاخره tracker رو غیر فعال کنیم که ببینیم چقدر تاثیر داره. البته الستیک تاثیر خودش رو با اینکه دیگه query روی tracker نمی‌رفت گذاشته بود ولی اینکه دیگه رو tracker هیچ درخواستی نره قاعدتا خیلی تاثیر داشت.یادم میاد که سرعت سایت اون موقع روی ۱۰۰۰ میلی ثانیه بود. وقتی tracker غیر فعال شد، به صورت غیر قابل باوری تاثیر گذاشت رو سیستم. سرعت ناگهان اومد روی ۴۰۰ میلی ثانیه و ثابت شد!!!! اون موقع با یه همچین شکلی توی سیستم مانیتورینگمون روبه‌رو شدیم:این شکلی شده بود سیستم(متاسفانه اون موقع از صفحه عکس نگرفتم)اون روز و روز بعدش من بارها و بارها صفحه سایت مانیتورینگ رو باز و بسته می‌کردم که ببینم واقعا همین شده یا الکی عه ولی واقعا همین طور بود!! سرعت سایت خیلی خوب شد و همه راضی بودند. اون روز واقعا حس خوبی داشتیم همه. اینکه تونسته بودیم سرعت سایت رو که خیلیا ازش شاکی بودند، بهتر کنیم.این بود داستان جابجایی ویرگول از MySql به Elasticsearch. البته که هنوز از MySql استفاده می‌کنیم ولی خب به لطف الستیک بعضی قسمت‌ها رو بهتر کردیم و در کل بار MySql کمتر شده و سرعت سایت خوبه :)

از ویرگول ‌MySqlای به ویرگول ‌Elasticsearchای - قسمت ۲ (آمار)

AmirHossein Bahrami — Wed, 23 Oct 2019 14:59:58 +0330

تو قسمت قبل گفتم که چی شد و چجوری شد که سرچ ویرگول رو بردیم روی الستیک. اما فقط سرچ نیست که داره با الستیک کار می‌کنه. بلکه بخش آمار هم داره از الستیک استفاده می‌کنه و این قابلیت‌های خوب و جدیدی که بهش اضافه شده به لطف الستیکه ? چون خیلی‌ها هم گفتند که فنی‌تر باشه، سعی کردم بیشتر از لحاظ فنی صحبت کنم.ماجرای اینکه آمار رفت روی الستیک از اینجا شروع شد که تعداد کاربرهای ویرگول داشت زیاد می‌شد و به همین خاطر سرعت سایت خیلی کم شده بود و سیستم‌های مانیتورینگ بهمون می‌گفتن که مشکل از دیتابیسیه که برای آمار استفاده می‌کنیم ?‍♂️. دیتابیس آمار MySQL بود و از دیتابیس اصلی جدا بود ولی تعداد نوشتن‌‌ها، خوندن‌ها و عملیات‌های آماری مثل جمع‌بندی(aggregation) و دسته‌بندی(grouping) زیاد و سنگینی داشت. خودتون می‌تونید حساب کنید که با تعداد بازدیدی که هر روز داشتیم و مقدار باری که هر کاربر صفحه آمارش رو باز می‌کرد، چقدر این عملیات‌ها زیاد می‌شدند. برای همین سرعت سایت خیلی پایین اومده بود و باید یه فکر جدی می‌کردیم. این‌جا بود که من (که شدیدا داشتم مبهوت الستیک و قابلیت‌هاش می‌شدم ?) دوباره اومدم جلو و گفتم بذارید لاگ رو ببریم روی الستیک. علی که خیلی سر سرچ با الستیک حال کرده‌بود بهم اجازه داد و منم شروع کردم به تحقیق و طراحی و کد زدن و …اولین مشکلی که همون اول به نظرم اومد این بود که چطوری اون حجم از دیتا رو، که تقریبا ۲۰ میلیون رکورد بود، ببریم روی الستیک. عملیات خیلی سنگینی حساب می‌شد و باید حتما دسته‌ دسته‌شون می‌کردم و طی چند روز توسط کرون‌جاب‌ها انجام می‌شد، چون نمی‌خواستم بار سینگینی روی الستیک باشه و کلی رم و سی‌پی‌یو مصرف کنه. همچنین اندپوینت _bulk توی الستیک، که برای ریختن دسته‌ای دیتاست، گفته‌شده بود که بهتره در لحظه تا یه حد خاصی دیتا از طریقش توی الستیک ریخته بشه و من با تست‌هایی که کردم به این نتیجه رسیدم که ۱۰۰۰ عدد خوبیه و خب برای ۲۰ میلیون رکورد کم بود. با خودم گفتم اول این قسمت رو درست می‌کنم و می‌ذارم به حال خودش تا تموم شه و همزمان کد‌های MySQL رو با کدهای الستیک عوض می‌کنم که دوتا کار با هم تقریبا تموم بشن اما هنوز نمی‌دونستم قراره چه اشتباهاتی بکنم و سر همین‌ها چه بلاهایی سرم بیاد ?‍♂️.با توجه به حجم دیتا، تخمین من این بود که اگر روزی یک میلیون و خورده‌ای دیتا توی الستیک بره، کمتر از دو هفته تموم می‌شه؛ همه هم خوشحال و فلان بودن که چقدر خوب و بالاخره دوران tracker (دیتابیس آمار) به سر میاد. از همون اول که عملیات رو شروع کردم، دونه دونه با باگ‌های یکی از یکی بدتر رو‌به‌رو می‌شدم و مجبور می‌شدم هی بزنم از اول دیتا توی الستیک ریخته‌بشه. یه بار می‌دیدم حواسم به نافرمی بعضی دیتاها نبوده(مثلا فرمت تاریخ چیزی نبود که تو mapping مشخص شده بود) و کرون‌جاب‌ها دارن به ارور می‌خورن. یه بار می‌دیدم حواسم به خطاهای زیرساختی و شبکه‌ای نبوده و ریکوئستی که به سمت الستیک می‌ره ارور می‌ده (که خب تو این مواقع باید جاب از اول اجرا می‌شد). حتی یه سری بخاطر مشکلات زیرساخت و storage دو سه روز عملیات متوقف شد (این یکی دیگه واقعا تقصیر من نبود ?). خلاصه که کاری که می‌گفتم کمتر از دو هفته تموم می‌شه، بعد از یک ماه تموم شد. این وسط، دیتاهای جدید هم تو tracker ریخته می‌شدن هم تو الستیک. بخاطر همین فقط دیتاهایی که تا یک تاریخ خاص بودن (زمانی که مطمئن بودیم دیتایی که تو الستیک هست سالم و درسته) رو سعی می‌کردیم جابجا کنیم، چون از بعد از اون دیگه تو الستیک بود.حالا که همه دیتاها یه جا جمع شده بودن، وقت تست رسید. بچه‌ها شروع کردن به تست کردن و یهو دیدیم اطلاعات با چیزی که توی trackerـه فرق می‌کنه؛ آماری که باید مثلا ۲۰۰ می‌بود، الستیک می‌گفت ۹۰ ?!! اون‌جا بود که من نمی‌دونستم چه خاکی به سرم بزنم و مونده بودم که چیکار باید بکنم. بعد از یک ماه دیتاها ناقصن. با گوگل هم چک کردیم و دیدیم خیلی فرق داره. اون موقع دیگه متوجه‌ شدم که یه چیزی رو خراب کردم. کلی گشتم تا ببینم مشکل از چیه. آمار چندین پست و کاربر رو چک کردم، کدها رو بارها و بارها خوندم و منطقش رو روی کاغذ نوشتم و بررسی کردم تا بتونم مشکل رو پیدا کنم. کلی وقت گذاشتم تا اینکه فهمیدم وقتی داشتم query گرفتن دیتاها از tracker رو ‌می‌نوشتم حواسم به این نبوده که یکی از جدول‌ها رو باید بجای join زدن left join می‌زدم ?‍♂️ چون لزوما برای هر سطر دیتا توی جدول اصلی، تو این جدول دیتا نداشتیم (رابطشون یک به صفر یا یک بود). از ترس اینکه الان اگه علی بفهمه کلی عصبانی می‌شه، با خودم گفتم تا اومد تو، مسخره بازی در میارم تا خنده‌ش بگیره و عصبی نشه برای همین تا اومد تو رفتم زیر میز که یعنی یه کار بدی کردم و خجالت‌زدم ? و این جوری خنده‌اش گرفت و همه چی به خوبی گذشت(البته بنده‌خدا انقدری هم که تو ذهنم خشنه نیست ?، فقط چون ویرگول واسش مهمه، خیلی حرص می‌خوره پیش خودش ولی می‌شه متوجه شد).دوباره عملیات migrate رو از اول شروع کردم و این بار دیگه چون همه باگ‌ها کشف شده ‌بودند، با سرعت بیشتر کار رو انجام دادم. تعداد کرون‌جاب‌ها رو زیاد کردم و تعداد دیتا رو کردم روزی ۳ میلیون. تخمینم ۵ روز بود که واقعا هم ۵ روزه تموم شد(خدارو شکر?‍♂️). صبح که رفتم شرکت، بچه‌ها اومدن و خواستیم دوباره تست کنیم. من دیگه با اعتماد به نفس کامل اومده بودم و می‌دونستم همه چی خوب بوده. تا اینکه یهو علی گفت پست فلان آمارش غلطه. نه در حد ۳ ۴ تا دونه بلکه در حد ۸۰تا ?!!! تو اون لحظه آن چنان استرسی به من وارد شد که داشتم می‌مردم. داشتم به این فکر می‌کردم که چجوری استعفا بدم و خودم دُمم رو بذارم رو کولم و برم ?. با این گندی که زدم دیگه آبرو نموند واسم ?. ولی پیمان که بزنم به تخته (تِق تِق) همیشه تو لحظات بحرانی می‌تونه خوب همه رو جمع کنه و اوضاع رو آروم کنه اومد پیشم و گفت بیا ببینیم چه مشکلی داره که فهمیدیم در واقع مشکلی از طرف کار من نبوده!!!! دیتاهای بازدید که از طرف ربات‌ها بودند، در اوایل کار tracker ثبت می‌شدند و من تو migrate اونا رو نیاوردم، برای همین انقد تفاوت داشت و در اصل کد من خیلی دقیق داشت جواب می‌داد ??اون موقع بود که دیگه از درست بودن آمار الستیک مطمئن شدیم و من یک نفس راحت کشیدم(ولی هیچ وقت استرس اون لحظه رو فراموش نمی‌کنم، خییییللللیییی بد بود?)اینایی که تا الان گفتم مال قسمتی بود که باید دیتای قدیمی رو روی سرویس جدید میاوردیم. ولی چالش‌هایی هم سمت پیاده‌سازی کد داشتیم. یکیش این بود که چیکار کنیم که تا حد ممکن، کسی نتونه آمار غلط ثبت بکنه. اون موقع، یه درسی داشتم به اسم مهندسی فناوری اطلاعات. توش یه مبحثی رو درس می‌دادن به اسم MAC و HMAC که برای اطمینان از صحت پیام هست. از این دو مبحث استفاده کردم و مکانیزمی رو طراحی کردم که همراه هر پیام که برای آمار از سمت کلاینت میاد، یک کد هم فرستاده بشه که سمت سرور چک بشه آیا واقعا این کاربر، این پست رو باز کرده یا نه و خب تا حد ممکن کمک کرد که کسی نتونه آمار غلط ثبت بکنه. خیلی نمی‌تونم دقیق بگم چجوری هست ولی کلی بخوام بگم، یه کدی که فقط خودمون داریم با یه سری اطلاعات هش گرفته می‌شن و برای کاربر فرستاده می‌شه و این هش سمت خودمون ذخیره می‌شه و وقتی ریکوئست میاد سمتمون، با صحتش رو می‌تونیم تا حد خوبی بررسی کنیم.وقتی که سرویس ثبت آمار توی مرحله تست بود، متوجه شدیم حجم زیادی از دیتایی که داره ثبت می‌شه رو ربات‌ها دارن ثبت می‌کنن. یعنی کلی صفحه هست که باز می‌شن، آمار بازدید واسشون ذخیره می‌شه ولی ربات هستن، نه کاربر عادی. تنها چیزی که می‌شد چک کرد، User-Agent بود. با لاگ‌های که ذخیره کردیم، متوجه‌ شدیم که تعداد زیادی از ربات‌ها رو می‌شه با فیلتر کردن کلمه‌هایی مثل bot و crawler و … پیدا کرد اما باز هم، همه ربات‌ها رو نمی‌شد پیدا کرد چون عوض کردن Header که کاری نداره. باید تحلیل رفتاری هم می‌کردیم. متوجه شدیم که خیلی از ربات‌ها، جاوا اسکریپت رو اجرا نمی‌کنن و اینجوری سعی کردیم یه سریشون رو تشخیص بدیم و فیلتر کنیم. البته باز شاید بشه گفت که بعضی از ربات‌ها هنوز از دستمون در می‌رن ولی خب تا حد خوبی اینجوری آمار رو دقیق‌تر کردیم.برای اینکه سرتون رو درد نیارم، یک سری داستان دیگه مونده که تو قسمت بعدی (و پایانی) می‌گم. امیدوارم براتون جالب باشه :)

از ویرگول MySql‌ای به ویرگول ‌Elasticsearchای - قسمت ۱ (سرچ)

AmirHossein Bahrami — Sun, 13 Oct 2019 19:35:00 +0330

به زور ویرگولی اصلی(بخونید زاخار اصلی?) تصمیم گرفتم روند انتقال سرچ و آمار ویرگول از MySQL به Elasticsearch رو براتون بنویسم و این تجربه‌ای که داشتم رو باهاتون به اشتراک بذارم.قصه از اونجا شروع می‌شه که یک روز بچه‌های ویرگولی(علی، علی، پیمان) گفتن کاش می‌شد سرچ توی ویرگول رو بهتر کنیم و چیزی که الان داریم رو بذاریم کنار چون خیلی داغون و نافرم و بده!! این شد که من، که تازه اسم الستیک به گوشم خورده بود و شنیده بودم توی سرچ متنی خیلی قَویه، پیشنهاد دادم که ببریمش روی الستیک و بچه‌ها هم موافقت کردن. شروع کردم به خوندن مستندهایی که بود و تست کردنش روی لپ‌تاپ خودم. هیچ ایده‌ای نداشتم چجوری باید باشه و هر روز بیشتر می‌خوندم و بیشتر یاد می‌گرفتم و خیلی برام جذاب بود. اما این تازه اول کلی داستان بود?‍♂️.اولین مشکلی که داشتم درست کردن mapping بود. همون‌طور که توی MySQL می‌گیم هر ستون چه ویژگی‌هایی باید داشته‌باشه، توی الستیک هم با mapping اینو مشخص می‌کنیم. با اینکه کلی مستندها رو خوندم، هر چند وقت یه بار مجبور می‌شدم mapping رو عوض کنم چون یه چیز جدید یاد می‌گرفتم یا سرچ به مشکل می‌خورد و می‌فهمیدم مشکل از mapping اشتباهه. مثلا یه سری، هرچی روی timestamp سرچ می‌زدیم، هی غلط جواب می‌داد تا اینکه فهمیدم مشکل از اینجاست که بخش روز رو توی mapping بجای dd گذاشتم DD (امان از کپی‌پیست‌های ندانسته?). هر دفعه هم که یه مشکلی تو mapping پیدا می‌شد، مجبور می‌شدم شب بیدار بمونم که دیتاها رو از MySQL دوباره منتقل کنم به الستیک چون باید دیتاها پاک می‌شدند و دوباره توی الستیک ریخته می‌شدن، و این مسئله بار زیادی داشت و باید هم بین دیتای موجود و دیتای الستیک هماهنگی می‌بود و نیاز بود وقتی این کار رو بکنم که کاربری آنچنان توی سیستم نباشه که دیتای جدید تولید نشه و در کل خیلی بدبختی داشت. ولی خب بالاخره به جایی رسید که این مشکلات حل شدند.یکی دیگه از بدختی‌ها این بود که برای بعضی از fieldهای فارسی، باید یک آنالیزور می‌ذاشتیم تا بشه بهتر سرچ کرد و نیاز به سرچ دقیق نباشه؛ یعنی مثلا فرقی بین فاصله و نیم فاصله یا ی و ي نباشه و چیزی که کاربر سرچ می‌کنه راحت‌تر پیدا بشه. کلی گشتم و یه ریپازیتوری توی گیت‌هاب پیدا کردم. با خیال راحت نصبش کردم و دیدم چقدر خوبه. ولی خب فقط یه مشکل داشت که هنوزم داره، اونم اینکه از نسخه‌های جدید الستیک پشتیبانی نمی‌کنه و صاحبش هم انگار دوست نداره آپدیتش کنه و جواب issueها رو بده? البته الان که دارم این نوشته رو می‌نویسم، فهمیدم چطوری خودم آپدیتش کنم و ازش بیلد بگیرم که بتونیم تو ورژن‌های جدید الستیک ازش استفاده کنیم?.بعد از اینکه دیتاها آماده شدن، رفتم سراغ کد زدن واسه بخش سرچ ویرگول. سعی کردیم با تلفیق آنالیزورهای خود الستیک و اونی که پیدا کرده بودم، یک ضریب خوب برای هر کدوم پیدا کنیم که جواب‌های سرچ بهتر و دقیق‌تر باشن. برای این کار، حالت‌های مختلف رو امتحان کردیم که ببینیم وقتی یک کلمه سرچ می‌شه، بین جواب‌ها، جوابی که آنالیزور فارسی پیدا کرده بالاتر بیاد یا آنالیزوری که پیدا کردم یا آنالیزور انگلیسی.حالا که همه چی درست شده بود، نوبت deploy کردنش روی سرور بود که این خودش داستان بزرگی بود. کلی باید می‌گشتم و مستند می‌خوندم که ببینم بهترین راهش چیه. کلی از deploymentهایی که آدما تو اینترنت گذاشتن رو تست کردم که ببینم کدوم جواب میده. یکی storageش درست وصل نمی‌شد، یکی نمی‌شد روش پلاگین نصب کرد، یکی باگ داشت و … خلاصه که دردسرش زیاد بود تا اینکه بالاخره تونستم راهش بندازم.طی زمان هی مشکلات کد در می‌اومد و برطرفشون می‌کردم و گاها مجبور می‌شدم بخاطر مشکلاتی که سمت آپدیت الستیک از روی Mysql داشتیم(باگ‌های کد و ...) تا نصف شب بیدار بمونم? که بار سیستم کم بشه و دیتای جدید ساخته نشه و بتونم دوباره از نو اطلاعات رو بریزم تو الستیک(reindex). چون هر بار، همونطور که بالاتر گفتم، باید دیتاها پاک می‌شدن و خب سرچ از کار می‌افتاد. حتی یک بار یادم میاد که شب وقتی می‌خواستم reindex کنم، به مشکل خوردیم و نتونستم درستش کنم و به مدت یک روز سرچ از کار افتاده بود و دیتا توش نبود تا اینکه فهمیدیم مشکل از کم بودن پردازنده برای پادهای الستیکه و با زیاد کردنشون مشکلمون حل شد.خوشبختانه توی سرچ مشکلات در همین حد بود. اون موقع این مشکلات واسم خیلی زیاد و بزرگ بنظر میومدن ولی خب وقتی خواستم آمار رو روی الستیک منتقل کنیم، تازه فهمیدم مشکل بزرگ یعنی چی?!! راجع به اون تو قسمت بعدی صحبت می‌کنم.

راه‌اندازی سرویس الستیک برای برنامه / سایت

AmirHossein Bahrami — Wed, 24 Apr 2019 16:17:53 +0430

الستیک یک شرکت ارائه‌دهنده خدمات جست‌و‌جو، ذخیره و visualization اطلاعات هست. اگر براتون سوال پیش اومده که الستیک‌سرچ چی هست می‌تونید این دو لینک (لینک ۱ و لینک ۲) رو ببینید.برای اینکه این سرویس را برای خود راه بیاندازید، ابتدا باید تصمیم بگیرید که به عنوان پایگاه‌داده اصلی قرار است استفاده بشه یا پایگاه داده دوم. معمولا الستیک‌سرچ را به عنوان پایگاه‌داده دوم انتخاب می‌کنند و با استفاده از پایگاه‌داده اصلی، الستیک‌سرچ را بروز می‌کنند.راه‌اندازی الستیک‌سرچ آسان هست چرا که هم روی داکر موجود هست، هم در helm (برای راه‌اندازی روی کوبرنتیز) و نصب خود آن بر روی سیستم (که فایل دانلود آن به صورت رایگان در سایت این شرکت موجود است). در این لینک توضیحاتی برای راه‌اندازی آن روی سیستم موجود هست که پیشنهاد می‌کنم ببینید.بعد از راه‌اندازی سرویس، باید با استفاده از Mapping مدل‌های داده‌ها را تعریف کنیم. برای مثال مدلی برای کاربران که شامل نام، نام‌کاربری، ایمیل و تاریخ عضویت در سرویس می‌باشد به صورت زیر است: https://gist.github.com/AmirHo3ein13/57ae822f3743ece7d2a8d06f6cee0c52 در این Mappingها، چند مشخصه مهم داریم. نوع ویژگی با type مشخص میشه. برای مثال نام‌کاربری از نوع text و روز عضویت از نوع date هست. index مشخص می‌کنه که آیا نیاز به سرچ بر روی این ویژگی داریم یا نه. analyzer نیز برای این است که متن را با استفاده از یک سری قواعد زبان، پردازش و جست‌وجو کنیم. لیست انواع داده‌ها را اینجا می‌تونید ببینید.بعد از مشخص کردن Mapping، اون را بر روی ایندکس خود تنظیم می‌کنیم و اطلاعات را با همین ساختار که طبق Mapping مشخص شده، وارد الستیک‌سرچ می‌کنیم.پس از ساخته شدن Index، نوبت به وارد کردن اطلاعات در الستیک‌سرچ می‌رسه. به دو صورت میشه این کار را انجام داد؛ به صورت تکی یا دسته‌ای (bulk). اندپوینت اضافه‌کردن داده به صورت تکیPUT index_name/doc/هست که در بدنه اون، ویژگی‌هایی از داده‌ای که می‌خوایم به ایندکس اضافه کنیم را قرار می‌دیم. برای مثال:PUT users/doc/3 { "username": "amirho3ein13", "last_activity": "2019/04/21 12:48:20", "email": "amirhossein@gmail.com" } اما این کار بصرفه نیست چرا که عملیات نوشتن در الستیک‌سرچ هزینه زیادی داره. راه بهینه این کار اضافه کردن به صورت دسته‌ای هست. اندپوینت اضافه‌کردن داده به صورت دسته‌ای POST _bulk هست. در بدنه این درخواست، تغییراتی که می‌خوایم انجام بدیم (create, update, delete) را قرار می‌دیم. برای مثال:POST _bulk { "create" : { "_index" : "test", "_id" : "1" } } { "field1" : "value1", "field2" : "value2" } { "delete" : { "_index" : "test", "_id" : "2" } } { "create" : { "_index" : "test", "_id" : "3" } } { "field1" : "value3" } { "update" : {"_id" : "1", "_index" : "test"} } { "doc" : {"field2" : "value3"} }توجه کنید که جدا کننده هر خط در بدنه این درخواست، کاراکتر n\ است.بعد از این که داده‌ها را به ایندکس‌ها اضافه کردیم، می‌تونیم با استفاده از اندپوینت _search بر روی داده‌ها جست‌وجو کنیم. برای مثال:GET /users/doc/_search { "query": { "match": { "username": "amirho3ein13" } } }در این مطلب هم توضیحاتی برای این کار هست که پیشنهاد می‌کنم ببینید.در آینده مطلب‌های دیگه‌ای می‌نویسم که چه کار‌هایی می‌شه با الستیک‌سرچ انجام داد، برای مثال انجام خودکار ایندکس داده‌ها، جست‌و‌جوهای پیشرفته و غیره که امیدوارم مفید واقع بشه.

گذاشتن Authentication روی سرویسی که یکی دیگه نوشته!

AmirHossein Bahrami — Mon, 11 Feb 2019 12:29:32 +0330

چند وقت پیش می‌خواستم سرویس کیبانا(یک سرویس visualization برای الستیک سرچ) که توسط الستیک نوشته شده رو دیپلوی کنم که دیدم Authentication نداره و خب اگه روی وب بذارم همه می‌تونن بهش دسترسی داشته باشن. خود الستیک هم به صورت پولی براش با استفاده از یک بسته به اسم xpack این امکان رو گذاشته که خب ما نمی‌تونستم ازش استفاده کنم :؟این‌طوری شد گشتم دنبال یه راه حل و رسیدم به روش Reverse Proxy با Nginx. این روش اینجوری هست که شما قبل از اینکه بسته‌هاتون به سمت سرویستون بره مشخص می‌کنید که اول از Reverse Proxyتون رد بشه و یک نام کاربری و رمز عبور بگیره و اگر درست بود بسته رو بفرسته سمت سرویس. در ادامه این روش رو توضیح میدم.برای این کار باید یه سرویس nginx راه بندازین یا اگر دارین فایل تنظیماتش رو عوض کنید. توی فایل nginx.conf اینا رو بنویسید البته حواستون باشه رو عوض کنید.user nginx; worker_processes 1; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1024; } http { upstream my_service { server ; } server { listen 80; auth_basic "Reverse Proxy Authentication"; auth_basic_user_file /etc/nginx/.htpasswd; location / { proxy_pass http://my_service; } } include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; #tcp_nopush on; keepalive_timeout 65; #gzip on; include /etc/nginx/conf.d/*.conf; }همونطور که می‌بینید این فایل نام کاربری و رمز عبور رو از یه فایل به اسم htpasswd. می‌خونه. برای ساختن این فایل از این دستور استفاده می‌کنیم:htpasswd -c ./.htpasswd البته می‌تونید اسم فایل رو هرطور که می‌خواید عوض کنید :)چیزی که من اینجا نوشتم تا حدی کمک می‌کنه ولی خب اگه نیاز به امنیت بیشتر دارین می‌تونید با کمی جست‌و‌جو تو وب بهترش کنید. خوشحال می‌شم اگر اینجا هم اطلاع بدید.