მოძველებული ფუნქციების ფილიალის წაშლა Kubernetes კლასტერში

Hi! მხატვრული ფილიალი (aka deploy preview, განხილვის აპლიკაცია) - ეს არის მაშინ, როდესაც განლაგებულია არა მხოლოდ სამაგისტრო ფილიალი, არამედ თითოეული pull მოთხოვნა უნიკალურ URL-ზე. შეგიძლიათ შეამოწმოთ მუშაობს თუ არა კოდი საწარმოო გარემოში; ფუნქცია შეიძლება აჩვენოს სხვა პროგრამისტებს ან პროდუქტის სპეციალისტებს. სანამ თქვენ მუშაობთ pull-ის მოთხოვნაზე, ყოველი ახალი commit მიმდინარე განლაგება ძველი კოდისთვის წაიშლება და ახალი კოდის ახალი განლაგება შემოვიდა. კითხვები შეიძლება გაჩნდეს, როდესაც თქვენ გააერთიანეთ pull-ის მოთხოვნა მთავარ ფილიალში. თქვენ აღარ გჭირდებათ ფუნქციების ფილიალი, მაგრამ Kubernetes რესურსები კვლავ კლასტერშია.

მეტი მხატვრული ფილიალების შესახებ

Kubernetes-ში ფუნქციების განშტოებების შექმნის ერთ-ერთი მიდგომა სახელთა სივრცის გამოყენებაა. მოკლედ, წარმოების კონფიგურაცია ასე გამოიყურება:

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

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

ფუნქციების განშტოებისთვის, სახელთა სივრცე იქმნება მისი იდენტიფიკატორით (მაგალითად, pull მოთხოვნის ნომერი) და გარკვეული სახის პრეფიქსი/პოსტფიქსი (მაგალითად, -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):

1. ჩვენ ვაყენებთ ახალ ვალდებულებას ფილიალში.
2. კონსტრუქციაზე ტარდება ლინტერები და/ან ტესტები.
3. Kubernetes pull-ის მოთხოვნის კონფიგურაციები იქმნება ფრენის დროს (მაგალითად, მისი ნომერი ჩასმულია მზა შაბლონში).
4. kubectl application-ის გამოყენებით, კონფიგურაციები ემატება კლასტერს (განლაგება).
5. Pull მოთხოვნა გაერთიანებულია მთავარ ფილიალში.

სანამ თქვენ მუშაობთ pull-ის მოთხოვნაზე, ყოველი ახალი commit მიმდინარე განლაგება ძველი კოდისთვის წაიშლება და ახალი კოდის ახალი განლაგება შემოვიდა. მაგრამ როდესაც pull მოთხოვნა გაერთიანდება მთავარ ფილიალში, აშენდება მხოლოდ ძირითადი ფილიალი. შედეგად, გამოდის, რომ ჩვენ უკვე დაგვავიწყდა pull-ის მოთხოვნა და მისი 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 дня, ეს სახელთა სივრცე არ წაიშლება.

არის კიდევ ერთი პარამეტრი, ის პასუხისმგებელია იმაზე, თუ რამდენად ხშირად უნდა სკანირდეს ყველა სახელთა სივრცე და შეამოწმოს დღეები განლაგების გარეშე - შეამოწმეთEveryMiutes. ნაგულისხმევად ტოლია 30 минутам.

როგორ აკეთებს ამას მუშაობა

პრაქტიკაში დაგჭირდებათ:

1. docker იზოლირებულ გარემოში მუშაობისთვის.
2. მინიკუბე ადგილობრივად გაზრდის კუბერნეტის კლასტერს.
3. კუბექტლი — ბრძანების ხაზის ინტერფეისი კლასტერის მართვისთვის.

ჩვენ ვზრდით კუბერნეტის კლასტერს ადგილობრივად:

$ 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 on 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, რომელიც შეიცავს ორ სახელთა სივრცეს (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 რამდენჯერმე და დარწმუნდით, რომ ისინი ამოიღეთ ერთ წუთში.

ალტერნატივები

რა შეიძლება გაკეთდეს ოპერატორის ნაცვლად, რომელიც მუშაობს კლასტერში? არსებობს რამდენიმე მიდგომა, ყველა მათგანი არასრულყოფილია (და მათი ნაკლოვანებები სუბიექტურია) და ყველა თავად წყვეტს, რა არის საუკეთესო კონკრეტული პროექტისთვის:

1. ფუნქციის ფილიალის წაშლა ძირითადი ფილიალის უწყვეტი ინტეგრაციის შექმნისას.

   • ამისათვის თქვენ უნდა იცოდეთ, თუ რომელი pull-ის მოთხოვნა ეხება შემუშავებულ ვალდებულებას. ვინაიდან ფუნქციის ფილიალის სახელების სივრცე შეიცავს pull-ის მოთხოვნის იდენტიფიკატორს - მის ნომერს, ან ფილიალის სახელს, იდენტიფიკატორი ყოველთვის უნდა იყოს მითითებული commit-ში.
   • სამაგისტრო ფილიალების აშენება ვერ ხერხდება. მაგალითად, თქვენ გაქვთ შემდეგი ეტაპები: ჩამოტვირთეთ პროექტი, გაუშვით ტესტები, შექმენით პროექტი, გააკეთეთ გამოშვება, გაგზავნეთ შეტყობინებები, გაასუფთავეთ ბოლო მოთხოვნის ფუნქციის ფილიალი. თუ შეტყობინებების გაგზავნისას build ვერ ხერხდება, თქვენ მოგიწევთ ხელით წაშალოთ კლასტერში არსებული ყველა რესურსი.
   • სათანადო კონტექსტის გარეშე, მახასიათებლის ტოტების წაშლა სამაგისტრო ნაგებობაში აშკარა არ არის.

2. ვებჰუკების გამოყენება (მაგალითად).

   • ეს შეიძლება არ იყოს თქვენი მიდგომა. მაგალითად, in Jenkins, მილსადენის მხოლოდ ერთი ტიპი მხარს უჭერს მისი კონფიგურაციების საწყის კოდში შენახვის შესაძლებლობას. ვებჰუკების გამოყენებისას, თქვენ უნდა დაწეროთ თქვენი საკუთარი სკრიპტი მათ დასამუშავებლად. ეს სკრიპტი უნდა განთავსდეს ჯენკინსის ინტერფეისში, რომლის შენარჩუნება რთულია.

3. დაწერეთ კრონჯობი და დაამატეთ Kubernetes კლასტერი.

   • დროის დახარჯვა წერასა და მხარდაჭერაზე.
   • ოპერატორი უკვე მუშაობს მსგავს სტილში, არის დოკუმენტირებული და მხარდაჭერილი.

გმადლობთ სტატიისადმი ყურადღებისთვის. პროექტის ბმული Github-ზე.

წყარო: www.habr.com