👁 Правила для отслеживания ресурсов Argo CD, Flux, Prometheus, cert-manager и других

Библиотека kubedog отвечает за отслеживание Kubernetes-ресурсов во время деплоя в Nelm и werf. В неё можно добавлять дополнительные правила, чтобы трекать кастомные ресурсы любых проектов. Недавно мы добавили правила для Argo CD, Flux, Prometheus, cert-manager, Kyverno и Bitnami Sealed Secrets.

Чуть больше подробностей об этом и информацию о том, как добавить свои правила для всех пользователей (а таким contributions мы очень рады!), — см. в дискуссии на GitHub.

Значительно уменьшена нагрузка на Kubernetes при развертывании (werf 2.47.0+, Nelm 1.12.0+)

Благодаря оптимизации отслеживания ресурсов, а также отображению логов не со всех Pod'ов сразу, а только с одного Pod'а на каждый контроллер, удалось добиться значительного уменьшения нагрузки на Kubernetes при развертывании.

К примеру, на тестовом кластере нагрузка на CPU на мастер-ноде упала в 10 раз при использовании Nelm/werf для развертывания Deckhouse (40 Helm-релизов, многие развертываются параллельно). Выигрыш тем больше, чем крупнее релиз (включая количество Pod'ов).

PS: аннотация werf.io/show-logs-only-for-number-of-replicas поможет настроить для каждого контроллера количество Pod'ов, с которых будут собираться логи (теперь по умолчанию — 1 Pod).

Настраиваемый жизненный цикл ресурсов, улучшения для "plan" и другое (werf 2.49.1, nelm 1.13.1)

Добавлены три новые аннотации для настройки того, как ресурсы ведут себя при развертывании:

* werf.io/delete-policy: before-creation|succeeded|failed
Вдохновлено helm.sh/hook-delete-policy, но работает для любых ресурсов, не только хуков. Позволяет пересоздать ресурс вместо его обновления и/или удалить ресурс после его удачного/неудачного развертывания.

* werf.io/deploy-on: pre-install|install|post-install|pre-upgrade|...
Вдохновлено helm.sh/hook, но работает для любых ресурсов. Позволяет отрендерить ресурс только при конкретном типе развертывания (install, upgrade, ...), и развернуть ресурс в pre, main или post-стадии.

* werf.io/ownership: release|anyone
Вдохновлено Helm-хуками. anyone сделает так, что ресурс не будет удален, если ресурс удален из чарта или если удален релиз, также релизные аннотации не будут применяться/валидироваться.

Эти три аннотации фактически позволяют сделать из обычного ресурса Helm-хук и наоборот. Если для вас не критична совместимость вашего чарта с Helm, мы рекомендуем больше не использовать Helm-хуки и веса хуков: вместо этого используйте эти три новые аннотации вместе с werf.io/weight или werf.io/deploy-dependency. Такой подход гораздо гибче, проще и обеспечит более быстрый выкат, т.к. все ресурсы будут развернуты в одной (main) стадии.

Добавлены новые опции для контроля вывода werf plan и nelm release plan install:
--show-insignificant-diffs
--show-sensitive-diffs
--show-verbose-diffs
--show-verbose-crd-diffs
--diff-context-lines

Другие обновления plan:
* Большие (и обычно бесполезные) диффы для создающихся/удаляющихся ресурсов теперь по умолчанию скрыты (можно вернуть обратно с --show-verbose-diffs)
* В вывод добавлено отображение причин, по которым ресурсы будут "blind applied"

Другие изменения:
* При выкате ресурсы начнут отображаться в таблице прогресса в момент их развертывания, а не с самого начала релиза
* Исправлено: render не рендерит хуки, если в них не присутствует pre-install или post-install
* Исправлено: давний баг с проблемами при выкате Helm-чартов с ресурсами с helm.sh/hook-delete-policy: succeeded

Больше про новые аннотации: https://ru.werf.io/docs/v2/usage/deploy/resource_lifecycle.html

Дайджест изменений в werf v2.47.1-v2.56.2

За последние 4 месяца в werf были добавлены 4 новые команды, 7 аннотаций, 48 CLI-флагов и ряд других улучшений.

В этом сообщении на GitHub мы собрали список недавних изменений 🙌

Дайджест по Nelm v1.12.0-v1.19 и зрелость Nelm v1

В дополнение к предыдущему анонсу по werf мы также представляем обзор последних изменений в Nelm. Поскольку проект за это время пережил значительный рефакторинг, добавление 60(!) новых фич и исправление накопившихся проблем, мы считаем Nelm v1 стабильным и «достаточно завершённым».

Поэтому приступаем к работе над Nelm v2 и Nelm-оператором. В то же время отметим продолжающуюся community-инициативу по реализации альтернативы Go-шаблонам в Nelm на базе TypeScript. По этой фиче есть формальный proposal, и все желающие поучаствовать приглашаются к обсуждению и реализации 🙌

Nelm, альтернатива для Helm, созданная в werf, чтобы деплой чартов в Kubernetes стал мощнее и удобнее, получил свою первую 1000 GitHub-звёзд 🎉

Тем временем, мы работаем над новыми фичами для утилиты — следите за обновлениями 😉

Проект werf сегодня отмечает своё десятилетие! 😮🥳

По этому случаю мы написали много ретроспективных букв о том, как проект развивался все эти годы, а также собрали немного праздничных цитат от наших пользователей. Погрузиться в историю werf и порадоваться вместе с нами можно в этой статье на Хабре 🙏

Расширенная локальная валидация ресурсов (werf v2.60.0, nelm v1.21.0)

Мы добавили поддержку расширенной локальной валидации стандартных и кастомных ресурсов на основе JSON Schema. Механизм основан на kubeconform.

Как это работает?

* Валидируем YAML
* Валидируем стандартные ресурсы декодером Kubernetes
* Валидируем стандартные ресурсы JSON-схемами из репозитория https://github.com/yannh/kubernetes-json-schema
* Валидируем кастомные ресурсы JSON-схемами из репозитория https://github.com/datreeio/CRDs-catalog (более 3 тысяч схем для популярных ресурсов)

Всё работает из коробки, настройки не требует. Ложные срабатывания практически исключены. Предположительно, новая валидация покрывает 95%+ встречающихся в реальности ресурсов.

Для изолированных окружений (без доступа к интернету) можно указать локальные JSON-схемы для валидации.

Как включить?

Фича доступна в экспериментальном режиме и включается переменной окружения NELM_FEAT_RESOURCE_VALIDATION=true. В следующем мажорном релизе фича будет включена по умолчанию.

Фича доступа в рамках работы следующих команд:

* werf plan
* werf converge
* werf rollback
* werf lint
* werf bundle plan
* werf bundle apply
* nelm release plan install
* nelm release install
* nelm release rollback
* nelm release chart lint

Новые флаги для гибкой настройки:

* --no-resource-validation
* --local-resource-validation
* --resource-validation-kube-version
* --resource-validation-skip
* --resource-validation-schema
* --resource-validation-extra-schema
* --resource-validation-cache-lifetime

P.S. Анонс фичи на GitHub.

Управление порядком удаления ресурсов (werf v2.60.0, nelm v1.21.0)

В дополнение к аннотации werf.io/deploy-dependency-<id>, задающей порядок выката ресурсов, добавлена новая аннотация werf.io/delete-dependency-<id>, задающая порядок удаления.

Пример:

kind: ValidatingWebhookConfiguration
metadata:
  name: my-webhook
---
kind: Deployment
metadata:
  name: my-webhook-deployment
  annotations:
    werf.io/delete-dependency-webhook: state=absent,kind=ValidatingWebhookConfiguration,name=my-webhook

В этом случае Deployment будет удалён только после того, как удалится ValidatingWebhookConfiguration. Пока можно дожидаться только ресурсов внутри релиза; зависимости от внешних ресурсов добавим позже.

Автоматическое определение порядка:

Для многих проблемных ресурсов мы проставляем порядок удаления автоматически. Например, если в релизе планируются к удалению ServiceAccount и использующий его Deployment, то мы сначала удалим Deployment, а потом ServiceAccount. Это работает для Namespace, ClusterRole, Role, ServiceAccount, CRD и других — аннотация не нужна.

Активация фичи:

Функция доступна только при export WERF_EXPERIMENT_NEW_DISMISS=1 в werf или export NELM_FEAT_NATIVE_RELEASE_UNINSTALL=true для Nelm. Будет включена по умолчанию в werf v3 и Nelm v2.

Подробности по фиче см. в документации:

* Развертывание / Порядок развертывания / Задание порядка удаления (только werf)
* Справочник / Аннотации для деплоя / Delete dependencies

P.S. Анонс фичи на GitHub.

Деплой по заранее построенному плану (werf v2.62.0, nelm v1.22.0)

Теперь можно сохранять план выката с werf plan --save-plan и деплоить этот план с помощью werf converge --use-plan. Вдохновлено и работает аналогично выполнению terraform plan -out и terraform apply.

Выкат в CI можно разделить на три шага:

1. Построение плана
2. Ревью и ручное или автоматическое одобрение планируемых изменений
3. Выполнение построенного плана

С --use-plan для выката будет использован именно тот план, который был построен с werf plan. А если --use-plan не использовался, то план будет пересобран дважды — один раз при werf plan, второй раз при werf converge — и может отличаться.

Работа с сохранённым планом

Сохранённый план представляет собой JSON-файл, сжатый с помощью gzip. Вы в любой момент можете просмотреть список запланированных этим планом изменений, используя команды:

- werf plan --show-plan <путь до сохраненного плана>
- nelm release plan show <путь до сохраненного плана>

Если при создании плана указан параметр --secret-key, то сохранённый план будет шифроваться.

Новые команды и флаги:

- werf plan: --save-plan, --show-plan
- werf converge: --use plan
- nelm release plan install: --save-plan
- nelm release install: --use plan
- nelm release plan show

P.S. Анонс фичи на GitHub.

🚀 Расширенная информация о собранных образах (werf 2.65.0)

⚙️ Вернули $.Values.global.werf

Информация об окружении и собранных образах werf теперь снова доступна в $.Values.global.werf. Использовать эти values в сабчартах проще, т. к. для их проброса не нужны export-values: любые глобальные values сразу доступны во всех чартах.

Использование $.Values.werf более не рекомендуется, но их поддержка остается — переписывать чарты не нужно.

⚙️ Собранные образы теперь можно пробросить в любой чарт

Во вновь добавленном $.Values.global.werf информация о собранных образах представлена гораздо более подробно, чем в $.Values.werf. Сравните сами, было:

werf:
  image:
    backend: example.org/apps/myapp:a243949...816
  tag:
    backend: a243949...816
  repo: apps/myapp

… и стало:

global:
  werf:
    images:
      backend:
        registry: example.org          # адрес container registry
        namespace: apps                # namespace репозитория
        name: myapp                    # короткое имя образа
        tag: a243949...816             # тег
        digest: sha256:ece15c4a...     # дайджест образа
        tag_digest: "a243949...816@sha256:ece15c4a..."

        image: example.org/apps/myapp                       # registry + repository
        repository: apps/myapp                              # namespace + name

        ref: "example.org/apps/myapp:tag@sha256:..."        # полная ссылка с дайджестом
        ref_tag: "example.org/apps/myapp:tag"               # полная ссылка с тегом
        repository_ref: "apps/myapp:tag@sha256:..."         # repository + tag + digest
        repository_tag: "apps/myapp:tag"                    # repository + tag
        name_ref: "myapp:tag@sha256:..."                    # name + tag + digest
        name_tag: "myapp:tag"                               # name + tag

Были добавлены все возможные комбинации для передачи информации об образах в сторонние чарты. Теперь неважно, какой формат указания образа используется в стороннем чарте: формат всегда найдется в $.Values.global.werf, после чего вы можете передать сборочную информацию через export-values, не форкая сам чарт. Например:

# .helm/Chart.yaml:
dependencies:
- name: postgres-operator
  export-values:
  - parent: global.werf.images.pg.registry
    child: image.registry
  - parent: global.werf.images.pg.repository
    child: image.repository
  - parent: global.werf.images.pg.tag
    child: image.tag

🔒Добавлена информация о digest’ах образов

Теперь можно ссылаться на образ по его digest’у, а не только по тегу. Это критично для сценариев, где тег может быть перезаписан (например, latest или stable), и гарантирует, что Kubernetes будет использовать именно тот образ, который успешно прошел все тесты на этапе CI/CD. Digest и прочие форматы его включающие доступны в $.Values.global.werf.images.<name>.

Больше информации — в документации.

P.S. Анонс фичи на GitHub.

🚀 TypeScript как альтернатива Helm-шаблонам (werf 2.68.0 / Nelm 1.24.0)

⚙️ О Helm-шаблонах

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

Принципиально улучшить Helm-шаблонизацию нельзя в силу технических причин. Но можно дать альтернативу для сложных сценариев.

⚙️ TypeScript как альтернатива

TypeScript широко используется для решения схожих задач в Pulumi, cdk8s, AWS CDK. Поэтому в дополнение к Helm-шаблонам мы добавили возможность использовать TypeScript для рендеринга манифестов.

Что даёт TypeScript для рендеринга манифестов в werf/Nelm:

- Отличная поддержка в IDE/редакторах: автоматическое дополнение, навигация по коду, статический анализ, рефакторинг, отладчик.
- Стандартный синтаксис: полноценные функции, типизация и прочее.
- Обширное сообщество: библиотеки, тулинг, обучающие материалы.
- Оригинальный TypeScript: никаких надстроек, разрабатывать чарт можно даже без werf/Nelm.
- Безопасно: TS исполняется в песочнице Deno, без доступа к сети, файловой системе, переменным окружения и т. п.
- Быстро: TS/JS-зависимости минифицируются и зашиваются в чарт при публикации, для исполнения TS нужен только бинарь Deno, который скачивается и кэшируется автоматически, TS исполняется с Deno Runtime крайне быстро.
- Работает из коробки: для развертывания чарта с TS нужен только werf/Nelm, никаких системных зависимостей.
- Поддерживается развертывание в изолированных окружениях.

🔧 Как попробовать

Включите поддержку TypeScript:

export NELM_FEAT_TYPESCRIPT=true

Для инициализации TypeScript в существующем чарте выполните:

werf chart ts init

… или:

nelm chart ts init ./mychart

Сгенерированный этими командами Deployment — см. по ссылке на GitHub внизу.

Для развертывания просто запустите:

werf converge

… или:

nelm release install -n myns -r myrelease ./mychart

Больше информации:
- Документация
- Анонс фичи на GitHub