Два обязательных модуля одновременно

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

M6 уроки 1–2 — механизм и полный сценарий одной mandatory-зависимости. Здесь — что происходит, когда пакету нужно сразу два обязательных модуля, на примере, аналогичном реальному Immich (self-hosted альтернатива Google Photos, использующая и PostgreSQL, и Redis).

Теория

requirements.modules.mandatory со списком из двух модулей

1
2
3
4
5
6
7
8

# package.yaml
requirements:
  modules:
    mandatory:
      - name: managed-postgres
        constraint: ">= 1.0.0"
      - name: managed-redis
        constraint: ">= 1.0.0"

Синтаксически это тот же самый список (M5 урок 2/M6 урок 1), просто с двумя элементами вместо одного — никакого специального синтаксиса «И»/«ИЛИ» не требуется: все элементы списка mandatory обязательны одновременно (это не список альтернатив, а список требований, которые должны выполняться все сразу).

Почему Immich-подобным приложениям нужны оба модуля

Реальный Immich использует PostgreSQL для хранения метаданных (альбомы, теги, пользователи) и Redis для очередей фоновых задач (генерация превью, распознавание лиц на фотографиях, транскодирование видео) — две принципиально разные категории хранения данных, каждая обслуживается своим специализированным Module платформы.

Что произойдёт, если доступен только один из двух модулей

Ключевой момент: даже если один из двух mandatory-модулей полностью готов (managed-postgres — Ready), а второй (managed-redis) отсутствует или не готов — Application не переходит в частично работающее состояние. Условие Installed требует всех mandatory-зависимостей одновременно — это булево «И», а не «хотя бы одна из». Статус явно перечисляет, какая именно зависимость всё ещё не удовлетворена:

1
2
3
4

- type: Installed
  status: "False"
  reason: InstallFailed
  message: "Required module 'managed-redis' is not enabled in the cluster (managed-postgres: OK)"

Диагностика при частичной неготовности

Практический вывод: при двух и более mandatory-зависимостях диагностика требует проверки каждой из них по отдельности, а не остановки на первой найденной проблеме — сообщение статуса должно (по конвенции хорошего Application-пакета) явно перечислять, какие конкретно зависимости не удовлетворены, а не просто «есть проблема с зависимостями» в общем виде.

1
2
3
4

for m in managed-postgres managed-redis; do
  echo "=== $m ==="
  d8 k get module "$m" -o jsonpath='{.status.phase}'; echo
done

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

• Считать, что Application частично заработает, если готов хотя бы один из нескольких mandatory-модулей. Это неверно — mandatory список требует все зависимости одновременно, частичная готовность не даёт частичной работоспособности.
• Останавливать диагностику после нахождения первой неготовой зависимости, не проверив остальные. Если модулей несколько, может быть неготово сразу несколько — стоит проверить все, чтобы не тратить несколько итераций «исправил одно — нашёл следующее».
• Проектировать пакет с зависимостью от двух модулей без явного, информативного сообщения в статусе о том, какая конкретно зависимость не удовлетворена. Общее сообщение «зависимости не готовы» без конкретики резко замедляет диагностику пользователем пакета.

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

1. Подготовьте тестовый пакет (или расширьте структуру существующего учебного примера) с двумя mandatory-зависимостями:

1
2
3
4
5
6
7

requirements:
  modules:
    mandatory:
      - name: managed-postgres
        constraint: ">= 1.0.0"
      - name: managed-redis
        constraint: ">= 1.0.0"

2. Включите только один из двух модулей и установите Application, наблюдая за статусом:

1
2
3
4

d8 k patch moduleconfig managed-postgres --type=merge -p '{"spec":{"enabled":true}}'
d8 k patch moduleconfig managed-redis --type=merge -p '{"spec":{"enabled":false}}'
d8 k apply -n course-m6-immich -f application.yaml
d8 k get app immich-demo -n course-m6-immich -o jsonpath='{.status.conditions}' | jq

3. Включите второй модуль и убедитесь, что Application переходит к следующим стадиям статусной модели:

1
2

d8 k patch moduleconfig managed-redis --type=merge -p '{"spec":{"enabled":true}}'
d8 k get app immich-demo -n course-m6-immich -w

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

Практики разработки в этом уроке нет — фокус на понимании поведения при множественных зависимостях.

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

1

d8 k get module <name> -o jsonpath='{.status.phase}'

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

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

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

• Deckhouse — Разработка Application-пакета
• Deckhouse — Зависимости Module

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

• Разворачиваем приложение в кластере Kubernetes под управлением Deckhouse c помощью werf — Flant на Habr.
• Вышла werf 2.0: новый движок развёртывания Nelm — Flant на Habr.
• Готовим Gitea со вкусом werf CI/CD в кластере Deckhouse. Часть 3 — Flant на Habr.

Книги

• Michael Hausenblas, Stefan Schimanski. Programming Kubernetes. 2019. ISBN 978-1492047107.

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

• Предыдущий урок: M6.02 — pgadmin + managed-postgres целиком.
• Следующий урок: M6.04 — Паттерн «Job-миграция перед Deployment».

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