برای مهندسان DevOps، یادگیری یک ابزار امروزه با مستندات آماده، ChatGPT، آموزشهای رایگان یوتیوب و وبلاگها آسان شده است.
با این حال، میتوانید با اجرای بهترین شیوهها و گردشهای کاری استاندارد صنعتی در طول فرآیند یادگیری، یادگیری خود را افزایش دهید.
درباره ابزار CI/CD
ابزارهای زیادی برای CI/CD وجود دارد. اگر لیست ابزارهای Devops من را بررسی کنید، بیش از ۱۵ ابزار برای CI/CD پیدا خواهید کرد. همیشه ابزارهای بیشتری وجود دارد.
اصول و گردشهای کاری اصلی CI/CD صرف نظر از ابزار شما یکسان باقی میمانند. هر ابزار ممکن است نحو و پیکربندیهای خود را برای ایجاد یک خط لوله داشته باشد.
بنابراین، بهترین ابزار CI/CD کدام است؟
شما میتوانید تمام روز در مورد بهترین ابزار بحث کنید. اکثر ابزارها از الگوی یکسانی پیروی میکنند.
شما گردش کاری خود را در Git تعریف میکنید و ابزار آن را اجرا میکند. چه Jenkins باشد، چه GitHub Actions، چه Gitlab CI، چه Circle CI و غیره.
اگر یک ابزار را به درستی یاد بگیرید، میتوانید ابزارهای دیگر را به سرعت یاد بگیرید.
این وبلاگ در مورد آموزش ابزارهای خاص نیست، بلکه لیستی از بهترین شیوهها و گردشهای کاری است. بنابراین هنگام انتخاب ابزارها برای یادگیری، میتوانید از این بهترین شیوهها پیروی کنید و خطوط لوله را توسعه دهید.
CI/CD برای اپلیکیشن و زیرساخت (IaC)
وقتی صحبت از DevOps میشود، CI/CD هم برای کد برنامه و هم برای کد زیرساخت (IaC) قابل اجرا است.
قبل از استقرار کد برنامه/کدهای زیرساخت در یک محیط، باید فرآیند آزمایش و بررسی را طی کنیم.
به عنوان مثال، کد برنامه از طریق تست واحد، تجزیه و تحلیل کد استاتیک، اسکن آسیبپذیری و غیره انجام میشود. ما باید همین کار را برای کد زیرساخت نیز انجام دهیم.
من بهترین شیوهها را تحت عناوین مختلف دستهبندی کردهام. بیایید مستقیماً به آن بپردازیم.
۱. مدیریت پیکربندی
مدیریت پیکربندی یک جنبه اساسی از یک سیستم CI/CD است.
به عنوان مثال، نقاط پایانی مانند Nexus URL، Sonarqube URL، نقاط پایانی اسکنر آسیبپذیری، نقاط پایانی API و غیره.
همیشه از متغیرهای سراسری برای ذخیره نقاط پایانی و پیکربندیهای رایج استفاده کنید. اگر تغییری وجود داشته باشد، تنها کاری که باید انجام دهید این است که به جای ایجاد تغییر در هر خط لوله، متغیر سراسری را تغییر دهید.
تمام ابزارهای CI/CD از ذخیره متغیرهای سراسری پشتیبانی میکنند و به شما امکان دسترسی به متغیرهای سراسری در خط لوله را میدهند.
۲. مدیریت سکرت
شرکت Uber به هکرها پول داده است تا یک نقض داده را که ۵۷ میلیون کاربر را درگیر کرده بود، پنهان کنند.
آیا میدانید چگونه این اتفاق افتاد؟
هکرها به اعتبارنامههای AWS که به مخزن GitHub سپرده شده بودند، دسترسی پیدا کردند.
هر سیستم CI/CD باید با اسرار سر و کار داشته باشد. این اسرار میتواند شامل توکنهای API، اعتبارنامههای پایگاه داده، اعتبارنامههای ابری، توکنهای حساب سرویس و غیره باشد. هنگام برخورد با اسرار CI/CD باید اصول DevSecOps را رعایت کنید.
هیچ یک از اسرار نباید به صورت کدنویسی شده یا در سیستم ci یا git به صورت متن ساده ذخیره شوند. همیشه از یک سیستم مدیریت اسرار استفاده کنید که در آن ابزار CI/CD اسرار مورد نیاز را در زمان اجرا بازیابی کند.
ابزارهای مدیریت اسرار مکانیسمهای مختلفی را برای دسترسی ایمن به اسرار در زمان اجرا ارائه میدهند.
همچنین، باید مطمئن شوید که اسرار مورد استفاده توسط خطوط لوله در گزارشها ظاهر نمیشوند.
Hashicorp Vault، AWS secrets manager و Google secret manager نمونههایی از راهحلهای مدیریت اسرار خارجی هستند.
۳. اصول خشک را دنبال کنید.
خشک - "خودتان را تکرار نکنید"
از ابتدا، باید روی به حداقل رساندن تکرارهای کد CI/CD کار کنید. یک پروژه ممکن است خطوط لوله زیادی با مراحل مشترک داشته باشد.
یکی از این نمونهها ساخت maven است.
فرض کنید ۵۰ سرویس دارید که به ساخت maven نیاز دارند و کد ۵۰ خط لوله را کپی میکنید. این اصلاً یک راهحل مقیاسپذیر نیست.
بنابراین بهتر است کتابخانهها یا گردشهای کاری مشترک را توسعه دهید و به جای تکرار مراحل در خطوط لوله برای هر سرویس، آنها را دوباره استفاده کنید.
به عنوان مثال، کتابخانه مشترک جنکینز و گردشهای کاری مشترک GitHub Actions به شما امکان میدهند از گردشهای کاری موجود برای خطوط لوله استفاده مجدد کنید.
توجه: گاهی اوقات، توسعه ماژولهای مشترک که متناسب با همه الزامات باشند، دشوار است. در این موارد، میتوانید ماژولهای قابل استفاده مجدد را برای تطبیق با الزامات خاص پروژه گسترش دهید.
۴. Pipeline مبتنی بر Git PR
ما در دوران GitOps هستیم.
هر خط لوله باید بخشی از Git باشد و برای هر PR آزمایش شود.
خط لولهها را حداقل در طول توسعه به صورت دستی ایجاد یا راهاندازی نکنید. این امر باعث ناسازگاری و خطای انسانی میشود. برای کد برنامه و زیربرنامه، هر PR باید قبل از ارسال به شاخهها به طور خودکار آزمایش شود (بررسی دروازهای).
استقرار در محیطهای خاص مانند مرحلهبندی یا تولید ممکن است نیاز به مداخله دستی داشته باشد. این امر در درجه اول به دلیل سیاستهای سازمانی، رعایت مقررات یا نیاز به فرآیندهای تأیید خاص است.
برای مثال، یک تغییر کد ممکن است قبل از استقرار در محیط تولید، نیاز به تأیید تیمهای تضمین کیفیت، تیمهای عملکرد، تیمهای امنیتی و ذینفعان تجاری داشته باشد.
5. ملاحظات شبکه خصوصی
وقتی از ابزارهای CI/CD در یک شبکه باز استفاده میکنیم، میتوانیم به تمام منابع موجود آنلاین دسترسی داشته باشیم و شما میتوانید هر زمان که نیاز باشد آن را دانلود و استفاده کنید.
با این حال، در پروژههای واقعی، ابزارهای CI/CD در یک شبکه خصوصی پشت پروکسیهای رو به جلو مانند Squid راهاندازی میشوند. ممکن است برای دانلود منابع از اینترنت به تأیید نیاز داشته باشید. این فقط برای مخازن رسمی لینوکس یا مدیران وابستگی مانند Maven مجاز خواهد بود.
بیشتر شرکتها رجیستریهای کانتینر عمومی مانند Docker Hub را مسدود میکنند. بنابراین وقتی راهحلها را پیادهسازی میکنید، از رجیستریهای خصوصی و منابع رسمی استفاده کنید.
6. گردشهای کاری توسعهدهنده محور:
کتابخانهها و اسنادی ایجاد کنید تا هر کسی بتواند بدون اطلاع ابزار، یک سرویس جدید را راهاندازی کند.
برخی از شرکتها تیمهای پلتفرمی دارند که این قالبهای عمومی را به عنوان بخشی از تلاشهای InnerSource ارائه میدهند.
و تیمهای مختلف در یک سازمان برای بهبود InnerSource به آن کمک میکنند.
7. توسعه خطوط لوله برای تیم
کتابخانههای خط لولهای را توسعه دهید که همه اعضای تیم آن را درک کنند. صرفاً به این دلیل که میتوانید یک کتابخانه پیچیده ایجاد کنید، به این معنی نیست که باید این کار را انجام دهید. همیشه از دیدگاه تیمی فکر کنید.
به عنوان مثال، میتوانید با استفاده از Jenkins pipeline DSL و کد خالص Groovy یک کتابخانه مشترک ایجاد کنید. اگر تیم DevOps شما نیاز به کسب مهارت برای توسعه در Groovy دارد، باید به DSL پایبند باشید. توسعه در Groovy خالص برای تیم در صورت نیاز به تغییر، سربار خواهد بود.
8. استفاده از عوامل ساخت زودگذر
هر ابزار CI/CD مفهوم عوامل ساخت را دارد. برای صرفهجویی در هزینه و جداسازی دغدغهها، خوب است که از عوامل ساخت زودگذر استفاده کنید. به این معنی که عوامل فقط در صورت نیاز مستقر میشوند.
میتوانید آنها را عوامل پویا یا عوامل بر اساس تقاضا بنامید.
هر ساخت بر روی یک عامل از یک الگوی خاص اجرا میشود و این امر ثبات در محیطهای ساخت را تضمین میکند.
عامل موقت میتواند یک ماشین مجازی، کانتینر داکر یا حتی Kubernetes pod باشد. اکثر ابزارهای CI/CD از عاملهای موقت پشتیبانی میکنند.
برای مثال، میتوانید Jenkins را با کلاستر Kubernetes ادغام کنید و jobها را طوری پیکربندی کنید که Podهای Kubernetes را به عنوان عوامل ساخت راهاندازی کنند.
اقدامات GitHub به طور پیشفرض از عوامل یا اجراکنندههای مبتنی بر کانتینر پشتیبانی میکنند.