ProHoster > Blog > Stjórnsýsla > Fjarlægir úrelta eiginleikagrein í Kubernetes klasa

Fjarlægir úrelta eiginleikagrein í Kubernetes klasa

Fjarlægir úrelta eiginleikagrein í Kubernetes klasa

РџСЂРІРμы! Eiginleikagrein (aka dreifðu forskoðun, endurskoðunarforrit) - þetta er þegar ekki aðeins aðalútibúið er sett upp, heldur einnig hver dráttarbeiðni á einstaka vefslóð. Þú getur athugað hvort kóðinn virkar í framleiðsluumhverfi; hægt er að sýna eiginleikann öðrum forriturum eða vörusérfræðingum. Á meðan þú ert að vinna í dráttarbeiðni er hverri nýrri commit núverandi dreifingu fyrir gamla kóðann eytt og nýja dreifingin fyrir nýja kóðann er sett út. Spurningar gætu komið upp þegar þú sameinaðir dráttarbeiðni í aðalútibúið. Þú þarft ekki lengur eiginleikagreinina, en Kubernetes tilföngin eru enn í þyrpingunni.

Meira um útibú

Ein aðferð til að búa til eiginleikaútibú í Kubernetes er að nota nafnarými. Í stuttu máli lítur framleiðslustillingin svona út:

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

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

Fyrir eiginleikagrein er nafnrými búið til með auðkenni þess (til dæmis númeri dráttarbeiðni) og einhvers konar forskeyti/eftirfestu (til dæmis, -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
...

Almennt skrifaði ég Kubernetes rekstraraðili (forrit sem hefur aðgang að klasaauðlindum), hlekkur á verkefnið á Github. Það fjarlægir nafnrými sem tilheyra gömlum eiginleikum. Í Kubernetes, ef þú eyðir nafnrými, er öðrum tilföngum í því nafnrými einnig eytt sjálfkrafa.

$ kubectl get pods --all-namespaces | grep -e "-pr-"
NAMESPACE            ... AGE
habr-back-end-pr-264 ... 4d8h
habr-back-end-pr-265 ... 5d7h

Þú getur lesið um hvernig á að innleiða eiginleikagreinar í klasa hér и hér.

Hvatning

Við skulum líta á dæmigerðan líftíma dráttarbeiðna með stöðugri samþættingu (continuous integration):

  1. Við ýtum nýjum skuldbindingum til útibúsins.
  2. Á smíðinni eru linters og/eða prófanir keyrðar.
  3. Stillingar Kubernetes togbeiðna eru búnar til á flugi (til dæmis er númer þess sett inn í fullbúið sniðmát).
  4. Með því að nota kubectl application er stillingum bætt við þyrpinguna (dreifa).
  5. Pullbeiðni er sameinuð í aðalútibúið.

Á meðan þú ert að vinna í dráttarbeiðni er hverri nýrri commit núverandi dreifingu fyrir gamla kóðann eytt og nýja dreifingin fyrir nýja kóðann er sett út. En þegar dráttarbeiðni er sameinuð í aðalútibúið verður aðeins aðalútibúið byggt. Fyrir vikið kemur í ljós að við höfum þegar gleymt dragbeiðninni og Kubernetes auðlindir hennar eru enn í klasanum.

Hvernig á að nota

Settu upp verkefnið með skipuninni hér að neðan:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml

Búðu til skrá með eftirfarandi efni og settu upp í gegnum kubectl apply -f:

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

Viðfang nafnrými Undirstrengur þarf til að sía nafnrými fyrir dráttarbeiðnir frá öðrum nafnasvæðum. Til dæmis, ef þyrpingin hefur eftirfarandi nafnrými: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, þá verða frambjóðendur til eyðingar habr-back-end-pr-17, habr-back-end-pr-33.

Viðfang afterDaysWithoutDeploy þarf til að eyða gömlum nafnasvæðum. Til dæmis ef nafnrými er búið til 3 дня 1 час til baka, og færibreytan gefur til kynna 3 дня, þessu nafnrými verður eytt. Það virkar líka í gagnstæða átt ef nafnrýmið er búið til 2 дня 23 часа til baka, og færibreytan gefur til kynna 3 дня, þessu nafnrými verður ekki eytt.

Það er ein færibreyta í viðbót, hún er ábyrg fyrir því hversu oft á að skanna öll nafnarými og athuga í marga daga án dreifingar - athugaEveryMinutes. Sjálfgefið er það jafnt og 30 минутам.

Hvernig virkar þetta

Í reynd þarftu:

  1. Docker fyrir að vinna í einangruðu umhverfi.
  2. Minikube mun ala upp Kubernetes klasa á staðnum.
  3. kubectl — skipanalínuviðmót fyrir klasastjórnun.

Við ræktum Kubernetes klasa á staðnum:

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

Við gefum til kynna kubectl notaðu staðbundna klasa sjálfgefið:

$ kubectl config use-context minikube
Switched to context "minikube".

Hlaða niður stillingum fyrir framleiðsluumhverfið:

$ curl https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml > stale-feature-branch-production-configs.yml

Þar sem framleiðslustillingar eru stilltar til að athuga gömul nafnrými, og nýlega ræktaður þyrpingin okkar er ekki með þau, munum við skipta um umhverfisbreytu IS_DEBUG á true. Með þessu gildi er færibreytan afterDaysWithoutDeploy er ekki tekið með í reikninginn og nafnarými eru ekki athugað í marga daga án uppsetningar, aðeins fyrir tilvik undirstrengs (-pr-).

Ef þú ert á Linux:

$ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml

Ef þú ert á macOS:

$ sed -i "" 's|false|true|g' stale-feature-branch-production-configs.yml

Uppsetning verkefnisins:

$ kubectl apply -f stale-feature-branch-production-configs.yml

Athugar hvort tilföng hafi birst í klasanum StaleFeatureBranch:

$ kubectl api-resources | grep stalefeaturebranches
NAME                 ... APIGROUP                             ... KIND
stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch

Við athugum hvort rekstraraðili hafi birst í þyrpingunni:

$ kubectl get pods --namespace stale-feature-branch-operator
NAME                                           ... STATUS  ... AGE
stale-feature-branch-operator-6bfbfd4df8-m7sch ... Running ... 38s

Ef þú skoðar annála þess er það tilbúið til að vinna úr auðlindum 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}

