Комментарии 9
Не надо helm для деплоя. Хельм — это в первую очередь пакетный менеджер. Т.е. возможность взять какое-то стороннее решение (редис, постгрес и что угодно) и получить манифесты для установки этого решения в кластер. К сожалению, хельм достаточно простой, что приводит к тому, что хельм чарты под все есть, только вот зачастую качество чартов очень низкое. Но для быстрого старта ОК.
Деплой через Хельм — боль. Там куча проблем — начиная от того, что коллеги все время упираются в размер секретов (вообще какой больной человек придумал релизы в секретах хранить? нет, чтобы придумать отдельную сущность, но это и понятно — решили использовать кубовый RBAC, чтобы побыстрее разработать). Что порядок установки ресурсов вызывает вопросы (тот же Kubeflow через хельм не накатишь, потому что там есть кросс-зависимости между компонентами, поэтому родная утилита kfctl по сути гонит несколько раз цикл применения манифестов — дешевое и сердитое, но рабочее решение). Хельмом сделать нормальный релиз вообще невозможно. Если нужно что-то сложнее, чем роллинг обновление одного дейплоймента. А если канарейка нужна? А если Green/Blue? Не, не работает. Я уж не говорю про то, что Хельмом накатить нечто, что нестандартное, например, Argo Rollout — увольте.
Еще проблема — если тебе нужно деплоить что-то вроде VirtualService Istio или OPA Gatekeeper constraints. Потому что один объект куба не может принадлежать двум релизам или двум инстанцированиям пайплайна (для того же Green/Blue deploy). Приходится обкладывать костылями
Короче — безопасно использовать хельм только для темплейтинга. Но лучше смотреть в сторону других вариантов "пакетирования" софта для куба.
werf vs. Helm: корректно ли их вообще сравнивать?
поэтому я полностью согласен с заголовком статьи — это совсем разные инструменты, с совершенно разными задачами и разным скоупом.
В Helm поддержка секретов возможна через подключение сторонних плагинов. Это усложняет установку Helm на новые хосты.
я бы уточнил — что тут имеется в виду? Шифрование "секретных" значений из values.yaml? Ну, так вроде есть договоренность, что либо можно values.yaml засунуть в гитлаб переменные и так обеспечить их сохранность, либо точечно добавлять "секретные" переменные через конкретные гитлаб переменные, дописывая их в конце вызова helm… Ну, или, лучше, на мой взгляд, использовать механизмы вроде sops — https://github.com/mozilla/sops
Если кратко, и не придираться к мелочам – абсолютно согласен.
Тут нужно понимать, что мы часто видим вопросы в духе "в чем отличие werf от helm" или "зачем werf, если есть helm". Стараемся объяснить как можно проще тем, кто входит в тему.
Да интереснее наверно было бы сравнение с тулами. Я вот например на Flux2 второй кластер перевожу. Несмотря на то что ещё сыроват (и не GA даже) уже нравится и никаких проблем.
Отличная статья, но на мой взгляд местами too opinionated :)
Ничего не имею против Werf, я люблю стандартизацию подходов и тулза у вас вышла отличная, но тем не менее выскажу немного критики по содержанию:
CI/CD у нас обычно несколько окружений (production, staging, development и т. д.). И конфигурация приложения может отличаться для разных окружений.
Технически Helm позволяет конфигурировать описанный chart параметрами, через которые передаются образы приложения и выбранное окружение. Однако конкретный путь — как это делать — не стандартизован. Пользователю Helm приходится решать это самому.
На счёт "не стандартизован" соглашусь, вариантов достичь желаемого достаточно много: можно передавать параметры через опции CLI или переменные окружения; можно пилить umbrela-чарты с оверрайдами для каждого энвайромента, но считаю что подход с использованием нескольких values файлов наиболее стандартным и популярным:
-f base.yaml -f stage.yaml-f base.yaml -f prod.yamlКстати, аналогичным образом можно передавать и секреты.
Если я правильно понял, werf позволяет реализовать тот же паттерн, но в виду упомянутого вами гитерминизма, по прежнему, не является правильным. К слову, тот же Helmfile позволяет указать набор параметров для хельма в зависимости от конкретного энвайромента.
Таким образом у меня по прежнему возникает вопрос: каким образом в werf правильно хранить и передавать параметры для разных энвайроментов? :)
- werf должна поддерживать GitOps-подход
GitOps в общем виде — это подход, при котором для развертывания приложений в Kubernetes используется единственный источник правды — Git-репозиторий. Через декларативные действия в Git вы управляете реальным состоянием инфраструктуры, запущенной в Kubernetes. Этот паттерн «из коробки» работает в werf.
У нас есть собственный взгляд на то, как должен быть реализован GitOps для CI/CD (уже упомянутый Giterminism). GitOps в werf поддерживает не только хранение Kubernetes-манифестов в Git, но и версионирование собираемых образов, связанное с Git. Откат до предыдущей версии приложения выполняется без сборки выкатывавшихся ранее образов (при условии, что версия учитывается политиками очистки). Другие существующие реализации GitOps не дают этой гарантии.
Можно долго ходить вокруг да около GitOps (огромное "спасибо" Weaveworks за то что придумали такой неоднозначный термин). Хранение правды в Git да, но всё-таки оно немного не про то.
Использование GitOps подразумевает наличие контроллера или GitOps-оператора (называйте как хотите), который делает непрерывный синк состояния Git-репозитория с Kubernetes-кластером.
По сути — это такой же reconciling loop, по аналогии с тем как контроллеры Kubernetes создают нижестоящие ресурсы. Например Deployment генерирует ReplicaSet, ReplicaSet генерирует Pods. Таким же образом должен работать и GitOps-оператор, отрендерив код описанного приложения в Git-репозитории, он должен непрерывно перекладывать его в Kubernetes.
Оба решения Helm и Werf не обладают данной характеристикой. Однако иметь контроллер Werf для Flux2, думаю, было бы весьма здорово.
Для организации GitOps, в том понимании в котором он изначально задумывался, таких решения сейчас два: ArgoCD и FluxCD. Второй более нативен к хельму, так как непосредственно использует его для деплоя в кластер.
Забавен тот факт, что применение GitOps может быть вообще не завязано на использование Git. Вышеупомянутые тулзы могут следить и работать также с Helm-registry и даже S3-бакетами.
У нас есть собственный взгляд на то, как должен быть реализован GitOps для CI/CD (уже упомянутый Giterminism). GitOps в werf поддерживает не только хранение Kubernetes-манифестов в Git, но и версионирование собираемых образов, связанное с Git. Откат до предыдущей версии приложения выполняется без сборки выкатывавшихся ранее образов (при условии, что версия учитывается политиками очистки). Другие существующие реализации GitOps не дают этой гарантии.
Здесь стоит упомянуть про kbld и kapp и другие утилиты от Caravel, которые делают примерно тоже самое что и Werf, но без жёсткой привязки к конкретному стеку.
И Gitkube, решения, которое может выступать в качестве гейтвея для деплоя с помощью простого git push, оно также умеет собирать образы и подставлять дайджест в темплейты.
Так как оно представляет своего рода гейтвей Git-to-Kubernetes, оно в принципе не позволяет запушить неисправный коммит в кластер. Таким образом, скрепя зубами, его всё таки можно назвать push-based GitOps-решением, однако оно не развивается уже как 3 года и я не советовал бы его использовать.
Моё мнение, что текущий вектор развития Werf, если вы держите курс на GitOps, должен основываться на изложенных выше идеях. При этом вам не потребуется существенно изменять функционал и логику работы Werf. Наоборот, вам просто нужно дополнить её соответствующим контроллером.
Сделать оператор как одну из опций (в дополнение к текущей, но не вместо ее) стоит в планах проекта: https://github.com/werf/werf/issues/2612
По терминологии — понятие GitOps нам тоже не очень (но его более-менее "знают"), поэтому придумали Giterminism.
Если у меня несколько (немного) микросервисов с 2-3 environments и минимальными требованиями к сценариям деплоя, то будет ли использование Werf для CD проще чем ArgoCD?
У меня есть опыт использования ArgoCD в одном проекте и ИМХО ArgoCD слишком сложен для простых проектов.
В арго и Флакс уже внесли изменения, которые позволяют их адаптировать именно к простым проектам. Например, теперь легко сделать историю с фиче-ветками (раньше надо было изобретать очередной слой абстракций)
Да, определённо проще — минимум конфигураций и, в базовом случае, всего одна werf-команда. Можно поднять за несколько часов на том же самом GitHub Actions (werf/actions).
werf vs. Helm: корректно ли их вообще сравнивать?