@vekov
Долго работал с монолитами, и вдруг решил сделать первый проект на микросервисах. Тема зацепила, сделал проект по доставке продуктов, всё разбито по частям, пока что крутится на minikube (так сложились обстоятельства).
И вот столкнулся с проблемой. Как это всё дело по нормальному «запайплайнить»?
Сейчас эта мусорка выглядит как:
— Есть 9 микросервисов. У каждого свой гит-репозиторий.
— Закидываю доработки с сервера разработки в гитхаб, там делаю пулл-реквесты, проверки кода и тд.
— Подтягиваю изменения на другой сервак. Там запускаю сборку образа для докера. Пушу в докерхаб.
— На проде лежит хелм, он стучится в докерхаб, собирает образы, запускает приложение в миникубе.
Я всем своим естеством чувствую, что это какая-то чушь, и так работать нельзя. Но как-то и полезного в сети ничего не нашел, по крайней мере такого, что было бы мне понятно. Следовательно вопрос — какие лучшие практики в доставке распределенных приложений?
Решения вопроса 1
@vitaly_il1
Подтягиваю изменения на другой сервак. Там запускаю сборку образа для докера. Пушу в докерхаб.
автоматически для релевантных веток, если прошли тесты, правильно?
На проде лежит хелм, он стучится в докерхаб, собирает образы, запускает приложение в миникубе
Насколько понимаю, это близко к модному сегодня принципу «GitOps». Посмотрите на ArgoCD или Flux, это два популярных инструмента для реализации GitOps.
Я работал с ArgoCD по такой схема:
1) CI на Jenkins -при коммите в release branch автоматически прогоняем тесты, строим образы и загоняем в repository
2) CD — Jenkins как оркестратор: deploy job, который обновляет название образа в репо, на который смотрит ArgoCD, который и делает деплой.
4
комментария
Ответы на вопрос 0