Нашата реализация на Continuous Deployment на платформата на клиента

В True Engineering създадохме процес на непрекъсната доставка на актуализации за сървърите на клиента и искаме да споделим този опит.

Първо разработихме онлайн система за клиента и я внедрихме в собствен клъстер Kubernetes. Сега нашето решение с висока натовареност се премести на платформата на клиента, за което настройвахме напълно автоматичен процес на Continuous Deployment. Благодарение на това, ускорихме времето за пускане на продукт на пазара.

В тази статия ще разкажем за всички етапи на процеса на Continuous Deployment (CD) или доставката на актуализации на платформата на клиента:

1. как стартира този процес,
2. синхронизация с Git-репозитория на клиента,
3. сглобяване на бекенда и фронтенда,
4. автоматично внедряване на приложението в тестова среда,
5. автоматично внедряване на Prod.

В процеса ще споделим детайли за настройките.

1. Стартиране на CD

Continuous Deployment започва, когато разработчикът качва промени в релизната клонка на нашия Git-репозитория.

Нашето приложение работи на базата на микросервисна архитектура и всички негови компоненти се съхраняват в един репозиторий. Благодарение на това се сглобяват и инсталират всички микросервиси, дори ако е променен един от тях.

Организирали сме работата чрез един репозиторий по няколко причини:

• Удобство на разработката — приложението активно се развива, така че може да се работи веднага с целия код.
• Единен CI/CD пайплайн, който гарантира, че приложението като единна система преминава всички тестове и се доставя в prod-окружението на клиента.
• Исключваме объркването с версиите — не се налага да съхраняваме карта на версиите на микросервизите и да описваме за всеки микросервиз своята конфигурация в Helm скриптове.

2. Синхронизация с Git-репозитория на изходния код на клиента

Направените промени автоматично се синхронизират с Git-репозитория на клиента. Там е настроена сборка на приложението, която се стартира след актуализация на клонката, и внедряване в прод. И двата процеса се извършват в тяхната среда от Git-репозитория.

Не можем да работим директно с клиента, тъй като ни трябват собствени среди за разработка и тестване. Използваме нашия Git репозиторий за тези цели - той е синхронизиран с техния Git репозиторий. Веднага щом разработчик публикува промени в съответния клон на нашия репозиторий, GitLab незабавно изпраща тези промени на клиента.

След това е необходимо да направим сборка. Тя се състои от няколко етапа: сборка на бекенда и фронтенда, тестване и доставка в продукция.

3. Сборка на бекенда и фронтенда

Сборката на бекенда и фронтенда е две паралелни задачи, които се изпълняват в системата GitLab Runner. Конфигурацията на оригиналната сборка се намира в същия репозиторий.

Ръководство за написване на YAML скрипт за сборка в GitLab.

GitLab Runner взема кода от нужния репозиторий, компилира Java приложението и го изпраща в Docker registry. Тук събираме бекенда и фронтенда, получаваме Docker образи, които съхраняваме в репозитория на страната на клиента. За управление на Docker образите използваме плъгина Gradle.

Синхронизираме версиите на нашите образи с версията на релиза, който ще бъде публикуван в Docker. За гладка работа сме направили няколко настройки:

1. Между тестовата среда и продукционната контейнерите не се пресъздават. Направихме параметризации, така че един и същ контейнер да може да работи без пресъздаване с всички настройки, променливи среди и услуги както в тестова среда, така и в продукция.

2. За актуализация на приложението чрез Helm е необходимо да зададете неговата версия. Сборката на бекенда, фронтенда и актуализацията на приложението – това са три различни задачи, за това е важно навсякъде да се използва една и съща версия на приложението. За тази задача използваме данни от историята на Git, тъй като конфигурацията на K8S клъстера и приложението се намират в един и същ Git репозиторий.

Версията на приложението получаваме от резултатите от изпълнението на командата
git describe --tags --abbrev=7.

4. Автоматично разгръщане на всички промени в тестовата среда (UAT)

