همیشه بهم میگن چرا چرخ رو دوباره میخوای اختراع کنی؟
چرا سری که درد نمیکنه رو میبندی؟
چرا اینقدر وقت برای R&D میذاری؟
چرا ...
چرا ...
و چراهای گوناگون دیگه ...
در مورد این سوالات هم بگم که معمولا دوستان و همکاران دلواپس من (همون دواپس DevOps خودمون، به این خاطر که اعتقاد دارم در درجه‌ی اول دلواپس زیرساخت‌هاست) بهم این خرده رو میگیرند که آقا وقتی helm chart, Kubernetes operator, Kubernetes CRD, ... هست و میشه سر سه سوت روی کلاسترت دیپلوی کنی و استفاده کنی، چرا میری دوباره چرخ اختراع میکنی و Ansible-role براش مینویسی.
خب اول در مورد اعتقاداتم بگم (نه، نگران نباشید از اون دست آدماش نیستم که بخوام بگم این درسته یا این درست نیست. اعتقادمه، اینجا جایی است برای بیان و البته نقدش).
البته اعتقاداتم در مورد دلواپس بودنم (اینجا فرض کنید ی استیکر هست دیگه)
از نظر من: (همیشه به دوست گرام و رو اعصابم کیوان میگم)
1- کاری رو اگه بار اول دستی انجام دادی، بار دوم لطف کن اتوماتیکش کن (حالا میخوای bash script, ansible, python script, ... بنویس براش)
2- دواپس خوب، دواپس بیکاره (اینقدر همه چی گل و بلبل راه افتاده و داره کار میکنه که نیازی نیست کاری انجام بده). البته این موضوع به تجربه و دانش فراوان برمیگرده. پس تا زمانی به اون نقطه برسیم، تلاش و کوشش و پشتکار فراوان نیاز است.
3- و ما ادراک anisble-role:
توی ی مصاحبه، یکی از مواردی که به عنوان مصاحبه‌گر از مصاحبه شونده درخواست شد که در موردش توضیح بده بحث داغ مستندسازی (Documentation) بود که در کمال ناباوری ایشون عنوان کردند که به هیچ وجه اهل مستندسازی نیستند !!!. البته در ادامه دلیل میشه گفت منطقی برای این کار داشتند و اون هم ترافیک کاری و اینکه معمولا تسکها رو به صورت IaC انجام میدن و به قول خود ایشون ی نوع داکیومنت حساب میشه !!!
بماند که از نظر من README.md و یا ابزارهایی مثل Confluence مختص این کار هست و میبایست جهت تجمیع مستندات، بهتره از ابزارهای مستندسازی استفاده کرد تا اینکه به طرف که تازه داره on-board میشه بگی برو فلان ansible-role یا بهمان terraform manifest رو بخون، خودت میفهمی داستان از چه قراره.
ولی همین اعتقاد ایشون (هنوز میگم اعتقاد، شاید بگی چرا نمیگه تفکر، بینش، روش و ...) منجر به ایده‌ای شد در ذهن من که خب به دید مستند بهش نگاه نکن، ولی راهیه برای عمیق شدن در نصب و کانفیگ ابزارهای مختلف. بهتره بگیم نسخه‌ی کاملتری از مستندات نحوه نصب و کانفیگ. چون توی Ansible-role باید حواست به همه حالات باشه تا بتونی با اطمینان اعلام کنی مناسب برای Platformهای مختلف.
در این زمینه هم آقای Geerling (https://github.com/geerlingguy) الگوی من در نوشتن Ansible-role است. اصلا تو ببین و بخون ansible-role-docker ش رو (https://github.com/geerlingguy/ansible-role-docker). لذت میبری. برای تقریبا تمامی حالات شرط و متغیر تعریف کرده. دستت بازه.
خب تا اینجا ممد آقا حرف زدی، چی خودت تو چنته داری؟ (شما بخون ولی باور نکن، این سوالاتی است که ممد درونم ازم همیشه میپرسه و خیلی جاها بازخواستم میکنه، البته خودسرزنشگر نیستم خدا رو شکر. ولی ی ممد درون اینطوری باید باشه که بی خیالی طی نکنیم)
تجربه‌های مختلفی در نوشتن Ansible-role داشتم که آخریش Redis Cluster بود باز نمیگم کامله ولی سعی‌ام رو کردم که کامل باشه. همین امروز هم ی کامیت روش زدم.
نوشتن این رول‌ها بهم این دید رو نسبت به اون ابزار میده که وقتی میخوام به صورت هلو برو تو گلو برم با helm chart اون هم نوع bitnami یا هر نوعی دیگری (البته نوشتن helm chart هم خیلی دوست دارم و عاشقشم) دیپلوی کنم، بدونم داستان از چه قراره. اون فایل values.yaml رو راحت‌تر ویرایشش کنم.
یا در مورد تجربه نوشتن رول مربوط به کلاستر RabbitMQ (چالش‌های عجیبی در مورد تست رول باهاش داشتم )، وقتی خواستم روی کلاستر Kubernetes دیپلویش کنم، با RabbitMQ Cluster Operator آشنا شدم که چقدر هم جذاب نوشته شده بود. در حالت عادی اگر میرفتم سراغش چیزی ازش نمیفهمیدم ولی نوشتن رول براش خیلی بهم کمک کرد و راحت‌تر مفاهیمش رو درک و بررسی کنم. (برگردیم به حرف دوستمون که نوشتن رول میتونه ی مستندسازی حساب بشه).
گفتم تست رول که اون هم خودش دنیاییه برای خودش. استفاده از Molecule و Vagrant. قول میدم در آینده‌ای نه چندان دور در موردش بنویسم
خب سرتون رو درد نیارم. این تلاشی بود در جهت بیان عقاید و اعتقاداتم، و اینکه ی مقدار هم در جهت تولید محتوا قدمی برداشته باشم و از خداوند متعال تداوم این راه را برای خودم و دوستان خواستارم.
