در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم)

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

خب یه مروری کنیم پست‌های قبلی رو:

• دواپس چیه و چرا لازمه؟  اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.

• چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.

• چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.

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

• در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.

• در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.

• در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.

• تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.

• در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.

• در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.

• در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.

• در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.

• در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.

• در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.

• در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.

• در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.

• در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.

• در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.

• در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.

• در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیم

• در مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.

• آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.

• کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.

• کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.

• پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.

• ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.

• اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.

• نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.

• استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.

• پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.

• پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.

• اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.

• کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.

• دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.

• مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.

• هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.

• سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.

• نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.

• نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.

• نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.

توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.

توضیح مقدمه‌ی گیت‌لب:

گیت‌لب یه ابزار جامع و کامله که کل چرخه‌ی دواپس رو می‌تونه پوشش بده. به خوبی می‌تونیم باهاش تمام کارهایی که لازم است در این چرخه‌ انجام بدیم رو برنامه‌ریزی کنیم و تا انتهای پیاده‌سازی و گرفتن فیدبک برامون راهکار داره و می‌تونه کمک کنه. گیت‌لب برای استقرار CI/CD که تو پست‌های قبلی در موردش صحبت کردیم، نیاز به هیچ ابزار دیگری نداره و تنها با ایجاد یه فایل gitlab-ci.yml. می‌تونه تمام مسیر رو پیش بره و انجام بده.

توضیح Workflow گیت‌لب:

تو تصویر فوق شما Workflow گیت‌ رو مشاهده می‌کنید. همان‌طور که تو این تصویر هم مشخص هست می‌تونیم به گونه‌ای تنظیم کنیم که به ازای هر پوش یا مرج‌ریکوئست فرآیند‌های مربوط به CI که شامل بیلد و تست می‌شه اجرا بشه و اگر همه چی خوب پیش رفت در ادامه دیپلوی تو استیج و پروداکشن رو پیش ببریم که این مسیر کاملا در اختیار ما است و می‌تونیم هر جایی از آن رو که دوست داشتیم تغییر بدیم و مطابق نیازمندی سیستم و سرویس آن را پیش ببریم.

توضیح کامپوننت‌های گیت‌لب:

Gitaly

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

GitLab Exporter

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

GitLab agent

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

GitLab Pages

گیت‌لب پیجز قابلیتی هست که بهمون کمک میکنه تا سایت‌های استاتیک رو به صورت مستقیم از ریپازیتوری منتشر کنیم. می‌تونیم ازش برای موارد شخصی یا موارد بیزینسی مثل پورتفولیو، پرزنتیشن‌ها، داکیومنت‌ها و … استفاده کنیم. قسمت داکیومنت‌های گیت‌لب خودش روی همین pages هست و به صورت as code نگهداری و پایش می‌شود.

GitLab Runner

کارهای مختلف توی CI/CD رو بهشون میگیم جاب. گیت‌لب رانر کامپوننتی هست که جاب ها رو انجام میده و نتیجه اونها رو برای گیت‌لب میفرسته. به عبارت دیگه گیت‌لب‌ تسک‌هایی که باید تحت عنوان Job انجام بده رو داخل این رانرها انجام می‌دهد.

GitLab Shell

گیت‌لب شل برنامه ای هست که طراحی شده برای هندل کردن سشن های SSH که به گیت‌لب میزنیم. دقت کنید که گیت‌لب شل یک شل یونیکس نیست و نمی‌تونه جایگزینی برای ‌Bash یا Zsh باشه. متداول است که برای کار با گیت از همین روش و ماژول استفاده می‌کنیم.

Puma

پوما یک وب سرور اوپن سورس به زبان روبی هست که گیت‌لب برای پاسخ به درخواست های http از اون استفاده میکنه. ویژگی بارز پوما این هست که از مالتی ترد استفاده میکنه و توانایی پاسخ به چندین درخواست به شکل همزمان رو داره که این ویژگی‌ پوما رو برای اپلیکیشن‌ها با ترافیک و لود بالا مناسب میکنه.

GitLab Workhorse

گیت‌لب ورک‌هاوس برنامه‌ای هست که اومده تا به پوما کمک کنه و عملکرد و سرعت وب سرور رو بالاتر ببره و برای پاسخ به درخواست هایی که نیاز به پردازش زمانبر دارن و موارد این شکلی، کمک کنه. به صورت کلی مسیر درخواست‌های http داخل گیت‌لب از این دو تا ماژول عبور می‌کنه.