Следващият етап в този скрипт за сборка е автоматичното обновление на K8S клъстера. Това се случва при условие, че всичките приложения са били събрани и всички артефакти са публикувани в Docker Registry. След това се стартира обновление на тестовата среда.

Обновлението на клъстера се стартира с помощта на Helm Актуализация. Ако нещо се обърка, Helm автоматично и самостоятелно ще върне всички свои промени. Няма нужда да се контролира работата му.

Предоставяме конфигурацията на K8S кластера заедно със сборката. Следователно следващата стъпка е да се актуализира: configMaps, deployments, services, secrets и всякакви други K8S конфигурации, които сме променили.

След това Helm стартира RollOut актуализацията на самото приложение в тестова среда. Преди приложението да бъде разположено в продукция. Това е направено, за да може потребителите ръчно да проверят бизнес функциите, които сме пуснали в тестовата среда.

5. Автоматично разгръщане на всички промени в Prod

За да разположите актуализация в продукционна среда, остава само да натиснете един бутон в GitLab — и контейнерите веднага се доставят в продукционната среда.

Същото приложение може да работи в различни среди — тестова и продукционна — без необходимост от повторна компилация. Използваме същите артефакти, без да променяме нищо в приложението, а параметрите определяме отвън.

Гъвкавата параметризация на настройките на приложението зависи от средата, в която ще се изпълнява. Изнесохме всички настройки на средите навън: всичко се параметризира чрез K8S конфигурация и Helm параметри. Когато Helm разгръща сборка в тестова среда, прилага тестови параметри, а в продукционната среда — продуктови параметри.

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

В параметрите на приложението се използват променливи на средата. Их значения се задават в контейнерите чрез K8S configmap, който се шаблонизира чрез Go шаблони. Например, задаването на променлива на средата за домейн може да стане така:

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

.Values.global.env – в тази променлива се съхранява името на средата (prod, stage, UAT).
.Values.app.properties.app_external_domain – в тази променлива задаваме искания домейн в файла .Values.yaml

При обновяване на приложението Helm извършва създаване от шаблоните на файла configmap.yaml и попълва стойността на APP_EXTERNAL_DOMAIN с необходимата стойност в зависимост от средата, в която стартира обновлението на приложението. Тази променлива се задава вече в контейнера. Достъпът до нея е от приложението, следователно, в всяка среда на приложението ще има различна стойност на тази променлива.

Относно неотдавнашното в Spring Cloud се появи поддръжка за K8S, включително работа с configMaps: Spring Cloud Kubernetes. Докато проектът активно се развива и коренно се променя, не можем да го използваме в продукция. Но активно следим състоянието му и го използваме в DEV конфигурации. Веднъж щом стабилизира — ще преминем от използване на променливи на средата към него.

Общо

И така, Continuous Deployment е настроен и работи. Всички обновления се извършват с натискане на един бутон. Доставката на промени в продукционната среда е автоматична. И, важно е, обновленията не спират работата на системата.

Планове за бъдещето: автоматична миграция на базата

Помислихме за апгрейд на базата и възможността тези промени да бъдат отменени. Все пак едновременно работят две различни версии на приложението: старата работи, а новата се загрява. И старата ще спрем само когато се уверим, че новата версия — работи. Миграцията на базата трябва да позволява работа с двете версии на приложението.

Затова не можем просто да променим името на колоната или другите данни. Но можем да създадем нова колона, да копираме в нея данните от старата колона и да напишем тригери, които при обновяване на данните ще копират и обновяват тях в друга колона. И след успешното внедряване на новата версия на приложението, след изминалия период на поддръжка след стартиране, ще можем да премахнем старата колона и ненужния тригер.

Ако новата версия на приложението работи неправилно, можем да се върнем към предишната версия, включително и предишната версия на базата. С една дума, нашите промени ще позволят работа с няколко версии на приложението едновременно.

Планираме да направим автоматизация на миграцията на базата чрез K8S работа, вградена в процеса на CD. И задължително ще споделим опита си на Хабра.

Източник: habr.com