معماری GitLab چیست و چگونه عملکرد CI/CD و مخازن را مدیریت می‌کند؟

• ۲۹ آبان ۱۴۰۴
• دسته بندی ها: عمومی

گیت لب (GitLab) یک ابزار محبوب DevOps است که ابزارهای کنترل نسخه، CI/CD و مدیریت پروژه را با هم ترکیب می‌کند. یک پلتفرم end to end که می‌تواند کل چرخه عمر توسعه نرم‌افزار را مدیریت کند و برای سازمان‌هایی که به جای چندین ابزار به یک پلتفرم یکپارچه نیاز دارند، کاملا مناسب است. شرکت‌هایی مانند Agoda، Airbus، CERN، Goldman Sachs و NVIDIA از گیت لب برای پیاده‌سازی‌های CI/CD و DevSecOps خود استفاده می‌کنند.

به طور کلی، Gitlab موارد زیر را ارائه می‌دهد:

• مدیریت مخزن Git – می‌توانید کد خود را مانند Github میزبانی و مدیریت کنید.
• خطوط: CI/CD از کل گردش کار CI/CD با استفاده از پیکربندی‌های ساده yaml پشتیبانی می‌کند.
• ردیابی مشکلات: می‌توانید کار، باگ‌ها و درخواست‌های ویژگی را برنامه‌ریزی و پیگیری کنید.
• بررسی کد: می‌توانید بررسی‌ها را انجام دهید، درخواست‌ها را با گردش‌های کاری تایید ادغام کنید.
• ثبت کانتینر: می‌توانید ایمیج Docker را ذخیره و مدیریت کنید.
• اسکن امنیتی: اگر تست امنیتی داخلی و تشخیص آسیب‌پذیری ارائه می‌دهد. به طور کلی، همه چیز در یک مکان یکپارچه شده است، نه اینکه چندین ابزار جداگانه را مدیریت کند.

معماری GitLab

مطالب زیر معماری GitLab و نحوه تعامل اجزای آن با یکدیگر را شرح می‌دهد. در این بخش نحوه همکاری همه اجزا، همانطور که در نمودار معماری پایین نشان داده شده، آمده است.

• هنگامی که یک کاربر وب به GitLab دسترسی پیدا می‌کند، درخواست HTTP(S) ابتدا به Nginx می‌رود که به عنوان یک پروکسی معکوس عمل می‌کند.
• Nginx درخواست را به GitLab Workhorse هدایت می‌کند، که تصمیم می‌گیرد که آیا خودش آن را مدیریت نماید یا به Puma ارسال کند.
• Puma یک وب سرور است که درخواست‌های حساس به زمان (time-sensitive)، مانند بازیابی داده‌های پروژه، مشکل و کاربر از PostgreSQL یا ذخیره سازی یا اطلاعات جلسه از Redis را مدیریت می‌کند.
• اگر وظایف پس‌زمینه، مانند ارسال اعلان‌ها یا اجرای کارهای CI/CD وجود داشته باشد، Puma آنها را به Sidekiq ارسال می‌کند، که کارها را با استفاده از Redis مدیریت شده و داده‌ها را در PostgreSQL و Gitaly ذخیره و بازیابی می‌کند. Gitaly یک فضای ذخیره‌سازی است که تمام داده‌های مخزن گیت در آن ذخیره می‌شود.
• وقتی کاربران عملیات گیت را انجام می‌دهند، مستقیم از شِل گیت‌لب از طریق SSH به گیتالی دسترسی پیدا می‌کنند.

همه این اجزا باید به درستی با گیت‌لب کار کنند. می‌توانیم در بخش بعدی آنها را بررسی کنیم.

با خرید وی پی اس از پارسدو، می‌توانید از قدرت و پایداری یک ماشین مجازی اختصاصی در ۵ موقعیت جهانی بهره‌مند شوید.

اجزای اصلی گیت‌لب

یکی از نیازهای کلیدی مهندسان DevOps، درک معماری اصلی گیت‌لب است. زیرا نمی‌توانید چیزی را که درک نکرده‌اید، بهینه‌سازی یا اصلاح کنید.
با درک معماری اصلی، می‌توانید عیب‌یابی، مقیاس‌بندی، ارتقاء، ادغام و موارد دیگر را انجام دهید.
گیت‌لب از اجزای زیادی تشکیل شده است. ما هر جزء را تجزیه و تحلیل کرده و توضیح دادیم که هر جزء (کامپوننت) چه کاری انجام می‌دهد. بیایید شروع کنیم.

