ການລຶບສາຂາຄຸນສົມບັດທີ່ລ້າສະໄໝຢູ່ໃນກຸ່ມ Kubernetes

Hello! ສາຂາຄຸນສົມບັດ (aka deploy preview, review app) - ນີ້ແມ່ນເວລາທີ່ບໍ່ພຽງແຕ່ສາຂາຕົ້ນສະບັບຖືກນໍາໄປໃຊ້, ແຕ່ຍັງແຕ່ລະຄໍາຮ້ອງຂໍດຶງໄປຫາ URL ທີ່ເປັນເອກະລັກ. ທ່ານສາມາດກວດເບິ່ງວ່າລະຫັດເຮັດວຽກຢູ່ໃນສະພາບແວດລ້ອມການຜະລິດ; ໃນຂະນະທີ່ທ່ານກໍາລັງເຮັດວຽກຢູ່ໃນຄໍາຮ້ອງຂໍການດຶງ, ແຕ່ລະ commit ໃຫມ່ deploy ໃນປັດຈຸບັນສໍາລັບລະຫັດເກົ່າຈະຖືກລຶບ, ແລະ deploy ໃຫມ່ສໍາລັບລະຫັດໃຫມ່ແມ່ນ rolled ອອກ. ຄໍາຖາມອາດຈະເກີດຂື້ນເມື່ອທ່ານລວມເອົາຄໍາຮ້ອງຂໍດຶງເຂົ້າໄປໃນສາຂາຕົ້ນສະບັບ. ທ່ານບໍ່ຕ້ອງການສາຂາຄຸນສົມບັດອີກຕໍ່ໄປ, ແຕ່ຊັບພະຍາກອນ Kubernetes ຍັງຢູ່ໃນກຸ່ມ.

ເພີ່ມເຕີມກ່ຽວກັບສາຂາຄຸນສົມບັດ

ວິທີໜຶ່ງໃນການສ້າງສາຂາຄຸນສົມບັດໃນ Kubernetes ແມ່ນການໃຊ້ namespaces. ໃນສັ້ນ, ການຕັ້ງຄ່າການຜະລິດເບິ່ງຄືວ່າ:

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

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

