پیکربندی Runner ها در گیت لب

پیکربندی Runner ها در گیت لب

پیکربندی Runner ها در گیت لب

در این مقاله به طور کامل با Runner های گیت لب آشنا میشویم و روند کار آنها را بررسی میکنیم.

GitLab runner برنامه ایی است که برای اجرای job ها در Pipeline، با CI/CD گیت لب کار میکند.

برنامه runner را میتوان با توجه به زیرساخت های مورد نیاز، انتخاب و نصب کرد. بعد از آن باید runner گیت لب را بر روی ماشینی که از هاست هایی که گیت لب به طور جداگانه و مجزا برای امنیت و نتیجه کارایی استفاده می کند، نصب کنید.

وقتی که از ماشین های مجزا استفاده میشود، میتوان سیستم عامل ها و ابزارهای مختلفی مثل kubernetes یا Docker را بر روی هر ماشین در اختیار داشت.

گیت لب Runner ، یک برنامه متن باز است که با استفاده از زبان برنامه نویسی Go نوشته شده است. همچنین می تواند به عنوان یک تک باینری که نیازی به استفاده از زبان های خاص ندارد، مورد استفاده قرار بگیرد.

گیت لب Runner را میتوان درون یک Docker container اجرا کرد و یا آن را به یک kubernetes cluster توسعه داد.

نسخه های مختلف گیت لب Runner

برای داشتن نتایج سازگار، نسخه major.minor گیت لب Runner باید با ورژن گیت لب major و minor همگام سازی شود. Runner های قدیمی ممکن است هنوز با ورژن های جدیدتر گیت لب کار کنند و برعکس آن. در حالی که اگر تفاوت نسخه وجود داشته باشد، ممکن است ویژگی ها در دسترس نباشند یا به طور صحیح کار نکنند.

سازگاری Backward، بین آپدیت های ورژن minor تضمین میشود. در حالی که، گاهی اوقات آپدیت های نسخه minor در گیت لب می تواند قابلیت و ویژگی های جدیدی که گیت لب Runner نیاز دارد را در یک ورژن minor مشترک، معرفی کند.

ثبت Runner

بعد از نصب برنامه Runner، نوبت به ثبت runner های شخصی میرسد. Runner ها عواملی هستند که Job های CI/CD گیت لب را اجرا میکنند.

زمانی که یک runner ثبت میشود، ارتباطات بین گیت لب و ماشینی که گیت لب Runner بر روی آن نصب شده نیز تنظیم و راه اندازی میشوند.

Runner ها معمولا Job ها را در ماشینی که گیت لب Runner در آن نصب شده، پردازش میکنند. در حالی که می توان یک پردازنده runner برای job ها را در یک container، kubernetes cluster یا مقیاس های خودکار در cloud، در اختیار داشت.

انتخاب Executor ها

زمانی که یک runner ثبت شد، باید یک executor انتخاب شود.

یک executor، برای اجرای هر job یک محیط تعیین و مشخص میکند.

برای مثال :

1. ممکن است شخصی بخواهد CI/CD job خود را در دستورات PowerShell اجرا کند، ممکن است بخواهد گیت لب runner را بر روی یک سرور ویندوز راه اندازی کند و سپس یک runner که از shell executor استفاده میکند را ثبت کند.

2. ممکن است شخص دیگری بخواهد CI/CD job خود را در دستورات یک Docker container سفارشی شده، اجرا و راه اندازی کند، ممکن است بخواهد گیت لب runner را در یک سرور لینوکس نصب کند و یک runner که از Docker executor استفاده میکند را ثبت کند.

موارد بالا فقط چند مورد از پیکربندی هایی است که امکان انجام دادنشان پیش می آید. علاوه بر اینها چندین و چند پیکربندی دیگر نیز وجود دارد.

اکنون شما میتواند گیت لب Runner را بر روی یک ماشین مجازی نصب کنید و برای executor آن از یک ماشین مجازی دیگر استفاده کنید.

زمانی که میخواهید گیت لب Runner را در یک Docker container نصب کنید و برای اجرای job ها Docker executor انتخاب کنید، ممکن است گیت لب Runner به عنوان یک پیکربندی “Docker-in-Docker” تعریف شود.

چه کسانی به Runner های گیت لب UI دسترسی دارند؟

قبل از ثبت یک Runner، باید برای آن دسترسی تعیین کنید یعنی برای آن مشخص کنید که در گیت لب قرار است در دسترس چه کسانی باشد، همه افراد عضو شده در گیت لب یا یک گروه یا پروژه خاص.

Runner ها سه نوع دارند:

  1. Shared runners

