Ffordd syml a diogel o awtomeiddio gosodiadau caneri gyda Helm

Mae defnyddio caneri yn ffordd effeithlon iawn o brofi cod newydd ar is-set o ddefnyddwyr. Mae'n lleihau'n fawr y llwyth traffig a all fod yn broblemus yn ystod y broses leoli, gan mai dim ond o fewn is-grŵp penodol y mae'n digwydd. Mae'r nodyn hwn yn ymwneud â sut i drefnu defnydd o'r fath gan ddefnyddio Kubernetes ac awtomeiddio lleoli. Mae hyn yn cymryd yn ganiataol bod gennych rywfaint o wybodaeth am adnoddau Helm a Kubernetes..



Mae lleoliad caneri syml i Kubernetes yn cynnwys dau adnodd allweddol: y gwasanaeth ei hun a'r offeryn lleoli. Mae lleoli Canary yn gweithio trwy un gwasanaeth sy'n cyfathrebu â dau adnodd gwahanol sy'n gwasanaethu traffig diweddaru. Bydd un o'r adnoddau hyn yn gweithio gyda'r fersiwn "caneri", a'r ail - gyda'r un sefydlog. Yn y sefyllfa hon, gallwn addasu nifer y fersiynau caneri er mwyn lleihau faint o draffig sydd ei angen ar gyfer cynnal a chadw. Os yw'n well gennych, er enghraifft, ddefnyddio Yaml, yna byddai'n edrych fel hyn yn Kubernetes:

kind: Deployment
metadata:
  name: app-canary
  labels:
    app: app
spec:
  replicas: 1
  ...
    image: myapp:canary
---
kind: Deployment
metadata:
  name: app
  labels:
    app: app
spec:
  replicas: 5
  ...
    image: myapp:stable
---
kind: Service
selector:
  app: app # Selector will route traffic to both deployments.

Mae hyd yn oed yn haws dychmygu opsiwn o'r fath ar kubectl, ac yn dogfennaeth ar gyfer Kubernetes mae hyd yn oed tiwtorial llawn ar y senario hwn. Ond prif gwestiwn y swydd hon yw sut rydyn ni'n mynd i awtomeiddio'r broses hon gan ddefnyddio Helm.

Awtomatiaeth Defnyddio Dedwydd

Yn gyntaf oll, mae angen map siart Helm, sydd eisoes yn cynnwys yr adnoddau a drafodwyd uchod. Dylai edrych yn rhywbeth fel hyn:

~/charts/app
├── Chart.yaml
├── README.md
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml

Sail cysyniad Helm yw rheoli datganiadau aml-fersiwn. Y fersiwn sefydlog yw ein prif gangen cod sefydlog ar gyfer y prosiect. Ond gyda chymorth Helm, gallwn ddefnyddio'r gollyngiad caneri gyda'n cod arbrofol. Y prif beth yw cadw'r cyfnewid traffig rhwng y fersiwn sefydlog a'r rhyddhau caneri. Byddwn yn rheoli hyn i gyd gan ddefnyddio dewisydd arbennig:

selector:
  app.kubernetes.io/name: myapp

Bydd ein hadnoddau "caneri" a gosod sefydlog yn nodi'r label hwn ar y modiwlau. Os yw popeth wedi'i ffurfweddu'n gywir, yna yn ystod y defnydd o'r fersiwn caneri o'n map siart Helm, byddwn yn gweld y bydd y traffig yn cael ei gyfeirio at y modiwlau sydd newydd eu defnyddio. Byddai fersiwn sefydlog y gorchymyn hwn yn edrych fel hyn:

helm upgrade
  --install myapp 
  --namespace default 
  --set app.name=myapp       # Goes into app.kubernetes.io/name
  --set app.version=v1       # Goes into app.kubernetes.io/version
  --set image.tag=stable 
  --set replicaCount=5

Nawr gadewch i ni edrych ar ein datganiad caneri. Er mwyn defnyddio'r fersiwn caneri, mae angen inni gofio dau beth. Rhaid i enw'r datganiad fod yn wahanol fel nad ydym yn diweddaru'r fersiwn sefydlog gyfredol. Rhaid i'r fersiwn a'r tag fod yn wahanol hefyd fel y gallwn ddefnyddio cod arall a nodi gwahaniaethau mewn tagiau adnoddau.

helm upgrade
  --install myapp-canary 
  --namespace default 
  --set app.name=myapp       # Goes into app.kubernetes.io/name
  --set app.version=v2       # Goes into app.kubernetes.io/version
  --set image.tag=canary 
  --set replicaCount=1

Dyna, mewn gwirionedd, yw'r cyfan! Os ydych chi'n pingio'r gwasanaeth, gallwch weld bod y diweddariad caneri yn cyfeirio traffig am ran o'r amser yn unig.

Os ydych chi'n chwilio am offer awtomeiddio lleoli sy'n cynnwys y rhesymeg a ddisgrifir, yna edrychwch ar danfonbot ac ymlaen Offer awtomeiddio Helm ar GitHub. Mae'r siartiau Helm a ddefnyddiwyd i weithredu'r dull a ddisgrifir uchod ar Github, yma. Yn gyffredinol, roedd yn drosolwg damcaniaethol o sut i weithredu awtomeiddio defnydd o fersiynau caneri yn ymarferol, gyda chysyniadau ac enghreifftiau penodol.

Ffynhonnell: hab.com