آشنایی با مفاهیم دوآپس DevOps

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

در گذشته نه خیلی دور (حدود ۹ یا ۱۰ سال پیش) که استفاده از سیستم عامل لینوکس در ایران فراگیر شد و خیلی از شرکت‌ها به ضرورت استفاده از این سیستم عامل پی بردند بازار کار آی‌تی در ایران می‌طلبید که سیس ادمین یا یا همون Linux System Administration زیاد جذب بشه . در حقیقت خیلی از شرکت‌ها و کسب‌وکارها نیاز داشتند که یک شخصی یا گروهی وجود داشته باشند که بتوانند از پس کارهای مربوط به سرورهای لینوکسی و سرویس‌های مورد نیازشون بر بیان و یا اینکه زیرساخت سرویس‌های فعلی رو به سمت لینوکس سوق بدهند .

این دوره چند ساله که تا الان هم ادامه داره دوره‌ای است که متخصص‌های زیادی در زمینه لینوکس وارد بازار کار شدند و به عنوان Linux System Admin در کسب‌وکارها مشغول به کار شدند .

عمده کار سیس ادمین‌ها راه اندازی و نگهداری سرویس‌ها و سرورهای لینوکسی بود که قرار بود اپلیکیشن‌های برنامه‌نویس‌ها روی این سرورها اجرا بشه و به کاربران خدمت رسانی کنند .

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

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

۲. سیس ادمین‌ها که وظیفه راه‌اندازی و نگهداری از سرویس‌ها و سرورهای لینوکسی رو برعهده دارند

و به صورت کاملا طبیعی این دو گروه دانش زیادی از کار و تخصص همدیگر ندارند و تعامل بین آنها کمی با مشکل روبرو می‌شد که در ادامه به برخی از اونها اشاره میکنم

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

موارد بالا برخی از مشکلات بوجود آمده در یک شرکت آی‌تی بود که اشاره کردیم

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

• دانش خوبی و عمیقی از سیستم‌عامل لینوکس داشته باشد
• دانش خوبی از زبان‌ها و منطق برنامه نویسی داشته باشد
• ابزارهای اتوماتیک کردن کارها را بشناسد
• از انجام کارهای تکراری به شدت بپرهیزد
• ابزارهای انجام تست را خوب بشناسد
• بتواند کاری کند که سرعت پیش‌رفتن کارها را بیشتر شود
• هماهنگی بین تیم‌های مختلف را انجام دهد

پس تا الان اگه بخوایم ارتباط DevOps رو با سایر گروه‌های مرتبط با یک شکل نشان بدیم میتواند به صورت زیر باشد .

با توجه به تصویر بالا DevOps نقطه مشترک تیم‌های مختلف از قبیل Develop و Test و Operation می‌باشد. یعنی راه ارتباط این تیم‌ها برای استاندارد شدن فرآیندها از طریق امکانات و سرویس‌هایی هست که یک نیروی DevOps راه اندازی می‌کند.

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

همانطور که در عکس بالا مشاهده می‌کنید کار نیروی DevOps از دو قسمت زیر تشکیل شده است.

• قسمت Dev که شامل مراحل زیر می‌باشد
  • مرحله plan : که در این مرحله برنامه ریزی صورت می‌گیرد که قرار است چه کارهایی انجام شود و هدف چیست. عمدتا این مرحله توسط تیم توسعه و برنامه نویسان انجام باید بشه
  • مرحله code : بعد از برنامه ریزی نوبت به نوشتن سورس می‌باشد و در واقع در این مرحله برنامه نویسان شروع به نوشتن و توسعه برنامه می‌کنند
  • مرحله build : در این مرحله تغییرات سورس کد جدید برنامه ساخته یا build می‌شود و در محیط تستی آماده بررسی است
  • مرحله test : بعد از آماده شدن و ساخته شدن سورس کد جدید نوبت به تست برنامه جدید می‌رسد
  • اگر همه چیز درست بود که از مرحله Dev خارج شده و به چرخه Ops وارد می‌شود در غیره این صورت چرخه متوقف می‌شود
• قسمت Ops که شامل مراحل زیر است
  • مرحله release : در این مرحله پس از موفقیت آمیز بودن تست یک نسخه جدید از نرم‌افزار ارایه می‌شود
  • مرحله deploy : سپس در این مرحله سورس کد جدید در محیط production یا عملیاتی قرار داده می‌شود
  • مرحله Operate : در این مرحله تمامی کارها برای زیر بار رفتن سورس کد جدید انجام می‌شود
  • مرحله Monitor : در این مرحله عملکرد سورس کد جدید مورد بررسی قرار می‌گیرد

حال که از چرخه اصلی و مراحل انجام کار در کل فرآیند مطلع شدیم بیایید با نام ابزارهایی که یک متخصص DevOps با آنها درگیر است آشنا شویم

چرخه Dev