پروکسی/سرور HTTP

گیت‌لب از وب سرور Nginx به عنوان پروکسی معکوس برای درخواست‌های کاربر استفاده می‌کند. این پروکسی حتی خاتمه SSL/TLS را برای رمزگذاری ترافیک بین کاربر و گیت‌لب مدیریت می‌کند.

رابط کاربری وب / API گیت‌لب

ما می‌توانیم به دو روش با گیت‌لب تعامل داشته باشیم: مستقیم از یک مرورگر وب با استفاده از رابط کاربری (Web UI) و از طریق فراخوانی‌های API، که معمولا برای تعامل برنامه‌ها با آن است.

کنترل‌کننده‌ها / ریلز / پوما

هسته گیت‌لب بر اساس چارچوب برنامه وب Ruby on Rails ساخته شده است.
وقتی عملی را در گیت‌لب انجام می‌دهید، چندین مولفه در بک‌اند با هم کار می‌کنند تا درخواست‌ها را مدیریت کنند.
با Puma شروع می‌شود که یک وب سرور گیت‌لب است که به درخواست‌های HTTP گوش می‌دهد. درخواست‌ها را به برنامه Rails ارسال می‌کند.

Rails از الگوی Model-View-Controller (MVC) پیروی می‌کند. وقتی Puma درخواست را به Rails ارسال می‌کند، به کنترلر مناسب مسیردهی می‌کند تا بگوید چه عملی باید انجام شود.

GitLab Workhorse

Workhorse یک پروکسی معکوس است که در مقابل Puma قرار می‌گیرد.
درخواست‌های HTTP کند و بزرگ (مثلا آپلود/دانلودهای بزرگ) را مدیریت می‌کند. پس از انتخاب درخواست‌های بزرگتر، درخواست‌های حساس به زمان باقی‌مانده را به Puma ارسال می‌کند.

شِل GitLab

ما می‌توانیم از طریق پروتکل SSH به شِل GitLab دسترسی پیدا کنیم تا کد را دانلود کرده و تغییرات را از محلی به ریموت آپلود کنیم.
ما از روش‌های احراز هویت استاندارد برای انجام ایمن این عملیات Git در GitLab استفاده می‌کنیم.
ذخیره‌سازی و دسترسی به Git در GitLab توسط Gitaly انجام می‌شود.

Gitaly

ذخیره‌سازی GitLab برای کدی که ذخیره می‌کنیم توسط سرویسی به نام Gitaly مدیریت می‌شود.
درخواست‌ها از Rails و Shell برای عملیات Git مانند push، commit، MR و غیره می‌آیند. این اجزا از طریق پروتکل gRPC با Gitaly ارتباط برقرار می‌کنند.

Sidekiq

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

Redis

سرور Redis یک حافظه داخلی GitLab است که داده‌های موقت را برای عملیات کلیدی زیر ذخیره می‌کند.

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

تمام داده‌های طولانی مدت در پایگاه داده PostgreSQL ذخیره می‌شوند.

PostgreSQL

PostgreSQL یک پایگاه داده رابطه‌ای است که داده‌های طولانی‌مدت مانند اطلاعات حساب کاربری، اطلاعات پروژه، مجوزها، مشکلات و MR، فراداده‌های خط لوله، متادیتای رجیستری و غیره را ذخیره می‌کند.

مخزن خالی GitLab

در Gitlab، هر پروژه یک مخزن خالی در سمت سرور دارد. این نوع خاصی از مخزن Git است که دایرکتوری کاری ندارد.
معمولا در یک مخزن محلی Git، دایرکتوری .git تمام کامیت‌ها، شاخه‌ها، برچسب‌ها و تاریخچه داده‌ها را ذخیره می‌کند.
در GitLab، فقط این داده‌های .git در سرور ذخیره می‌شوند. این چیزی است که مخزن خالی (bare repository) را تشکیل می‌دهد. این مخزن معمولا برای همگام‌سازی (synchronization) وجود دارد.

به طور خلاصه، مخزن خالی در GitLab معمولا  برای پیاده‌سازی قابلیت‌های اصلی Git (git push، git pull و غیره) وجود دارد.

همچنین، تمام اجزای GitLab، مانند GitLab Rails، GitLab Shell و Gitaly، برای مدیریت این عملیات Git، چه از طریق HTTP و چه از طریق SSH، با هم کار می‌کنند.

ذخیره‌سازی و پایداری داده‌ها در GitLab

