🥇راهنمای مبتدیان: ساخت خط لوله DevOps

اگر در DevOps تازه کار هستید، به این راهنمای ساخت اولین خط لوله پنج مرحله ای خود نگاهی بیندازید.

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

سفر DevOps من

من قبلاً برای تیم ابری Citi Group در حال توسعه یک برنامه تحت وب Infrastructure-as-a-Service (IaaS) برای مدیریت زیرساخت ابری Citi کار می کردم، اما همیشه به چگونگی کارآمدتر کردن فرآیند توسعه و ایجاد تغییرات مثبت فرهنگی علاقه مند بوده ام. به تیم توسعه پاسخ را در کتابی یافتم که توسط گرگ لاوندر، مدیر ارشد فناوری سیتی برای معماری ابری و زیرساخت توصیه شده است. این کتاب "پروژه ققنوس" نام داشت (پروژه فونیکس) و اصول DevOps را هنگام خواندن مانند یک رمان توضیح می دهد.

جدول پشت کتاب نشان می‌دهد که شرکت‌های مختلف چند بار سیستم‌های خود را در یک محیط انتشار مستقر می‌کنند:

آمازون: 23 در روز
گوگل: 5 در روز
نتفلیکس: 500 در روز
فیس بوک: روزی یک بار
توییتر: 3 بار در هفته
شرکت معمولی: هر 9 ماه یک بار

فرکانس های آمازون، گوگل و نتفلیکس چگونه ممکن است؟ این به این دلیل است که این شرکت ها متوجه شدند که چگونه یک خط لوله DevOps تقریباً بی نقص بسازند.

تا زمانی که DevOps را در Citi پیاده‌سازی کردیم، از آن دور بودیم. در آن زمان، تیم من محیط های مختلفی داشت، اما استقرار در سرور توسعه کاملاً دستی بود. همه توسعه دهندگان تنها به یک سرور توسعه مبتنی بر IBM WebSphere Application Server Community Edition دسترسی داشتند. مشکل این بود که هر زمان که چندین کاربر همزمان بخواهند مستقر شوند، سرور خاموش می‌شد، بنابراین توسعه‌دهندگان مجبور بودند یکدیگر را از مقاصد خود آگاه کنند، که بسیار دردناک بود. علاوه بر این، مشکلاتی در مورد پوشش تست کد سطح پایین، فرآیندهای دست و پاگیر استقرار دستی، و ناتوانی در ردیابی استقرار کد مرتبط با یک کار خاص یا داستان کاربر وجود داشت.

متوجه شدم که باید کاری انجام شود و یک همکار همفکر پیدا کردم. ما تصمیم گرفتیم در ساخت خط لوله اولیه DevOps همکاری کنیم - او یک ماشین مجازی Tomcat و سرور برنامه راه اندازی کرد در حالی که من روی Jenkins کار می کردم، Atlassian Jira و BitBucket را یکپارچه کردم و روی پوشش تست کد کار می کردم. این پروژه جانبی بسیار موفقیت آمیز بود: ما تقریباً به طور کامل بسیاری از فرآیندها را خودکار کردیم، تقریباً به 100٪ آپتایم در سرور توسعه خود رسیدیم، ردیابی و پوشش تست کد بهبود یافته را ارائه دادیم، و توانایی پیوند شاخه ها در Git را به مشکلات در Jira یا استقرار اضافه کردیم. بیشتر ابزارهایی که برای ساخت خط لوله DevOps خود استفاده کردیم منبع باز بودند.

اکنون می‌دانم خط لوله DevOps ما چقدر ساده بود: ما از پسوندهایی مانند فایل‌های Jenkins یا Ansible استفاده نکردیم. با این حال، این خط لوله ساده، شاید به لطف اصل پارتو (که به عنوان قانون 80/20 نیز شناخته می شود) به خوبی کار کرد.

مقدمه ای کوتاه بر DevOps و خط لوله CI/CD

اگر از چند نفر بپرسید "DevOps چیست؟" احتمالاً چند پاسخ متفاوت دریافت خواهید کرد. DevOps، مانند Agile، تکامل یافته است تا رشته های مختلفی را در بر بگیرد، اما اکثر مردم در مورد چند چیز توافق دارند: DevOps یک روش توسعه نرم افزار یا چرخه عمر توسعه نرم افزار (SDLC) است که اصل اصلی آن تغییر فرهنگی است که در آن توسعه دهندگان و غیر توسعه دهندگان -توسعه دهندگان در محیطی وجود دارند که:

