Наша имплементација континуиране имплементације на платформи клијента

Ми у Труе Енгинееринг-у смо поставили процес за континуирану испоруку ажурирања серверима клијената и желимо да поделимо ово искуство.

За почетак смо развили онлајн систем за купца и применили га у сопственом Кубернетес кластеру. Сада је наше решење са великим оптерећењем прешло на платформу корисника, за коју смо поставили потпуно аутоматски процес континуиране имплементације. Захваљујући томе, убрзали смо време за стављање на тржиште - испоруку промена у окружењу производа.

У овом чланку ћемо говорити о свим фазама процеса континуиране имплементације (ЦД) или испоруке ажурирања на платформу корисника:

1. Како почиње овај процес?
2. синхронизацију са Гит репозиторијумом клијента,
3. склапање бекенда и фронтенда,
4. аутоматска примена апликације у тестном окружењу,
5. аутоматско распоређивање у Прод.

Успут ћемо поделити детаље подешавања.

1. Покрените ЦД

Континуирана примена почиње тако што програмер гура измене у грану издања нашег Гит спремишта.

Наша апликација ради на микросервисној архитектури и све њене компоненте се чувају у једном спремишту. Захваљујући томе, све микросервисе се прикупљају и инсталирају, чак и ако се један од њих променио.

Организовали смо рад кроз једно спремиште из неколико разлога:

• Лакоћа развоја - апликација се активно развија, тако да можете радити са свим кодом одједном.
• Јединствени ЦИ/ЦД цевовод који гарантује да апликација као јединствен систем пролази све тестове и испоручује се у производно окружење корисника.
• Уклањамо забуну у верзијама – не морамо да складиштимо мапу верзија микросервиса и описујемо њену конфигурацију за сваку микросервис у Хелм скриптама.

2. Синхронизација са Гит репозиторијумом клијентовог изворног кода

Измене се аутоматски синхронизују са Гит репозиторијумом клијента. Тамо се конфигурише склоп апликације, који се покреће након ажурирања гране, и имплементације до наставка. Оба процеса потичу у свом окружењу из Гит спремишта.

Не можемо директно да радимо са репозиторијумом корисника јер су нам потребна сопствена окружења за развој и тестирање. За ове сврхе користимо наше Гит спремиште – синхронизовано је са њиховим Гит репозиторијумом. Чим програмер објави промене у одговарајућој грани нашег спремишта, ГитЛаб одмах прослеђује ове промене клијенту.

Након тога морате обавити монтажу. Састоји се од неколико фаза: бацкенд и фронтенд монтажа, тестирање и испорука у производњу.

3. Састављање позадине и фронтенда

Изградња позадине и фронтенда су два паралелна задатка која се изводе у ГитЛаб Руннер систему. Његова оригинална конфигурација склопа налази се у истом спремишту.

Водич за писање ИАМЛ скрипте за изградњу у ГитЛабу.

ГитЛаб Руннер узима код из потребног спремишта, склапа га командом за изградњу Јава апликације и шаље га у Доцкер регистар. Овде састављамо бацкенд и фронтенд, добијамо Доцкер слике, које стављамо у спремиште на страни клијента. За управљање Доцкер сликама које користимо Градле додатак.

Верзије наших слика синхронизујемо са изданом верзијом која ће бити објављена у Доцкер-у. За несметан рад направили смо неколико подешавања:

1. Контејнери се не реконструишу између тестног окружења и производног окружења. Направили смо параметре тако да исти контејнер може да ради са свим подешавањима, варијаблама окружења и услугама како у тестном окружењу тако иу продукцији без поновне изградње.

2. Да бисте ажурирали апликацију преко Хелм-а, морате навести њену верзију. Правимо позадину, фронтенд и ажурирамо апликацију – ово су три различита задатка, па је важно да свуда користите исту верзију апликације. За овај задатак користимо податке из Гит историје, пошто су наша К8С конфигурација кластера и апликације у истом Гит спремишту.

Верзију апликације добијамо из резултата извршења команде
git describe --tags --abbrev=7.

4. Аутоматско увођење свих промена у тест окружење (УАТ)

Следећи корак у овој скрипти за прављење је аутоматско ажурирање К8С кластера. Ово се дешава под условом да је цела апликација направљена и да су сви артефакти објављени у Доцкер регистру. Након тога почиње ажурирање тестног окружења.

