Ние от True Engineering сме създали процес за непрекъснато доставяне на актуализации до клиентските сървъри и искаме да споделим този опит.
Като начало разработихме онлайн система за клиента и я внедрихме в нашия собствен клъстер Kubernetes. Сега нашето високонатоварено решение се премести в платформата на клиента, за която сме настроили напълно автоматичен процес на непрекъснато внедряване. Благодарение на това ускорихме времето за пускане на пазара - доставянето на промени в продуктовата среда.
В тази статия ще говорим за всички етапи на процеса на непрекъснато внедряване (CD) или доставката на актуализации на платформата на клиента:
- Как започва този процес?
- синхронизиране с Git хранилището на клиента,
- сглобяване на бекенд и преден енд,
- автоматично внедряване на приложение в тестова среда,
- автоматично разгръщане към произв.
Ще споделим подробностите за настройката по пътя.
1. Стартирайте CD
Непрекъснатото внедряване започва с натискане от страна на разработчика на промени в клона за освобождаване на нашето Git хранилище.
Нашето приложение работи на микросервизна архитектура и всички негови компоненти се съхраняват в едно хранилище. Благодарение на това всички микроуслуги се събират и инсталират, дори ако една от тях е променена.
Организирахме работа чрез едно хранилище по няколко причини:
- Лесна разработка - приложението се развива активно, така че можете да работите с целия код наведнъж.
- Един CI/CD конвейер, който гарантира, че приложението като единна система преминава всички тестове и се доставя до производствената среда на клиента.
- Елиминираме объркването във версиите - не е нужно да съхраняваме карта на версиите на микроуслугата и да описваме нейната конфигурация за всяка микроуслуга в Helm скриптове.
2. Синхронизиране с Git хранилището на изходния код на клиента
Направените промени се синхронизират автоматично с Git хранилището на клиента. Там се конфигурира сглобяването на приложението, което се стартира след актуализиране на клона и разгръщането към продължението. И двата процеса произхождат от тяхната среда от Git хранилище.
Не можем да работим директно с хранилището на клиента, защото се нуждаем от собствени среди за разработка и тестване. Ние използваме нашето Git хранилище за тези цели - то е синхронизирано с тяхното Git хранилище. Веднага след като разработчик публикува промени в съответния клон на нашето хранилище, GitLab незабавно изпраща тези промени на клиента.
След това трябва да извършите сглобяването. Състои се от няколко етапа: сглобяване на бекенд и фронтенд, тестване и доставка до производство.
3. Сглобяване на бекенда и фронтенда
Изграждането на бекенда и предния край са две паралелни задачи, които се изпълняват в системата GitLab Runner. Неговата оригинална конфигурация на сглобяване се намира в същото хранилище.
.
GitLab Runner взема кода от необходимото хранилище, сглобява го с командата за изграждане на Java приложение и го изпраща в регистъра на Docker. Тук сглобяваме backend и frontend, получаваме Docker изображения, които поставяме в хранилище от страна на клиента. За управление на Docker изображения, които използваме .
Ние синхронизираме версиите на нашите изображения с версията на изданието, която ще бъде публикувана в Docker. За безпроблемна работа направихме няколко корекции:
1. Контейнерите не се възстановяват между тестовата среда и производствената среда. Направихме параметризации, така че един и същ контейнер да може да работи с всички настройки, променливи на средата и услуги както в тестовата среда, така и в производствената среда без повторно изграждане.
2. За да актуализирате приложение чрез Helm, трябва да посочите неговата версия. Ние изграждаме бекенда, фронтенда и актуализираме приложението – това са три различни задачи, така че е важно да използвате една и съща версия на приложението навсякъде. За тази задача използваме данни от историята на Git, тъй като нашата конфигурация на клъстер K8S и приложенията са в едно и също Git хранилище.
Получаваме версията на приложението от резултатите от изпълнението на командата
git describe --tags --abbrev=7.
4. Автоматично внедряване на всички промени в тестовата среда (UAT)
Следващата стъпка в този скрипт за изграждане е автоматично актуализиране на клъстера K8S. Това се случва при условие, че цялото приложение е изградено и всички артефакти са публикувани в регистъра на Docker. След това стартира актуализацията на тестовата среда.
Актуализацията на клъстера започва с помощта . Ако в резултат на това нещо не върви по план, Helm автоматично и независимо ще отмени всичките си промени. Работата му не се нуждае от контрол.
Ние доставяме конфигурацията на клъстер K8S заедно с монтажа. Следователно следващата стъпка е да го актуализираме: configMaps, внедрявания, услуги, тайни и всички други конфигурации на 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 с желаната стойност в зависимост от средата, в която стартира актуализацията на приложението. Тази променлива вече е зададена в контейнера. Тя може да бъде достъпна от приложението, така че всяка среда на приложение ще има различна стойност за тази променлива.
Сравнително наскоро поддръжката на K8S се появи в Spring Cloud, включително работа с configMaps: . Докато проектът се развива активно и се променя радикално, ние не можем да го използваме в производството. Но ние активно следим състоянието му и го използваме в DEV конфигурации. Веднага щом се стабилизира, ще преминем от използването на променливи на средата към него.
Общо
И така, непрекъснатото внедряване е конфигурирано и работи. Всички актуализации стават с едно натискане на клавиш. Доставката на промени в продуктовата среда е автоматична. И което е важно, актуализациите не спират системата.
Бъдещи планове: автоматична миграция на база данни
Помислихме за надграждане на базата данни и възможността за връщане назад на тези промени. В края на краищата две различни версии на приложението работят едновременно: старата работи, а новата е готова. А старата ще я изключим едва когато сме сигурни, че новата версия работи. Миграцията на базата данни трябва да ви позволи да работите и с двете версии на приложението.
Следователно не можем просто да променим името на колоната или други данни. Но можем да създадем нова колона, да копираме данни от старата колона в нея и да напишем тригери, които при актуализиране на данните едновременно ще ги копират и актуализират в друга колона. И след успешното внедряване на новата версия на приложението, след периода на поддръжка след стартиране, ще можем да изтрием старата колона и тригера, който е станал ненужен.
Ако новата версия на приложението не работи правилно, можем да се върнем към предишната версия, включително предишната версия на базата данни. Накратко, нашите промени ще ви позволят да работите едновременно с няколко версии на приложението.
Планираме да автоматизираме миграцията на базата данни чрез задача K8S, интегрирайки я в процеса на CD. И определено ще споделим това преживяване на Хабре.
Източник: www.habr.com