آموزش جامع راه اندازی GitLab روی VPS؛ از تخصیص منابع تا استقرار حرفه‌ای (Self-Host)

راه اندازی GitLab روی VPS نیازمند شناخت دقیق منابع سخت‌افزاری و معماری نرم‌افزاری است. برای مدیران زیرساخت و تیم‌های فنی، چالش اصلی پیش از نصب سیستم آغاز می‌شود؛ یعنی جایی که تخصیص دقیق CPU، میزان RAM، فضای ذخیره‌سازی و معماری گیت‌لب رانر (GitLab Runner) باید بهینه‌سازی شود. در این مقاله تخصصی، مسیر صفر تا صد انتخاب منابع، نصب و کانفیگ اولیه، پیکربندی گواهی امنیتی (SSL)، پیاده‌سازی CI/CD و استراتژی‌های بک‌آپ‌گیری را بررسی می‌کنیم تا استقرار سیستم شما با بالاترین پرفورمنس و پایداری انجام شود.

گیت‌لب سلف‌هاست (Self-Managed) چیست و چرا باید آن را روی VPS راه‌اندازی کنیم؟

سیستم GitLab Self-Hosted (که در مستندات رسمی با نام Self-Managed شناخته می‌شود) به‌معنای استقرار و اجرای این پلتفرم روی زیرساختی است که کنترل صددرصدی شبکه، سیستم‌عامل و منابع آن منحصراً در اختیار سازمان شما قرار دارد. خرید VPS یکی از روش‌های استاندارد برای پیاده‌سازی معماری تک‌گره (single-node) است.

بسیاری از تیم‌های فنی گیت‌لب اختصاصی را برای حفظ محرمانگی کدها انتخاب می‌کنند؛ اما باید توجه داشت که سلف‌هاست به‌خودی‌خود مساوی با امنیت بیشتر نیست. امنیت پایدار به نگهداری مستمر، به‌روزرسانی‌های امنیتی (Patching)، کنترل دسترسی (Access Control)، بک‌آپ‌گیری و مقاوم‌سازی سرور (Hardening) وابسته است. با این حال، سرور مجازی برای GitLab محیطی فراهم می‌کند که هیچ شخص ثالثی به سورس‌کدهای تجاری شما دسترسی نداشته باشد.

گیت‌لب (GitLab) چیست و چه کاربردی در توسعه نرم‌افزار دارد؟

پلتفرم GitLab یک سیستم یکپارچه مدیریت سورس‌کد (Source Code Management) و DevSecOps مبتنی بر هسته گیت (Git) است که قابلیت‌هایی مثل میزبانی امن مخازن کد (Repositories)، بررسی و تایید درخواست‌های ادغام (Merge Requests) و ابزارهای پیشرفته CI/CD را در یک محیط واحد و متمرکز ارائه می‌دهد.

کاربردهای کلیدی این ابزار برای تیم‌های توسعه شامل موارد زیر است:

• مدیریت سورس‌کد: میزبانی امن مخازن گیت برای پروژه‌های تجاری و سازمانی؛
• همکاری تیمی یکپارچه: تسریع فرایند بررسی کد (Code Review) و مدیریت متمرکز فرایندهای ادغام.
• اتوماسیون زیرساخت: اجرای پایپ‌لاین‌ها (Pipelines) برای پیاده‌سازی یکپارچه‌سازی و استقرار مداوم (Continuous Integration/Continuous Deployment)؛
• مدیریت پروژه: پیگیری وظایف، باگ‌ها و زمان‌بندی چرخه‌های توسعه در کنار کدها.

نکته مهم: توجه کنید که سیستم کنترل نسخه گیت (Git) فقط یک ابزار خط فرمان است، اما گیت‌لب (GitLab Server) پلتفرمی است که تمام نیازهای چرخه حیات نرم‌افزار را پوشش می‌دهد.

مقایسه گیت‌لب کلاود (Cloud) و سلف‌هاست (Self-Managed)؛ کدام معماری مناسب شماست؟

تفاوت اصلی در سطح دسترسی به سرور و محل ذخیره‌سازی داده‌ها است. نسخه Cloud مدیریتی از سمت شما نیاز ندارد، اما نسخه سلف‌هاست کنترل کامل را به شما می‌دهد. جدول زیر به درک بیشتر این تفاوت‌ها کمک می‌کند:

نکته کلیدی در محاسبه هزینه‌ها: علاوه‌بر موارد بالا، هنگام تصمیم‌گیری برای انتخاب مدل سلف‌هاست، باید «هزینه‌های پنهان» (Hidden Costs) را نیز در نظر بگیرید؛ مواردی مثل:

• حقوق متخصص دواپس (DevOps)؛
• تامین زیرساخت پشتیبان‌گیری (Backup)؛
• زمان اختصاص‌یافته برای ارتقای سیستم (Upgrade)؛
• راه‌اندازی سیستم‌های مانیتورینگ.

چرا گیت‌لب را روی سرور مجازی نصب کنیم؟ (مزایای نصب GitLab روی VPS)

مهم‌ترین مزیت نصب GitLab روی سرور لینوکس، کنترل روی فضای ذخیره‌سازی مخازن (Repository Storage) و دسترسی کاربران است.

مزایای عملیاتی این روش به شرح زیر است:

• امنیت شبکه: امکان اعمال سیاست‌های شبکه (Network Policies) داخلی و مسدودسازی کامل دسترسی از آدرس‌های IP ناشناس یا خارج از سازمان؛
• بهینه‌سازی عملکرد: نصب و کانفیگ گیت‌لب رانر (GitLab Runner) اختصاصی، برای اجرای بسیار سریع‌تر بیلدها (Builds)؛
• حذف محدودیت‌ها: اجرای پایپ‌لاین‌های اختصاصی (Custom Pipelines) بدون نگرانی از اتمام محدودیت دقایق رایگان در نسخه‌های ابری.
• پشتیبان‌گیری منعطف: کنترل کامل روی استراتژی و زمان‌بندی بک‌آپ‌گیری متناسب با سیاست‌های حفظ داده (Data Retention) در شرکت؛
• استقلال زیرساختی: کاهش وابستگی به ارائه‌دهندگان سرویس‌های ابری (SaaS) و مصونیت در برابر تحریم‌های بین‌المللی یا قطعی‌های پیش‌بینی‌نشده.

استفاده از سرور مناسب GitLab امکان اعمال کنترل امنیتی بیشتر را فراهم می‌کند؛ مشروط بر اینکه پیکربندی سیستم‌عامل به‌درستی انجام شده باشد.

چه سازمان‌هایی به معماری سلف‌هاست (GitLab Self-Managed) نیاز دارند؟

گروه‌هایی که امنیت کدها یا سفارشی‌سازی زیرساخت برایشان حیاتی است، مخاطب اصلی این معماری هستند:

• تیم‌های توسعه فعال: نیازمند به محیطی بدون محدودیت برای اجرای CI/CD؛
• شرکت‌های نرم‌افزاری: برای متمرکزسازی ابزارهای DevOps روی یک سرور واحد؛
• سازمان‌های حساس: نهادهای مالی که قوانین اجازه خروج داده از شبکه داخلی را به آن‌ها نمی‌دهد؛
• مهندسان زیرساخت: تیم‌هایی که قصد یکپارچه‌سازی ابزارها را با Active Directory سازمانی دارند.

در مقابل، یک تیم بسیار کوچک بدون دانش مدیریت Linux Server که صرفاً نیازمند میزبانی Git Repository است، بهتر است از پلتفرم‌های SaaS استفاده کند.

انتخاب VPS مناسب برای GitLab؛ به چه منابعی نیاز داریم؟

پیش از آغاز فرایند نصب، تامین یک زیرساخت قدرتمند با سطح دسترسی کامل (Root Access) الزامی است. پیاده‌سازی یک معماری سلف‌منج (Self-Managed) واقعی، نیازمند کنترل کامل روی سیستم‌عامل و استفاده از منابع پردازشی قابل‌ارتقا است. در چنین شرایطی، خرید vps با کانفیگ سخت‌افزاری اختصاصی، تنها مسیر اصولی و امن برای تیم‌های مهندسی محسوب می‌شود.

در سمت دیگر، باید توجه داشت که استفاده از فضاهای اشتراکی به‌هیچ‌عنوان برای این پلتفرم مناسب نیست. اگر نیاز سازمان شما صرفاً میزبانی یک وب‌سایت یا اپلیکیشن معمولی است، خرید هاست لینوکس می‌تواند گزینه منطقی باشد؛ اما معماری پردازشی سنگین GitLab Server قطعاً به VPS یا Server با دسترسی ادمین نیاز دارد.

معیارهای تخصصی برای تخمین منابع (Sizing)

فرایند Sizing صرفاً براساس تعداد دولوپرها انجام نمی‌شود. فاکتورهای حیاتی دیگری به‌طور مستقیم روی مصرف سخت‌افزار شما اثر می‌گذارند؛ از جمله:

• حجم مخازن کد (Repository Size) و فایل‌های حجیم (LFS)؛
• فرکانس ارسال و دریافت کد (Push/Pull Frequency)؛
• ترافیک وب و API؛
• سنگینی وظایف پایپ‌لاین (Pipeline) و حجم رجیستری (Registry)؛
• تعداد سرویس‌های گیت‌لب رانر (GitLab Runner) متصل به سرور.

حداقل منابع سخت‌افزاری مورد نیاز برای نصب GitLab روی VPSS

بر اساس مستندات رسمی، مقدار منابع پایه و توصیه‌شده برای پیاده‌سازی نسخه تک‌گره (Single-Node) در مقیاس استاندارد، برابر با ۸ هسته پردازنده مجازی (vCPU) و ۱۶ گیگابایت حافظه موقت (RAM) تعیین شده است. جدول زیر جزئیات حداقل منابع مورد نیاز گیت‌لب روی سرور مجازی را نمایش می‌دهد:

طبق جدول، مقدار baseline رسمی عمومی برای محیط تک‌نودی ۸ vCPU و 16GB RAM است. در واقع، راه‌اندازی با 8GB رم صرفاً برای نصب‌های محدود و تست شخصی است و نیازمند بهینه‌سازی (tuning) شدید است؛ این کانفیگ هرگز گزینه پایداری برای یک تیم فنی محسوب نمی‌شود.

چرا استفاده از درایوهای SSD و NVMe برای سرور GitLab مهم است؟

سرویس Gitaly و عملیات Git operations به‌شدت به فرایندهای خواندن و نوشتن تصادفی  (random I/O) و پردازش هزاران فایل کوچک متکی هستند؛ به همین دلیل تاخیر شبکه و IOPS دیسک مستقیماً روی سرعت کلون کردن (Clone)، عملیات دریافت (Fetch)، ارسال (Push) و پاسخ‌گویی کلی پلتفرم (Responsiveness) تاثیر می‌گذارند.

علاوه‌براین، سرعت I/O نقش حیاتی روی عملکرد دیتابیس PostgreSQL، استخراج فایل‌های خروجی (Artifacts) و اجرای سریع وظایف پایپ‌لاین (Pipeline Workloads) ایفا می‌کند. مستندات رسمی صراحتاً استفاده از SSD را برای کامپوننت Gitaly قویاً توصیه می‌کند و این بخش را کاملاً I/O intensive می‌داند. در نتیجه، برای تضمین بالاترین سرعت و جلوگیری از افت پرفورمنس در محیط‌های عملیاتی، استفاده از سرورهای مجهز به درایو NVMe یک ضرورت است.

سرور مجازی (VPS) یا سرور اختصاصی؛ کدام زیرساخت برای GitLab بهتر است؟

تصمیم‌گیری بین سرور مجازی برای GitLab و سرور اختصاصی، به بودجه و شدت پردازش‌های CI/CD شرکت شما بستگی دارد. به جدول زیر دقت کنید:

همان‌طور که در جدول مشخص است، استفاده از سرورهای مجازی (VPS) با منابع تضمین‌شده، گزینه‌ای مقرون‌به‌صرفه برای تیم‌های کوچک تا متوسط محسوب می‌شود؛ اما تهیه یک سرور اختصاصی زمانی ارزش استراتژیک پیدا می‌کند که پلتفرم شما نیازمند پردازش بدون‌افت و مستمر پردازنده (Sustained CPU)، عملیات خواندن/نوشتن (I/O) سنگین روی دیتابیس، میزبانی از مخازن (Repositories) بسیار حجیم، یا پردازش همزمان ده‌ها سرویس گیت‌لب رانر باشد.