در این چرخه چهار مرحله plan و code و build و test وجود داشت که به ترتیب ابزار‌های موجود در هریک را نام می‌برم و راجع به هریک توضیح مختصری می‌دهم

مرحله plan و مرحله code

در این دو مرحله چون عمده کار (تقریبا همه کار) توسط تیم توسعه و برنامه نویسان انجام می‌شود و از طرفی به دلیل تنوع در شیوه انجام کار و همچنین زبان برنامه نویسی, خیلی نیروی DevOps درگیر این مراحل نیست . فقط برای نگهداری کد از سرویس گیتلب (gitlab) عمدتا استفاده می‌شود.

مرحله build

در این مرحله بسته به زبانی که برنامه با آن نوشته شده میتواند ابزارهای مختلفی استفاده کرد . برای نمونه شیوه build کردن یک برنامه با زبان nodeJS با ابزار npm صورت میگیرد. یا برای جاوا ابزار maven مناسب هست و همچنین معمولا برای مشاهده نتیجه build معمولا سورس کد را در قالب یک کانتینر container با ابزار داکر docker ارایه می‌دهند .

مرحله test

این مرحله یکی از مهمترین مراحل این چرخه هست که باید بسیار با دقت انجام شود. انتخاب ابزار در این مرحله بستگی دارد به این که ما چه مدل تستی را انجام میدهیم و اینکه چه چیزی را قرار است تست کنیم. برای نمونه برای تست استرس و پرفورمنس http ابزارهای tsung و apache jmeter مناسب هست. یا برای اینکه فانکشنالیتی یک سرویس را تست کنیم ابزار katakon studio و یا selenium مناسب هست و همچنین برای تست API هم میتوانید از این دو ابزار استفاده کنید که به صورت کامل رفتار یک کاربر در وبسایت شما را شبیه سازی می‌کنند .

چرخه Ops

مرحله release

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

مرحله deploy

در این مرحله از ابزارهای اتومیشن مانند Ansible و chef و puppet و … استفاده می‌شود

مرحله operates

این مرحله و مرحله قبل deploy اکثر جاها یکجا پیاده سازی می‌شوند و ابزارها یکسان هست

مرحله monitor

در این مرحله هم معمولا از ابزارهای (ELK (Elasticsearch , Logstash , Kibana و zabbix و grafana استفاده می‌شود.

نکته بسیار مهم

برای اتوماتیک کردن تمامی این کارها و به اصطلاح پیوسته کردن کل فرآیند از ابزارهای gitlab و jenkins استفاده می‌شود.

یک داستان

برای درک بهتر مطالب بالا میخوام در قالب یک داستان مراحل رو توضیح بدم

• برنامه نویسان برای بهتر شدن کد و ایجاد یک سری امکانات جدید یا اصلاح یک باگ و یا موارد دیگه برنامه میریزن که یک سری تغییر توی سورس کدشون انجام دهند.
• برای اینکار میان برنامه رو تغییر میدن و سورس کد برنامه رو روی گیتلب قرار میدن و توی گیتلب یه تریگر trigger درست شده که به محض اعمال push روی یک برنچ branch خاص که این برنچ مخصوص خودشون است یه وبهوک webhook از سرویس jenkins رو صدا میزنه
• توی جنکینز هم یک پروژه با همون webhook تعریف شده که به محض صدا زدن این webhook قرار است که کارهای زیر رو انجام بده
  • سورس کد رو میگره
  • اول که یک build آماده میکنه برای خود برنامه نویسان که بتونند نتیجه کارشون رو ببینند
  • بعد میره یه داکر از اون build تستی درست میکنه
    • نکته :  اینکه حالا برنامه نویسا میتونند نتیجه کار خودشون رو ببینند
  • بعد یه تست فانکشنالیتی از سرویسشون میگیره و برای این کار از katalon studio استفاده می‌کنه
  • نتیجه تمام این کارها رو هم به برنامه نویسا نشون میده
• بعد که تست اولیه اوکی بود برنامه نویسها برنچ خاص رو با برنچ اصلی که برای پروداکشن هست مرج merge میکنند
• بعداز مرج کردن یه webhook دیگه از جنکینز صدا زده میشه که کار اون ساختن محیط تست برای تیم تست هست. توجه کنید که این محیط تستی برای تیم تست می‌باشد و با آن محیط تست قبلی که مخصوص برنامه نویس‌ها بود متقاوت است . در واقع این تست پیش از رفتن به محیط production هست و از نظر برنامه نویس‌ها برنامه آماده پروداکشن هست .
• حالا نوبت به اجرای سناریوهای طراحی شده توسط تیم تست با استفاده از نرم افزار katalon studio به صورت اتوماتیک می‌باشد
• وقتی که تمام مراحل تست درست بود حال نوبت به بارگذاری کد جدید روی محیط عملیاتی می‌باشد.
• و در آخر هم باید مانیتورینگ کنیم ببینیم شرایط به چه صورت هست