Sidekiq

سایدکیک یک پراسسور بک گراند به زبان روبی هست که از صف Redis جاب هاش رو برمیداره و توی بک گراند انجام شون میده. سایدکیک میتونه وظایف پردازشی پس زمینه مثل ارسال ایمیل، پردازش فایل، ایجاد گزارش و مواردی ازین دست رو به صورت موازی و بدون تاثیر بر عملکرد گیت‌لب انجام بده چون به صورت مستقل از گیت‌لب اجرا میشه.

توضیح دیزاین گیت‌لب و نحوه‌ی پیاده‌سازی

gitlab omnibus

گیت‌لب omnibus یه راه سریع و راحت برای نصب، نگهداری و آپدیت یک اینستنس استاندارد از گیت‌لب به ما میده. میتونیم آمنی‌باس رو در قالب یک پکیج که شامل تمام کامپوننت های مورد نیاز برای داشتن یه گیت‌لب هست، دانلود کنیم و به صورت on-premises یا روی کلاد اونو بالا بیاریم.

مزایا:

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

• برای بالا اومدن گیت‌لب و ران شدنش یه کانفیگ حداقلی نیاز داره.

• آپگرید کردن به ورژن‌های بعدی تو این روش خیلی آسونه.

• محیط‌های مختلف رو پشتیبانی میکنه و نیازش به پشتیبانی برای مشکلات احتمالی خیلی کم هست.

میزان منابع مورد نیاز:

4 core CPU , 4 GB RAM , 50 GB Disk

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

8 core CPU , 8 GB RAM , 100 GB Disk

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

نحوه‌ی پیاده‌سازی:

توضیح کوتاه نصب و کانفیگ گیت‌لب

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

کانفیگ گیت‌لب بهتون اجازه میده از url که میخواید قسمت های مختلف سرویس تون با اون بالا بیاد تا تنظیمات وب سرور و موارد مرتبط با احراز هویت کاربران و سرویس ایمیل گیت‌لب و … رو به شکلی که میخواید تغییر بدید.

گیت‌لب خیلی ابزار کاملی هست و کانفیگ‌های خیلی خیلی زیادی داره که با وقت گذاشتن می‌تونید به خوبی با آنها آشنا بشید و ازش استفاده کنید. به صورت کلی تو این مستند بیشتر به مواردیکه مهم‌تر هستند اشاره می‌کنم.

توضیح بکاپ و ‌restore گیت‌لب:

همواره کد‌های تیم‌ها و موارد این چنینی از سرمایه‌های مهم هر سازمانی می‌باشد. بکاپ گیت‌لب و امکان بازگرداندن آن خیلی مهمه و درجه‌ی اهمیت بالایی داره. جای نگرانی نیست چونکه خود گیت‌لب به ما امکانات خیلی خوبی برای این کار داده و ما می‌تونیم با استفاده از آنها به خوبی بکاپ و ریستور انجام بدیم. گیت‌لب امکان بک آپ گرفتن رو از طریق دستور gitlab-backup create بهمون میده. خروجی بک آپ در مسیر var/opt/gitlab/backups/ ریخته می‌شه که حتما میدونید که اگر از داکر استفاده میکنید این مسیر رو باید براش والیوم بسازید. مسیر ذخیره سازی بک آپ رو میشه از طریق تغییر دادن وریبل backup_path داخل فایل کانفیگ، تغییر داد. هر بک آپی که می‌گیریم در قالب یک فایل tar به همراه یک TIMESTAMP که زمان گرفته شدن بک آپ هست، ذخیره می‌شود. برای restore بک آپ باید فایل‌های مختلف بک آپ‌مون رو با استفاده از همین TIMESTAMP تشخیص بدیم و مشخص کنیم. در ادامه لیستی از مواردی رو که میتونیم توی گیت‌لب ازشون بک آپ بگیریم براتون میارم و کامندلاین گیت‌لب این امکان رو بهمون میده که هر موردی رو که نخواستیم توی بک آپ SKIP کنیم. این موضوع خیلی می‌تونه بهمون کمک کنه که فایل بکاپ ما شامل چه مواردی باشه و به عبارت دیگه از چیزهایی که می‌خواهیم بکاپ بگیرم.

• Database

• Attachments

• Git repositories data

• CI/CD job output logs

• CI/CD job artifacts

• LFS objects

• Terraform states

• Container Registry Images

• Gitlab Pages Content

• Packages

• Snippets

• Group wikis

