Kubernetes ક્લસ્ટરમાં જૂની સુવિધા શાખાને દૂર કરી રહ્યાં છીએ

હેલો! ફીચર શાખા (ઉર્ફ ડિપ્લોય પ્રીવ્યૂ, રિવ્યુ એપ) - આ ત્યારે થાય છે જ્યારે માત્ર માસ્ટર બ્રાન્ચ જ તૈનાત કરવામાં આવતી નથી, પરંતુ દરેક પુલ રિક્વેસ્ટને એક અનન્ય 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
...

સામાન્ય રીતે, મેં લખ્યું કુબરનેટ્સ ઓપરેટર (એક એપ્લિકેશન જે ક્લસ્ટર સંસાધનોની ઍક્સેસ ધરાવે છે), ગીથબ પર પ્રોજેક્ટની લિંક. તે નેમસ્પેસને દૂર કરે છે જે જૂની વિશેષતા શાખાઓથી સંબંધિત છે. કુબરનેટ્સમાં, જો તમે નેમસ્પેસ કાઢી નાખો છો, તો તે નેમસ્પેસના અન્ય સંસાધનો પણ આપમેળે કાઢી નાખવામાં આવે છે.

$ 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 પુલ વિનંતી ગોઠવણી ફ્લાય પર જનરેટ થાય છે (ઉદાહરણ તરીકે, તેનો નંબર ફિનિશ્ડ ટેમ્પલેટમાં દાખલ કરવામાં આવે છે).
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

પેરામીટર નેમસ્પેસ સબસ્ટ્રિંગ અન્ય નેમસ્પેસમાંથી પુલ વિનંતીઓ માટે નેમસ્પેસ ફિલ્ટર કરવા માટે જરૂરી છે. ઉદાહરણ તરીકે, જો ક્લસ્ટરમાં નીચેની નેમસ્પેસ છે: 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 минутам.

આ કેવી રીતે કામ કરે છે

વ્યવહારમાં, તમારે આની જરૂર પડશે:

1. Docker અલગ વાતાવરણમાં કામ કરવા માટે.
2. મિનીકુબે સ્થાનિક રીતે કુબરનેટીસ ક્લસ્ટર ઊભું કરશે.
3. kubectl - ક્લસ્ટર મેનેજમેન્ટ માટે કમાન્ડ લાઇન ઇન્ટરફેસ.

અમે સ્થાનિક રીતે કુબરનેટ્સ ક્લસ્ટર ઉભા કરીએ છીએ:

$ 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