Деплой в K8s з пулл реквесту & тести

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Шановне панство,

Нажаль штатний девопс пішов у «відпустку» а на мене звалили деякі його обов`язки.

Потрібно у ГітХаб пулл реквест вокрфлоу додати розгортування коду з бранчу у кубер та отримання зовнішнього тимчасового URL вида my-test-service-pr-1235.mysite.com

Потім використовуючи цю URL проранити деякі тести та видалити усе з кубера.

Стосовно тестів все ок -я додав це а ось з розгортанням коду у тимчасовий сервіс на кубері — проблема ... не уявляю як це зробити з пул реквесту.

Дехто підказав що потрібно використовувати Bridge-to-Kubernetes moimhossain.com/...​/03/bridge-to-kubernetes як описано у статті але ж не зовсім розумію як це зробити...

Тож проблема така.

— Маю у наявності код (.NET 6 WebAPI) у гілці ГітХаб-а та з нього зробив контейнер у Azure Container Registry,

— Треба розгорнути цей контейнер у кубері та отримати зовнішній тимчасовий URL на цей WebAPI сервіс

Це треба зробити у ГітХаб вокрвлоу але якщо зможу це зробити у терміналі руками то те ж саме зможу перенести у ГітХаб

Заздалегідь дякую за ідеї та посилання на стітті.

PS: Може комусь моє запитання здаватиметься дуже простим тож давайте без жартів.

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Робив таке кілька років тому, щоправда без операторів.

Принципово схема виглядала наступним чином: по вебхуку (ми ловили каменти в ПР, а не сам факт створення) автоматизація (у нас то був Дженкінс) створювала в нон-продакшн кластері новий неймспейс і встановлювала туди сервіси із залежностями, як наприклад, БД.

Із технологій використовували Jenkins, Helm (бо Хельм імперативний). Спочатку юзали амбрела-чарт, але потім розпиляли його на окремі чарти, бо то був жах із ним працювати. Перейшли на Skaffold .

Важливий нюанс, що вам потрібно не просто підняти сервіс в ізоляції, а забезпечити йому необхідні залежності. Наприклад, як менеджити БД в такому випадку? Якщо кожен фіча-енв використовує одну й ту саму БД, що робити із несумісними міграціями і змінами в схемі?

Якщо сервісів в вашій екосистемі багато, як забезпечити ізоляцію? Дуплікувати всю інфру може бути дуже дорого. Якщо ні, то потрібно якось дуплікувати трафік на фіча-енв або ж використовувати там кенері.

Коротше кажучи, фіча-енви — це круто, але потребує багато зусиль і іноді ті самі задачі можна вирішити легше, наприклад, якщо сервіс, розгорнутий локально, буде підключатись до АПІ в дев, тощо.

Ось це може знадобитися для видалення ресурсів K8S для пулл реквеста, коли з ним вже ніхто не буде працювати — github.com/...​e-feature-branch-operator

Не ідеально, але дуже просто.

Зазвичай для деплою в к8с використовують Helm для чартів і щось типу ArgoCD/Flux для CI/CD. В вас є якісь тулзи з цього?

Так хелм чарти вже є та використовуються.
Але інші інструменти "

ArgoCD/Flux

" ми не використувємо.
В мене є тільки код у GH гілці та GitHub YAML воркфлоу з різноматінтими GH Actions які я можу використовувати..
Питання як задеплоїти в кубер в мене не виникає я це знаю та знайомий з HELM та kubectl
Питання в тому що замовник( тех лід замовника) наполягає на використання Bridge To Kubernetes у спосіб описаний тут
moimhossain.com/...​/03/bridge-to-kubernetes
але я бачу що так не виходить бо «магії» яка там є — насправді не існує.

Команді яка працює зараз потрібно щоб як тільки з`являється нова гілка у ГХ наприклад «story/12345» то код з неї автоматично деплоїться у кубер так назовні з`являється як URL
story-12345.MyClusterDomain.Com
Ось намагаюсь зараз це зробити через HELM та встановлення налаштувань Ingress під час деплойменту
helm upgrade —install my-service . —set property="value" —set property2="value2″ (звісно там не property та не value а реальні налаштування)

отримання зовнішнього тимчасового URL вида my-test-service-pr-1235.mysite.com

Цей крок до речі можна скіпнути, можеш просто зробити port-forward на локальну тачку з кластера.
kubernetes.io/...​ccess-application-cluster

Або пайплайн з тригером на пул реквесті або або пайплайн чек як один з апруверів пр.
Залежно що там є в гітхабі

стосовно пайплайну усе зрозуміло — трігер на пул реквест.. та уся робота воркфлоу там і буде.
Я це зробив і дійшов до того що в мене вже є докер у азур контейнер реестрі готовий до розгортання у кубері
А от що далі ?
Мені потрібно
— розгорнути тільки цей контейнер у кубері не зачипивши інші сервіси
— отримати унікальне посилання (URL) на сервіс для того щоб Постмен тести спрямувати на нього.
— якщо цей сервіс залежить від інших то цю залежність потрібно підтримати
— автоматично видалити сервіс та усі под-и з кубера пістя того як тести завершено.
Я звісно шукав у інтернеті щось подібне але небагато знайшов нажаль.
Як на мене задача дуже типова тільки для автоматизації СI але не можу знайти прикладів того як її вирішують

Пишешь отдельный ямл для деплоймента этого сервиса в таргет кластер и через кубстл -апплай его деплоишь. Как писать ямл гуглится легко, в нем описывешь собственно сервис — из какого образа его брать, его экспожур и таргет урл.

Тож як я розумію треба й Ingress деплоймент написати в тому YAML файлі ?
Тобто у YAML буде такий зміст
Deployment
Service
Ingress ( тут потрібно вказати Host щось накшталт my-pr-123-myDNS.com ) ??

Типа того. Точный синтаксис не помню...

Ну в ci буде таска yaml задеплоїти.
А що задеплоїти швидше інший ямл (наприклад який описує деплой k8s) чи може якийсь хелм.

Пайплайна тільки автоматизує те що руками робиш

так я розумію це що пайплайн це не «магія» :-)
задеплоїти YAML файл я зможу та й роблю це зараз у себе локально з терміналу щоб зафіксувати всі шаги..

Ну тоді наприклад це просто ямл файо з кубкрнетіс деплой

Kubectc create -f deploy. Yaml
Kubectl delete ...

Підписатись на коментарі