هنگام خرید VPS برای GitLab به چه نکاتی توجه کنیم؟

برای داشتن یک سرور مناسب GitLab که در آینده دچار افت کیفیت نشود، موارد زیر را هنگام تهیه سرویس بررسی کنید:

• ارائه هسته‌های پردازشی اختصاصی (Dedicated/Guaranteed vCPU) برای جلوگیری از افت فرکانس در پردازش‌های سنگین؛
• قابلیت ارتقای سریع ظرفیت
• استفاده از هارد NVMe یا SSD سازمانی با شاخص IOPS مناسب؛
• دسترسی مستقیم و کامل Root Access؛
• پشتیبانی از سیستم‌های اسنپ‌شات (Snapshot) و بک‌آپ‌گیری یکپارچه در سطح دیتاسنتر؛
• امکان افزایش حجم Disk بدون نیاز به مهاجرت پیچیده؛
• تخصیص IP ثابت و معتبر برای ارتباطات API؛
• انتخاب دیتاسنتر نزدیک به تیم توسعه جهت کاهش پینگ؛
• امکان نصب نسخه‌های پایدار اوبونتو نظیر Ubuntu04 یا ۲۲.۰۴؛
• پهنای باند بالا برای فرایندهای مداوم Clone و دریافت Artifacts؛
• قابلیت ایجاد ماشین‌های جانبی ارزان برای استقرار سرویس‌های GitLab Runner.

تفاوت vCPU اشتراکی و منابع تضمین‌شده: کدام برای GitLab مناسب‌تر است؟

یکی از تفاوت‌های اساسی در انتخاب سرور مجازی لینوکس برای تیم‌های توسعه، نوع تخصیص پردازنده است. رفتار GitLab workload به هیچ عنوان یکنواخت نیست؛ فرایند Push، عملیات فشرده‌سازی سیستم Backup، اجرای Sidekiq jobs و تریگر شدن همزمان چندین pipeline می‌توانند پردازنده را دچار burst شدید کنند.

شرکت سازنده در بخش پیش‌نیازهای مستندات رسمی خود، استفاده از burstable instance types (پردازنده‌های اشتراکی) را به دلیل ایجاد performance کاملاً غیرقابل‌پیش‌بینی توصیه نمی‌کند. پس هنگام بررسی سرویس‌ها فقط عدد ۸ Core را نبینید؛ چون ممکن است اشتراکی باشند؛ بلکه روی اختصاصی بودن منابع پافشاری کنید.

چگونه فضای ذخیره‌سازی (Storage) سرور گیت‌لب را پیش از خرید VPS محاسبه کنیم؟

محاسبه حجم ذخیره‌سازی، از چالش‌های اساسی مهندسان دواپس است. فرمول زیر به عنوان یک راه‌حل عملیاتی پیشنهادی برای تخمین فضا (و نه فرمول رسمی) پیشنهاد می‌شود:

• Storage مورد نیاز ≈ داده فعلی × (۱ + رشد پیش بینی شده) × ۱.۲۵

منظور از «حجم داده‌های فعلی» در این سناریو، مجموع فضای اشغال‌شده توسط موارد زیر است:

• مخازن سورس‌کد (Repositories)؛
• فایل‌های حجیم گیت (Git LFS)؛
• فایل‌های خروجی بیلدها (Artifacts)؛
• مخزن تصاویر داکر (Container Registry)؛
• انواع فایل‌های رسانه‌ای و آپلودی (Uploads)؛
• جداول پایگاه داده (Database) و فایل‌های لاگ (Logs).

اگر Backup روی همان سرور نگهداری می‌شود، حجم retention بکاپ باید اضافه شود؛ اما در صورت انتقال بک‌آپ‌ها به یک فضای ذخیره‌سازی ابری و خارجی، فقط لحاظ کردن یک فضای موقت (Temporary Headroom) روی سرور اصلی برای اجرای فرایند فشرده‌سازی کافی است.

یک مثال کاربردی:

• 80GB داده فعلی × ۱.۵ برای رشد ۵۰ درصدی × ۱.۲۵ جهت لحاظ ۲۵ درصد فضای آزاد ≈ ۱۵۰

در این سناریو، تهیه دیسک با حجم حدود ۱۶۰ تا 200GB NVMe تصمیمی منطقی است. برای محیط‌های توزیع‌شده، استفاده از Object Storage الزامی و برای سایر installationها شدیداً توصیه می‌شود.

آموزش راه‌اندازی GitLab روی VPS لینوکس از صفر تا اجرا

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

آماده‌سازی VPS و نصب پیش‌نیازهای GitLab

آماده‌سازی سیستم عامل بیس، قدم اول راه‌اندازی GitLab روی VPS است. برای شروع، سیستم‌عامل Ubuntu Server 24.04 یا ۲۲.۰۴ را نصب کنید.

موارد زیر باید پیش از نصب چک شوند:

• تخصیص یک DNS/FQDN معتبر مانند example.com؛
• اتصال به سرور از طریق SSH و اجرای دستور آپدیت Package index؛
• بررسی و فعال‌سازی Firewall و باز کردن پورت‌های ضروری؛
• نظارت نهایی بر وضعیت CPU/RAM/Disk برای تطابق با معماری.

پورت‌های حیاتی سیستم شامل پورت ۲۲ برای SSH، پورت ۸۰ برای HTTP و Let’s Encrypt validation و پورت ۴۴۳ برای HTTPS است. راهنمای رسمی Ubuntu دقیقاً همین سه پورت را معرفی می‌کند.

نصب GitLab با Omnibus Package

نصب سیستم با روش Omnibus Package که با نام Linux package نیز شناخته می‌شود، ساده‌ترین و پایدارترین راهکار برای نصب روی یک VPS مستقل است.

مراحل اجرایی شامل موارد زیر است:

• اضافه کردن Repository رسمی مخازن به لینوکس؛
• انتخاب و نصب نسخه متن‌باز (CE) یا تجاری (EE)؛
• مشخص کردن آدرس دقیق دامنه در متغیر EXTERNAL_URL؛
• اجرای دستور نصب package از مخزن؛
• راه‌اندازی کامپوننت‌ها با اجرای دستور gitlab-ctl reconfigure؛
• بررسی سلامت سرویس‌ها با کامند gitlab-ctl status.

پس از اتمام پروسه، باید با یوزر root لاگین کنید. فایل حاوی رمز عبور در مسیر /etc/gitlab/initial_root_password قرار دارد. تغییر فوری Password و مقداردهی Admin Email الزامی است؛ زیرا این فایل پس از ۲۴ ساعت به‌صورت خودکار پاک می‌شود.

تنظیم Domain و SSL برای GitLab

برای استفاده از پلتفرم در یک محیط production حتماً باید ترافیک شبکه را روی یک Domain واقعی و از طریق HTTPS رمزنگاری کنید.

ابتدا از ست شدن A/AAAA record دامنه روی IP سرور اطمینان حاصل کنید. سپس فایل تنظیمات را باز کرده و external_url را با آدرس دامنه (با پیشوند https) آپدیت کنید. سیستم برای برقراری ارتباط امن به یک SSL Certificate معتبر نیازمند است. اگر external_url شما روی https تنظیم شده و گواهینامه دستی معرفی نکرده باشید، ساختار Linux package می‌تواند گواهینامه رایگان Let’s Encrypt را فعال کند. برای این کار باز بودن پورت‌های ۸۰ و ۴۴۳ ضروری است تا HTTPS Redirect و validation به درستی عمل کنند.

نصب GitLab با Docker؛ چه زمانی مناسب است؟

نصب گیت‌لب (GitLab) با استفاده از داکر، گزینه‌ای ایدیال برای تیم‌هایی است که به اصول استقرار (Deployment) و ماندگاری داده‌های کانتینری (Persistence) تسلط دارند و می‌خواهند تنظیمات و داده‌های خود را کاملاً از طریق Volumeها مدیریت کنند.

مزایای این روش:

• استقرار تکرارپذیر (Reproducible Deployment)
• جابه‌جایی و انتقال بسیار ساده‌تر سرورها
• تفکیک دقیق اطلاعات روی Volumeهای مشخص
• اجرا و مدیریت بی‌دردسر با کمک Docker Compose

چالش‌ها و محدودیت‌ها:

• پیچیدگی مدیریت Volumeها در سیستم‌های بکاپ‌گیری
• چالش‌های مربوط به شبکه‌سازی (Networking)
• دشواری‌های برنامه‌ریزی برای ارتقا (Upgrade Planning)
• تحمیل بار پردازشی اضافه به منابع سرور (Resource Overhead)

راه‌اندازی GitLab Runner و CI/CD

سرویس GitLab Runner یک اپلیکیشن کاملاً مجزا است که وظیفه دریافت و اجرای Jobهای تعریف‌شده در فایل‌های Pipeline را برعهده دارد. در واقع، تمام فرایندهای ساخت (Build)، تست کدها و مراحل استقرار (Deployment) مستقیماً روی سرور Runner انجام می‌شوند.

نکات کلیدی در استقرار و پیکربندی:

• شما می‌توانید Runnerها را بسته به نیاز، در سطح یک پروژه خاص (Project)، یک گروه (Group) یا به‌صورت سراسری در کل سیستم (Instance Runner) فعال کنید.
• در زمان کانفیگ، انتخاب نوع اجراکننده (Executor) بسیار حائز اهمیت است؛ در این میان، مدل Docker executor بالاترین کاربرد و انعطاف‌پذیری را در محیط‌های عملیاتی دارد.
• تنظیم میزان هم‌زمانی پایپ‌لاین‌ها (Pipeline concurrency)، نظارت دقیق بر میزان مصرف منابع (CPU و RAM) و تامین امنیت توکن‌های احراز هویت، از مهم‌ترین وظایف ادمین شبکه و زیرساخت است.

توجه کنید که workflow جدید احراز هویت با Runner Authentication Token (دارای پیشوند -glrt) کار می‌کند؛ ساختار قدیمی Registration Token اکنون به‌صورت کامل legacy deprecated است و در آپدیت ۲۰.۰ حذف خواهد شد.

چرا GitLab Runner را روی VPS جدا اجرا کنیم؟

پردازش‌های اتوماسیون تست و کامپایل کد به‌شدت نیازمند منابع سخت‌افزاری (CPU/RAM-intensive) هستند و منابع سیستم را اشغال می‌کنند. این پردازش‌ها اگر روی سرور اصلی اجرا شوند، دیتابیس PostgreSQL، کش Redis و سیستم مدیریت فایل Gitaly را کاملاً مختل می‌کنند. برای پروژه‌هایی با CI/CD فعال، استقرار Runner در ماشینی کاملاً جدا، مهم‌ترین عامل برای ارتقای معماری از یک سرور به دو ماشین مستقل است. مستند رسمی سیستم نیز نصب سرویس اجراکننده را روی سروری جداگانه به عنوان prerequisite فنی معرفی می‌کند.

مدیریت حرفه‌ای GitLab Self Hosted؛ امنیت، Backup و بهینه‌سازی

یک سرور مجازی برای GitLab نیازمند نگهداری مداوم است تا کدهای سازمانی از دسترسی‌های غیرمجاز در امان بمانند و سیستم همیشه پایدار بماند.

افزایش امنیت GitLab روی VPS

اعمال پروتکل‌های امنیتی در لایه سیستم‌عامل و وب، قدم اول حفاظت از سورس‌کدها است. اقدامات ضروری امنیتی شامل موارد زیر است:

• فعال‌سازی و اجبار استفاده از پروتکل HTTPS؛
• تنظیم دقیق Firewall سرور لینوکسی؛
• مسدودسازی پسورد و استفاده اجباری از SSH Key (ترجیحاً ED25519 یا حداقل RSA 4096 bit)؛
• فعال‌سازی ابزار احراز هویت 2FA. (سیستم GitLab Self-Managed امکان enforce کردن 2FA را برای همه کاربران و Adminها دارد)؛
• غیرفعال کردن گزینه Public Signup جهت جلوگیری از ثبت‌نام افراد متفرقه؛
• رعایت اصل Least Privilege در تخصیص دسترسی‌ها؛
• اجرای منظم Patch/Upgrade لایه‌های سیستم‌عامل؛
• حفاظت از اطلاعات لاگین Admin account.

چگونه از GitLab Backup بگیریم؟

ایجاد یک روال Backup قابل بازیابی و مطمئن، صرفاً محدود به کپی گرفتن از فایل‌های Repository نیست و نیازمند یک ساختار جامع است. یک فرایند بکاپ کامل باید کامپوننت‌های زیر را پوشش بدهد:

• سورس کدهای Git repositories؛
• دیتابیس اصلی PostgreSQL؛
• فایل‌های گرافیکی ذخیره شده در LFS؛
• خروجی بیلدها در پوشه Artifacts و ایمیج‌های

دستور بکاپ‌گیری سیستمی به‌تنهایی موارد حیاتی مانند محتویات پوشه /etc/gitlab، فایل پیکربندی gitlab-secrets.json و همچنین کلیدهای TLS/SSH keys را ذخیره نمی‌کند؛ کپی این موارد روی یک سرور Object Storage یا محیط Offsite copy الزامی است. هنگام Restore اطمینان حاصل کنید که مقصد، دقیقاً هم‌نسخه با فایل Backup باشد و حتماً Restore تست شود.

مشکلات رایج GitLab روی VPS و راه‌حل آن‌ها

در طول پشتیبانی از سرور مجازی GitLab، با خطاها و گلوگاه‌های مشخصی روبه‌رو خواهید شد:

بهترین معماری GitLab برای تیم‌های حرفه‌ای

طراحی ساختار شبکه و سرورها نقش مستقیمی در توان پاسخگویی سیستم دارد. معماری سرور مناسب GitLab به سه سطح زیر تقسیم می‌شود:

• سطح ۱: نصب نرم‌افزار پایه، PostgreSQL، سرویس Redis و کامپوننت Gitaly روی یک ماشین واحد. این سناریو صرفاً برای تیم کوچک و workload محدود است.
• سطح ۲: ایجاد ماشین مجزا برای پلتفرم در کنار GitLab Runner مستقل و پیاده‌سازی Object Storage. این پیشنهاد اصلی مقاله برای تیم‌های توسعه فعال است.
• سطح ۳: رویکرد تفکیک تمام components یا معماری Reference Architecture. در این مدل Gitaly، پایگاه داده PostgreSQL، سرور Redis و Object Storage در ماشین‌های مختلف توزیع می‌شوند و کاملاً آماده مقیاس‌پذیری هستند.

برای ۱۰۰۰ کاربر typical، سیستم Reference Architecture نیازمند یک نود پایه با ۸ vCPU و 16GB رم است و معیار اصلی sizing بر اساس RPS محاسبه می‌شود.

چگونه GitLab Self Hosted را بدون ریسک به‌روزرسانی کنیم؟

پشتیبانی مداوم یکی از چالش‌های نسخه سلف‌هاست است. قبل از هرگونه Upgrade، گرفتن کپی Backup الزامی است. شما نمی‌توانید مستقیم از یک نسخه قدیمی به جدیدترین آپدیت بپرید؛ مسیر Upgrade Path رسمی باید بررسی شود. فرایند ارتقا نیازمند نصب آخرین patch هر minor است و باید مطمئن شوید پردازش‌های background migrations قبل از رفتن به مرحله بعد تمام شده‌اند. در آپدیت‌های نسخه ۱۹، نقاط stopهای برنامه‌ریزی شده مستقیماً روی نسخه‌های ۱۹.۲، ۱۹.۵، ۱۹.۸ و ۱۹.۱۱ قرار دارند.

سخن پایانی؛ چه سرور مجازی (VPS) برای GitLab مناسب است؟

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

1. استفاده شخصی و محیط تست: یک سیستم با ۸ گیگابایت RAM برای Workloadهای محدود کاملاً پاسخگو است.
2. تیم‌های کوچک (محیط Production): زیرساخت خود را حداقل با ۸ هسته پردازشی (vCPU)، ۱۶ گیگابایت RAM و فضای ذخیره‌سازی پرسرعت NVMe آغاز کنید.
3. سازمان‌های بزرگ: برای پردازش‌های سنگین، استقرار پلتفرم روی سرور اختصاصی (Dedicated Server) یا پیاده‌سازی معماری مرجع (Reference Architecture) ضروری است.

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