Компоненты и линтеры платформы
Что нужно знать перед уроком
- M2.01 — Application vs Module — нужна граница Application/Module для понимания, почему линтеры разные
Что нужно знать перед уроком
M2 уроки 1–3 — граница Application/Module, устройство платформы, объекты зависимостей. Последний урок модуля — обзор компонентов, которые реально исполняют рендер/деплой, и линтеров, которые проверяют качество пакетов до попадания в кластер.
Теория
nelm-source-controller/3p-helm-controller — кто реально рендерит и деплоит чарты
Когда вы (в M4/M7) вызываете werf converge или nelm release install, эти команды на этапе разработки работают локально/в CI. Но в самом кластере есть компоненты платформы, которые непрерывно следят за состоянием установленных релизов и модулей:
nelm-source-controller— компонент, отвечающий за отслеживание источников чартов (аналог того, как ArgoCD/FluxCD следят за git-репозиториями, но интегрированный со стеком Nelm/werf) и синхронизацию их состояния в кластере.3p-helm-controller— компонент для поддержки релизов, установленных в «третьесторонней» (third-party) модели Helm — обеспечивает совместимость платформы с чартами, не прошедшими полный путь через Werf/Nelm-специфичные механизмы.
Для Application-разработчика это — иллюстративное знание: вы не настраиваете эти компоненты напрямую, но полезно понимать, что «магия» деплоя, которую вы видите в кластере после werf converge, — не сам werf работает в кластере постоянно, а именно эти платформенные контроллеры поддерживают состояние.
dmtlint vs pkglint — количественное сравнение
dmtlint (Module) | pkglint (Application) | |
|---|---|---|
| Число линтеров | 9: container, docs, hooks, images, module, no-cyrillic, openapi, rbac, templates | 6: docs, icon, images, layout, oss, templates |
| Проверяет RBAC/CRD | да (rbac, openapi включает конверсии CRD) | нет — у Application просто нет RBAC/CRD, которые можно было бы проверять |
| Конфиг | .dmtlint.yaml | .pkglint.yaml |
| Запуск | dmt lint | d8 package verify |
Разница в 9 vs 6 линтеров и наличие целых категорий (rbac, часть openapi про конверсии CRD), которых физически не может быть у pkglint, — это то же самое архитектурное разграничение из M2 урока 1, выраженное в конкретных инструментах. У Module выше цена ошибки (cluster-wide RBAC, CRD, влияющие на весь кластер) — соответственно выше и строгость проверки.
Подробная практика с обоими линтерами — весь M9, включая специальный разбор анализа (не написания) существующего Module через dmtlint в M9 уроках 3–4.
Роль werf/werf-giterminism.yaml в CI поставки самого Deckhouse (иллюстративно)
Сам Deckhouse — тоже собирается и поставляется через тот же стек Werf, что и ваши Application-пакеты (общность инструментов экосистемы, о которой шла речь в M0 уроке 1). Это упоминается здесь чисто иллюстративно — чтобы вы понимали: принципы giterminism, cleanup registry, которые вы изучите в M3 и M8 на примере своих Application-пакетов, — те же самые принципы, по которым живёт сама платформа.
Частые ошибки и подводные камни
- Пытаться напрямую настраивать
nelm-source-controller/3p-helm-controller. Это внутренние компоненты платформы, не предназначенные для прямой настройки Application-разработчиком — ваша точка взаимодействия —werf/nelmCLI на этапе разработки и CI. - Считать, что
pkglint— «облегчённая версия»dmtlint, а не принципиально другой набор проверок. Некоторые линтеры (icon,layout,oss) есть только уpkglintи не имеют прямого аналога вdmtlint— наборы не являются подмножеством друг друга, они отражают разные структуры пакетов.
Практика в кластере
| |
Если какие-то из компонентов недоступны в вашей CE-сборке — это ожидаемо, обзор носит ознакомительный характер.
Практика разработки
В этом уроке нет собственной сборки — обзор компонентов и инструментов, с которыми вы будете работать начиная с M3.
Шпаргалка команд урока
Полная шпаргалка dmtlint/pkglint уже доступна как заготовка:
📋 dmtlint-pkglint
, будет пополнена командами в M9.
Вопросы для самопроверки
dmtlint содержит 9 линтеров (включая rbac и openapi с конверсиями CRD), pkglint — 6, т.к. у Application физически нет RBAC/CRD для проверки.
Источник: GitHub — deckhouse/dmt
Разница в линтерах напрямую отражает архитектурную разницу ответственности: cluster-wide влияние Module требует большей строгости проверки.
Источник: Рекомендуемая литература
Линтеры отражают разные структуры пакетов Application и Module — часть проверок pkglint (icon, layout, oss) не имеет прямого аналога в dmtlint.
Источник: Рекомендуемая литература
Это платформенный компонент непрерывного слежения за состоянием релизов в кластере, отличный от локального/CI-вызова werf/nelm CLI.
Источник: Рекомендуемая литература
Deckhouse использует тот же стек Werf для собственной поставки — общность инструментов экосистемы, о которой говорилось с M0.
Источник: Werf — Giterminism
Рекомендуемая литература
Официальная документация
- GitHub — deckhouse/dmt — README.md
- GitHub — deckhouse/deckhouse-cli — internal/packagecmd/internal/verify/lint/linters/
Статьи и блоги
- Разворачиваем приложение в кластере Kubernetes под управлением Deckhouse c помощью werf — Flant на Habr.
- Установка Deckhouse в kind — Flant на Habr.
- Вышла werf 2.0: новый движок развёртывания Nelm — Flant на Habr.
Книги
- Marko Lukša. Kubernetes in Action. 2nd ed., 2022. ISBN 978-1617297618.
Связанные материалы
- Предыдущий урок: M2.03 — Module как зависимость.
- Следующий модуль: M3 — Docker и Werf, урок 1 — Docker-основы.
- Практика с линтерами целиком: M9.
✓ Урок пройден — все вопросы самопроверки отвечены верно