ویرگول
ورودثبت نام
احمد رفیعی
احمد رفیعی
خواندن ۱۲ دقیقه·۲ ماه پیش

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

gitlab
gitlab

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

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

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

gitlab lifecycle
gitlab lifecycle

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

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


gitlab workflow
gitlab workflow

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

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


gitlab architecture
gitlab architecture

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

Gitaly

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

HA Gitaly
HA Gitaly


GitLab Exporter

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

grafana dashboard for gitlab exporter
grafana dashboard for gitlab exporter


GitLab agent

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

gitlab agent for k8s
gitlab agent for k8s


GitLab Pages

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

gitlab pages
gitlab pages


GitLab Runner

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

gitlab runner
gitlab runner


GitLab Shell

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

git pull flow
git pull flow


Puma

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

PUMA
PUMA


GitLab Workhorse

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

gitlab workhorse
gitlab workhorse



Sidekiq

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

sidekiq
sidekiq



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

gitlab omnibus

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

gitlab omnibus
gitlab omnibus


مزایا:

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

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

4 core CPU , 4 GB RAM , 50 GB Disk

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

8 core CPU , 8 GB RAM , 100 GB Disk

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

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

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

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

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

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


gitlab backup & restore
gitlab backup & restore

توضیح بکاپ و ‌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 و استفاده از داکر این هست که شما فقط عدد ایمیج کامپوز فایلتون رو ادیت می‌کنید 🙂

upgrade path
upgrade path


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

gitlab pipeline
gitlab pipeline
  • 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 🕊

ci cdبک آپgitlabgitlab ci cdگیتلب
مشاور زیرساخت. موسس سایت آموزشی DockerMe.ir
شاید از این پست‌ها خوشتان بیاید