🥇حذف یک شاخه ویژگی قدیمی در یک خوشه Kubernetes

سلام! شاخه ویژگی (معروف به استقرار پیش‌نمایش، برنامه بازبینی) - این زمانی است که نه تنها شاخه اصلی مستقر می‌شود، بلکه هر درخواست کشش به یک URL منحصربه‌فرد نیز اجرا می‌شود. می‌توانید بررسی کنید که آیا کد در محیط تولید کار می‌کند یا خیر؛ این ویژگی را می‌توان به برنامه‌نویسان دیگر یا متخصصان محصول نشان داد. هنگامی که شما در حال کار بر روی یک درخواست کشش هستید، هر استقرار جدید commit فعلی برای کد قدیمی حذف می‌شود و استقرار جدید برای کد جدید منتشر می‌شود. هنگامی که یک درخواست کشش را در شاخه اصلی ادغام کردید، ممکن است سؤالاتی پیش بیاید. شما دیگر به شاخه ویژگی نیاز ندارید، اما منابع Kubernetes هنوز در خوشه هستند.

بیشتر در مورد شاخه های ویژگی

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

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end
spec:
  replicas: 3
...

برای شاخه ویژگی، یک فضای نام با شناسه آن (مثلاً شماره درخواست کشش) و نوعی پیشوند/پسوند (مثلاً -pr-):

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end-pr-17
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end-pr-17
spec:
  replicas: 1
...

در کل نوشتم اپراتور Kubernetes (برنامه ای که به منابع خوشه دسترسی دارد)، پیوند به پروژه در Github. فضاهای نامی را که به شاخه های ویژگی قدیمی تعلق دارند حذف می کند. در Kubernetes، اگر فضای نامی را حذف کنید، سایر منابع موجود در آن فضای نام نیز به طور خودکار حذف می شوند.

$ kubectl get pods --all-namespaces | grep -e "-pr-"
NAMESPACE            ... AGE
habr-back-end-pr-264 ... 4d8h
habr-back-end-pr-265 ... 5d7h

می توانید در مورد نحوه پیاده سازی شاخه های ویژگی در یک خوشه مطالعه کنید اینجا и اینجا.

انگیزه

بیایید به یک چرخه عمر درخواست کشش معمولی با ادغام پیوسته نگاه کنیم (continuous integration):

ما یک commit جدید را به شعبه فشار می دهیم.
در ساخت، لینترها و/یا تست ها اجرا می شوند.
تنظیمات درخواست کشش Kubernetes به سرعت ایجاد می شود (به عنوان مثال، شماره آن در قالب تمام شده درج می شود).
با استفاده از kubectl application، تنظیمات به خوشه اضافه می شوند (deploy).
درخواست کشش در شاخه اصلی ادغام می شود.

هنگامی که شما در حال کار بر روی یک درخواست کشش هستید، هر استقرار جدید commit فعلی برای کد قدیمی حذف می‌شود و استقرار جدید برای کد جدید منتشر می‌شود. اما هنگامی که یک درخواست کشش در شاخه اصلی ادغام می شود، تنها شاخه اصلی ساخته می شود. در نتیجه، معلوم می شود که ما قبلاً درخواست کشش را فراموش کرده ایم و منابع Kubernetes آن هنوز در خوشه هستند.

نحوه استفاده

پروژه را با دستور زیر نصب کنید:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml

یک فایل با محتوای زیر ایجاد کنید و از طریق آن نصب کنید kubectl apply -f:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 3

پارامتر namespaceSubstring برای فیلتر کردن فضاهای نام برای درخواست های کشش از فضاهای نام دیگر مورد نیاز است. به عنوان مثال، اگر خوشه دارای فضای نام زیر باشد: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33، سپس نامزدهای حذف خواهند شد habr-back-end-pr-17, habr-back-end-pr-33.

