ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിലെ കാലഹരണപ്പെട്ട ഫീച്ചർ ബ്രാഞ്ച് നീക്കംചെയ്യുന്നു

ഹലോ! ഫീച്ചർ ബ്രാഞ്ച് (അതായത് വിന്യസിക്കുക പ്രിവ്യൂ, റിവ്യൂ ആപ്പ്) - ഇത് മാസ്റ്റർ ബ്രാഞ്ച് വിന്യസിക്കുമ്പോൾ മാത്രമല്ല, ഓരോ അഭ്യർത്ഥനയും ഒരു അദ്വിതീയ URL-ലേയ്ക്കാണ്. ഒരു പ്രൊഡക്ഷൻ പരിതസ്ഥിതിയിൽ കോഡ് പ്രവർത്തിക്കുന്നുണ്ടോയെന്ന് നിങ്ങൾക്ക് പരിശോധിക്കാം; ഫീച്ചർ മറ്റ് പ്രോഗ്രാമർമാർക്കോ ഉൽപ്പന്ന സ്പെഷ്യലിസ്റ്റുകൾക്കോ ​​കാണിക്കാനാകും. നിങ്ങൾ ഒരു പുൾ അഭ്യർത്ഥനയിൽ പ്രവർത്തിക്കുമ്പോൾ, പഴയ കോഡിനായുള്ള ഓരോ പുതിയ കമ്മിറ്റ് കറന്റ് ഡിപ്ലോയും ഇല്ലാതാക്കപ്പെടും, പുതിയ കോഡിനായി പുതിയ വിന്യാസം പുറത്തിറക്കും. നിങ്ങൾ ഒരു പുൾ അഭ്യർത്ഥന മാസ്റ്റർ ബ്രാഞ്ചിലേക്ക് ലയിപ്പിക്കുമ്പോൾ ചോദ്യങ്ങൾ ഉയർന്നേക്കാം. നിങ്ങൾക്ക് ഇനി ഫീച്ചർ ബ്രാഞ്ച് ആവശ്യമില്ല, എന്നാൽ കുബർനെറ്റസ് ഉറവിടങ്ങൾ ഇപ്പോഴും ക്ലസ്റ്ററിലാണ്.

ഫീച്ചർ ബ്രാഞ്ചുകളെക്കുറിച്ച് കൂടുതൽ

കുബർനെറ്റസിൽ ഫീച്ചർ ബ്രാഞ്ചുകൾ ഉണ്ടാക്കുന്നതിനുള്ള ഒരു സമീപനം നെയിംസ്‌പെയ്‌സുകൾ ഉപയോഗിക്കുക എന്നതാണ്. ചുരുക്കത്തിൽ, പ്രൊഡക്ഷൻ കോൺഫിഗറേഷൻ ഇതുപോലെ കാണപ്പെടുന്നു:

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
...

പൊതുവേ, ഞാൻ എഴുതി കുബർനെറ്റസ് ഓപ്പറേറ്റർ (ക്ലസ്റ്റർ ഉറവിടങ്ങളിലേക്ക് ആക്‌സസ് ഉള്ള ഒരു ആപ്ലിക്കേഷൻ), Github-ലെ പദ്ധതിയിലേക്കുള്ള ലിങ്ക്. പഴയ ഫീച്ചർ ശാഖകളുടേതായ നെയിംസ്‌പെയ്‌സുകൾ ഇത് നീക്കം ചെയ്യുന്നു. കുബർനെറ്റസിൽ, നിങ്ങൾ ഒരു നെയിംസ്‌പെയ്‌സ് ഇല്ലാതാക്കുകയാണെങ്കിൽ, ആ നെയിംസ്‌പെയ്‌സിലെ മറ്റ് ഉറവിടങ്ങളും സ്വയമേവ ഇല്ലാതാക്കപ്പെടും.