Ажурирање кластера је покренуто коришћењем Хелм Упдате. Ако, као резултат, нешто није ишло по плану, Хелм ће аутоматски и независно вратити све своје промене. Његов рад не треба контролисати.

Ми испоручујемо конфигурацију кластера К8С заједно са склопом. Стога је следећи корак да га ажурирамо: цонфигМапс, имплементације, услуге, тајне и све друге К8С конфигурације које смо променили.

Хелм затим покреће РоллОут ажурирање саме апликације у тестном окружењу. Пре него што се апликација примени у производњу. Ово је урађено како би корисници могли ручно да тестирају пословне карактеристике које стављамо у окружење за тестирање.

5. Аутоматско постављање свих промена у Проз

Да бисте применили ажурирање у производном окружењу, потребно је само да кликнете на једно дугме у ГитЛаб-у - и контејнери се одмах испоручују у производно окружење.

Иста апликација може да ради у различитим окружењима — тест и производња — без поновне изградње. Користимо исте артефакте без промене било чега у апликацији, а параметре постављамо споља.

Флексибилна параметризација подешавања апликације зависи од окружења у којем ће се апликација извршавати. Све поставке окружења смо померили споља: све је параметризовано кроз К8С конфигурацију и Хелм параметре. Када Хелм имплементира склоп у тестно окружење, подешавања теста се примењују на њега, а подешавања производа се примењују на производно окружење.

Најтеже је било параметризовати све коришћене сервисе и варијабле које зависе од окружења, и превести их у варијабле окружења и опис-конфигурације параметара окружења за Хелм.

Подешавања апликације користе променљиве окружења. Њихове вредности се постављају у контејнере користећи К8С цонфигмап, који је шаблонизован помоћу Го шаблона. На пример, постављање променљиве окружења на име домена може се урадити овако:

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Валуес.глобал.енв – ова променљива чува име окружења (прод, стаге, УАТ).
.Валуес.апп.пропертиес.апп_ектернал_домаин – у овој променљивој постављамо жељени домен у датотеци .Валуес.иамл

Приликом ажурирања апликације, Хелм креира датотеку цонфигмап.иамл од шаблона и попуњава вредност АПП_ЕКСТЕРНАЛ_ДОМАИН жељеном вредношћу у зависности од окружења у којем ажурирање апликације почиње. Ова променљива је већ постављена у контејнеру. Може се приступити из апликације, тако да ће свако окружење апликације имати различиту вредност за ову променљиву.

Релативно недавно, подршка за К8С појавила се у Спринг Цлоуд-у, укључујући рад са цонфигМапс: Пролећни облак Кубернетес. Док се пројекат активно развија и радикално мења, не можемо га користити у производњи. Али ми активно пратимо његово стање и користимо га у ДЕВ конфигурацијама. Чим се стабилизује, прећи ћемо са коришћења променљивих окружења на њега.

Укупно

Дакле, континуирана имплементација је конфигурисана и ради. Сва ажурирања се дешавају једним притиском на тастер. Испорука промена у окружењу производа је аутоматска. И, што је најважније, ажурирања не заустављају систем.

Планови за будућност: аутоматска миграција базе података

Размишљали смо о надоградњи базе података и могућности враћања ових промена. На крају крајева, две различите верзије апликације раде у исто време: стара је покренута, а нова је покренута. А стару ћемо искључити тек када будемо сигурни да нова верзија ради. Миграција базе података би требало да вам омогући рад са обе верзије апликације.

Због тога не можемо једноставно променити назив колоне или друге податке. Али можемо да креирамо нову колону, копирамо податке из старе колоне у њу и упишемо окидаче који ће, приликом ажурирања података, истовремено да их копирају и ажурирају у другој колони. А након успешног постављања нове верзије апликације, након периода подршке након покретања, моћи ћемо да избришемо стару колону и окидач који је постао непотребан.

Ако нова верзија апликације не ради исправно, можемо се вратити на претходну верзију, укључујући претходну верзију базе података. Укратко, наше промене ће вам омогућити да радите истовремено са неколико верзија апликације.

Планирамо да аутоматизујемо миграцију базе података путем К8С посла, интегришући је у ЦД процес. И дефинитивно ћемо ово искуство поделити на Хабре.

Извор: ввв.хабр.цом