ProHoster >> Blog >> Administrimi >> Heqim branch-in e vjetruar të funksionalitetit në klasterin Kubernetes

Heqim branch-in e vjetruar të funksionalitetit në klasterin Kubernetes

Heqim branch-in e vjetruar të funksionalitetit në klasterin Kubernetes

PĂ«rshĂ«ndetje! Dega feature (nĂ« tĂ« ashtuquajturĂ«n deploy preview, review app) — kjo ndodh kur deployohet jo vetĂ«m dega master, por edhe çdo pull request nĂ« njĂ« URL unik. Mund tĂ« kontrolloni nĂ«se kodi funksionon nĂ« ambientin production, dhe funksionin mund ta tregoni programuesve tĂ« tjerĂ« ose produktologĂ«ve. NdĂ«rsa po punoni nĂ« pull request, çdo commit i ri anulon deploy-n aktual pĂ«r kodin e vjetĂ«r, dhe njĂ« deploy i ri pĂ«r kodin e ri hapet. Pyetje mund tĂ« lindin kur e keni bashkuar pull request-in nĂ« degĂ«n master. Dega e funksionit nuk ju nevojitet mĂ«, por resurset e Kubernetes ende ndodhen nĂ« klaster.

Më shumë për degat e funksionit

Një nga qasjet për të bërë degat e funksionit në Kubernetes është përdorimi i namespace-ve. Nëse do ta thjeshtojmë, konfigurimet e production duken kështu:

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

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