این نوع Runner ها برای تمام پروژه ها قابل استفاده هستند.

  1. Group runners

این مدل Runner ها برای تمام پروژه ها و زیر مجموعه های یک گروه قابل دسترس هستند.

  1. Specific runners

این دسته از Runner ها برای پروژه های فردی یا تک نفره قابل دسترس هستند.

هنگامی که یک runner ثبت میکنید، باید یک رمز برای گروه یا پروژه گیت لب خود قرار دهید. در این صورت runner تشخیص میدهد که چه پروژه هایی برای چه کاربرانی قابل دسترس است.

Tag ها

هنگام ثبت هر runner میتوان به آن یک سری tag اضافه کرد.

وقتی یک CI/CD job اجرا میشود، میداند که کدام runner توسط نگاه کردن به tag ها دستور می دهد.

برای مثال اگر یک runner دارای tag ruby باشد، میتوانید قطعه کد زیر را به پروژه های موجود در فایل gitlab-ci.yml. خود اضافه کنید:

job:

tags:

– ruby

 

وقتی job اجرا می شود، از runner هایی استفاده میکند که دارای ruby tag باشند.

پیکربندی Runner ها

از طریق ویرایش فایل config.toml نیز میتوان runner ها را پیکربندی و تنظیم کرد. config.toml فایلی است که در پروسه نصب runner نصب میشود.

در این فایل میتوانید تنظیمات یک runner خاص و یا همه runner ها را ویرایش کنید. همچنین میتوانید تنظیماتی مثل logging و cache و مواردی مثل همزمانی، حافظه، محدودیت CPU و … را در runner اعمال کنید.

نظارت کردن بر روی Runner ها

برای نظارت و کنترل runner ها میتوان از Prometheus استفاده کرد. به وسیله Prometheus میتوان مواردی مثل تعداد job های در حال اجرا و مقدار حافظه ایی که Runner ها از CPU استفاده کرده اند را نیز مشاهده و کنترل کرد.

اجرای Job با استفاده از runner

بعد از اینکه یک runner پیکربندی میشود و برای پروژه در دسترس قرار میگیرد، CI/CD job ها نیز میتوانند از runner استفاده کنند.

نام runner ها یا tag هایی که در در فایل .gitlab-ci.yml برای آنها تعریف شده را مشخص کنید. سپس وقتی به مخزن commit شدید، Pipeline ها اجرا میشوند و executor های runner ها ، دستورات را پردازش میکنند.

Runner ها در GitLab.com

اگر از GitLab.com استفاده میکنید، به این معناست که Runner ها GitLab را برای شما مدیریت میکنند. این runner ها برای تمام پروژه ها فعال هستند، هر چند که میتوانید آنها را غیر فعال کنید.

اگر شخصی نخواهد از runner های مدیریت گیت لب استفاده کند، میتواند گیت لب Runner را نصب کند و سپس Runner شخصی و مربوط به خودش را در GitLab.com ثبت کند.

ویژگی های گیت لب Runner

  • اجرای همزمان چند job
  • استفاده از چندین رمز با چندین سرور (حتی برای هر پروژه)
  • محدودیت تعداد job های همزمان در هر رمز
  • Job ها میتوانند به چندین صورت اجرا شوند:
    • محلی
    • با استفاده از Docker container ها
    • با استفاده بیشتر از Docker container ها و executing job نسبت به SSH
    • استفاده از Docker container همراه با مقیاس های خودکار در cloud های مختلف و مجازی سازی hypervisors
    • اتصال به یک سرور remote SSH
  • استفاده از زبان برنامه نویسی Go و توزیع شده به عنوان تک باینری بدون هیچ گونه الزامات دیگر
  • پشتیبانی و ساپورت از Bash، PowerShell Core و ویندوز PowerShell
  • قابل اجرا بر روی سیستم عامل هایی که Docker بر روی آنها قابل اجراست. مثل لینوکس، مک و ویندوز
  • اجازه سفارش سازی محیطی که job در آن اجرا میشود
  • بارگیری پیکربندی به صورت خودکار بدون نیاز به راه اندازی مجدد
  • استفاده و تنظیم آسان در محیط های مختلف مثل Docker، Docker-SSH و … .
  • قابلیت کش کردن کانتینرهای داکر
  • نصب آسان به عنوان یک سرویس برای سیستم عامل های لینوکس، مک و ویندوز.
  • جاسازی معیارهای Prometheus در HTTP سرور
  • مدیریت کارکنان برای نظارت و انتقال معیارهای Prometheus و بقیه اطلاعات JOB های تعیین شده به گیت لب
بستن