عملیات خودکار که قبلا به صورت دستی انجام می شد.
هر کس کاری را که بهترین انجام می دهد انجام می دهد.
تعداد پیاده سازی ها برای یک دوره زمانی مشخص افزایش می یابد. افزایش توان عملیاتی؛
افزایش انعطاف پذیری توسعه

در حالی که داشتن ابزارهای نرم افزاری مناسب تنها چیزی نیست که برای ایجاد یک محیط DevOps نیاز دارید، برخی از ابزارها ضروری هستند. ابزار کلیدی یکپارچه سازی مداوم و استقرار مداوم (CI/CD) است. در این خط لوله، محیط‌ها مراحل مختلفی دارند (مانند DEV، INT، TST، QA، UAT، STG، PROD)، بسیاری از عملیات‌ها خودکار هستند و توسعه‌دهندگان می‌توانند کد با کیفیت بالا بنویسند، به چابکی توسعه و فرکانس استقرار بالا دست یابند.

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

مرحله 1: روش های CI/CD

اولین چیزی که نیاز دارید یک ابزار CI/CD است. جنکینز، یک ابزار منبع باز مبتنی بر جاوا و دارای مجوز تحت مجوز MIT، ابزاری است که DevOps را محبوب کرد و به استاندارد واقعی تبدیل شد.

پس جنکینز چیست؟ به آن به عنوان نوعی کنترل از راه دور جهانی جادویی فکر کنید که می تواند با سرویس ها و ابزارهای مختلف صحبت کرده و سازماندهی کند. ابزار CI/CD مانند جنکینز به خودی خود بی فایده است، اما با اتصال به ابزارها و سرویس های مختلف قدرتمندتر می شود.

جنکینز تنها یکی از ابزارهای منبع باز CI/CD است که می‌توانید برای ساخت خط لوله DevOps خود از آن استفاده کنید.

جنکینز: Creative Commons و MIT
تراویس CI: MIT
کروز کنترل: BSD
Buildbot: GPL
آپاچی گامپ: آپاچی 2.0
کابین: گنو

در اینجا فرآیندهای DevOps با ابزار CI/CD چگونه به نظر می رسند:

شما یک ابزار CI/CD دارید که روی لوکال هاست خود اجرا می شود، اما در حال حاضر کار زیادی نمی توانید انجام دهید. بیایید به مرحله بعدی در سفر DevOps خود برویم.

مرحله 2: مدیریت سیستم های کنترل کد منبع

بهترین (و احتمالاً ساده‌ترین) راه برای آزمایش اینکه ابزار CI/CD شما می‌تواند جادو کند، ادغام با ابزار کنترل کد منبع (SCM) است. چرا به کنترل منبع نیاز دارید؟ فرض کنید در حال توسعه یک اپلیکیشن هستید. هر زمان که برنامه ای ایجاد می کنید، برنامه نویسی می کنید، چه از جاوا، پایتون، C++، Go، Ruby، جاوا اسکریپت یا هر یک از چندین زبان برنامه نویسی gazillion استفاده کنید. کدی که می نویسید کد منبع نامیده می شود. در ابتدا، به خصوص زمانی که به تنهایی کار می کنید، احتمالاً خوب است که همه چیز را در یک فهرست محلی قرار دهید. اما از آنجایی که پروژه بزرگتر می شود و افراد دیگر را برای مشارکت دعوت می کنید، به راهی برای جلوگیری از تضاد و در عین حال به اشتراک گذاری موثر تغییرات نیاز دارید. شما همچنین به راهی برای بازیابی نسخه‌های قبلی نیاز دارید، زیرا ایجاد نسخه‌های پشتیبان و کپی/پیست کردن در آنها قبلاً منسوخ شده است. شما (و هم تیمی هایتان) به چیز بهتری نیاز دارید.

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

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

Git: GPLv2 و LGPL v2.1
براندازی: آپاچی 2.0
سیستم نسخه های همزمان (CVS): گنو
وستا: LGPL
Mercurial: GNU GPL v2+

این همان چیزی است که خط لوله DevOps با افزودن کنترل های کد منبع به نظر می رسد.