اجزای ذخیره‌سازی GitLab را به صورت جداگانه بررسی کردیم.به طور کلی، نحوه عملکرد ذخیره‌سازی در Gitlab به این صورت است.

1. تمام اطلاعات مخزن گیت لب در bare repository (مانند یک پایگاه داده از مخازن) ذخیره و داده‌ها توسط سرور Gitaly در فایل سیستم ذخیره می‌شوند.
2. تمام متادیتا (کاربران، پروژه‌ها، مشکلات، ساخت‌های CI/CD، برچسب‌ها و غیره) GitLab در پایگاه داده PostgreSQL ذخیره می‌شوند.
3. GitLab از یک کش چند لایه با استفاده از Redis، In-memory و HTTP برای پاسخ سریع استفاده می‌کند که برای صف‌های کاری هم استفاده می‌شود.

مقیاس‌پذیری و دسترسی‌پذیری بالای GitLab

هنگام پیاده‌سازی Gitlab در پروژه‌های DevOps، مقیاس‌پذیری و دسترسی‌پذیری به بخش کلیدی تبدیل می‌شود وقتی پروژه‌ها رشد می‌کنند. به عنوان مثال، اگر یک تیم پلتفرم مرکزی GitLab را به عنوان یک سرویس ارائه دهد، بسیاری از تیم‌ها ممکن است به همان نمونه GitLab متصل شوند.
در چنین مواردی، نیازی نیست کل سیستم گیت لب را به طور همزمان مقیاس‌بندی کنید. در عوض، می‌توانید اجزای جداگانه را بر اساس حجم کار و الزامات مقیاس‌بندی کنید.

به عنوان مثال، PostgreSQL، Redis و Gitaly اجزای stateful هستند و این اجزا عملیات سنگین I/O و پس‌زمینه را مدیریت می‌کنند. بنابراین به جای اجرای آنها به صورت تکی، می‌توانید آنها را در یک کلاستر مستقر کنید.
نسخه‌های کپی(replicas ) در کلاسترها باید چندین زون را برای دسترسی بالا پوشش دهند. همچنین، بکاپ‌گیری‌های دوره‌ای در سناریوهای بازیابی فاجعه (disaster recovery) کمک خواهند کرد.

احراز هویت GitLab

GitLab به طور پیشفرض، ورود استاندارد با استفاده از نام کاربری و رمز عبور را ارائه می‌دهد. علاوه بر این، می‌توانید احراز هویت دو عاملی را برای بهبود امنیت فعال کنید.

برای تنظیمات سازمانی، می‌توانید از ارائه‌دهندگان احراز هویت خارجی مانند LDAP، SAML یا OAuth2 برای احراز هویت کاربر استفاده کنید.
برای دسترسی ایمن به شِل GitLab برای عملیات Git، می‌توانیم از روش Secure Shell (SSH) استفاده کنیم.
برای احراز هویت مبتنی بر API، می‌توانید از توکن‌های دسترسی شخصی (PAT) یا توکن‌های حامل استفاده کنید.

مجوز GitLab

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

• Guest (فقط مشاهده)
• Reporter (خواندن همه و مدیریت مشکلات)
• Developer (خواندن و نوشتن)
• Maintainer (مدیر پروژه – تقریبا کنترل کامل)
• Owner (کنترل کامل)

مانیتور گیت لب با Prometheus و Grafana

یک نمونه گیت لب خود میزبان (Self-hosted) را می‌توان با استفاده از Prometheus و Grafana مانیتور کرد. ما می‌توانیم تمام عملکرد، سلامت سیستم و مشکلات را با استفاده از معیارهای داخلی آن ردیابی کنیم و آنها را در داشبوردها تجسم کنیم.
گیت‌لب همچنین لاگ‌های مربوط به تمام اجزای خود را در یک مکان مرکزی در /var/log/gitlab/ ذخیره می‌کند. می‌توانید از جمع‌آوری‌کننده‌های لاگ مانند Fluent Bit برای جمع‌آوری این لاگ‌ها و ارسال آنها به یک سیستم مرکزی ثبت لاگ یا مانیتورینگ برای تجزیه و تحلیل بیشتر استفاده کنید.

جمع‌بندی

در این مطلب، به معماری GitLab و نحوه تعامل تمام اجزای کلیدی در پشت صحنه نگاهی انداختیم.
همچنین در مورد موضوعات مهمی مانند ذخیره‌سازی، مقیاس‌پذیری، احراز هویت و مجوز که در محیط‌های سازمانی بسیار مهم هستند، بحث کردیم.