0%

Три стадии деплоя и что на них влияет

Уровень: expert ~50 мин Практика: Umami (продолжение M5/M6) (MIT)

Что нужно знать перед уроком

  • M4.04 — Три стадии Nelm подробно — нужна базовая модель Render/Plan/Apply
  • M6.08 — Итоговая связка — нужен опыт с конкретными паттернами аннотаций перед систематическим справочником

Что нужно знать перед уроком

M4 урок 4 — базовая модель трёх стадий Nelm. M6 целиком — практические примеры конкретных аннотаций. Этот урок открывает M7 — полный, систематический справочник всех аннотаций Nelm по официальной документации Nelm-аннотаций, начиная с того, на какую именно стадию влияет каждая категория аннотаций.

Теория

Таблица «категория аннотаций → стадия, на которую влияет»

Категория аннотацийRenderPlanApply
werf.io/deploy-on✅ решает, попадёт ли ресурс в рендер для текущей операции——
Расшифровка секретов (werf_secret_file, secret-values.yaml)✅——
werf.io/weight, deploy-dependency-*, external-dependency.werf.io/*—✅ строят DAG—
werf.io/delete-policy, delete-propagation, delete-dependency-*—✅ определяют состав DAG✅ выполняются
werf.io/ownership, helm.sh/resource-policy—✅ влияют на то, что считается «к удалению»✅
track-termination-mode, fail-mode, failures-allowed-per-replica, no-activity-timeout——✅ работают только здесь
skip-logs, log-regex, show-logs-*——✅ работают только здесь

Render: решение «попадёт ли ресурс в рендер вообще»

werf.io/deploy-on (M7 урок 3) — единственная категория аннотаций, влияющая буквально на сам факт присутствия ресурса в итоговом наборе манифестов для конкретной операции (install/upgrade/rollback/uninstall и их pre-/post- варианты). Это принципиально отличается от остальных аннотаций: deploy-dependency/weight не решают, будет ли ресурс отрендерен — они решают когда уже отрендеренный ресурс будет применён. На стадии Render также происходит расшифровка .helm/secret-values.yaml/.helm/secret/ (M4 урок 2) — в памяти, для получения финального текста манифеста.

Plan: построение DAG на основе аннотаций порядка и владения

Все аннотации, определяющие порядок операций (weight, deploy-dependency-*, external-dependency.werf.io/*, delete-dependency-*) и то, что именно считается операцией удаления (ownership, resource-policy: keep) обрабатываются на стадии Plan (M4 урок 4) — именно здесь строится граф DAG, который затем будет исполнен на Apply. Dry-run Server-Side Apply (M4 урок 3) для каждого ресурса тоже происходит здесь, независимо от порядка (diff вычисляется для всех ресурсов параллельно, а вот применение уже подчиняется построенному графу).

Apply: только здесь работают tracking и log

Категории аннотаций из M7 уроков 4–5 (track-termination-mode, fail-mode, no-activity-timeout, все log-*) не имеют смысла ни на Render, ни на Plan — они управляют исключительно поведением во время реального применения: как долго ждать готовности ресурса, что делать при неудаче, показывать ли логи контейнеров в вывод команды. Попытка «продиагностировать» эти аннотации на этапе nelm chart render/nelm release plan install бессмысленна — они физически не активируются до Apply.

Частые ошибки и подводные камни

  • Ожидать, что deploy-dependency-* влияет на присутствие ресурса в рендере. Это не так — deploy-dependency работает только на Plan/Apply, решая порядок, а не факт наличия; за это отвечает исключительно deploy-on.
  • Пытаться отладить no-activity-timeout/fail-mode через nelm chart render. Эти аннотации активируются только на Apply — рендер их просто проигнорирует (хотя и корректно скопирует в итоговый манифест как обычные метаданные).
  • Не понимать, почему изменение weight/deploy-dependency не видно в nelm chart render, но видно в nelm release plan install. Render не строит DAG вообще — граф появляется только на стадии Plan, соответственно и эффект этих аннотаций проявляется только начиная с неё.

Практика в кластере

Практики в кластере в этом уроке нет — материал систематизирующий, практика с конкретными аннотациями — во всех последующих уроках M7.

Практика разработки

🧩 Практика урока: Umami (продолжение M5/M6) · лицензия MIT

Сопоставьте аннотации, уже применённые к пакету Umami в M6, с таблицей стадий из теории этого урока:

1

grep -rn "werf.io/" templates/ | sort

Для каждой найденной аннотации определите, на какой стадии (Render/Plan/Apply) она реально работает, сверяясь с таблицей выше — это упражнение готовит к систематическому изучению всех аннотаций в следующих уроках M7.

Шпаргалка команд урока

1
2
3

nelm chart render . -r <release>          # проявляет эффект deploy-on и расшифровки секретов
nelm release plan install -n <ns> -r <release> .   # проявляет эффект weight/deploy-dependency/ownership
nelm release install -n <ns> -r <release> .        # проявляет эффект tracking/log-аннотаций

Вопросы для самопроверки

Какая категория аннотаций решает, попадёт ли ресурс в рендер вообще?

Остальные аннотации порядка не влияют на присутствие ресурса, только на момент его применения.

Источник: Deckhouse — Nelm-аннотации

На какой стадии строится DAG операций на основе weight/deploy-dependency?

Plan — стадия построения графа операций на основе dry-run SSA и аннотаций порядка.

Источник: Deckhouse — Nelm-аннотации

Могут ли tracking-аннотации (no-activity-timeout, fail-mode) быть продиагностированы через nelm chart render?

Render — чистая шаблонизация, tracking-аннотации управляют исключительно поведением при реальном применении.

Источник: Deckhouse — Nelm-аннотации

Когда происходит расшифровка .helm/secret-values.yaml?

Как разобрано в M4 уроке 4, расшифровка секретов — часть стадии Render.

Источник: Deckhouse — Nelm-аннотации

Влияет ли werf.io/ownership на то, что происходит на стадии Render?

ownership — категория, относящаяся к владению/удалению, а не к присутствию в рендере (это зона ответственности deploy-on).

Источник: Deckhouse — Nelm-аннотации

Рекомендуемая литература

Официальная документация

Статьи и блоги

Книги

  • Matt Butcher, Matt Farina, Josh Dolitsky. Learning Helm. 2019. ISBN 978-1492036781.

Связанные материалы