گیت‌لب از Mattermost data (سرویس چت گیت‌لب) و Redis و جاب های Sidekiq بک آپ نمی‌گیرد.

نکته مهم: گیت‌لب از فایل های کانفیگش بک آپ نمیگیره چونکه اطلاعات رمز شده‌ای مثل اطلاعات مربوط به احراز هویت دو مرحله ای یا 2FA و وریبل‌های CI/CD که اونها رو رمز کردیم توی بک آپ هست و ذخیره کردن فایل کانفیگ که حاوی پسورد این رمزنگاری هست در کنار دیتای رمز شده، ایراد امنیتی میتونه داشته باشه. بنابراین حواستون باشه که از فایل های کانفیگ حتما خودتون بک آپ بگیرید که حالت حداقلیش برای Omnibus میشه دوتا فایل زیر:

/etc/gitlab/gitlab-secrets.json

/etc/gitlab/gitlab.rb

معمولا در پروداکشن‌هایی با اهمیت بالاتر بک آپ رو توصیه میکنن که توی یک استورج ریموت مثل Amazon S3 یا Openstack Swift ذخیره کنیم. گیت‌لب هم این امکان رو داره که بک آپ رو به استورج ریموت بفرسته.

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

نهایتا برای restore کردن بک آپ‌تون به گیت‌لب حواستون باشه که اول سرویس‌های وب رو استاپ کنید یعنی به کمک دستورات gitlab-ctl stop puma و gitlab-ctl stop sidekiq سرویس‌های پوما و سایدکیک رو استاپ کنید و با دستور gitlab-ctl restore میتونید بک آپی رو که از طریق متغیر BACKUP توی کامند مشخص می‌کنید رو برگردونید به گیت‌لب تون و بعد از انجام این فرآیند سرویس هاتون رو ری استارت کنید.

توضیح آپدیت گیت‌لب

گیت‌لب از سمنتیک ورژنینگ به صورت ( Patch ).( Minor ).( Major ) استفاده میکنه. احتمالا به دلیل Backward-incompatible و Migrations که در برخی از ورژن های گیت‌لب اتفاق می‌افته، نمی‌تونیم به صورت مستقیم لزوما به ورژن بالاتری که میخوایم آپگرید کنیم و ممکنه نیاز باشه که طی چند استپ دونه دونه این آپدیت هارو انجام بدیم تا به ورژنی که میخوایم برسیم که ابزار هایی مثل Upgrade Path هستن که این مسیرو برای حالت های مختلف نصب گیت‌لب میگن و از زیبایی‌های نصب با روش Omnibus و استفاده از داکر این هست که شما فقط عدد ایمیج کامپوز فایلتون رو ادیت می‌کنید 🙂

توضیح موارد مهم داخل گیت‌لب:

• Commit

به یک تغییر کد که توی ریپازیتوری ذخیره اش کردیم، کامیت می‌گیم.

• Job

به دستوراتی که یک رانر باید اجرا کنه جاب می‌گیم.

• Pipeline

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

• Stage

استیج یه جورایی یه تقسیم بندی توی پایپ لاین هست، معمولا استیج های build و test و deploy رو داریم و معمولا جاب های درون یک استیج به صورت موازی اجرا میشن اگه رانر کافی داشته باشیم.

• Runner

رانر ایجنت یا سروری هست که جاب هارو برای ما انجام میده.

• Artifact

به آرشیو فایل‌ها و دایرکتوری‌های خروجی یک جاب که می‌خوایم اونا رو نگه داریم، آرتیفکت می‌گیم.

• Variables

مواردی توی فایل پایپ‌لاین‌مون که می‌خواهیم متغییر باشن و بتونم اونها رو تغییر بدیم یا به صورت مخفی باشند درون گیت رو با وریبل میذاریم توی فایل مون.

• Environment

میتونیم اپلیکیشن رو توی محیط های مختلف عملیاتی مثل stage و product دیپلوی کنیم و انوایرومنت این امکان رو به ما میده که پایپ‌لاین‌مون رو برای محیط های مختلف جدا کنیم.

• Cache

میتونیم برای اجرای سریع تر پایپ لاین‌مون مواردی مثل دیپندنسی هارو کش کنیم.

• Pipeline trigger

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

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

مراقب خودتون باشید. 🌹🐳🌹

خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.

🫀 Follow DockerMe 🫀

🔔 Follow YouTube 🔔

📣 Follow Instagram 📣

🖇 Follow LinkedIn DockerMe🖇

🔎 Follow Linkedin Ahmad Rafiee 🔎

🕊 Follow Twitter 🕊