Просты і бяспечны спосаб аўтаматызацыі канарэечных дэплояў з дапамогай Helm

Канарэечны дэплой - гэта вельмі эфектыўны спосаб тэсціравання новага кода на нейкім падмностве карыстальнікаў. Ён значна змяншае трафік-нагрузку, з якой могуць узнікнуць праблемы падчас разгортвання, бо адбываецца толькі ў межах вызначанай падгрупы. Гэта нататка прысвечана таму, як арганізаваць падобны дэплой сродкамі Kubernetes і аўтаматызацыі дэплою. Мяркуецца, што вы ведаеце пра Helm і рэсурсы Kubernetes.



Просты канарэечны дэплой у Kubernetes уключае ў сябе два ключавых рэсурсу: сам сэрвіс і прылада разгортвання. Канарэечны дэплой працуе праз адну службу, якая ўзаемадзейнічае з двума рознымі рэсурсамі, якія абслугоўваюць трафік абнаўлення. Адзін з гэтых рэсурсаў будзе працаваць з «канарэечнай» версіяй, а другі – са стабільнай. У гэтай сітуацыі мы можам рэгуляваць колькасць канарэчных версій для таго, каб знізіць аб'ём неабходнага да абслугоўвання трафіку. Калі, да прыкладу, вы аддаеце перавагу выкарыстоўваць Yaml, тое выглядаць у 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.

Яшчэ прасцей уявіць такі варыянт можна на kubectl, а ў дакументацыі па Kubernetes нават ёсць паўнавартасны тутарыял па гэтым сцэнары. Але галоўнае пытанне гэтай пасады заключаецца ў тым, як мы збіраемся аўтаматызаваць гэты працэс, выкарыстоўваючы Helm.

Аўтаматызацыя канарэечнага дэплою

Першым чынам нам спатрэбіцца карта чартаў Helm, у якую ўжо занесеныя якія абмяркоўваюцца намі вышэй рэсурсы. Выглядаць яна павінна быць прыкладна так:

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

Аснова канцэпцыі Helm – кіраванне мультыверсіямі рэлізаў. Stable-версія - гэта наша асноўная стабільная галінка кода праекта. Але з дапамогай Helm мы можам разгарнуць канарэчны рэліз з нашым эксперыментальным кодам. Галоўнае - захаваць абмен трафікам паміж стабільнай версіяй і канарэечным рэлізам. Кіраваць усім гэтым мы будзем з дапамогай спецыяльнага селектара:

selector:
  app.kubernetes.io/name: myapp

Нашы як «канарэечныя», так і stable-рэсурсы дэплою будуць паказваць гэтую пазнаку на модулях. Калі ўсё наладзіць правільна, то падчас дэплою канарэечнай версіі нашай карты чартаў Helm мы ўбачым, што трафік будзе накіроўвацца на свежаразгорнутыя модулі. Стабільная версія гэтай каманды будзе выглядаць так:

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

Цяпер давайце праверым наш канарэечны рэліз. Каб задэплоіць канарэечную версію, нам трэба памятаць пра дзве рэчы. Назва рэлізу павінна адрознівацца, каб мы не накацілі апдэйт на бягучую stable-версію. Версія і тэг таксама павінны адрознівацца, каб мы маглі разгарнуць іншы код і вызначыць адрозненні па пазнаках рэсурсаў.

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

Вось, уласна, і ўсё! Калі пінгнуць службу, то можна ўбачыць, што канарэечнае абнаўленне маршрутызуе трафік толькі частку часу.

Калі вы шукайце прылады аўтаматызацыі дэплою, якія складаюцца з апісаную логіку, то звернеце ўвагу на Deliverybot і на інструменты аўтаматызацыі Helm на GitHub. Чарты Helm, выкарыстоўваныя для рэалізацыі апісанага вышэй спосабу ляжаць на Github, вось тут. Наогул, гэта быў тэарэтычны агляд таго, як рэалізаваць аўтаматызацыю дэплою канарэчных версій на практыцы, з пэўнымі канцэпцыямі і прыкладамі.

Крыніца: habr.com