Kubernetes පොකුරක් තුළ යල් පැන ගිය විශේෂාංග ශාඛාවක් ඉවත් කිරීම

හෙලෝ! විශේෂාංග ශාඛාව (එනම් යෙදවීම පෙරදසුන, සමාලෝචන යෙදුම) - මෙය ප්‍රධාන ශාඛාව පමණක් නොව, අද්විතීය URL එකකට ඇදීමේ ඉල්ලීමක් යොදන විටය. කේතය නිෂ්පාදන පරිසරයක ක්‍රියා කරන්නේ දැයි ඔබට පරීක්ෂා කළ හැකිය; විශේෂාංගය වෙනත් ක්‍රමලේඛකයින්ට හෝ නිෂ්පාදන විශේෂඥයින්ට පෙන්විය හැක. ඔබ ඇදීමේ ඉල්ලීමක වැඩ කරන අතරතුර, පැරණි කේතය සඳහා එක් එක් නව කැපවීම වත්මන් යෙදවීම මකා දමනු ලබන අතර, නව කේතය සඳහා නව යෙදවීම සිදු කෙරේ. ඔබ ඇදීමේ ඉල්ලීමක් ප්‍රධාන ශාඛාව වෙත ඒකාබද්ධ කළ විට ප්‍රශ්න මතු විය හැක. ඔබට තවදුරටත් විශේෂාංග ශාඛාව අවශ්‍ය නොවේ, නමුත් 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):

1. අපි ශාඛාවට නව කැපවීමක් තල්ලු කරමු.
2. ගොඩනැගීමේදී, ලින්ටර් සහ/හෝ පරීක්ෂණ ක්‍රියාත්මක වේ.
3. කුබර්නෙට්ස් පුල් ඉල්ලීම් වින්‍යාසයන් පියාසර කරන විට ජනනය වේ (උදාහරණයක් ලෙස, එහි අංකය නිමි අච්චුවට ඇතුළත් කර ඇත).
4. kubectl apply භාවිතා කරමින්, වින්‍යාසයන් පොකුරට එකතු කරනු ලැබේ (deploy).
5. අදින්න ඉල්ලීම ප්‍රධාන ශාඛාවට ඒකාබද්ධ කර ඇත.

ඔබ ඇදීමේ ඉල්ලීමක වැඩ කරන අතරතුර, පැරණි කේතය සඳහා එක් එක් නව කැපවීම වත්මන් යෙදවීම මකා දමනු ලබන අතර, නව කේතය සඳහා නව යෙදවීම සිදු කෙරේ. හැබැයි පුල් රික්වෙස්ට් එකක් මාස්ටර් බ්‍රාන්ච් එකට මර්ජ් කලාම ගොඩ නැගෙන්නේ මාස්ටර් බ්‍රාන්ච් එක විතරයි. එහි ප්‍රතිඵලයක් වශයෙන්, ඇදීමේ ඉල්ලීම ගැන අපට දැනටමත් අමතක වී ඇති බවත්, එහි 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.

පරාමිතිය පසු දින විතවුට් ඩිප්ලෝයි පැරණි නාම අවකාශ මකා දැමීමට අවශ්‍ය විය. උදාහරණයක් ලෙස, නාම අවකාශය නිර්මාණය කරන්නේ නම් 3 дня 1 час ආපසු, සහ පරාමිතිය පෙන්නුම් කරයි 3 дня, මෙම නාම අවකාශය මකා දැමෙනු ඇත. නාම අවකාශය නිර්මාණය කළහොත් එය ද ප්‍රතිවිරුද්ධ දිශාවට ක්‍රියා කරයි 2 дня 23 часа ආපසු, සහ පරාමිතිය පෙන්නුම් කරයි 3 дня, මෙම නාම අවකාශය මකා නොදමනු ඇත.

තවත් එක් පරාමිතියක් ඇත, සියලු නාම අවකාශයන් කොපමණ වාරයක් පරිලෝකනය කළ යුතුද යන්න සහ යෙදවීමකින් තොරව දින පරීක්ෂා කිරීම සඳහා එය වගකිව යුතුය - සෑම මිනිත්තුවක්ම පරීක්ෂා කරන්න. පෙරනිමියෙන් එය සමාන වේ 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

නිෂ්පාදන වින්‍යාසයන් පැරණි නාම අවකාශ පරීක්ෂා කිරීමට වින්‍යාස කර ඇති නිසාත්, අපගේ අලුතින් මතු කරන ලද පොකුරේ ඒවා නොමැති නිසාත්, අපි පරිසර විචල්‍යය ප්‍රතිස්ථාපනය කරන්නෙමු. 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. webhooks භාවිතා කිරීම (උදාහරණයකි).

   • මෙය ඔබගේ ප්‍රවේශය නොවිය හැක. උදාහරණයක් ලෙස, in ජෙන්කින්ස්, ප්‍රභව කේතයේ එහි වින්‍යාසයන් සුරැකීමේ හැකියාව සඳහා සහාය වන්නේ එක් නල මාර්ගයක් පමණි. webhooks භාවිතා කරන විට, ඒවා සැකසීමට ඔබ ඔබේම පිටපතක් ලිවිය යුතුය. මෙම ස්ක්‍රිප්ට් එක නඩත්තු කිරීමට අපහසු ජෙන්කින්ස් අතුරු මුහුණතේ තැබීමට සිදුවේ.

3. ලිවීමට ක්‍රොන්ජොබ් සහ Kubernetes පොකුරක් එකතු කරන්න.

   • ලිවීමට සහ සහාය සඳහා කාලය ගත කිරීම.
   • ක්රියාකරු දැනටමත් සමාන ශෛලියකින් ක්රියා කරයි, ලේඛනගත කර සහය දක්වයි.

ලිපිය කෙරෙහි ඔබේ අවධානයට ස්තූතියි. Github හි ව්‍යාපෘතියට සබැඳිය.

මූලාශ්රය: www.habr.com