Kanariar Inplementazioa Jenkins-X Istio Flagger erabiliz
Canary inplementazioa eskuz egingo dugu GitOps bidez eta Kubernetes baliabide nagusiak sortuz/aldatuz. Artikulu hau sarrera egiteko da batez ere Kubernetes Canary-en inplementazioak nola funtzionatzen duen, automatizazio metodo eraginkorragoak baitaude, hurrengo artikuluetan kontuan hartuko ditugunak.
Canary estrategiarekin, eguneraketak erabiltzaileen azpimultzo bati soilik aplikatzen zaizkio. Monitorizazioaren, erregistro-datuen, eskuzko probaren edo beste iritzi-kanal batzuen bidez, bertsioa probatzen da erabiltzaile guztiei kaleratu aurretik.
Kubernetes inplementazioa (eguneratze iraunkorra)
Kubernetes Deployment-en estrategia lehenetsia eguneratzea da, non pods kopuru jakin bat abiarazten den irudien bertsio berriekin. Arazorik gabe sortu badira, irudien bertsio zaharrak dituzten lekak amaitu egiten dira, eta paraleloki berriak sortzen dira.
GitOps
Adibide honetan GitOps erabiltzen dugu zeren eta:
Git egia iturri bakar gisa erabiliz
Git Eragiketak erabiltzen ditugu eraikitzeko eta inplementatzeko (ez da beharrezkoa git tag/merge ez den komandorik)
Adibidea
Har dezagun praktika on bat: aplikazioaren kodearen biltegi bat eta azpiegiturarako biltegi bat edukitzea.
Aplikazioen biltegia
Oso sinplea den Python+Flask API bat da, erantzun bat JSON gisa itzultzen duena. Paketea GitlabCI bidez eraikiko dugu eta emaitza Gitlab Erregistrora eramango dugu. Erregistroan bi bertsio ezberdin ditugu:
wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2
Haien arteko desberdintasun bakarra itzulitako JSON fitxategiaren aldaketa da. Aplikazio hau zein bertsiorekin komunikatzen garen ahalik eta errazen ikusteko erabiltzen dugu.
Azpiegituren biltegia
Arbi honetan GitlabCI bidez zabalduko dugu Kubernetesera, .gitlab-ci.yml Honako hau da:
Aldaketa hauek inplementazioa hasiko den biltegira bultzatzen ditugu (GitlabCI bidez) eta ondorioz ikusten dugu:
Gure Zerbitzuak bi inplementazioetara zuzenduko ditu, biek aplikazio-hautatzailea baitute. Kubernetesen aleatorizazio lehenetsia dela eta, erantzun desberdinak ikusi beharko genituzke eskaeren % 10ean:
Gure aplikazioaren egungo egoera (GitOps, Git-etik hartutako egiaren iturri bakarretik hartuta) erreplika aktibo dituzten bi inplementazioren presentzia da, bertsio bakoitzeko bat.
Erabiltzaileen ~% 10 bertsio berri bat ezagutzen da eta nahi gabe probatzen du. Orain da erregistroetan akatsak eta jarraipen-datuetan arazoak aurkitzeko unea.
2. urratsa: kaleratu bertsio berria erabiltzaile guztiei
Dena ondo joan zela erabaki genuen eta orain bertsio berria erabiltzaile guztiei zabaldu behar diegu. Horretarako, eguneratu besterik ez dugu egiten deploy.yaml irudiaren bertsio berri bat instalatzea eta erreplika kopurua berdina 10. In deploy-canary.yaml erreplika kopurua 0ra ezarriko dugu. Inplementatu ondoren, emaitza hau izango da:
Laburbilduz
Niretzat, inplementazioa eskuz exekutatzeak k8s erabiliz zein erraz konfigura daitekeen ulertzen laguntzen du. Kubernetesek API baten bidez dena eguneratzeko aukera ematen dizunez, urrats hauek scripten bidez automatiza daitezke.
Inplementatu behar den beste gauza bat probatzaileen sarrera puntu bat da (LoadBalancer edo Ingress bidez), zeinaren bitartez bertsio berria bakarrik sar daiteke. Eskuzko nabigaziorako erabil daiteke.
Etorkizuneko artikuluetan, egin dugunaren zatirik handiena inplementatzen duten beste irtenbide automatizatu batzuk aztertuko ditugu.