$ 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. കുബർനെറ്റസ് പുൾ അഭ്യർത്ഥന കോൺഫിഗറേഷനുകൾ ഫ്ലൈയിൽ ജനറേറ്റുചെയ്യുന്നു (ഉദാഹരണത്തിന്, പൂർത്തിയായ ടെംപ്ലേറ്റിൽ അതിന്റെ നമ്പർ ചേർത്തിരിക്കുന്നു).
4. kubectl apply ഉപയോഗിച്ച്, കോൺഫിഗറേഷനുകൾ ക്ലസ്റ്ററിലേക്ക് ചേർക്കുന്നു (വിന്യാസം).
5. പുൾ അഭ്യർത്ഥന മാസ്റ്റർ ബ്രാഞ്ചിലേക്ക് ലയിപ്പിച്ചിരിക്കുന്നു.

നിങ്ങൾ ഒരു പുൾ അഭ്യർത്ഥനയിൽ പ്രവർത്തിക്കുമ്പോൾ, പഴയ കോഡിനായുള്ള ഓരോ പുതിയ കമ്മിറ്റ് കറന്റ് ഡിപ്ലോയും ഇല്ലാതാക്കപ്പെടും, പുതിയ കോഡിനായി പുതിയ വിന്യാസം പുറത്തിറക്കും. എന്നാൽ ഒരു പുൾ റിക്വസ്റ്റ് മാസ്റ്റർ ബ്രാഞ്ചിൽ ലയിപ്പിക്കുമ്പോൾ, മാസ്റ്റർ ബ്രാഞ്ച് മാത്രമേ നിർമ്മിക്കപ്പെടുകയുള്ളൂ. തൽഫലമായി, പുൾ അഭ്യർത്ഥനയെക്കുറിച്ച് ഞങ്ങൾ ഇതിനകം മറന്നുവെന്നും അതിന്റെ കുബർനെറ്റസ് ഉറവിടങ്ങൾ ഇപ്പോഴും ക്ലസ്റ്ററിലാണെന്നും ഇത് മാറുന്നു.

എങ്ങനെ ഉപയോഗിക്കാം

ചുവടെയുള്ള കമാൻഡ് ഉപയോഗിച്ച് പ്രോജക്റ്റ് ഇൻസ്റ്റാൾ ചെയ്യുക:

$ 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.

പാരാമീറ്റർ ശേഷംDays WithoutDeploy പഴയ നെയിംസ്പേസുകൾ ഇല്ലാതാക്കേണ്ടതുണ്ട്. ഉദാഹരണത്തിന്, നെയിംസ്പേസ് സൃഷ്ടിച്ചാൽ 3 дня 1 час തിരികെ, ഒപ്പം പരാമീറ്റർ സൂചിപ്പിക്കുന്നു 3 дня, ഈ നെയിംസ്പേസ് ഇല്ലാതാക്കപ്പെടും. നെയിംസ്പേസ് ഉണ്ടാക്കിയാൽ അത് വിപരീത ദിശയിലും പ്രവർത്തിക്കുന്നു 2 дня 23 часа തിരികെ, ഒപ്പം പരാമീറ്റർ സൂചിപ്പിക്കുന്നു 3 дня, ഈ നെയിംസ്പേസ് ഇല്ലാതാക്കില്ല.

ഒരു പാരാമീറ്റർ കൂടിയുണ്ട്, എല്ലാ നെയിംസ്‌പെയ്‌സുകളും എത്ര തവണ സ്‌കാൻ ചെയ്യണമെന്നും വിന്യാസം കൂടാതെ ദിവസങ്ങൾ പരിശോധിക്കണമെന്നും ഇത് ഉത്തരവാദിയാണ് - ഓരോ മിനിറ്റിലും പരിശോധിക്കുക. സ്ഥിരസ്ഥിതിയായി ഇത് തുല്യമാണ് 30 минутам.

എങ്ങനെ പ്രവർത്തിക്കുന്നില്ല

പ്രായോഗികമായി, നിങ്ങൾക്ക് ഇത് ആവശ്യമാണ്:

