Canary inplementazioa oso modu eraginkorra da kode berria probatzeko erabiltzaileen azpimultzo batean. Inplementazio-prozesuan zehar arazotsuak izan daitezkeen trafiko-karga nabarmen murrizten du, azpimultzo jakin batean bakarrik gertatzen baita. Ohar hau Kubernetes eta inplementazioaren automatizazioa erabiliz halako inplementazioa nola antolatu aztertzen da. Helm eta Kubernetes baliabideei buruz zerbait badakizula suposatzen dugu.
Kubernetesen kanariar inplementazio soil batek bi baliabide gako biltzen ditu: zerbitzua bera eta hedapen tresna. Canary inplementazioak eguneratze-trafikoa zerbitzatzen duten bi baliabide ezberdinekin elkarreragiten duen zerbitzu bakar baten bidez funtzionatzen du. Baliabide horietako batek "kanariar" bertsioarekin funtzionatuko du, eta bigarrenak bertsio egonkorrarekin. Egoera honetan, kanariar bertsioen kopurua erregulatu dezakegu zerbitzatzeko behar den trafikoa murrizteko. Adibidez, Yaml erabiltzea nahiago baduzu, honela izango da Kubernetesen:
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.
Are errazagoa da aukera hau kubectl erabiliz imajinatzea eta barne
Kanariarren hedapenaren automatizazioa
Lehenik eta behin, Helm diagrama-mapa bat behar dugu, lehen aipatu ditugun baliabideak biltzen dituena. Honelako itxura izan beharko luke:
~/charts/app
├── Chart.yaml
├── README.md
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ └── service.yaml
└── values.yaml
Helm kontzeptuaren oinarria bertsio anitzeko bertsioen kudeaketa da. Bertsio egonkorra proiektuaren kodearen gure adar egonkor nagusia da. Baina Helm-ekin gure kode esperimentalarekin kanariar bertsio bat zabaldu dezakegu. Gauza nagusia bertsio egonkorraren eta canary bertsioaren arteko trafiko-trukea mantentzea da. Hau guztia hautatzaile berezi baten bidez kudeatuko dugu:
selector:
app.kubernetes.io/name: myapp
Gure hedapen-baliabide "kanario" eta egonkorrak etiketa hori adieraziko dute moduluetan. Dena behar bezala konfiguratuta badago, gure Helm diagramaren maparen kanariar bertsioaren hedapenean trafikoa zabaldu berri diren moduluetara bideratuko dela ikusiko dugu. Komando honen bertsio egonkorra honela izango da:
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
Ikus dezagun orain gure kanariar oharra. Kanariar bertsioa zabaltzeko, bi gauza gogoratu behar ditugu. Argitalpenaren izenak desberdina izan behar du, egungo bertsio egonkorraren eguneraketarik ez egiteko. Bertsioak eta etiketak ere desberdinak izan behar dute, beste kode batzuk zabaldu ahal izateko eta baliabideen etiketen arabera desberdintasunak identifikatu ahal izateko.
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
Hori da dena! Zerbitzuari ping egiten baduzu, canary eguneraketak trafikoa denboraren zati batean bakarrik bideratzen duela ikus dezakezu.
Deskribatutako logika barne hartzen duten hedapen automatizazio tresnak bilatzen ari bazara, arreta jarri
Iturria: www.habr.com