Lihtne ja turvaline viis kanaride juurutamise automatiseerimiseks Helmiga

Kanarike deployed on hapx markt is an efficient way to test new code with a specific subset of users. It significantly reduces the traffic load that may cause problems during deployment, as it occurs only within a defined subgroup. This note is dedicated to organizing such a deployment using Kubernetes and deployment automation. It is assumed that you have some knowledge of Helm and Kubernetes resources..



A simple canary deployment in Kubernetes involves two key resources: the service itself and the deployment tool. The canary deployment operates through a single service that interacts with two different resources handling update traffic. One of these resources will run with a "canary" version, while the other will handle the stable version. In this scenario, we can regulate the number of canary versions to reduce the amount of traffic that needs to be managed. For example, if you prefer using YAML, it would look like this in Kubernetes:

tüüp: Deployment
metaandmed:
  nimi: app-canary
  sildid:
    rakendus: app
spetsifikatsioon:
  koopiad: 1
  ...
    pilt: myapp:canary
---
tüüp: Deployment
metaandmed:
  nimi: app
  sildid:
    rakendus: app
spetsifikatsioon:
  koopiad: 5
  ...
    pilt: myapp:stable
---
tüüp: Service
valik:
  rakendus: app # Valik suunab liiklust mõlemale deployment'ile.

Sellist varianti on veelgi lihtsam ette kujutada kubectl'i abil, kuid Kubernetes'e dokumentatsioonis on isegi täielik juhend selle stsenaariumi kohta. Kuid selle postituse peamine küsimus on, kuidas me kavatseme seda protsessi automatiseerida, kasutades Helm.

Kanarüüde automatiseerimine

Esiteks vajame Helm'i chart'i faili, kuhu on juba lisatud eelnevalt arutatud ressursid. See peaks välja nägema umbes nii:

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

Helm'i kontseptsiooni põhialus on mitme versiooni haldamine. Stable-versioon on meie põhja stabiilne koodiharu. Kuid Helm'i abil saame käivitada kanarüüsid meie eksperimentaalse koodiga. Peamine on säilitada liikluse vahetamine stabiilse versiooni ja kanarüüde vahel. Kõike seda haldame spetsiaalse valijaga:

valija:
  app.kubernetes.io/name: myapp

Meie nii «kanarilistes» kui ka stable-deploy ressurssidest avaldatud märk tähistab seda moodulites. Kui kõik on õigesti seadistatud, siis kanariversiooni Helm chart'i avaldamise ajal suunatakse liiklus värskelt juurutatud moodulitele.

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

Nüüd kontrollime meie kanariversiooni. Kanariversiooni juurutamiseks peame meeles pidama kahte asja. Erinev nimi põhiversioonist peab olema, et me ei saaks praegusele stable-versioonile uuendust. Versioon ja silt peavad samuti olema erinevad, et saaksime juurutada teist koodi ja määrata ressursimärkide erinevused.

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

Ja see ongi kõik! Kui kutsuda teenust, siis näeme, et kanariversiooni uuendus suunab liiklust ainult osaliselt ajast.

Kui otsite juurutusautomaatika tööriistu, mis sisaldavad kirjeldatud loogikat, siis tasub tähelepanu pöörata Deliverybot ja Helmi automaatika tööriistadele GitHubis. Helmi diagrammid, mida kasutatakse ülaltoodud meetodi rakendamiseks, asuvad GitHubis, siit. Üldiselt oli see teoreetiline ülevaade sellest, kuidas ellu viia kanarindade versioonide juurutuse automatiseerimist praktikas, koos konkreetsete kontseptsioonide ja näidetega.

Allikas: habr.com