ສໍາລັບສາຂາຄຸນສົມບັດ, namespace ຖືກສ້າງຂຶ້ນດ້ວຍຕົວລະບຸຂອງມັນ (ຕົວຢ່າງ, ຈໍານວນການຮ້ອງຂໍການດຶງ) ແລະບາງປະເພດຂອງຄໍານໍາຫນ້າ / postfix (ຕົວຢ່າງ, -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. ມັນເອົາ namespaces ທີ່ຂຶ້ນກັບສາຂາຄຸນສົມບັດເກົ່າ. ໃນ Kubernetes, ຖ້າທ່ານລຶບ namespace, ຊັບພະຍາກອນອື່ນໆໃນ namespace ນັ້ນກໍ່ຈະຖືກລຶບໂດຍອັດຕະໂນມັດ.

$ 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. ໃນການກໍ່ສ້າງ, linters ແລະ / ຫຼືການທົດສອບແມ່ນດໍາເນີນການ.
3. ການຕັ້ງຄ່າການຮ້ອງຂໍການດຶງ Kubernetes ແມ່ນຖືກສ້າງຂຶ້ນໃນທັນທີ (ຕົວຢ່າງ, ຕົວເລກຂອງມັນຖືກໃສ່ເຂົ້າໄປໃນແມ່ແບບສໍາເລັດຮູບ).
4. ການນໍາໃຊ້ kubectl ນໍາໃຊ້, ການຕັ້ງຄ່າຈະຖືກເພີ່ມໃສ່ກຸ່ມ (ປັບໃຊ້).
5. ການຮ້ອງຂໍດຶງຖືກລວມເຂົ້າໄປໃນສາຂາແມ່ບົດ.

ໃນຂະນະທີ່ທ່ານກໍາລັງເຮັດວຽກຢູ່ໃນຄໍາຮ້ອງຂໍການດຶງ, ແຕ່ລະຄໍາຫມັ້ນສັນຍາໃຫມ່ທີ່ຈະນໍາໄປໃຊ້ໃນປັດຈຸບັນສໍາລັບລະຫັດເກົ່າຈະຖືກລຶບຖິ້ມ, ແລະການນໍາໃຊ້ໃຫມ່ສໍາລັບລະຫັດໃຫມ່ແມ່ນ rolled ອອກ. ແຕ່ເມື່ອການຮ້ອງຂໍການດຶງໄດ້ຖືກລວມເຂົ້າໄປໃນສາຂາແມ່ບົດ, ມີພຽງແຕ່ສາຂາແມ່ບົດເທົ່ານັ້ນທີ່ຈະຖືກສ້າງຂຶ້ນ. ດັ່ງນັ້ນ, ມັນປະກົດວ່າພວກເຮົາໄດ້ລືມແລ້ວກ່ຽວກັບການຮ້ອງຂໍການດຶງ, ແລະຊັບພະຍາກອນ 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

Parameter namespaceSubstring ຕ້ອງການເພື່ອກັ່ນຕອງ namespaces ສໍາລັບການດຶງຄໍາຮ້ອງຂໍຈາກ namespaces ອື່ນໆ. ຕົວຢ່າງ, ຖ້າກຸ່ມມີ namespaces ຕໍ່ໄປນີ້: 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.

Parameter afterdaysWithoutDeploy ຕ້ອງການລຶບ namespaces ເກົ່າ. ຕົວຢ່າງ, ຖ້າ namespace ຖືກສ້າງຂຶ້ນ 3 дня 1 час ກັບຄືນໄປບ່ອນ, ແລະຕົວກໍານົດການຊີ້ໃຫ້ເຫັນ 3 дня, namespace ນີ້ຈະຖືກລຶບ. ມັນຍັງເຮັດວຽກໃນທິດທາງກົງກັນຂ້າມຖ້າ namespace ຖືກສ້າງຂຶ້ນ 2 дня 23 часа ກັບຄືນໄປບ່ອນ, ແລະຕົວກໍານົດການຊີ້ໃຫ້ເຫັນ 3 дня, namespace ນີ້ຈະບໍ່ຖືກລຶບ.

ມີຕົວກໍານົດການເພີ່ມເຕີມຫນຶ່ງ, ມັນເປັນຄວາມຮັບຜິດຊອບສໍາລັບການສະແກນ namespaces ທັງຫມົດເລື້ອຍໆແລະກວດເບິ່ງສໍາລັບມື້ໂດຍບໍ່ມີການນໍາໃຊ້ - ກວດ​ສອບ​ທຸກ​ນາ​ທີ​. ໂດຍຄ່າເລີ່ມຕົ້ນມັນເທົ່າກັບ 30 минутам.

ວິທີການເຮັດວຽກນີ້

ໃນ​ການ​ປະ​ຕິ​ບັດ​, ທ່ານ​ຈະ​ຕ້ອງ​ການ​:

1. Docker ສໍາລັບການເຮັດວຽກຢູ່ໃນສະພາບແວດລ້ອມທີ່ໂດດດ່ຽວ.
2. ມິນິຄິບ ຈະຍົກກຸ່ມ Kubernetes ຢູ່ໃນທ້ອງຖິ່ນ.
3. kubectl - ການໂຕ້ຕອບເສັ້ນຄໍາສັ່ງສໍາລັບການຄຸ້ມຄອງກຸ່ມ.

ພວກເຮົາຍົກກຸ່ມ 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

ນັບຕັ້ງແຕ່ການຕັ້ງຄ່າການຜະລິດຖືກຕັ້ງຄ່າເພື່ອກວດເບິ່ງ namespace ເກົ່າ, ແລະກຸ່ມທີ່ສ້າງຂຶ້ນໃຫມ່ຂອງພວກເຮົາບໍ່ມີພວກມັນ, ພວກເຮົາຈະປ່ຽນຕົວແປສະພາບແວດລ້ອມ. IS_DEBUG ສຸດ true. ດ້ວຍຄ່ານີ້ພາລາມິເຕີ afterDaysWithoutDeploy ບໍ່​ໄດ້​ຖືກ​ເອົາ​ເຂົ້າ​ໃນ​ບັນ​ຊີ​ແລະ namespaces ບໍ່​ໄດ້​ຖືກ​ກວດ​ສອບ​ສໍາ​ລັບ​ມື້​ໂດຍ​ບໍ່​ມີ​ການ​ນໍາ​ໃຊ້​, ພຽງ​ແຕ່​ສໍາ​ລັບ​ການ​ເກີດ​ຂຶ້ນ​ຂອງ substring (-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

ການ​ຕັ້ງ​ຄ່າ​ສະ​ແດງ​ໃຫ້​ເຫັນ​ການ​ຄົ້ນ​ຫາ​ສໍາ​ລັບ namespaces ກັບ substring ເປັນ​ -pr- ທຸກໆຄັ້ງ 1 минуту.:

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

ຜູ້ປະກອບການໄດ້ຕອບສະຫນອງແລະພ້ອມທີ່ຈະກວດສອບ namespaces:

$ 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, ປະກອບດ້ວຍສອງ namespaces (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, namespaces 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. ລຶບສາຂາຄຸນສົມບັດໃນລະຫວ່າງການສ້າງສາຂາແມ່ແບບຢ່າງຕໍ່ເນື່ອງ.

   • ເພື່ອເຮັດສິ່ງນີ້, ທ່ານຈໍາເປັນຕ້ອງຮູ້ວ່າຄໍາຮ້ອງຂໍດຶງທີ່ກ່ຽວຂ້ອງກັບຄໍາຫມັ້ນສັນຍາທີ່ຖືກສ້າງຂຶ້ນ. ເນື່ອງຈາກຄຸນສົມບັດສາຂາ namespace ມີຕົວລະບຸການຮ້ອງຂໍດຶງ - ຕົວເລກຂອງມັນ, ຫຼືຊື່ຂອງສາຂາ, ຕົວລະບຸຈະຕ້ອງຖືກລະບຸຢູ່ໃນຄໍາຫມັ້ນສັນຍາ.
   • ການສ້າງສາຂາແມ່ບົດລົ້ມເຫລວ. ສໍາລັບຕົວຢ່າງ, ທ່ານມີຂັ້ນຕອນດັ່ງຕໍ່ໄປນີ້: ດາວໂຫລດໂຄງການ, ດໍາເນີນການທົດສອບ, ການກໍ່ສ້າງໂຄງການ, ການປ່ອຍຕົວ, ສົ່ງການແຈ້ງເຕືອນ, ລ້າງສາຂາຄຸນນະສົມບັດຂອງຄໍາຮ້ອງຂໍດຶງສຸດທ້າຍ. ຖ້າການກໍ່ສ້າງລົ້ມເຫລວໃນເວລາສົ່ງການແຈ້ງເຕືອນ, ທ່ານຈະຕ້ອງລຶບຊັບພະຍາກອນທັງຫມົດໃນ cluster ດ້ວຍຕົນເອງ.
   • ຖ້າບໍ່ມີສະພາບການທີ່ເຫມາະສົມ, ການລຶບສາຂາຄຸນສົມບັດໃນ master build ແມ່ນບໍ່ຈະແຈ້ງ.

2. ໃຊ້ webhooks (ຕົວຢ່າງ).

   • ນີ້ອາດຈະບໍ່ແມ່ນວິທີການຂອງເຈົ້າ. ຕົວຢ່າງ, ໃນ Jenkins, ພຽງແຕ່ຫນຶ່ງປະເພດຂອງທໍ່ສະຫນັບສະຫນູນຄວາມສາມາດໃນການບັນທຶກການຕັ້ງຄ່າຂອງມັນຢູ່ໃນລະຫັດແຫຼ່ງ. ເມື່ອໃຊ້ webhooks, ທ່ານຈໍາເປັນຕ້ອງຂຽນ script ຂອງທ່ານເອງເພື່ອປຸງແຕ່ງພວກມັນ. script ນີ້ຈະຕ້ອງຖືກຈັດໃສ່ໃນການໂຕ້ຕອບ Jenkins, ເຊິ່ງຍາກທີ່ຈະຮັກສາ.

3. ການຂຽນ Cronjob ແລະເພີ່ມກຸ່ມ Kubernetes.

   • ໃຊ້ເວລາໃນການຂຽນແລະການສະຫນັບສະຫນູນ.
   • ຜູ້ປະກອບການເຮັດວຽກຢູ່ໃນຮູບແບບທີ່ຄ້າຍຄືກັນແລ້ວ, ຖືກບັນທຶກແລະສະຫນັບສະຫນູນ.

ຂໍຂອບໃຈທ່ານສໍາລັບຄວາມສົນໃຈຂອງທ່ານກັບບົດຄວາມ. ເຊື່ອມຕໍ່ກັບໂຄງການໃນ Github.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com