1. ഡോക്കർ ഒറ്റപ്പെട്ട അന്തരീക്ഷത്തിൽ ജോലി ചെയ്തതിന്.
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 ഓൺ 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. മാസ്റ്റർ ബ്രാഞ്ചിന്റെ തുടർച്ചയായ സംയോജന സമയത്ത് ഫീച്ചർ ബ്രാഞ്ച് ഇല്ലാതാക്കുക.

   • ഇത് ചെയ്യുന്നതിന്, ഏത് പുൾ അഭ്യർത്ഥനയാണ് നിർമ്മിക്കുന്ന പ്രതിബദ്ധതയുമായി ബന്ധപ്പെട്ടതെന്ന് നിങ്ങൾ അറിയേണ്ടതുണ്ട്. ഫീച്ചർ ബ്രാഞ്ച് നെയിംസ്‌പെയ്‌സിൽ പുൾ അഭ്യർത്ഥന ഐഡന്റിഫയർ അടങ്ങിയിരിക്കുന്നതിനാൽ - അതിന്റെ നമ്പർ അല്ലെങ്കിൽ ബ്രാഞ്ചിന്റെ പേര്, ഐഡന്റിഫയർ എല്ലായ്പ്പോഴും കമ്മിറ്റിൽ വ്യക്തമാക്കേണ്ടതുണ്ട്.
   • മാസ്റ്റർ ബ്രാഞ്ച് നിർമ്മാണം പരാജയപ്പെടുന്നു. ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് ഇനിപ്പറയുന്ന ഘട്ടങ്ങളുണ്ട്: പ്രോജക്റ്റ് ഡൗൺലോഡ് ചെയ്യുക, ടെസ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുക, പ്രോജക്റ്റ് നിർമ്മിക്കുക, റിലീസ് ചെയ്യുക, അറിയിപ്പുകൾ അയയ്ക്കുക, അവസാനത്തെ പുൾ അഭ്യർത്ഥനയുടെ ഫീച്ചർ ബ്രാഞ്ച് മായ്‌ക്കുക. ഒരു അറിയിപ്പ് അയയ്‌ക്കുമ്പോൾ ബിൽഡ് പരാജയപ്പെടുകയാണെങ്കിൽ, ക്ലസ്റ്ററിലെ എല്ലാ ഉറവിടങ്ങളും നിങ്ങൾ സ്വമേധയാ ഇല്ലാതാക്കേണ്ടതുണ്ട്.
   • ശരിയായ സന്ദർഭമില്ലാതെ, മാസ്റ്റർ ബിൽഡിലെ ഫീച്ചർ ബ്രാഞ്ചുകൾ ഇല്ലാതാക്കുന്നത് വ്യക്തമല്ല.

2. വെബ്‌ഹുക്കുകൾ ഉപയോഗിക്കുന്നു (ഉദാഹരണം).

   • ഇത് നിങ്ങളുടെ സമീപനമായിരിക്കില്ല. ഉദാഹരണത്തിന്, ഇൻ ജെങ്കിൻസ്, ഒരു തരം പൈപ്പ്ലൈൻ മാത്രമേ അതിന്റെ കോൺഫിഗറേഷനുകൾ സോഴ്സ് കോഡിൽ സംരക്ഷിക്കാനുള്ള കഴിവിനെ പിന്തുണയ്ക്കൂ. വെബ്‌ഹുക്കുകൾ ഉപയോഗിക്കുമ്പോൾ, അവ പ്രോസസ്സ് ചെയ്യുന്നതിന് നിങ്ങളുടേതായ സ്‌ക്രിപ്റ്റ് എഴുതേണ്ടതുണ്ട്. ഈ സ്ക്രിപ്റ്റ് ജെങ്കിൻസ് ഇന്റർഫേസിൽ സ്ഥാപിക്കേണ്ടതുണ്ട്, അത് പരിപാലിക്കാൻ പ്രയാസമാണ്.

3. എഴുതാൻ ക്രോൺജോബ് ഒരു കുബർനെറ്റസ് ക്ലസ്റ്റർ ചേർക്കുക.

   • എഴുത്തിനും പിന്തുണക്കുമായി സമയം ചെലവഴിക്കുന്നു.
   • ഓപ്പറേറ്റർ ഇതിനകം സമാനമായ ശൈലിയിൽ പ്രവർത്തിക്കുന്നു, രേഖപ്പെടുത്തുകയും പിന്തുണയ്ക്കുകയും ചെയ്യുന്നു.

ലേഖനത്തിൽ നിങ്ങളുടെ ശ്രദ്ധയ്ക്ക് നന്ദി. Github-ലെ പ്രോജക്റ്റിലേക്കുള്ള ലിങ്ക്.

അവലംബം: www.habr.com