Ordering и dependencies целиком

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

M7 урок 1 — модель стадий, M6 урок 4 — первое знакомство с deploy-dependency на практике, M6 урок 6 — external-dependency. Этот урок собирает все четыре механизма управления порядком в единый систематический раздел.

Теория

werf.io/weight — группировка по числовому весу

1
2
3

metadata:
  annotations:
    werf.io/weight: "-10"

Ресурсы с одинаковым весом деплоятся параллельно, ресурсы с разным весом — последовательно, в порядке возрастания (отрицательные веса раньше положительных). Это самый простой механизм управления порядком — если нужно только «сначала это, потом то» без явной проверки готовности, weight часто удобнее, чем deploy-dependency.

Отличие от deploy-dependency: weight — это грубая сортировка по числу, без проверки состояния целевого ресурса (Nelm просто ждёт, пока все ресурсы с меньшим весом будут применены, не обязательно готовы). deploy-dependency — точная проверка конкретного состояния (ready, present, absent) конкретного ресурса. Для сценария «Job должен успешно завершиться перед Deployment» (M6 урок 4) weight не подходит — он гарантирует только порядок применения, а не завершения Job.

werf.io/deploy-dependency-<id> — точная зависимость по состоянию

1
2
3
4

metadata:
  annotations:
    werf.io/deploy-dependency-db: state=ready,kind=StatefulSet,name=postgres
    werf.io/deploy-dependency-migrations: state=present,kind=Job,name=db-migrate

Формат: <произвольный-id> в имени аннотации (для читаемости и во избежание конфликтов при нескольких зависимостях на одном ресурсе), значение — набор key=value через запятую: state (ready/present/absent), kind, name (и опционально namespace, если ресурс в другом namespace). Это именно тот механизм, который используется в M6 уроке 4 для миграций.

<id>.external-dependency.werf.io/resource — зависимость от ресурса вне текущего релиза

Синтаксис аналогичен deploy-dependency, но нацелен на ресурсы, управляемые другим контроллером/оператором (не самим Nelm-релизом), как разобрано в M6 уроке 6 на примере cert-manager. Ключевое отличие: deploy-dependency работает внутри DAG одного релиза, external-dependency явно выходит за его границы и опрашивает состояние произвольного объекта кластера.

werf.io/delete-dependency-<id> — зависимость порядка при удалении

1
2
3

metadata:
  annotations:
    werf.io/delete-dependency-app: state=absent,kind=Deployment,name=app

Зеркальный механизм для deploy-dependency, но для обратного направления: ресурс удаляется только после того, как указанный ресурс исчез из кластера (state=absent). Практическое применение — управление порядком очистки, когда, например, Deployment должен быть полностью удалён раньше, чем связанный с ним Secret (сначала снять нагрузку, потом убрать креды).

Сводная таблица: когда какой механизм использовать

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

• Использовать weight там, где нужна проверка готовности. weight гарантирует только порядок применения, а не завершения/готовности — для Job-миграций (которые должны завершиться успешно, а не просто быть применены) обязателен deploy-dependency с state=ready или state=present в зависимости от типа проверки.
• Путать deploy-dependency и external-dependency. Первый — для ресурсов внутри текущего Nelm-релиза (Nelm сам их создаёт и отслеживает), второй — для ресурсов, управляемых другими контроллерами (cert-manager и подобные), где Nelm лишь наблюдает за их состоянием, не управляя жизненным циклом.
• Забывать про delete-dependency при проектировании порядка удаления. По умолчанию Nelm не гарантирует специальный порядок при uninstall — если он важен (например, приложение должно остановиться раньше, чем удалится Secret с учётными данными), нужно явно описать это через delete-dependency.

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

1
2

d8 k get jobs,deployments -n course-m6-umami -o custom-columns=NAME:.metadata.name,ANNOTATIONS:.metadata.annotations
nelm release plan install -n course-m6-umami -r umami .

Изучите вывод plan — найдите в нём отражение построенного DAG на основе deploy-dependency-аннотаций вашего пакета.

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

Добавьте в пакет Umami аннотацию werf.io/weight для группировки некритичных вспомогательных ресурсов (например, ConfigMap с дефолтными дашбордами), которые не требуют проверки готовности, а просто должны применяться после основного Deployment.

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

Полная сводная таблица аннотаций порядка — 📋 nelm .

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

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

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

• Deckhouse — Nelm-аннотации для Application

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

• Вышла werf 2.0: новый движок развёртывания Nelm — Flant на Habr.
• Представляем werf 1.0 stable: GitOps и Helm — Flant на Habr.
• GitLab + K8s + Werf — Habr.

Книги

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

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

• Предыдущий урок: M7.01 — Три стадии деплоя и что на них влияет.
• Следующий урок: M7.03 — Lifecycle-аннотации целиком.

✓ Урок пройден — все вопросы самопроверки отвечены верно