پارامتر afterDaysWithoutDeploy برای حذف فضاهای نام قدیمی مورد نیاز است. به عنوان مثال، اگر فضای نام ایجاد شود 3 дня 1 час برگشت، و پارامتر نشان می دهد 3 дня، این فضای نام حذف خواهد شد. همچنین در صورت ایجاد فضای نام در جهت مخالف عمل می کند 2 дня 23 часа برگشت، و پارامتر نشان می دهد 3 дня، این فضای نام حذف نخواهد شد.

یک پارامتر دیگر نیز وجود دارد، این پارامتر مسئول تعداد دفعات اسکن همه فضاهای نام و بررسی روزهای بدون استقرار است - هر دقیقه را بررسی کنید. به طور پیش فرض برابر است 30 минутам.

چطور کار می کند؟

در عمل، شما نیاز دارید:

کارگر بارانداز برای کار در محیط ایزوله
مینی کوب поднимет Kubernetes кластер локально.
کوبکتل — интерфейс командной строки для управления кластером.

ما یک خوشه Kubernetes را به صورت محلی ایجاد می کنیم:

$ minikube start --vm-driver=docker
minikube v1.11.0 on Darwin 10.15.5
Using the docker driver based on existing profile.
Starting control plane node minikube in cluster minikube.

ما نشان می دهیم kubectl به طور پیش فرض از خوشه محلی استفاده کنید:

$ kubectl config use-context minikube
Switched to context "minikube".

دانلود تنظیمات برای محیط تولید:

$ curl https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml > stale-feature-branch-production-configs.yml

از آنجایی که پیکربندی‌های تولید برای بررسی فضاهای نام قدیمی پیکربندی شده‌اند، و خوشه جدید ما آنها را ندارد، متغیر محیطی را جایگزین خواهیم کرد. IS_DEBUG بر true. با این مقدار پارامتر afterDaysWithoutDeploy در نظر گرفته نمی شود و فضاهای نام برای روزها بدون استقرار بررسی نمی شوند، فقط برای وقوع زیر رشته (-pr-).

اگر شما در Linux:

$ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml

اگر شما در macOS:

$ sed -i "" 's|false|true|g' stale-feature-branch-production-configs.yml

نصب پروژه:

$ kubectl apply -f stale-feature-branch-production-configs.yml

بررسی اینکه منبعی در خوشه ظاهر شده است StaleFeatureBranch:

$ kubectl api-resources | grep stalefeaturebranches
NAME                 ... APIGROUP                             ... KIND
stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch

بررسی می کنیم که یک عملگر در خوشه ظاهر شده است:

$ kubectl get pods --namespace stale-feature-branch-operator
NAME                                           ... STATUS  ... AGE
stale-feature-branch-operator-6bfbfd4df8-m7sch ... Running ... 38s

اگر به گزارش های آن نگاه کنید، آماده پردازش منابع است StaleFeatureBranch:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Operator Version: 0.0.1"}
...
... "msg":"Starting EventSource", ... , "source":"kind source: /, Kind="}
... "msg":"Starting Controller", ...}
... "msg":"Starting workers", ..., "worker count":1}

ما به صورت آماده نصب می کنیم fixtures (پیکربندی های آماده برای مدل سازی منابع خوشه ای) برای یک منبع StaleFeatureBranch:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/stale-feature-branch.yml

تنظیمات نشان می دهد که فضاهای نام با یک رشته فرعی جستجو شود -pr- یک بار در 1 минуту.:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 1 
  checkEveryMinutes: 1

اپراتور پاسخ داده است و آماده بررسی فضاهای نام است:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Stale feature branch is being processing.","namespaceSubstring":"-pr-","afterDaysWithoutDeploy":1,"checkEveryMinutes":1,"isDebug":"true"}

