استفاده از Kubernetes در Gitlab - بخش اول

خیلی از شما ها از Gitlab استفاده می کنید. یکی از بهترین ویژگی هاش امکان اتصال به کلاستر Kubernetes و استقرار پروژه هاست که در این پست به اون می پردازیم.

آرش حاتمی

Sep 4, 2020 • 2 min read

یکی از بهترین و محبوب ترین پلتفرم های موجود برای کنترل سورس و نسخه پروژه ها Gitlab بوده که با توجه به ویژگی های خوبش همه روزه توسط افراد حقیقی یا شرکت ها استفاده میشه. بزرگترین قابلیت اون Self-Hosted بودنشه که به راحتی میشه روی سرور های خودمون نصبش کنیم. از طرف دیگه ابزاری مانند Kubernetes وجود داره که یک Orchestration خیلی قوی به حساب میاد و در کنار باقی ابزار ها همیشه کمک تیم های فنی هستن.

تا حالا احتمالا با هر دوی این ابزار ها کار کردید ولی اطلاع دارید که امکان اتصالشون بهم هم وجود داره ؟ شاید توی قسمت Operations بهش برخورد کرده باشید.

Screenshot_2020-09-04-Kubernetes-Clusters---Nikas-Server-1

با این کار چنین مزیت هایی براتون به وجود میاد :

استفاده از قابلیت Review Apps
اجرای Pipeline های مختلف
استقرار پروژه ها
مانیتورینگ کلاستر
استفاده از قابلیت Auto DevOps
استفاده از ترمینال های تحت وب
و ...

تنظیم

قبل از شروع هرچیز لازمه تا کلاستر خودتون راه اندازی شده و آماده باشه. برای این منظور می تونید از آموزش زیر استفاده کنید :

پس از اینکه از عملکرد صحیح کلاستر اطمینان پیدا کردید به Operations > Kubernetes برید تا اولین کلاستر رو تنظیم کنید. اگر از گیتلب به صورت Self-Hosted استفاده می کنید و دسترسی مدیریتی دارید هم که گزینه اش به صورت مجزا در پنل وجود داره و میتونید کلاستری رو به صورت جامع برای کاربرها و پروژه های مختلف تعریف کنید.

از اونجایی که میخوایم از کلاستر خودمون استفاده کنیم دیگه نیازی به انتخاب Amazon EKS یا Google GKE نیست. گرچه بخوایم هم نمیتونیم استفاده کنیم :)))

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

نام
حوزه یا مراحل کاری پروژه ها که باید به این کلاستر اختصاص پیدا کنند
آدرس API
گواهینامه جهت اتصال با HTTPS
توکن امنیتی

در ادامه به توضیح هر مورد می پردازیم

نام

این بخش که فکر نکنم نیاز به توضیح داشته باشه و همه چیزش مشخصه. فقط دقت داشته باشید که اگه از کلاستر های مختلف استفاده می کنید در انتخاب نام هم ظرافت هایی رو به خرج بدید تا همه چیز مرتب تر باشه. این مورد وقتی قسمت Environment رو مشخص می کنید بیشتر به چشم میاد.

Environment scope

در این بخش باید تعریف کنید که این کلاستر جهت انجام چه اموری به کار برده میشه. برای مثال میتونید یک کلاستر رو برای محیط Production و کلاستر دیگر رو برای موارد دیگه استفاده کنید.

برای مثال فایل pipeline زیر رو در نظر بگیرید :

stages:
  - deploy

deploy staging:
  stage: deploy
  script: make deploy
  environment:
    name: staging
    url: https://staging.test.ir/

deploy production:
  stage: deploy
  script: make deploy
  environment:
    name: production
    url: https://test.ir/

در اینجا ما دو نسخه از پروژه مستقر می کنیم که یکی از اونها در محیط Production و دیگری برای Staging تنظیم میشه. به راحتی می تونید مشخص کنید هر کدوم از این روندهای استقرار روی چه کلاستری انجام بشه.

به صورت پیشفرض با استفاده از کارکتر * کلاستر برای تمامی موارد تنظیم میشه.

API URL

در این قسمت باید آدرس API مربوط به کلاستر خودتون رو وارد کنید. برای این منظور دستور زیر رو اجرا کنید :

kubectl cluster-info | grep 'Kubernetes master' | awk '/http/ {print $NF}'

آدرسی که به شما داده میشه باید برای این قسمت تنظیم بشه. دقت کنید که K8S نسخه های متعددی API داره و شما باید آدرس اصلی کلاستر رو استفاده کنید و نه آدرسی مشخص از API ها. برای مثال :

https://k8s.cluster = درست
https://k8s.cluster/api/v1 = غلط

CA Certificate

جهت اتصال به کلاستر و اطمینان از امنیت این بخش لازمه تا گواهینامه معتبری استفاده بشه. هنگام ساخت کلاستر یک مورد پیشفرض وجود داره که می تونید از همون استفاده کنید ( یا اینکه گواهینامه خودتون رو تنظیم کنید ). جهت به دست آوردن این گواهینامه ابتدا این دستور رو وارد کنید :

kubectl get secrets

لیستی از کلیه secret ها برای شما میاد که باید دنبال موردی مشابه با default-token-xxxxx بگردید. اسم اون رو کپی کرده و در دستور زیر قرار بدید و اجرا کنید :

kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode

متن کامل کلید گواهینامه به شما داده میشه که باید در این بخش اون رو قرار بدید.

Service Token

جهت اعتبارسنجی درخواست ها باید یک حساب مدیریتی هم داشته باشیم. این حساب مدیریتی باید جزو دسته بندی cluster-admin باشه تا دسترسی های لازم رو به شما بده. جهت این کار فایلی با نام gitlab-admin.yml و محتوای زیر آماده کنید :

piVersion: v1
kind: ServiceAccount
metadata:
  name: gitlab-admin
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: gitlab-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: gitlab-admin
    namespace: kube-system

سپس با استفاده از دستور kubectl apply این فایل رو اجرا کنید. در مرحله آخر باید توکن مربوط به این حساب کاربری رو با استفاده از دستور زیر به دست بیاریم :

kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep gitlab-admin | awk '{print $1}')

توکن نمایش داده شده رو کپی کنید و در بخش مربوطه قرار بدید.

RBAC-enabled cluster

هنگام ساخت کلاستر شما دو گزینه RBAC و ABAC پیش روتون هست. در صورتی که از کلاستر های RBAC استفاده می کنید این گزینه رو فعال کنید ( که خب این مورد هم پیشنهاد میشه ).

GitLab-managed cluster

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

وقتی کلاستر تنظیم شد و از صحت کار مطلع شدید میتونید به تب Applications برید و برنامه های پیشفرضی که برای شما در نظر گرفته شده رو انتخاب و نصب کنید. به عنوان اولین مورد Prometheus رو نصب می کنیم تا گزینه مانیتورینگ هم به صورت پیشفرض براتون فعال بشه.

Screenshot_2020-09-04-Kubernetes-Cluster---Admin-Area-1--1

فقط کافیه که روی دکمه Install مربوطه کلیک کرده و صبر کنید تا روند نصب کامل بشه.

توجه کنید که گیتلب یک Namespace جدید با نام gitlab-managed-apps میسازه و برنامه ها رو توی اون مستقر می کنه. حالا به گیت لب برگشته و تب Health رو چک کنید. همونطور که مشاهده می کنید مانیتورینگ ساده ای از وضعیت فعلی کلاستر به شما نمایش داده میشه :

حالا همه چیز برای استقرار خودکار پروژه ها آماده است. در آموزش بعدی به این مورد می پردازیم ...