Simpla kaj sekura maniero aŭtomatigi kanariajn deplojojn kun Helm

Kanaria deplojo estas tre efika maniero testi novan kodon sur subaro de uzantoj. Ĝi signife reduktas la trafikŝarĝon kiu povas esti problema dum la deplojprocezo, ĉar ĝi nur okazas ene de specifa subaro. Ĉi tiu noto estas dediĉita al kiel organizi tian deplojon uzante Kubernetes kaj deplojan aŭtomatigon. Ni supozas, ke vi scias ion pri Helm kaj Kubernetes-resursoj.



Simpla kanaria deplojo al Kubernetes inkluzivas du ŝlosilajn rimedojn: la servon mem kaj la disfaldan ilon. Kanaria deplojo funkcias per ununura servo, kiu interagas kun du malsamaj rimedoj servantaj ĝisdatigtrafikon. Unu el ĉi tiuj rimedoj funkcios kun la "kanaria" versio, kaj la dua funkcios kun la stabila versio. En ĉi tiu situacio, ni povas reguligi la nombron da kanariaj versioj por redukti la kvanton de trafiko necesa por servi. Se, ekzemple, vi preferas uzi Yaml, tiam ĝi aspektos tiel en 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.

Estas eĉ pli facile imagi ĉi tiun opcion uzante kubectl, kaj en Kubernetes dokumentaro Estas eĉ plena lernilo pri ĉi tiu scenaro. Sed la ĉefa demando de ĉi tiu afiŝo estas kiel ni aŭtomatigos ĉi tiun procezon uzante Helm.

Aŭtomatigo de kanaria deplojo

Antaŭ ĉio, ni bezonas Helm-diagramon, kiu jam inkluzivas la rimedojn, kiujn ni diskutis supre. Ĝi devus aspekti kiel ĉi tio:

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

La bazo de la Helm-koncepto estas la administrado de plurversiaj eldonoj. La stabila versio estas nia ĉefa stabila branĉo de la projektkodo. Sed kun Helm ni povas disfaldi kanarian eldonon per nia eksperimenta kodo. La ĉefa afero estas konservi trafikan interŝanĝon inter la stabila versio kaj la kanaria liberigo. Ni administros ĉion ĉi uzante specialan elektilon:

selector:
  app.kubernetes.io/name: myapp

Niaj "kanaraj" kaj stabilaj disfaldaj rimedoj indikos ĉi tiun etikedon sur la moduloj. Se ĉio estas agordita ĝuste, tiam dum la deplojo de la kanaria versio de nia Helm-diagramo-mapo ni vidos, ke trafiko estos direktita al la nove deplojitaj moduloj. La stabila versio de ĉi tiu komando aspektos jene:

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

Nun ni kontrolu nian kanarian liberigon. Por deploji la kanarian version, ni devas memori du aferojn. La eldonnomo devas esti malsama por ke ni ne lanĉu ĝisdatigon al la nuna stabila versio. La versio kaj etikedo ankaŭ devas esti malsamaj por ke ni povu disfaldi alian kodon kaj identigi diferencojn per rimedetikedoj.

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

Tio estas ĉio! Se vi pingas la servon, vi povas vidi, ke la kanaria ĝisdatigo trafikas nur parton de la tempo.

Se vi serĉas deplojajn aŭtomatigajn ilojn, kiuj inkluzivas la priskribitan logikon, tiam atentu Deliverybot kaj plu Helm-aŭtomatigaj iloj sur GitHub. La Helm-diagramoj uzataj por efektivigi la metodon priskribitan supre estas sur Github, ĝuste ĉi tie. Ĝenerale, tio estis teoria superrigardo de kiel efektivigi aŭtomatigon de deplojo de kanariaj versioj en praktiko, kun specifaj konceptoj kaj ekzemploj.

fonto: www.habr.com