نصب fixtures, содержащие два namespace’а (project-pr-1, project-pr-2) و آنها deployments, services, ingress، و غیره:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/first-feature-branch.yml -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/second-feature-branch.yml
...
namespace/project-pr-1 created
deployment.apps/project-pr-1 created
service/project-pr-1 created
horizontalpodautoscaler.autoscaling/project-pr-1 created
secret/project-pr-1 created
configmap/project-pr-1 created
ingress.extensions/project-pr-1 created
namespace/project-pr-2 created
deployment.apps/project-pr-2 created
service/project-pr-2 created
horizontalpodautoscaler.autoscaling/project-pr-2 created
secret/project-pr-2 created
configmap/project-pr-2 created
ingress.extensions/project-pr-2 created

ما بررسی می کنیم که تمام منابع بالا با موفقیت ایجاد شده اند:

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...
NAME                              ... READY ... STATUS  ... AGE
pod/project-pr-1-848d5fdff6-rpmzw ... 1/1   ... Running ... 67s

NAME                         ... READY ... AVAILABLE ... AGE
deployment.apps/project-pr-1 ... 1/1   ... 1         ... 67s
...

Так как мы включили debug، فضاهای نام project-pr-1 и project-pr-2، بنابراین تمام منابع دیگر باید بلافاصله بدون در نظر گرفتن پارامتر حذف شوند afterDaysWithoutDeploy. این را می توان در گزارش های اپراتور مشاهده کرد:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-1"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-1","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-1"}
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-2"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-2","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-2"}

اگر در دسترس بودن منابع را بررسی کنید، آنها در وضعیت قرار می گیرند Terminating (فرآیند حذف) یا قبلاً حذف شده است (خروجی دستور خالی است).

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...

می توانید روند ایجاد را تکرار کنید fixtures چندین بار و مطمئن شوید که آنها در عرض یک دقیقه حذف شده اند.

جایگزین، گزینه ها

به جای اپراتور که در یک خوشه کار می کند چه کاری می توان انجام داد؟ چندین رویکرد وجود دارد، همه آنها ناقص هستند (و کاستی های آنها ذهنی است)، و هر کس برای خودش تصمیم می گیرد که برای یک پروژه خاص چه چیزی بهتر است:

حذف شاخه ویژگی در حین ایجاد ادغام پیوسته شاخه اصلی.
- برای انجام این کار، باید بدانید که کدام درخواست کششی مربوط به commitی است که در حال ساخت است. از آنجایی که فضای نام شاخه ویژگی حاوی شناسه درخواست pull - شماره آن یا نام شاخه است، شناسه همیشه باید در commit مشخص شود.
- ساخت شعبه اصلی در حال شکست است. به عنوان مثال، شما مراحل زیر را دارید: دانلود پروژه، اجرای تست، ساخت پروژه، انتشار، ارسال اعلان، پاک کردن شاخه ویژگی آخرین درخواست کشش. اگر در هنگام ارسال اعلان، بیلد ناموفق باشد، باید تمام منابع موجود در کلاستر را به صورت دستی حذف کنید.
- بدون زمینه مناسب، حذف شاخه های ویژگی در ساخت اصلی واضح نیست.
استفاده از وب هوک (مثال).
- ممکن است این رویکرد شما نباشد. به عنوان مثال، در جنکینز، تنها یک نوع خط لوله از قابلیت ذخیره تنظیمات آن در کد منبع پشتیبانی می کند. هنگام استفاده از وب هوک ها، باید اسکریپت خود را بنویسید تا آنها را پردازش کنید. این اسکریپت باید در رابط جنکینز قرار گیرد که نگهداری آن دشوار است.
یک پیغام بنویسید کرنجاب و یک خوشه Kubernetes اضافه کنید.
- صرف زمان برای نوشتن و پشتیبانی.
- اپراتور قبلاً به سبک مشابه کار می کند، مستند شده و پشتیبانی می شود.

از توجه شما به مقاله متشکرم. پیوند به پروژه در Github.

منبع: www.habr.com

حذف یک شاخه ویژگی قدیمی در یک خوشه Kubernetes

بیشتر در مورد شاخه های ویژگی

انگیزه

نحوه استفاده

چطور کار می کند؟

جایگزین، گزینه ها

اضافه کردن نظر انصراف از پاسخ