بلاگ/راه‌اندازی GitLab Runner خودمیزبان روی سرور مجازی و اختصاصی برای CI/CD
به‌روز شده

راه‌اندازی GitLab Runner خودمیزبان روی سرور مجازی و اختصاصی برای CI/CD

1405/06/060 بازدید
راه‌اندازی GitLab Runner خودمیزبان روی سرور مجازی و اختصاصی برای CI/CD

راه‌اندازی GitLab Runner خودمیزبان روی سرور مجازی و اختصاصی برای CI/CD

نمایی از اجرای پایپ‌لاین GitLab روی زیرساخت خودمیزبان GitLab Runner برنامه‌ای است که jobهای تعریف‌شده در فایل .gitlab-ci.yml را دریافت و اجرا می‌کند. با نصب Runner روی زیرساخت خودتان، منابع پردازشی، شبکه، کش و محیط اجرای پایپ‌لاین را در اختیار دارید و به سهمیه دقیقه‌های Runner اشتراکی وابسته نیستید. در این راهنما، راه‌اندازی GitLab Runner روی سرور را با اجراکننده Docker انجام می‌دهیم. هر job داخل یک کانتینر جدا اجرا می‌شود؛ بنابراین وابستگی‌های پروژه کمتر با سیستم‌عامل میزبان تداخل پیدا می‌کنند و پاک‌سازی محیط بعد از پایان job نیز ساده‌تر است. این روش برای پروژه‌هایی مناسب است که build و test مداوم دارند، به شبکه خصوصی دسترسی می‌خواهند یا برای اجرای پایپ‌لاین به منابع مشخصی مثل CPU، حافظه و دیسک سریع نیاز دارند. اگر با ساختار پایپ‌لاین و مراحل CI/CD در گیت‌لب آشنا نیستید، ایجاد یک شبکه توسعه مداوم با GitLab CI/CD گام‌های اولیه را شرح می‌دهد.

سرور مجازی یا اختصاصی؛ کدام برای Runner مناسب‌تر است؟

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

معیارسرور مجازیسرور اختصاصی
هزینه شروعکمتربیشتر
افزایش منابعمعمولاً سریع‌ترنیازمند ارتقا یا تعویض سخت‌افزار
پایداری عملکردوابسته به نوع مجازی‌سازی و پلنمنابع کاملاً در اختیار Runner
workload مناسبتست، lint، buildهای متوسطکامپایل سنگین، چند Runner هم‌زمان، ساخت ایمیج‌های بزرگ
مدیریت اولیهساده‌ترنیازمند برنامه‌ریزی بیشتر برای ظرفیت
جداسازی از پروژه‌های دیگرمناسب با VM مستقلمناسب با Runner و شبکه اختصاصی

برای یک Runner عمومی تیم، حداقل ۲ هسته CPU، چهار گیگابایت RAM و ۳۰ تا ۵۰ گیگابایت فضای SSD در نظر بگیرید. این اعداد قطعی نیستند؛ یک build فرانت‌اند ممکن است حافظه زیادی مصرف کند، در حالی که اجرای lint برای یک پروژه کوچک منابع چندانی نمی‌خواهد. فضای دیسک را دست‌کم نگیرید. ایمیج‌های Docker، لایه‌های build و کش پروژه‌ها به‌مرور دیسک را پر می‌کنند. بهتر است مصرف دیسک از ابتدا مانیتور و پاک‌سازی دوره‌ای نیز تنظیم شود؛ دستورهای این کار در مدیریت و حذف ایمیج‌ها، کانتینرها و حجم‌های Docker آمده است.

پیش‌نیازهای نصب GitLab Runner

این آموزش بر پایه یک سرور لینوکسی Debian یا Ubuntu نوشته شده است. پیش از شروع، موارد زیر را آماده کنید: - دسترسی کاربر دارای مجوز sudo - یک نمونه GitLab.com یا GitLab خودمیزبان - دسترسی Maintainer یا Owner به پروژه یا گروه - Docker Engine فعال روی سرور - ارتباط خروجی HTTPS با GitLab و رجیستری ایمیج - DNS و ساعت صحیح روی سرور ابتدا بسته‌های سیستم را به‌روزرسانی کنید:

