توضیح مقدمه‌ی گیتلب:
گیتلب یه ابزار جامع و کامله که کل چرخه‌ی دواپس رو میتونه پوشش بده. به خوبی میتونیم باهاش تمام کارهایی که لازم است در این چرخه انجام بدیم رو برنامه‌ریزی کنیم و تا انتهای پیاده‌سازی و گرفتن فیدبک برامون راهکار داره و میتونه کمک کنه. گیتلب برای استقرار CI/CD که تو پست‌های قبلی در موردش صحبت کردیم، نیاز به هیچ ابزار دیگری نداره و تنها با ایجاد یه فایل gitlab-ci.yml. میتونه تمام مسیر رو پیش بره و انجام بده.
gitlab workflow
توضیح Workflow گیتلب:
تو تصویر فوق شما Workflow گیت رو مشاهده میکنید. همان‌طور که تو این تصویر هم مشخص هست میتونیم به گونه‌ای تنظیم کنیم که به ازای هر پوش یا مرج‌ریکوئست فرآیند‌های مربوط به CI که شامل بیلد و تست میشه اجرا بشه و اگر همه چی خوب پیش رفت در ادامه دیپلوی تو استیج و پروداکشن رو پیش ببریم که این مسیر کاملا در اختیار ما است و میتونیم هر جایی از آن رو که دوست داشتیم تغییر بدیم و مطابق نیازمندی سیستم و سرویس آن را پیش ببریم.
gitlab architecture
توضیح کامپوننت‌های گیتلب:
Gitaly
گیتالی سرویسی هست که توسط گیتلب طراحی شده تا نیاز به استورج یا NFS رو توی پیاده‌سازی‌های توزیع شده گیتلب حذف کنه. بنابراین گیتلب برای خوندن و نوشتن دیتا از گیتالی استفاده میکنه. بسته به طراحی و نیاز ممکنه حتی گیتالی رو به عنوان یه بک گراند سرویس روی سرور جداگانه نصب کنیم و حتی در صورت نیاز اونو کلاستر کنیم.
HA Gitaly
GitLab Exporter
کامپوننتی که خود گیتلب طراحی کرده که برای استخراج متریک‌های گیتلب و دادن اون دیتا به پرومتئوس ازش استفاده می‌کنیم. اگه آشنا نیستید در آینده بهش میرسیم اما پرومتئوس ابزاری برای مانیتورینگ و موارد این شکلی هست که به کمک اون و اکسپورتری که توی گیتلب داره میتونیم هر لحظه بفهمیم که توی سیستم‌مون چه خبره.
grafana dashboard for gitlab exporter
GitLab agent
گیتلب ایجنت یه کامپوننت مخصوص کلاستر هست که برای حل کردن سازگاری گیتلب با کوبرنتیز بهمون کمک میکنه تا دیپلوی‌منت هامون رو با کلاستر کوبر سینک کنیم.
gitlab agent for k8s
GitLab Pages
گیتلب پیجز قابلیتی هست که بهمون کمک میکنه تا سایت‌های استاتیک رو به صورت مستقیم از ریپازیتوری منتشر کنیم. میتونیم ازش برای موارد شخصی یا موارد بیزینسی مثل پورتفولیو، پرزنتیشن‌ها، داکیومنت‌ها و … استفاده کنیم. قسمت داکیومنت‌های گیتلب خودش روی همین pages هست و به صورت as code نگهداری و پایش می‌شود.
gitlab pages
GitLab Runner
کارهای مختلف توی CI/CD رو بهشون میگیم جاب. گیتلب رانر کامپوننتی هست که جاب ها رو انجام میده و نتیجه اونها رو برای گیتلب میفرسته. به عبارت دیگه گیتلب تسک‌هایی که باید تحت عنوان Job انجام بده رو داخل این رانرها انجام می‌دهد.
gitlab runner
GitLab Shell
گیتلب شل برنامه ای هست که طراحی شده برای هندل کردن سشن های SSH که به گیتلب میزنیم. دقت کنید که گیتلب شل یک شل یونیکس نیست و نمی‌تونه جایگزینی برای Bash یا Zsh باشه. متداول است که برای کار با گیت از همین روش و ماژول استفاده می‌کنیم.
git pull flow
Puma
پوما یک وب سرور اوپن سورس به زبان روبی هست که گیتلب برای پاسخ به درخواست های http از اون استفاده میکنه. ویژگی بارز پوما این هست که از مالتی ترد استفاده میکنه و توانایی پاسخ به چندین درخواست به شکل همزمان رو داره که این ویژگی پوما رو برای اپلیکیشن‌ها با ترافیک و لود بالا مناسب میکنه.
PUMA
GitLab Workhorse
گیتلب ورک‌هاوس برنامه‌ای هست که اومده تا به پوما کمک کنه و عملکرد و سرعت وب سرور رو بالاتر ببره و برای پاسخ به درخواست هایی که نیاز به پردازش زمانبر دارن و موارد این شکلی، کمک کنه. به صورت کلی مسیر درخواست‌های http داخل گیتلب از این دو تا ماژول عبور میکنه.
gitlab workhorse
Sidekiq
سایدکیک یک پراسسور بک گراند به زبان روبی هست که از صف Redis جاب هاش رو برمیداره و توی بک گراند انجام شون میده. سایدکیک میتونه وظایف پردازشی پس زمینه مثل ارسال ایمیل، پردازش فایل، ایجاد گزارش و مواردی ازین دست رو به صورت موازی و بدون تاثیر بر عملکرد گیتلب انجام بده چون به صورت مستقل از گیتلب اجرا میشه.
sidekiq
توضیح دیزاین گیتلب و نحوه‌ی پیاده‌سازی
gitlab omnibus
گیتلب omnibus یه راه سریع و راحت برای نصب، نگهداری و آپدیت یک اینستنس استاندارد از گیتلب به ما میده. میتونیم آمنی‌باس رو در قالب یک پکیج که شامل تمام کامپوننت های مورد نیاز برای داشتن یه گیتلب هست، دانلود کنیم و به صورت on-premises یا روی کلاد اونو بالا بیاریم.
gitlab omnibus
مزایا:
فایده آمنی‌باس اینه که نیازمندی‌های پکیج رو توی خودش داره و بدون پیچیدگی زیاد میتونیم گیتلب مون رو نصب کنیم.
برای بالا اومدن گیتلب و ران شدنش یه کانفیگ حداقلی نیاز داره.
آپگرید کردن به ورژن‌های بعدی تو این روش خیلی آسونه.
محیط‌های مختلف رو پشتیبانی میکنه و نیازش به پشتیبانی برای مشکلات احتمالی خیلی کم هست.
میزان منابع مورد نیاز:
۴ core CPU , 4 GB RAM , 50 GB Disk
میتونه این نیازمندی سرور، گیتلب یه شرکت کوچیک یا متوسط رو پاسخگو باشه.
۸ core CPU , 8 GB RAM , 100 GB Disk
میتونه تا ۱۰۰۰ تا یوزر رو هندل کنه. البته این عددی هست که خود گیتلب داره بهش اشاره میکنه و شما بهتره که قدری از این بالاتر در نظر بگیرد. نکته‌ی دیگه اینکه میزان استوریج کاملا به نوع استفاده و فایل‌های شما بستگی دارد.
نحوه‌ی پیاده‌سازی:
توضیح کوتاه نصب و کانفیگ گیتلب
برای نصب راحت تر گیتلب روش omnibus و زیرساخت داکر رو پیشنهاد میکنم که میتونید با استفاده از کامپوز فایل اونو خیلی راحت در قالب یه سرویس داکری بالا بیارید و کانفیگ هاش رو بسته به نیازی که دارید انجام بدید.
کانفیگ گیتلب بهتون اجازه میده از url که میخواید قسمت های مختلف سرویس تون با اون بالا بیاد تا تنظیمات وب سرور و موارد مرتبط با احراز هویت کاربران و سرویس ایمیل گیتلب و … رو به شکلی که میخواید تغییر بدید.
گیتلب خیلی ابزار کاملی هست و کانفیگ‌های خیلی خیلی زیادی داره که با وقت گذاشتن میتونید به خوبی با آنها آشنا بشید و ازش استفاده کنید. به صورت کلی تو این مستند بیشتر به مواردیکه مهم‌تر هستند اشاره میکنم.
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
توضیح موارد مهم داخل گیتلب:
gitlab pipeline
Commit
به یک تغییر کد که توی ریپازیتوری ذخیره اش کردیم، کامیت میگیم.
Job
به دستوراتی که یک رانر باید اجرا کنه جاب میگیم.
Pipeline
به یک دسته از از جاب ها که توی استیج های مختلف تقسیم میشن پایپ لاین میگیم.
Stage
استیج یه جورایی یه تقسیم بندی توی پایپ لاین هست، معمولا استیج های build و test و deploy رو داریم و معمولا جاب های درون یک استیج به صورت موازی اجرا میشن اگه رانر کافی داشته باشیم.
Runner
رانر ایجنت یا سروری هست که جاب هارو برای ما انجام میده.
Artifact
به آرشیو فایل‌ها و دایرکتوری‌های خروجی یک جاب که میخوایم اونا رو نگه داریم، آرتیفکت میگیم.
Variables
مواردی توی فایل پایپ‌لاین‌مون که می‌خواهیم متغییر باشن و بتونم اونها رو تغییر بدیم یا به صورت مخفی باشند درون گیت رو با وریبل میذاریم توی فایل مون.
Environment
میتونیم اپلیکیشن رو توی محیط های مختلف عملیاتی مثل stage و product دیپلوی کنیم و انوایرومنت این امکان رو به ما میده که پایپ‌لاین‌مون رو برای محیط های مختلف جدا کنیم.
Cache
میتونیم برای اجرای سریع تر پایپ لاین‌مون مواردی مثل دیپندنسی هارو کش کنیم.
Pipeline trigger
با این گزینه میتونیم تعریف کنیم که چه اتفاقی سیگنال شروع رو به پایپ لاین ما بده، مثلا بگیم که اگه توی یک برنچ خاص از پروژه پوش اتفاق افتاد اون وقت پایپ لاین اجرا بشه.