یک ابزار CI/CD می‌تواند فرآیندهای تأیید، دریافت کد منبع و همکاری بین اعضا را خودکار کند. بد نیست؟ اما چگونه می توان آن را به یک برنامه کاربردی تبدیل کرد تا میلیاردها نفر بتوانند از آن استفاده کنند و از آن قدردانی کنند؟

مرحله 3: یک ابزار Build Automation ایجاد کنید

عالی! می توانید کد را بررسی کنید و تغییراتی را در سیستم کنترل کد منبع ایجاد کنید، همچنین از دوستان خود دعوت کنید تا در توسعه مشارکت کنند. اما شما هنوز برنامه ای ایجاد نکرده اید. برای ایجاد یک برنامه تحت وب، باید آن را در قالب بسته قابل توسعه کامپایل و بسته بندی کنید یا به عنوان یک فایل اجرایی اجرا کنید. (توجه داشته باشید که یک زبان برنامه نویسی تفسیر شده مانند جاوا اسکریپت یا PHP نیازی به کامپایل ندارد.)

از ابزار اتوماسیون ساخت استفاده کنید. صرف نظر از اینکه کدام ابزار اتوماسیون ساخت را برای استفاده انتخاب می کنید، همه آنها یک هدف مشترک دارند: ساخت کد منبع در قالبی دلخواه و خودکار کردن کار تمیز کردن، کامپایل، آزمایش و استقرار در یک محیط خاص. ابزارهای ساخت بسته به زبان برنامه نویسی شما متفاوت خواهد بود، اما در اینجا برخی از گزینه های متن باز رایج وجود دارد.

نام
مجوز
زبان برنامه نویسی

MAVEN
آپاچی 2.0
جاوه

مورچه
آپاچی 2.0
جاوه

لغزش
آپاچی 2.0
جاوه

Bazel
آپاچی 2.0
جاوه

ساخت
گنو
N / A

خر خر کردن
MIT
جاوا اسکریپت

جرعه
MIT
جاوا اسکریپت

سازنده
آپاچی
یاقوت

شن کش
MIT
یاقوت

AAP
گنو
پــایتــون

جواهرات
MIT
پــایتــون

بیت بیک
GPLv2
پــایتــون

کیک
MIT
C#

ASDF
مهاجران (MIT)
LISP

دوز و کلک
BSD
هاسكل

عالی! می توانید فایل های پیکربندی ابزار اتوماسیون ساخت را در کنترل منبع قرار دهید و به ابزار CI/CD خود اجازه دهید همه چیز را کنار هم بگذارد.

همه چیز خوب است، اینطور نیست؟ اما کجا برنامه خود را مستقر کنید؟

مرحله 4: وب سرور برنامه

تا اینجا شما یک فایل بسته بندی شده دارید که هم قابل اجرا و هم قابل نصب است. برای اینکه هر برنامه ای واقعاً مفید باشد، باید نوعی سرویس یا رابط ارائه دهد، اما شما به یک کانتینر برای میزبانی برنامه خود نیاز دارید.

سرور برنامه وب دقیقاً چنین ظرفی است. سرور محیطی را فراهم می کند که در آن می توان منطق بسته در حال استقرار را تعریف کرد. سرور همچنین یک رابط فراهم می کند و با باز کردن سوکت ها به دنیای خارج، خدمات وب را ارائه می دهد. برای راه اندازی به یک سرور HTTP و همچنین محیطی (مانند ماشین مجازی) نیاز دارید. در حال حاضر، فرض می کنیم بیشتر در مورد این موضوع بیشتر یاد می گیرید (اگرچه در زیر به ظروف می پردازم).

چندین سرور برنامه وب منبع باز وجود دارد.

نام
مجوز
زبان برنامه نویسی

تامکت
آپاچی 2.0
جاوه

جت
آپاچی 2.0
جاوه

WildFly
GNU Lesser Public
جاوه

ماهی شیشه ای
CDDL و GNU کمتر عمومی
جاوه

جنگو
3-ClauseBSD
پــایتــون

گردباد
آپاچی 2.0
پــایتــون

گل شاخدار
MIT
پــایتــون

پــایتــون
MIT
پــایتــون

آهن
MIT
یاقوت

Node.js و
MIT
جاوا اسکریپت

خط لوله DevOps شما تقریباً آماده استفاده است. آفرین!

در حالی که می توانید در آنجا توقف کنید و خودتان ادغام را انجام دهید، کیفیت کد نکته مهمی است که یک توسعه دهنده برنامه باید نگران آن باشد.

مرحله 5: پوشش تست کد

اجرای آزمایش ها می تواند یکی دیگر از نیازهای دست و پا گیر باشد، اما توسعه دهندگان باید هر گونه اشکال در برنامه را زودتر شناسایی کنند و کیفیت کد را بهبود بخشند تا اطمینان حاصل شود که کاربران نهایی راضی هستند. خوشبختانه، ابزارهای منبع باز بسیاری برای آزمایش کد شما و ارائه توصیه هایی برای بهبود کیفیت آن وجود دارد. بهتر از آن، بیشتر ابزارهای CI/CD می توانند به این ابزارها متصل شوند و فرآیند را خودکار کنند.

تست کد شامل دو بخش است: چارچوب‌های تست کد که به شما در نوشتن و اجرای آزمایش‌ها کمک می‌کنند و ابزارهای پیشنهادی که به بهبود کیفیت کد کمک می‌کنند.

سیستم های تست کد

نام
مجوز
زبان برنامه نویسی

JUnit
Eclipse مجوز عمومی
جاوه

مسخره کردن آسان
آپاچی
جاوه

موکیتو
MIT
جاوه

پاور ماک
آپاچی 2.0
جاوه

Pytest
MIT
پــایتــون

فرضیه
موزیلا
پــایتــون

سمی
MIT
پــایتــون

سیستم های توصیه بهبود کد

نام
مجوز
زبان برنامه نویسی

پوشش
گنو
جاوه

پوشش کد
Eclipse Public (EPL)
جاوه

Coverage.py
آپاچی 2.0
پــایتــون

اما
مجوز عمومی مشترک
جاوه

JaCoCo
Eclipse مجوز عمومی
جاوه

فرضیه
موزیلا
پــایتــون

سمی
MIT
پــایتــون

یاسمن
MIT
جاوا اسکریپت

سرنوشت
MIT
جاوا اسکریپت

موچا
MIT
جاوا اسکریپت

جادوگری
MIT
جاوا اسکریپت

توجه داشته باشید که اکثر ابزارها و فریمورک های ذکر شده در بالا برای جاوا، پایتون و جاوا اسکریپت نوشته شده اند، زیرا C++ و C# زبان های برنامه نویسی اختصاصی هستند (حتی اگر GCC منبع باز است).

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

مراحل اضافی

ظروف

همانطور که قبلاً گفتم، می توانید سرور خود را در یک ماشین مجازی یا سرور میزبانی کنید، اما کانتینرها یک راه حل محبوب هستند.

ظروف چیست؟ توضیح کوتاه این است که یک ماشین مجازی به حجم عظیمی از حافظه سیستم عامل، بیشتر از اندازه یک برنامه، نیاز دارد، در حالی که یک کانتینر برای اجرای یک برنامه تنها به چند کتابخانه و پیکربندی نیاز دارد. بدیهی است که هنوز کاربردهای مهمی برای ماشین مجازی وجود دارد، اما کانتینر یک راه حل سبک وزن برای میزبانی یک برنامه، از جمله سرور برنامه است.

در حالی که گزینه های دیگر کانتینر وجود دارد، Docker و Kubernetes محبوب ترین هستند.

داکر: آپاچی 2.0
Kubernetes: آپاچی 2.0

ابزارهای اتوماسیون متوسط

خط لوله DevOps ما در درجه اول بر روی ایجاد و استقرار برنامه های کاربردی متمرکز است، اما بسیاری از کارهای دیگر وجود دارد که می توانید با ابزار DevOps انجام دهید. یکی از این موارد استفاده از ابزارهای زیرساخت به عنوان کد (IaC) است که به ابزارهای اتوماسیون میان افزار نیز معروف هستند. این ابزارها به خودکارسازی نصب، مدیریت و سایر وظایف میان افزار کمک می کنند. بنابراین، برای مثال، یک ابزار اتوماسیون می‌تواند برنامه‌هایی مانند یک سرور برنامه کاربردی وب، یک پایگاه داده و یک ابزار نظارتی را با تنظیمات مناسب استخراج کرده و آنها را در یک سرور برنامه مستقر کند.

در اینجا برخی از ابزارهای اتوماسیون میان افزار منبع باز آورده شده است:

پاسخگویی: عمومی گنو
SaltStack: آپاچی 2.0
سرآشپز: آپاچی 2.0
عروسک: آپاچی یا جی پی ال