Как правильно настраивать CI/CD для проекта на kubernetes/swarm под PHP?

Question

[Иван Веков]

Доброго времени суток!

Долго работал с монолитами, и вдруг решил сделать первый проект на микросервисах. Тема зацепила, сделал проект по доставке продуктов, всё разбито по частям, пока что крутится на minikube (так сложились обстоятельства).

И вот столкнулся с проблемой. Как это всё дело по нормальному "запайплайнить"?

Сейчас эта мусорка выглядит как:
- Есть 9 микросервисов. У каждого свой гит-репозиторий.
- Закидываю доработки с сервера разработки в гитхаб, там делаю пулл-реквесты, проверки кода и тд.
- Подтягиваю изменения на другой сервак. Там запускаю сборку образа для докера. Пушу в докерхаб.
- На проде лежит хелм, он стучится в докерхаб, собирает образы, запускает приложение в миникубе.

Я всем своим естеством чувствую, что это какая-то чушь, и так работать нельзя. Но как-то и полезного в сети ничего не нашел, по крайней мере такого, что было бы мне понятно. Следовательно вопрос - какие лучшие практики в доставке распределенных приложений?

Answer 1

[Vitaly Karasik]

Я не вижу ничего "страшно неправильного" в вашем методе.

Подтягиваю изменения на другой сервак. Там запускаю сборку образа для докера. Пушу в докерхаб.

автоматически для релевантных веток, если прошли тесты, правильно?

На проде лежит хелм, он стучится в докерхаб, собирает образы, запускает приложение в миникубе

Насколько понимаю, это близко к модному сегодня принципу "GitOps". Посмотрите на ArgoCD или Flux, это два популярных инструмента для реализации GitOps.
Я работал с ArgoCD по такой схема:
1) CI на Jenkins -при коммите в release branch автоматически прогоняем тесты, строим образы и загоняем в repository
2) CD - Jenkins как оркестратор: deploy job, который обновляет название образа в репо, на который смотрит ArgoCD, который и делает деплой.

https://www.reddit.com/r/kubernetes/comments/jfces...

Comments

[Иван Веков]

Добрый день, спасибо за ответ.

Возможно, сейчас это мне кажется очень неправильным, потому что как раз ни релевантных веток, ни тестов, ничего подобного у меня сейчас не настроено, и почти всё делается вручную.

Я даже сейчас лишь на стадии выбора между гитлабом и битбакетом. Сейчас всё на гитхабе, а он мне не нравится, да и не на все проекты подходит.

Про гитОпс и Арго с Флюксом - почитаю, спасибо.

Что мне кажется странным в том, что я описал - это создание отдельного репо под каждый микросервис и способ доставки - я вручную делаю билд образа и вручную отправляю в докерхаб, пока что понимания как эту часть автоматизируют - нет. Знаю, что есть проекты где микросервисы исчисляются даже не десятками. И неужто под каждый заведен отдельный репозиторий...

[Vitaly Karasik]

Понял! Я думал это уже автоматически.

Я даже сейчас лишь на стадии выбора между гитлабом и битбакетом. Сейчас всё на гитхабе, а он мне не нравится, да и не на все проекты подходит.

ИМХО, это не так важно. Я много работал с GitHub и привык к нему, но по-моему, разница незначительна. Как минимум если использовать внешний CI.

это создание отдельного репо под каждый микросервис

- мне более привычно monorepo, но и ваш вариант принят у многих

способ доставки - я вручную делаю билд образа и вручную отправляю в докерхаб

Вот с этого я бы и начал - выбрать любой CI, например GitHub Actions если вы уже там, и настроить pipeline который включает постройку образа и загрузку его в репо. А потом можно добавлять тесты, SonarCloud, coverage и т.п.
А потом думать о CD, то есть самом deployment.

[Иван Веков]

Внешние CI никогда не использовал, делал только простейший пайп на Bitbucket+BambooServer)

Про monorepo почитаю. Спасибо.

То есть получается путь такой:

• Разработчик отправляет по одному из микросервисов обновления пулл-реквестом на ревью
  
• После согласования на конкретную ветку, пайплайн должен собрать образ с обновленным кодом приложения
  
• CI отправляет полученный образ в dockerhub/registry
  
• Сборка отправляется на тестовый сервер, где прогоняются тесты и собираются артефакты
  
• Если всё ок - обновление поставляется на прод и там запускается обновление через хелм
  

Как-то так?)

[Vitaly Karasik]

В целом да.

Если всё ок - обновление поставляется на прод и там запускается обновление через хелм

В GitOps flow немного по-другому деплоится, но идея та же.
Плюс про автоматический деплой в прод я много читал, но в реальной жизни еще не видел.