понял в каком месте werf реализует концепцию GitOps. с таким же успехом можно helm3 с дженкинса запускать. или я что-то упускаю?
Основная идея и основной смысл 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 .
Обсуждают сегодня