Основная идея и основной смысл GitOps, как мы это понимаем,

это то что git является signgle source of truth. То есть в git у нас лежит вся-вся информация: код приложения, все зависимости, информация как собирать контейнеры, информация как деплоить в кубернетес и пр. И дальше у нас есть “нечто”, которое делает так, чтобы реальность изменялась в соответствии с изменениями в git. Мы считаем, что этот подход может быть реализован НЕ только установкой “некоторого оператора” в кубернетис, который будет следить за гитом, но и с помощью консольной тулы, которую можно дергать из любого CI. Более того, с нашей точки зрения подход с CLI тулой НЕ накладывает лишние ограничения – мы можем делать CI любым инструментом и с любым количеством нюансов, дергая CLI тулу, которая “синкает git с реальностью” (с кубом).

Что касается helm – нет, werf делает гораздо больше:
1. werf собирает образы (с помощью docker или своим сборщиком, с расширенными возможностями)
2. werf тэгирует образы так, чтобы они были связаны с коммитами в git (там разные стратегии, много деталей)
3. werf “просовывает” информацию о собранных образах в helm
4. в werf используется дополненная версия helm, в которой решины вопросы ожидания (https://github.com/flant/kubedog), 3 way mege (https://werf.io/documentation/reference/deploy_process/experimental_three_way_merge.html), вывода логов и многого другого (https://werf.io/documentation/reference/deploy_process/deploy_into_kubernetes.html)

Кроме этого, там много “дополнительных” штук, типа механизма очистки образов в registry, удобной интеграции с CI (пока только с gitlab, но скоро будут другие) и пр.

И да, КОНЕЧНО ВСЕ ЭТО МОЖНО СДЕЛАТЬ НА СКРИПТАХ, вопрос в том, что в werf уже решена куча вопросов out of the box!

Подробное видео с кучей подробностей: https://www.youtube.com/watch?v=cK3ackGUTLw .

Небольшой комментарий. Если это утилита, то нет гарантий, что гит в какой-то момент перестанет быть единым источником правды. Это та вещь, по которой больно прошлись все системы управления конфигурацией. Приходит админ или другая конкурирующая система, вносит изменения и в результате мы имеем гонку. А скрипты - да, все задолбались их уже писать. Каждый раз, как в новый. Факт. Это больно. Неприятно. И потом их ещё нужно отлаживать. И поддерживать

спасибо за развернутое описание. звучит все круто и логично. Но есть ряд случаев, когда наличие некоторого кубернетис оператора предпочтительнее, чем вызов cli тулы. Например, при наличии множества сервисов, которые имеют разный подход к CI/разные CI системы/etc и деплоятся в один кубернетис кластер. То есть, я предпочту описать несколько yaml-файлов для центрального оператора, который будет потом пулить последнюю версию манифестов с гита для всех сервисов, согласно этой конфигурации. Но я не готов сказать какой подход действительно лучше, будем на практике проверять. Как по мне, pull-mode выглядит перспективнее чем push.

Как вы чистите регистри, мы написали внутренний чистильщик который кучу деталей учитывает не найдя ничего подходящего на гитхабе