sudo apt update
sudo apt upgrade -y

اگر Docker نصب نیست، آن را از مخزن رسمی Docker و متناسب با توزیع سرور نصب کنید؛ مقالهٔ نصب Docker و استفاده از آن نمونه‌ای کامل از این مراحل (روی CentOS) است. سپس صحت سرویس را بررسی کنید:

sudo systemctl enable --now docker
sudo docker run --rm hello-world

خروجی موفق hello-world نشان می‌دهد daemon داکر فعال است و می‌تواند کانتینر بسازد.

نصب GitLab Runner روی لینوکس

برای دریافت به‌روزرسانی‌های بعدی، بهتر است GitLab Runner را از مخزن رسمی آن نصب کنید. مخزن را اضافه کنید:

curl -L \
  "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" \

  | sudo bash

سپس بسته Runner را نصب کنید:

sudo apt install -y gitlab-runner

وضعیت سرویس را ببینید:

sudo systemctl status gitlab-runner

اگر سرویس اجرا نشده بود، آن را فعال کنید:

sudo systemctl enable --now gitlab-runner

نسخه نصب‌شده را نیز ثبت کنید تا هنگام عیب‌یابی بدانید Runner با چه نسخه‌ای اجرا می‌شود:

gitlab-runner --version

ساخت و رجیستر Runner در GitLab

در GitLab به تنظیمات پروژه یا گروه بروید و بخش CI/CD > Runners را باز کنید. یک Runner جدید بسازید، سیستم‌عامل Linux را انتخاب کنید و tagهای موردنیاز را وارد کنید. GitLab در پایان یک authentication token و فرمان پیشنهادی رجیستر را نمایش می‌دهد. توکن را مانند رمز عبور نگه دارید. آن را داخل مخزن، فایل .gitlab-ci.yml یا تاریخچه عمومی shell قرار ندهید. فرایند رجیستر را می‌توان به‌صورت تعاملی اجرا کرد:

sudo gitlab-runner register

Runner اطلاعات زیر را می‌پرسد: - آدرس GitLab؛ برای GitLab.com برابر https://gitlab.com/ - authentication token ایجادشده در پنل - نام قابل تشخیص برای Runner - اجراکننده یا executor که در این راهنما docker است - ایمیج پیش‌فرض، برای مثال alpine:3.20 برای رجیستر غیرتعاملی نیز می‌توانید از این الگو استفاده کنید:

sudo gitlab-runner register \
  --non-interactive \
  --url "https://gitlab.com/" \
  --token "RUNNER_AUTHENTICATION_TOKEN" \
  --executor "docker" \
  --description "arianet-docker-runner" \
  --docker-image "alpine:3.20"

بهتر است مقدار توکن را از یک متغیر محیطی موقت یا ابزار مدیریت secret دریافت کنید و مقدار واقعی آن را در اسکریپت دائمی ننویسید. پس از رجیستر، Runner را فهرست و ارتباط آن را بررسی کنید:

sudo gitlab-runner list
sudo gitlab-runner verify

در پنل GitLab نیز وضعیت Runner باید online نمایش داده شود.

دریافت job پایپ‌لاین از GitLab توسط Runner خودمیزبان و اجرای آن داخل کانتینر Docker روی سرور

تنظیم فایل config.toml

تنظیمات Runner معمولاً در مسیر /etc/gitlab-runner/config.toml ذخیره می‌شود. پیش از ویرایش، یک نسخه پشتیبان بگیرید:

sudo cp /etc/gitlab-runner/config.toml \
  /etc/gitlab-runner/config.toml.backup

یک پیکربندی پایه برای Docker executor می‌تواند چنین ساختاری داشته باشد: ```toml concurrent=2 check_interval=3