توی این پست میریم سراغ مقدمات گیتلب و سعی میکنم با مفاهیم مختلفش آشنا بشیم.
خب یه مروری کنیم پست‌های قبلی رو:
توصیه میکنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.
توضیح مقدمه‌ی گیتلب:
گیتلب یه ابزار جامع و کامله که کل چرخه‌ی دواپس رو میتونه پوشش بده. به خوبی میتونیم باهاش تمام کارهایی که لازم است در این چرخه انجام بدیم رو برنامه‌ریزی کنیم و تا انتهای پیاده‌سازی و گرفتن فیدبک برامون راهکار داره و میتونه کمک کنه. گیتلب برای استقرار CI/CD که تو پست‌های قبلی در موردش صحبت کردیم، نیاز به هیچ ابزار دیگری نداره و تنها با ایجاد یه فایل gitlab-ci.yml. میتونه تمام مسیر رو پیش بره و انجام بده.
توضیح Workflow گیتلب:
تو تصویر فوق شما Workflow گیت رو مشاهده میکنید. همان‌طور که تو این تصویر هم مشخص هست میتونیم به گونه‌ای تنظیم کنیم که به ازای هر پوش یا مرج‌ریکوئست فرآیند‌های مربوط به CI که شامل بیلد و تست میشه اجرا بشه و اگر همه چی خوب پیش رفت در ادامه دیپلوی تو استیج و پروداکشن رو پیش ببریم که این مسیر کاملا در اختیار ما است و میتونیم هر جایی از آن رو که دوست داشتیم تغییر بدیم و مطابق نیازمندی سیستم و سرویس آن را پیش ببریم.
توضیح کامپوننت‌های گیتلب:
گیتالی سرویسی هست که توسط گیتلب طراحی شده تا نیاز به استورج یا NFS رو توی پیاده‌سازی‌های توزیع شده گیتلب حذف کنه. بنابراین گیتلب برای خوندن و نوشتن دیتا از گیتالی استفاده میکنه. بسته به طراحی و نیاز ممکنه حتی گیتالی رو به عنوان یه بک گراند سرویس روی سرور جداگانه نصب کنیم و حتی در صورت نیاز اونو کلاستر کنیم.
کامپوننتی که خود گیتلب طراحی کرده که برای استخراج متریک‌های گیتلب و دادن اون دیتا به پرومتئوس ازش استفاده می‌کنیم. اگه آشنا نیستید در آینده بهش میرسیم اما پرومتئوس ابزاری برای مانیتورینگ و موارد این شکلی هست که به کمک اون و اکسپورتری که توی گیتلب داره میتونیم هر لحظه بفهمیم که توی سیستم‌مون چه خبره.
گیتلب ایجنت یه کامپوننت مخصوص کلاستر هست که برای حل کردن سازگاری گیتلب با کوبرنتیز بهمون کمک میکنه تا دیپلوی‌منت هامون رو با کلاستر کوبر سینک کنیم.
گیتلب پیجز قابلیتی هست که بهمون کمک میکنه تا سایت‌های استاتیک رو به صورت مستقیم از ریپازیتوری منتشر کنیم. میتونیم ازش برای موارد شخصی یا موارد بیزینسی مثل پورتفولیو، پرزنتیشن‌ها، داکیومنت‌ها و … استفاده کنیم. قسمت داکیومنت‌های گیتلب خودش روی همین pages هست و به صورت as code نگهداری و پایش می‌شود.
کارهای مختلف توی CI/CD رو بهشون میگیم جاب. گیتلب رانر کامپوننتی هست که جاب ها رو انجام میده و نتیجه اونها رو برای گیتلب میفرسته. به عبارت دیگه گیتلب تسک‌هایی که باید تحت عنوان Job انجام بده رو داخل این رانرها انجام می‌دهد.
گیتلب شل برنامه ای هست که طراحی شده برای هندل کردن سشن های SSH که به گیتلب میزنیم. دقت کنید که گیتلب شل یک شل یونیکس نیست و نمی‌تونه جایگزینی برای Bash یا Zsh باشه. متداول است که برای کار با گیت از همین روش و ماژول استفاده می‌کنیم.
پوما یک وب سرور اوپن سورس به زبان روبی هست که گیتلب برای پاسخ به درخواست های http از اون استفاده میکنه. ویژگی بارز پوما این هست که از مالتی ترد استفاده میکنه و توانایی پاسخ به چندین درخواست به شکل همزمان رو داره که این ویژگی پوما رو برای اپلیکیشن‌ها با ترافیک و لود بالا مناسب میکنه.
گیتلب ورک‌هاوس برنامه‌ای هست که اومده تا به پوما کمک کنه و عملکرد و سرعت وب سرور رو بالاتر ببره و برای پاسخ به درخواست هایی که نیاز به پردازش زمانبر دارن و موارد این شکلی، کمک کنه. به صورت کلی مسیر درخواست‌های http داخل گیتلب از این دو تا ماژول عبور میکنه.
سایدکیک یک پراسسور بک گراند به زبان روبی هست که از صف Redis جاب هاش رو برمیداره و توی بک گراند انجام شون میده. سایدکیک میتونه وظایف پردازشی پس زمینه مثل ارسال ایمیل، پردازش فایل، ایجاد گزارش و مواردی ازین دست رو به صورت موازی و بدون تاثیر بر عملکرد گیتلب انجام بده چون به صورت مستقل از گیتلب اجرا میشه.
توضیح دیزاین گیتلب و نحوه‌ی پیاده‌سازی
گیتلب 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 کنیم. این موضوع خیلی میتونه بهمون کمک کنه که فایل بکاپ ما شامل چه مواردی باشه و به عبارت دیگه از چیزهایی که می‌خواهیم بکاپ بگیرم.
گیتلب از 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 و استفاده از داکر این هست که شما فقط عدد ایمیج کامپوز فایلتون رو ادیت میکنید 🙂
توضیح موارد مهم داخل گیتلب:
به یک تغییر کد که توی ریپازیتوری ذخیره اش کردیم، کامیت میگیم.
به دستوراتی که یک رانر باید اجرا کنه جاب میگیم.
به یک دسته از از جاب ها که توی استیج های مختلف تقسیم میشن پایپ لاین میگیم.
استیج یه جورایی یه تقسیم بندی توی پایپ لاین هست، معمولا استیج های build و test و deploy رو داریم و معمولا جاب های درون یک استیج به صورت موازی اجرا میشن اگه رانر کافی داشته باشیم.
رانر ایجنت یا سروری هست که جاب هارو برای ما انجام میده.
به آرشیو فایل‌ها و دایرکتوری‌های خروجی یک جاب که میخوایم اونا رو نگه داریم، آرتیفکت میگیم.
مواردی توی فایل پایپ‌لاین‌مون که می‌خواهیم متغییر باشن و بتونم اونها رو تغییر بدیم یا به صورت مخفی باشند درون گیت رو با وریبل میذاریم توی فایل مون.
میتونیم اپلیکیشن رو توی محیط های مختلف عملیاتی مثل stage و product دیپلوی کنیم و انوایرومنت این امکان رو به ما میده که پایپ‌لاین‌مون رو برای محیط های مختلف جدا کنیم.
میتونیم برای اجرای سریع تر پایپ لاین‌مون مواردی مثل دیپندنسی هارو کش کنیم.
با این گزینه میتونیم تعریف کنیم که چه اتفاقی سیگنال شروع رو به پایپ لاین ما بده، مثلا بگیم که اگه توی یک برنچ خاص از پروژه پوش اتفاق افتاد اون وقت پایپ لاین اجرا بشه.
توی قسمت‌های بعدی مسیر دواپس‌مون رو ادامه میدیم و بیشتر گیتلب و انواع پایپ‌لاین های اون رو با هم بررسی می‌کنیم.
مراقب خودتون باشید. 🌹🐳🌹
خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.
🫀 Follow DockerMe 🫀
🔔 Follow YouTube 🔔
📣 Follow Instagram 📣
🖇 Follow LinkedIn DockerMe🖇
🔎 Follow Linkedin Ahmad Rafiee 🔎
🕊 Follow Twitter 🕊