Við setjum upp tilbúna fixtures (tilbúnar stillingar fyrir líkanagerð fyrir klasaauðlindir) fyrir tilföng StaleFeatureBranch:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/stale-feature-branch.yml

Stillingar gefa til kynna að leitað sé að nafnasvæðum með undirstreng -pr- einu sinni inn 1 минуту.:

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

Rekstraraðili hefur svarað og er tilbúinn til að athuga nafnarými:

$ 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"}

Setja upp fixtures, sem inniheldur tvö nafnrými (project-pr-1, project-pr-2) og þeim deployments, services, ingress, og svo framvegis:

$ 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

Við athugum að öll tilföngin hér að ofan hafi verið búin til:

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

Þar sem við tókum með debug, nafnarými project-pr-1 и project-pr-2, því verður að eyða öllum öðrum tilföngum strax án þess að taka tillit til færibreytunnar afterDaysWithoutDeploy. Þetta má sjá í rekstrarskránum:

$ 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"}

Ef þú athugar framboð á tilföngum verða þau í stöðunni Terminating (eyðingarferli) eða þegar eytt (úttak skipana er tómt).

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

Þú getur endurtekið sköpunarferlið fixtures nokkrum sinnum og vertu viss um að þau séu fjarlægð innan mínútu.

Valkostir

Hvað er hægt að gera í stað rekstraraðila sem vinnur í klasa? Það eru nokkrar aðferðir, allar eru þær ófullkomnar (og gallar þeirra eru huglægir) og hver og einn ákveður sjálfur hvað er best fyrir tiltekið verkefni:

  1. Eyða eiginleika útibúi meðan á samfelldri samþættingu bygginga aðalútibús stendur.

    • Til að gera þetta þarftu að vita hvaða dráttarbeiðni tengist skuldbindingunni sem verið er að smíða. Þar sem nafnsvæði eiginleikaútibúa inniheldur auðkenni dragbeiðni - númer þess, eða nafn útibúsins, verður auðkennið alltaf að vera tilgreint í commitinu.
    • Uppbygging meistaragreina mistakast. Til dæmis, þú hefur eftirfarandi stig: hlaða niður verkefninu, keyrðu próf, byggðu verkefnið, gerðu útgáfu, sendu tilkynningar, hreinsaðu eiginleikagrein síðustu dráttarbeiðni. Ef smíðin mistekst þegar tilkynning er send verður þú að eyða öllum tilföngum í þyrpingunni handvirkt.
    • Án rétts samhengis er ekki augljóst að eyða eiginleikagreinum í aðalbyggingunni.

  2. Notkun vefhooks (Dæmi).

    • Þetta er kannski ekki nálgun þín. Til dæmis, í Jenkins, aðeins ein tegund leiðslu styður getu til að vista stillingar sínar í frumkóðanum. Þegar þú notar webhooks þarftu að skrifa þitt eigið handrit til að vinna úr þeim. Þetta handrit verður að setja í Jenkins viðmótið, sem er erfitt að viðhalda.

  3. Að skrifa Cronjob og bæta við Kubernetes klasa.

    • Að eyða tíma í að skrifa og styðja.
    • Rekstraraðilinn vinnur nú þegar í svipuðum stíl, er skjalfestur og studdur.

Þakka þér fyrir athygli þína á greininni. Tengill á verkefnið á Github.

Heimild: www.habr.com

Bæta við athugasemd