Për dega të funksionit krijohet një namespace me identifikuesin e saj (për shembull, numri i pull request-it) dhe një prefiks/postfix të caktuar (për shembull, -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
...

Në përgjithësi, unë shkrova Kubernetes Operator (aplikacioni që ka qasje në resurset e klasterit), shkolla për projektin në Github. Ai heq namespace-t që i përkasin degëve të vjetra të funksioneve. Në Kubernetes, nëse hiqet një namespace, burimet e tjera në atë namespace gjithashtu hiqen automatikisht.

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

Për mënyrën se si të implementoni degët e funksioneve në klaster, mund të lexoni këtu dhe këtu.

Motivimi

Le të shohim një cikël të zakonshëm jetësor të një kërkese për tërheqje me integrimin e vazhdueshëm (integrimi i vazhdueshëm):

  1. Shtojmë një commit të ri në degë.
  2. Gjatë ndërtimit, aktivizohen linters dhe/ose testet.
  3. Në kohë reale formohen konfigurimet e kërkesës për tërheqje në Kubernetes (për shembull, numri i saj vendoset në një shabllon të gatshëm).
  4. Me ndihmën e kubectl apply, konfigurimet hyjnë në klaster (deploy).
  5. Kërkesat për tërheqje bashkohen në degën master.

Ndërsa punoni në kërkesën për tërheqje, çdo commit i ri heq deploy-in aktual për kodin e vjetër dhe nxjerr një deploy të ri për kodin e ri. Por kur kërkesa për tërheqje bashkohet në degën master, do të ndërtohet vetëm dega master. Si rezultat, harrojmë për kërkesën për tërheqje, por burimet e saj Kubernetes ende ndodhen në klaster.

Si të përdorim

Instaloni projektin me komandën më poshtë:

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

Krijo një skedar me përmbajtjen e mëposhtme dhe vendos përmes kubectl apply -f:

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

Parametri namespaceSubstring nevojitet për të filtruar namespace-t për kërkesat e tërheqjes nga namespace të tjera. Për shembull, nëse në klaster ka këto namespace: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, atëherë kandidatët për fshirje do të jenë habr-back-end-pr-17, habr-back-end-pr-33.

Parametri afterDaysWithoutDeploy nevojitet për të fshirë namespace-t e vjetra. Për shembull, nëse namespace është krijuar 3 ditë 1 orë më parë, dhe në parametrin është caktuar 3 ditë, ky namespace do të fshihet. Funksionon edhe në anën tjetër, nëse namespace është krijuar 2 ditë 23 orë më parë, dhe në parametrin është caktuar 3 ditë, ky namespace nuk do të fshihet.

Ka edhe njĂ« parametĂ«r tjetĂ«r, ai pĂ«rgjigjet pĂ«r sa shpesh skanohet tĂ« gjithĂ« namespace-t dhe kontrollohet pĂ«r ditĂ«t pa deploy — checkEveryMinutes. NĂ« mĂ«nyrĂ« tĂ« paracaktuar, ai Ă«shtĂ« i barabartĂ« me 30 minuta.

Si funksionon

Në praktikë, do të nevojitet:

  1. Docker për të punuar në një mjedis të izoluar.
  2. Minikube do të ngrejë klasterin Kubernetes lokal.
  3. kubectl — ndĂ«rfaqja e komandave pĂ«r tĂ« menaxhuar klasterin.

Ngremë klasterin Kubernetes lokal:

$ minikube start --vm-driver=docker
minikube v1.11.0 në Darwin 10.15.5
Duke përdorur drejtuesin docker në bazë të profilit ekzistues.
Duke filluar kontrollin e planeve minikube në klasterin minikube.

Tregojmë kubectl përdor klasterin lokal si parazgjedhje:

$ kubectl config use-context minikube
Kalova në kontekstin "minikube".

Po shkarkojmë konfiguratat për ambientin e production-it:

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

Pasi konfiguratat e production-it janë vendosur të kontrollojnë namespace-t e vjetra, dhe në klasterin tonë të sapo krijuar nuk ka asnjë, do të zëvendësojmë variablën e ambientit IS_DEBUG në e vërtetë. Me këtë vlerë, parametri afterDaysWithoutDeploy nuk merret parasysh dhe namespace-t nuk kontrollohen për ditë pa deploy, vetëm për përmbajtjen e nënstringut (-pr-).

Nëse jeni në Linux:

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

Nëse jeni në macOS:

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

Po instalojmë projektin:

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

Po kontrollojmë që resurset janë shfaqur në klaster StaleFeatureBranch:

$ kubectl api-resources | grep stalefeaturebranches
EMRI                 ... APIGROUP                             ... LLOJI
stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch

Po kontrollojmë që operatori është shfaqur në klaster:

$ kubectl get pods --namespace stale-feature-branch-operator
EMRI                                           ... STATUS  ... MOSHA
stale-feature-branch-operator-6bfbfd4df8-m7sch ... Duke funksionuar ... 38s

Nëse shikoni në logjet e tij, ai është gati të përpunojë resurset StaleFeatureBranch:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Versioni i Operatorit: 0.0.1"}
...
... "msg":"Duke filluar EventSource", ... , "source":"lloji i burimit: /, Lloji="}
... "msg":"Duke filluar Kontrolluesin", ...}
... "msg":"Duke filluar punëtorët", ..., "numri i punëtorëve":1}

Instalojmë gotiot fixtures (konfigurime të gatshme për simulimin e burimeve të klasës) për burimin StaleFeatureBranch:

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

Konfigurimet specifikojnĂ« tĂ« kĂ«rkojnĂ« namespace’ë me nĂ«npjesĂ«n -pr- njĂ« herĂ« nĂ« 1 minutĂ«.:

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

Operatori ka reaguar dhe Ă«shtĂ« gati tĂ« kontrollojĂ« namespace’ët:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Gurëza e branches së vjetra po përshkruhet.","namespaceSubstring":"-pr-","afterDaysWithoutDeploy":1,"checkEveryMinutes":1,"isDebug":"true"}

InstalojmĂ« fixtures, qĂ« pĂ«rmban dy namespace’a (project-pr-1, project-pr-2) dhe shĂ«rbimet e tyre dispozita, , dhe kĂ«shtu me radhĂ«:, ingress, dhe kĂ«shtu me radhĂ«:

$ 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

Kontrollojmë që të gjitha burimet e lartpërmendura janë krijuar me sukses:

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

