آشنایی با مفاهیم دوآپس 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 به صورت اتوماتیک می‌باشدوقتی که تمام مراحل تست درست بود حال نوبت به بارگذاری کد جدید روی محیط عملیاتی می‌باشد.و در آخر هم باید مانیتورینگ کنیم ببینیم شرایط به چه صورت هستو در آخر اگه دوس دارید که لینوکس رو به صورت کاملا رایگان یاد بگیرید و دانش خودتون رو به اشتراک بگذارید و یا اینکه از دانش دیگران بهره ببرید به وبسایت ما sudoer یه نگاهی بندازید