آشنایی با DevOps
آشنایی با مفاهیم دوآپس DevOps
DevOps یه مفهومی هست که این روزها خیلی جاها راجع بهش می‌شنوید و می‌خونید . در واقع این روزها کمتر شرکت و یا کسبوکاری هست که در زمینه آی‌تی کار کنه و نیاز به نیروی متخصص DevOps نداشته باشه . علاوه بر نیاز بالای بازار کار به این تخصص خوبه بدونید که خیلیا هم هستند که در حال برنامه ریزی برای وارد شدن به این تخصص هستند و تصمیم دارند تا در آینده در این حرفه فعالیت داشته باشند . ولی اینکه DevOps چه کسی هست و چه کارهایی باید بلد باشه رو در ادامه براتون توضیح میدم .
در گذشته نه خیلی دور (حدود ۹ یا ۱۰ سال پیش) که استفاده از سیستم عامل لینوکس در ایران فراگیر شد و خیلی از شرکت‌ها به ضرورت استفاده از این سیستم عامل پی بردند بازار کار آی‌تی در ایران می‌طلبید که سیس ادمین یا یا همون Linux System Administration زیاد جذب بشه . در حقیقت خیلی از شرکت‌ها و کسب‌وکارها نیاز داشتند که یک شخصی یا گروهی وجود داشته باشند که بتوانند از پس کارهای مربوط به سرورهای لینوکسی و سرویس‌های مورد نیازشون بر بیان و یا اینکه زیرساخت سرویس‌های فعلی رو به سمت لینوکس سوق بدهند .
این دوره چند ساله که تا الان هم ادامه داره دوره‌ای است که متخصص‌های زیادی در زمینه لینوکس وارد بازار کار شدند و به عنوان Linux System Admin در کسب‌وکارها مشغول به کار شدند .
عمده کار سیس ادمین‌ها راه اندازی و نگهداری سرویس‌ها و سرورهای لینوکسی بود که قرار بود اپلیکیشن‌های برنامه‌نویس‌ها روی این سرورها اجرا بشه و به کاربران خدمت رسانی کنند .
این به این معنی هست که در هر شرکت و کسبوکاری دو تیپ متخصص مربوط به سرویس مشاهده می‌شود
۱. برنامه نویسها که وظیفه تولید و توسعه اپلیکیشن ها و برنامه ها رو بر عهده دارند
۲. سیس ادمین‌ها که وظیفه راه‌اندازی و نگهداری از سرویس‌ها و سرورهای لینوکسی رو برعهده دارند
و به صورت کاملا طبیعی این دو گروه دانش زیادی از کار و تخصص همدیگر ندارند و تعامل بین آنها کمی با مشکل روبرو می‌شد که در ادامه به برخی از اونها اشاره میکنم
- مثلا برنامه‌نویس‌ها شناخت خیلی درستی از سیستم‌عامل و شرایط زیرساختی ندارند
- یا سیس‌ادمین‌ها سواد و دانش کافی درباره اپلیکیشن و نحوه برنامه‌نویسی و اجرای برنامه ها ندارند
- برنامه‌نویس‌ها نیاز به یک محیط تستی برای تست و بررسی اپلیکیشن خود دارند
- سیس‌ادمین‌ها نیاز دارند تا اپلیکیشن نوشته شده قبل از استفاده در محیط پروداکشن به صورت کامل تست و عیب‌یابی شوند . پس در این میان نیاز به وجود یک تیم تست نکته بسیار مهمی هست
- فرآیندها به صورت دستی و غیره اتومات بوده و همین باعث کندی و افزایش ضریب خطا می‌شود
- هماهنگی بین تیم برنامه‌نویس و سیس‌ادمین و تست دشوار و روند پیش‌رفتن کار کند و طاقت فرسا هستند
موارد بالا برخی از مشکلات بوجود آمده در یک شرکت آی‌تی بود که اشاره کردیم
برای برطرف نمودن مشکلات نام برده شده جای خالی یک شخص یا یک تیمی احساس می‌شود که بتواند کارهای زیر را انجام دهد
- دانش خوبی و عمیقی از سیستم‌عامل لینوکس داشته باشد
- دانش خوبی از زبان‌ها و منطق برنامه نویسی داشته باشد
- ابزارهای اتوماتیک کردن کارها را بشناسد
- از انجام کارهای تکراری به شدت بپرهیزد
- ابزارهای انجام تست را خوب بشناسد
- بتواند کاری کند که سرعت پیش‌رفتن کارها را بیشتر شود
- هماهنگی بین تیم‌های مختلف را انجام دهد
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 به صورت اتوماتیک می‌باشد
- وقتی که تمام مراحل تست درست بود حال نوبت به بارگذاری کد جدید روی محیط عملیاتی می‌باشد.
- و در آخر هم باید مانیتورینگ کنیم ببینیم شرایط به چه صورت هست
دوآپس یک فرایند تولید نرم‌افزار است که بر مبنای ارتباط و همکاری هرچه بیشتر میان تیم‌های توسعهٔ نرم‌افزار و تیم‌های اجرایی بنا شده است که در طی این فرآیند عملیات توسعهٔ نرم‌افزار و همچنین اِعمال تغییرات زیرساختی به صورت خودکار درمی‌آیند و در کل هدف از چنین فرایندی ایجاد فرهنگی است که در آن تولید، تست و انتشار نرم‌افزار به شیوه‌ای سریع، مداوم و مطمئن انجام شود.
حال بپردازیم به بررسی فرایند توسعهٔ نرم‌افزار به طوری که این فرایند را می‌توان به پنج مرحلهٔ اصلی تقسیم کرد که عبارتند از:
Planning (طرح‌ریزی)
در این مرحله از فرآیند توسعهٔ نرم‌افزار، تیمی متشکل از دولوپرها، مدیران تولید و … اهداف پروژه را ترسیم نموده و ساختار کلی نرم‌افزار را تعیین میکنند و در این مرحله مهندس دوآپس باید از دانش فنی اعضای تیم و تسلط آنها بر پلتفرم‌های مورد استفاده بهره برده و بررسی نماید که چگونه می‌توان در قالب یک سیستم جامع و یکپارچه به تمام اهداف مورد نظر تیم جامهٔ عمل پوشاند (در کل، این مرحله از کار یکی از گام‌های زمان‌بَر است.)
پس از اینکه شِمای کلی سیستم اولیه پیاده‌سازی و اجرا شد، مهمترین مسئله هدایت تیم در جهت نحوهٔ افزودن قابلیت‌ها و تکنولوژی‌های از قبل تولیدشده به این سیستم است. در واقع، مهندس دوآپس همواره باید به دنبال راه‌کار‌هایی برای انجام خودکار فرآیندهای مختلف باشد تا بار انجام این کارها تا حد امکان از دوش اعضای تیم برداشته شود که در این مرحله مهندس دوآپس باید پاسخ سؤالات زیر را بیابد:
– دو سرویس مختلف چگونه می‌توانند با هم در تعامل باشند؟
– برای مرتبط کردن این دو سرویس از چه پروتکلی باید استفاده نمود؟
– آیا سخت‌افزاری که در اختیار ما قرار دارد پاسخگوی نیازمان هست؟
– برای اینکه بتوانیم در پروسهٔ تولید به مهندسان کمک کنیم، نیاز به چه چیزهایی داریم؟
– آیا سرویس مذکور به اصطلاح Production-Ready خواهد بود؟
– آیا تمام دیپندنسی‌های مورد استفاده در نرم‌افزار برای ما ملموس هستند؟
– چه چیزی را لازم است بسازیم و چه چیزی را باید خریداری کنیم؟
– آیا یک تَسک خاص را می‌توان به صورت خودکار انجام داد؟
– چه‌طور می‌توان در آینده از این نرم‌افزار پشتیبانی نمود؟
Development (توسعه)
در این مرحله، ترکیب‌بندی کلی کار مشخص شده و دیگر نوبت دولوپرها است تا کد بزنند و فیچرهای پیش‌بینی‌شده را برای نرم‌افزار توسعه دهند و هدف عمدهٔ مهندس دوآپس در چنین مرحله‌ای این است که به دنبال راه‌هایی برای سریع‌تر انجام شدن کارها باشد. به عبارتی، وی باید راهی پیش پای دولوپرها بگذارد تا بتوانند بهترین کار را در کمترین زمان ممکن انجام دهند و این دقیقاً با هدف نهایی کار، یعنی تولید نرم‌افزار، هماهنگ و سازگار است.
در حقیقت، در این پروسه مهندس دوآپس به دولوپرها می‌گوید که از چه ابزاری استفاده کنند و همچنین ابزارهای جدید را در اختیار آنها قرار می‌دهد تا کارشان تسهیل گردد. همچنین این مهندس دوآپس است که باید بخش‌های مختلف کدهایی که توسط دولوپرها و در محیط توسعه نوشته شده‌اند را مانند قطعات پازل در کنار هم قرار داده و آنها را با محیط نهایی نرم‌افزار هماهنگ کند. سؤالاتی که یک مهندس دوآپس در این مرحله ممکن است با آن مواجه شود عبارتند از:
– چگونه می‌توانیم دولوپرها را در فضایی مشابه فضای محصول نهایی نگاه داریم؟
– چه‌طور به دولوپرها اجازه دهیم تا از ابزارهای مورد علاقهٔ خود استفاده کنند؟
– چگونه می‌توانیم بهره‌وری و کارایی دولوپرها را افزایش دهیم؟
– چه‌طور باید برای دولوپرها توضیح دهیم که محیط نهایی نرم‌افزار چگونه خواهد بود؟
Testing (تست کردن)
در این مرحله، دولوپرها و مسئولین کنترل کیفیت (QC) کدها را تست نموده و آنها را برای یکپارچه شدن با سورس‌کد اصلی آماده میکنند که در این مرحله ممکن است از ابزارها و اسکریپت‌هایی به منظور انجام خودکار تست‌ها استفاده شود اما هنوز هم برای اجرای دستی کدها بر روی سیستم‌های داخلی شرکت به حضور دولوپرها و مسئولین کنترل کیفیت نیاز است.
در اینجا است که دوباره پای مهندس دوآپس به میان می‌آید به طوری که در این مرحله وظیفه‌اش این است که برای تکرار خودکار تست‌ها راهی بیابد به طوری که میتواند از ابزارهایی مانند Jenkins ،Bamboo و یا Drone استفاده کند که این‌ها ابزارهای Continuous Integration یا به اختصار CI هستند که تست مداوم کدها را آسان‌تر میکنند. همچنین در این مرحله لازم است تا به سؤالات زیر پاسخ داده شود:
– چگونه می‌توان به اصطلاح چندین Client Environment تکرارپذیر ایجاد نمود؟
– از کجا بدانیم تست مورد نظر در مورد کدام نسخه از سرویس در حال انجام است؟
– چگونه تاریخچهٔ تست‌ها را دنبال کنیم و با استفاده از آن به روندهای موجود پی ببریم؟
– چگونه پس از تست نمودن کدها، مشکلات احتمالی را به دولوپرها اعلام کنیم؟
– داده‌های تست را از کجا به دست آوریم؟
Deployment (استقرار)
این اصطلاح به معنای آپلود کردن کدها روی سرور اصلی نرم‌افزار است. به طور کلی، این مرحله در مورد این است که کدهای نوشته‌شده چه‌طور و با چه نظمی در محصول نهایی قرار بگیرند تا کاربر نرم‌افزار قادر به استفاده از سرویس ما گردد. در این مرحله نیز مهندسان دوآپس از ابزارهای CI، مشابه آنچه که در بخش قبل معرفی شد، استفاده میکنند و بعضی از مهمترین سؤالاتی که در این مرحله باید پاسخ داده شوند عبارتند از:
– چه زمانی یک نسخهٔ نهایی‌نشده از نرم‌افزار آمادهٔ دیپلوی شدن است؟
– چگونه بدون اینکه کاربر متوجه شود، سرویسی را دیپلوی نماییم؟
– چگونه مطمئن شویم سرویسی که به تازگی دیپلوی شده منجر به ایجاد اختلال نمی‌شود؟
– چگونه فرآیند دیپلوی شدن را به صورت خودکار درآوریم؟
– چگونه در صورت لزوم در فرآیند دیپلوی خودکار، مراحلی را به صورت دستی و غیرخودکار انجام دهیم؟
– چگونه فرآیند دیپلوی را با روشی تکرارپذیر انجام دهیم؟
معمولاً این مرحله زمان زیادی را از مهندسان دوآپس نمی‌گیرد اما بخشی که این مهندسین باید بیشترین زمان و انرژی خود را صرف آن کنند، مرحلهٔ بعدی، Maintenance، است.
Maintenance (نگهداری)
همان‌طور که گفتیم، مرحلهٔ نگهداریِ نرم‌افزار یکی از مراحلی است که بیشترین زمان یک مهندس دوآپس را به خود اختصاص می‌دهد و این فاز تماماً در مورد انجام کارهایی است که در نهایت موجب در دسترس قرار گرفتن یک سیستم و حفظ کارایی آن می‌شوند. در این مرحله سؤالاتی مانند موارد زیر باید پاسخ داده شوند:
– چگونه می‌توانیم از مشکلات و باگ‌های موجود در محصول یا سرویس آگاه شویم؟
– چگونه باگ‌های مختلف موجود در محصول یا سرویس را به تیم‌های مناسب ارجاع دهیم؟
– چگونه باگ‌های زیرساختی موجود در محصول را برطرف کنیم؟
– به عنوان یک مهندس دوآپس چگونه می‌توانیم از سلامت و کارایی همهٔ سرویس‌ها مطمئن شویم؟
جمع‌بندی
DevOps آمیزه و مخلوطی از چندین نقش بوده و هدف نهایی آن کنار هم قرار دادن دولوپرها و مهندسان اجرایی است. فرهنگ دوآپس ویژگی‌ها و قابلیت‌های جدید محصول را با زیرساخت‌های آن سازگار می‌نماید و سبب می‌شود تا این دو بتوانند در کنار هم به خوبی عمل کنند. نیاز به توضیح نیست که اصطلاح DevOps از دو واژهٔ Development به معنی «توسعه» و Operations به معنی «عملیات» ساخته شده است.
منبع: سودوئر + سکان آکادمی
آشنایی با DevOps