Duke bërë këtë, debug, namespace-të project-pr-1 dhe project-pr-2, gjithashtu të gjitha burimet e tjera, duhet të fshihen menjëherë pa marrë parasysh parametrin afterDaysWithoutDeploy. Në logët e operatorit kjo është e dukshme:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Namespace duhet të fshihet për shkak se moda e debugging është e aktivizuar.","namespaceName":"project-pr-1"}
... "msg":"Namespace është duke u përpunuar.","namespaceName":"project-pr-1","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace është fshirë.","namespaceName":"project-pr-1"}
... "msg":"Namespace duhet të fshihet për shkak se moda e debugging është e aktivizuar.","namespaceName":"project-pr-2"}
... "msg":"Namespace është duke u përpunuar.","namespaceName":"project-pr-2","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace është fshirë.","namespaceName":"project-pr-2"}

Nëse kontrolloni disponueshmërinë e burimeve, ato do të jenë në statusin Duke u përfunduar (procesi i fshirjes) ose tashmë janë fshirë (dalja e komandës është e zbrazët).

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

Mund të përsërisni procesin e krijimit fixtures disa herë dhe të siguroheni që ato do të fshihen brenda një minute.

Alternativat

ÇfarĂ« mund tĂ« bĂ«ni nĂ« vend tĂ« operatorit qĂ« punon nĂ« klaster? Ka disa qasje, tĂ« gjitha nuk janĂ« tĂ« pĂ«rsosura (dhe disavantazhet e tyre janĂ« subjektive), dhe secili vendos se cila Ă«shtĂ« mĂ« e pĂ«rshtatshme pĂ«r projektin specifik:

  1. Të fshini branch-in e karakteristikave gjatë ndërtimit të integrimit të vazhdueshëm të branch-it master.

    • PĂ«r kĂ«tĂ«, duhet tĂ« dini se cilin pull request i pĂ«rket commit-it qĂ« po ndĂ«rtohet. Duke qenĂ« se emri i hapĂ«sirĂ«s sĂ« branch-it tĂ« veçorisĂ« pĂ«rmban identifikuesin e pull request-it — numrin e tij ose emrin e branch-it, identifikuesi gjithmonĂ« duhet tĂ« pĂ«rmendet nĂ« commit.
    • NdĂ«rtesat e branch-it master dĂ«shtojnĂ«. PĂ«r shembull, keni kĂ«to etapa: shkarkoni projektin, ekzekutoni testet, ndĂ«rtoni projektin, bĂ«ni lĂ«shimin, dĂ«rgoni njoftimet, pastroni branch-in e veçorisĂ« sĂ« pull request-it tĂ« fundit. NĂ«se ndĂ«rtimi dĂ«shtoi nĂ« dĂ«rgimin e njoftimit, do t'ju duhet tĂ« fshini tĂ« gjitha burimet nĂ« klaster manualisht.
    • Pa kontekst tĂ« duhur, fshirja e branch-it tĂ« veçorisĂ« nĂ« ndĂ«rtimin master nuk Ă«shtĂ« e qartĂ«.

  2. PĂ«rdorimi i webhook-ve (shembull).

    • MundĂ«sisht, kjo nuk Ă«shtĂ« qasja juaj. PĂ«r shembull, nĂ« Jenkins, vetĂ«m njĂ« lloj pipeline-i mbĂ«shtet mundĂ«sinĂ« pĂ«r tĂ« ruajtur konfigurimet e tij nĂ« kodin burimor. NĂ« pĂ«rdorimin e webhook-ve, duhet tĂ« shkruani skriptin tuaj pĂ«r pĂ«rpunimin e tyre. Ky skript do tĂ« duhet tĂ« vendoset nĂ« ndĂ«rfaqen e Jenkins-it, çka Ă«shtĂ« e vĂ«shtirĂ« pĂ«r t'u mbajtur.

  3. Shkruani Cronjob dhe shtoni klasterin Kubernetes.

    • Kosto kohe pĂ«r tĂ« shkruar dhe mbajtur.
    • Operatori tashmĂ« funksionon nĂ« njĂ« stil tĂ« ngjashĂ«m, Ă«shtĂ« dokumentuar dhe mbĂ«shtetet.

Faleminderit për vëmendjen ndaj artikullit. Lidhja me projektin në Github.

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster