Yksinkertainen ja turvallinen tapa automatisoida kanarialinjojen käyttöönotto Helmin avulla

Canaryn käyttöönotto on erittäin tehokas tapa testata uutta koodia osalla käyttäjiä. Se vähentää merkittävästi liikennekuormitusta, joka voi olla ongelmallista käyttöönottoprosessin aikana, koska sitä esiintyy vain tietyssä osajoukossa. Tämä huomautus on omistettu tällaisen käyttöönoton järjestämiseen Kubernetesin ja käyttöönottoautomaation avulla. Oletamme, että tiedät jotain Helmin ja Kubernetesin resursseista.



Yksinkertainen Canary-käyttöönotto Kubernetesiin sisältää kaksi avainresurssia: itse palvelun ja käyttöönottotyökalun. Canaryn käyttöönotto toimii yhden palvelun kautta, joka on vuorovaikutuksessa kahden eri päivitysliikennettä palvelevan resurssin kanssa. Yksi näistä resursseista toimii "kanarian" version kanssa ja toinen vakaan version kanssa. Tässä tilanteessa voimme säädellä Canary-versioiden määrää vähentääksemme palvelemiseen tarvittavan liikenteen määrää. Jos esimerkiksi haluat käyttää Yamlia, se näyttää tältä Kubernetesissa:

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.

On vielä helpompi kuvitella tämä vaihtoehto käyttämällä kubectlia ja in Kubernetesin dokumentaatio Tästä skenaariosta on jopa täydellinen opetusohjelma. Mutta tämän viestin pääkysymys on, kuinka aiomme automatisoida tämän prosessin Helmin avulla.

Kanarian käyttöönoton automatisointi

Ensinnäkin tarvitsemme Helm chart -kartan, joka sisältää jo edellä käsitellyt resurssit. Sen pitäisi näyttää suunnilleen tältä:

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

Helm-konseptin perustana on moniversioiden julkaisujen hallinta. Vakaa versio on tärkein vakaa haaramme projektikoodissa. Mutta Helmin avulla voimme ottaa käyttöön Canary-julkaisun kokeellisella koodillamme. Tärkeintä on ylläpitää liikenteen vaihtoa vakaan version ja kanarian julkaisun välillä. Hallitsemme kaiken tämän erityisen valitsimen avulla:

selector:
  app.kubernetes.io/name: myapp

"Canary" ja vakaat käyttöönottoresurssit osoittavat tämän merkinnän moduuleissa. Jos kaikki on konfiguroitu oikein, Helm-karttakarttamme kanariankielisen version käyttöönoton aikana näemme, että liikenne ohjataan juuri käyttöön otettuihin moduuleihin. Tämän komennon vakaa versio näyttää tältä:

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

Tarkastetaan nyt kanarian julkaisumme. Kanariankielisen version käyttöönottoa varten meidän on muistettava kaksi asiaa. Julkaisun nimen on oltava erilainen, jotta emme julkaise päivitystä nykyiseen vakaaseen versioon. Version ja tagin on myös oltava erilaisia, jotta voimme ottaa käyttöön muun koodin ja tunnistaa erot resurssitunnisteiden avulla.

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

Siinä kaikki! Jos pingaat palvelua, näet, että kanarian päivitys reitittää liikennettä vain osan ajasta.

Jos etsit käyttöönoton automaatiotyökaluja, jotka sisältävät kuvatun logiikan, kiinnitä huomiota Deliverybot ja edelleen Ruoriautomaatiotyökalut GitHubissa. Yllä kuvatun menetelmän toteuttamiseen käytetyt Helm-kaaviot ovat Githubissa, täällä. Yleisesti ottaen tämä oli teoreettinen katsaus siihen, miten Canary-versioiden käyttöönoton automatisointi toteutetaan käytännössä, erityisillä konsepteilla ja esimerkeillä.

Lähde: will.com