بیشترین جاهای استفاده شده از Gitlab-Runner روی سرورها به صورت native بوده یا نهایتش Docker.
خیلی دیگه نهایتش، این بود که یه تغییری روی executorش میدادیم (مثلا میزاشتیم روی داکر یا shell) و استفاده میکردیم.
از kubernetes executor استفاده میکنیم در کلاستر kubernetes برای ساخت اپلیکیشن، این executor با کال کردن API کلاستر یک pod به ازای هر CI job بالا میاره.
در واقع kubernetes executor مراحل ساخت رو به چند مرحله تقسیم میکنه:
قبل از این که سراغ نصب و پیاده سازی اصل داستان بریم، برای تمیز پیش رفتن و بجای این که بریم همه چی رو به insecure تغییری بدیم، cert-manager رو نصب میکنیم.
انتظار میره روی کلاسترتون ingress رو داشته باشین
برای نصب cert-manager به صورت خوشگل و best-practice مثل همیشه با Helm پیش میریم.
بعد از نصب cert-manager ما یک ClusterIssuer تعریف میکنیم که بتونیم گواهینامه ssl رو دریافت کنیم، (این کار رو کنین تا هر وقت نیاز به ssl داشتین به صورت خودکار خودِ cert-manager براتون اوکی کنه)
در واقع operator برای مدیریت چرخه حیات (lifecycle) هستش، چرخه حیاتِ gitlab runner در کلاستر kubernetes و یا open-shift.
هدف از operator این هستش که وظایف (tasks) مورد نیاز برای اجرای CI/CD در کلاستر رو خودکار کنه.
برای نصب operator نیاز هستش کلاستر کوبر از ورژن 1.27 به بعد باشه و همین طور operator ما هم ورژنی که معرفی شده 0.28 هستش که نصب میکنیم.
در مرحله اول، نصب Operator Lifecycle Manager (OLM)، که ابزاری برای کمک به مدیریت operatorهای در حال اجرا روی کلاستر هستش و بعد از آن نصب خودِ Operator.
در نظر داشته باشید operator ما روی نیم اسپیس operators هستش
نمونه خروجی بعد از نصب موفق آمیز:
مثل همیشه ما از Helm استفاده کردیم و تغییراتی که نیاز هستش رو روش اعمال کردیم، یک سری تغییرات نیاز هستش که انجام بشه، مثلا اجازه این که رانر بتونه در کل کلاستر اپلیکیشن رو اجرا کنه نه فقط در namespaceی که بهش داده شده (یعنی دسترسی داشته باشه به بقیه namespaceها) - همین طور رولی که دسترسی داشته باشه به ساخت یا آپدیت و یا حتی دیلیت resourceهایی که در pipeline تعریف میشه، این مورد بسته به نیاز شما و pipeline شما تغییر میکنه:
در تصویر بالا تمامی نمونه تغییراتی هستش که نیاز داشتیم روی values فایل برای runner بدیم.
بعد از تغییراتی که خواستیم و اعمال کردیم میریم سراغ نصب gitlab-runner:
بعد از نصب هم میتونیم ازش با دستور kubectl get all -n gitlab-runner مطمئن بشیم:
بعد از مراحل بالا شما gitlab-runnerتون به صورت کامل اماده هستش و میتونین pipelineهای خودتون رو اجرا کنین، شاید سوال باشه که چرا cert-manager استفاده شده چون یکی از پیش نیاز های operator هستش و باید از ورژن 1.7.1 به بعد هم باشه.
سعی کردم تمام مراحل رو به صورت جزئی بزارم، ولی اگه جایی اشتباهی وجود داره و یا موردی هستش خودشحال میشم باهام در ارتباط باشین.
منابع:
