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

Ние во True Engineering поставивме процес за континуирана испорака на ажурирања до серверите на клиентите и сакаме да го споделиме ова искуство.

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

Во оваа статија ќе зборуваме за сите фази на процесот на континуирано распоредување (ЦД) или испорака на ажурирања на платформата на клиентот:

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

Попатно ќе ги споделиме деталите за поставувањето.

1. Стартувајте го ЦД-то

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

Нашата апликација работи на микросервис архитектура и сите нејзини компоненти се складирани во едно складиште. Благодарение на ова, сите микроуслуги се собираат и инсталираат, дури и ако еден од нив е променет.

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

• Леснотија на развој - апликацијата активно се развива, така што можете да работите со целиот код одеднаш.
• Единствен CI/CD гасовод кој гарантира дека апликацијата како единствен систем ги поминува сите тестови и се доставува до производната средина на клиентот.
• Ја елиминираме конфузијата во верзиите - не мораме да складираме мапа на верзии на микросервис и да ја опишуваме нејзината конфигурација за секоја микросервис во скриптите на Helm.

2. Синхронизација со складиштето Git на изворниот код на клиентот

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

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

По ова треба да го направите собранието. Се состои од неколку фази: склопување на задниот дел и предниот дел, тестирање и испорака до производство.

3. Склопување на задниот дел и предниот дел

Изградбата на задниот дел и предниот дел се две паралелни задачи што се извршуваат во системот GitLab Runner. Неговата оригинална конфигурација на склопот се наоѓа во истото складиште.

Упатство за пишување YAML скрипта за градење во GitLab.

GitLab Runner го зема кодот од потребното складиште, го составува со командата за изградба на апликација Java и го испраќа во регистарот Docker. Овде ги собираме заднината и предниот дел, добиваме слики од Docker, кои ги ставаме во складиште на страната на клиентот. За управување со Docker сликите што ги користиме Приклучок Gradle.

Ги синхронизираме верзиите на нашите слики со верзијата за издавање што ќе биде објавена во Docker. За непречено функционирање, направивме неколку прилагодувања:

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

2. За ажурирање на апликација преку Helm, мора да ја наведете нејзината верзија. Ние го градиме задниот дел, предниот дел и ја ажурираме апликацијата - ова се три различни задачи, па затоа е важно да се користи истата верзија на апликацијата насекаде. За оваа задача, користиме податоци од историјата на Git, бидејќи нашата конфигурација и апликациите на кластерот K8S се во истото складиште на Git.

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

4. Автоматско распоредување на сите промени во околината за тестирање (UAT)

Следниот чекор во оваа градба скрипта е автоматско ажурирање на кластерот K8S. Ова се случува доколку целата апликација е изградена и сите артефакти се објавени во Docker Registry. После ова, започнува ажурирањето на околината за тестирање.

Ажурирањето на кластерот започна да се користи Ажурирање на кормилото. Ако, како резултат, нешто не одеше според планот, Helm автоматски и независно ќе ги врати назад сите свои промени. Неговата работа не треба да се контролира.

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

Helm потоа извршува ажурирање RollOut на самата апликација во околината за тестирање. Пред апликацијата да биде распоредена во производство. Ова е направено така што корисниците можат рачно да ги тестираат деловните карактеристики што ги ставаме во околината за тестирање.

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

За да поставите ажурирање во производствената средина, само треба да кликнете на едно копче во GitLab - и контејнерите веднаш се доставуваат до производната средина.

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

Флексибилната параметризација на поставките на апликацијата зависи од околината во која ќе се извршува апликацијата. Ги преместивме сите поставки на околината надворешно: сè е параметриизирано преку конфигурацијата K8S и параметрите на Helm. Кога Helm распоредува склоп во околината за тестирање, поставките за тестирање се применуваат на него, а поставките на производот се применуваат на производната средина.

Најтешко беше да се параметризираат сите користени услуги и променливи кои зависат од околината и да се преведат во променливи на околината и опис-конфигурации на параметрите на околината за Helm.

Поставките на апликацијата користат променливи на околината. Нивните вредности се поставени во контејнери со помош на K8S configmap, која е шаблонирана со користење на шаблони Go. На пример, поставувањето променлива на околината на името на доменот може да се направи вака:

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

.Вредности.глобални.env – оваа променлива го складира името на околината (prod, stage, UAT).
.Values.app.properties.app_external_domain – во оваа променлива го поставуваме саканиот домен во датотеката .Values.yaml

Кога ажурира апликација, Helm создава датотека configmap.yaml од шаблони и ја пополнува вредноста APP_EXTERNAL_DOMAIN со саканата вредност во зависност од околината во која започнува ажурирањето на апликацијата. Оваа променлива е веќе поставена во контејнерот. Може да се пристапи од апликацијата, така што секоја околина на апликацијата ќе има различна вредност за оваа променлива.

Релативно неодамна, поддршката за K8S се појави во Spring Cloud, вклучувајќи работа со configMaps: Пролетниот облак Kubernetes. Додека проектот активно се развива и радикално се менува, ние не можеме да го користиме во производството. Но, ние активно ја следиме неговата состојба и ја користиме во конфигурациите на DEV. Штом се стабилизира, ќе се префрлиме од користење на променливи на околината на него.

Во вкупен

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

Идни планови: автоматска миграција на базата на податоци

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

Затоа, не можеме едноставно да го промениме името на колоната или други податоци. Но, можеме да создадеме нова колона, да копираме податоци од старата колона во неа и да запишеме предизвикувачи кои, при ажурирање на податоците, истовремено ќе ги копираат и ажурираат во друга колона. И по успешното распоредување на новата верзија на апликацијата, по периодот на поддршка по лансирањето, ќе можеме да ја избришеме старата колона и активирањето што стана непотребно.

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

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

Извор: www.habr.com