CONTROL CENTER MARKET — УСТАНОВКА, ОБНОВЛЕНИЕ И УДАЛЕНИЕ МОДУЛЕЙ Продукт: Control Center Версия: [ТРЕБУЕТ УТОЧНЕНИЯ: VERSION] Тип документа: Руководство администратора Market Последнее обновление: 09.09.2026 ЧТО МЫ НАСТРОИМ Инструкция описывает общий жизненный цикл устанавливаемых Market-модулей. Market не является частью Control Center Core: модуль устанавливается отдельно по выбору администратора и имеет собственные требования, permissions, данные и процедуру обновления/удаления. ПРИМЕРЫ MARKET-МОДУЛЕЙ - Domain Services; - PXE Deployment; - Software Automation; - Inventory. Наличие этих возможностей в Market не означает, что они установлены или активны. ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ Требование | Значение Core | Healthy, поддерживаемая версия Права | Market/Module administration Compatibility | Модуль совместим с текущей версией Core Signature | Package/manifest проходит штатную проверку подписи Capacity | Достаточно CPU/RAM/storage/network Backup | Актуален перед stateful/destructive операциями Network | Разрешены только реально необходимые внешние/внутренние flows Entitlement | [ТРЕБУЕТ УТОЧНЕНИЯ: если применимо к редакции/лицензии] АРХИТЕКТУРА Control Center Core | +→ Market catalog | v Module package/manifest | compatibility + signature | permissions + capacity preview | Change | Job | Module Actual State/Health Каждый модуль должен использовать общие механизмы Identity/RBAC, Change/Job, Health, Audit и backup/recovery там, где это предусмотрено его контрактом. ПЕРЕД УСТАНОВКОЙ 1. Определите, действительно ли функция нужна. 2. Прочитайте требования конкретного модуля. 3. Проверьте совместимость Core/module. 4. Проверьте сетевые зависимости и открываемые порты. 5. Просмотрите требуемые permissions/scopes. 6. Проверьте resource profile в Capacity Planner. 7. Для stateful-модуля подготовьте backup target/recovery plan. 8. Не устанавливайте несколько альтернативных сервисов на один namespace/порт без поддерживаемой архитектуры. Шаг 1. Выбор модуля Откройте Market [Уточнить название элемента интерфейса]. Перед установкой проверьте карточку/manifest: - имя и версия; - publisher/signature status; - совместимые версии Control Center; - поддерживаемые ОС/ролей узлов; - permissions; - CPU/RAM/storage/network requirements; - required ports/integrations; - data/backup requirements; - update channel; - known limitations. [ТРЕБУЕТ УТОЧНЕНИЯ: точный manifest schema и UI]. Шаг 2. Проверка подписи и происхождения Устанавливайте только модуль, который проходит встроенную проверку package/manifest signature и compatibility. Не отключайте проверку подписи и не подменяйте package вручную. Ожидаемый результат: Market показывает модуль как доверенный/проверенный в терминах текущей версии. [ТРЕБУЕТ УТОЧНЕНИЯ: точные статусы Compatible/Verified/Trusted]. Шаг 3. Проверка permissions Просмотрите, какие действия модуль сможет выполнять. Оцените: - какие ресурсы он читает; - какие mutations выполняет; - какие scopes требуются; - нужен ли privileged execution; - какие внешние соединения создаются. Риск: Модуль с широкими permissions увеличивает blast radius. Если permission кажется избыточным — не устанавливайте модуль до выяснения причины. Шаг 4. Capacity preview Откройте Capacity Planner и выполните what-if установки модуля. Проверьте: - базовый и пиковый CPU; - RAM; - постоянный/временный storage; - disk IOPS/latency; - network; - database growth, если модуль stateful; - capacity при отказе узла в HA. Ожидаемый результат: Есть подходящее placement без нарушения headroom/fault-domain rules. Шаг 5. Установка 1. Нажмите Install [Уточнить точное название действия]. 2. Выберите версию/канал, если доступно. 3. Выберите placement. 4. Укажите только необходимые настройки. 5. Просмотрите diff, permissions и network impact. 6. Создайте Change. 7. Дождитесь Job. 8. Проверьте Module Actual State/Health. Что изменится: В Control Center появится новый управляемый модуль и связанные с ним роли/сервисы/данные согласно manifest. Риск: Модуль может потреблять ресурсы, открывать сетевые flows и хранить собственные stateful данные. Rollback: Если установка не завершилась, используйте штатный module rollback/remove/cleanup. Не удаляйте внутренние файлы/таблицы вручную. Шаг 6. Первичная конфигурация Настройте модуль по специализированной инструкции. Перед первой production mutation выполните: - Health check; - connectivity check; - backup setup для stateful module; - минимальный функциональный тест; - RBAC test. Шаг 7. Обновление модуля 1. Проверьте compatibility с текущим Core. 2. Прочитайте изменения и migrations. 3. Создайте backup данных модуля, если он stateful. 4. Проверьте capacity/storage для migration. 5. Запустите Update через Market. 6. Дождитесь Change/Job. 7. Проверьте Health и функциональность. 8. Не обновляйте критические replicas одновременно, если модуль поддерживает HA. Риск: Несовместимая версия модуля может стать Unhealthy даже при успешном Core. Rollback: Используйте только поддерживаемый module downgrade или restore. [ТРЕБУЕТ УТОЧНЕНИЯ: module rollback semantics]. Шаг 8. Отключение модуля Если поддерживается Disable: 1. определите, какие функции перестанут работать; 2. остановите новые module-specific Changes; 3. дождитесь активных Jobs; 4. выполните Disable; 5. проверьте, что данные сохранены согласно заявленной политике. Disable не равен Remove. [ТРЕБУЕТ УТОЧНЕНИЯ: поддерживается ли disabled state для всех модулей]. Шаг 9. Удаление модуля ПРЕДУПРЕЖДЕНИЕ: Remove может удалить сервисы и, в зависимости от выбранной опции, данные модуля. Перед удалением: - создайте backup/export; - проверьте зависимости других модулей/ресурсов; - завершите Jobs; - выполните drain, если применяется; - определите режим data retention. 1. Откройте Module → Remove [Уточнить UI]. 2. Просмотрите dependency report. 3. Выберите поддерживаемый вариант: сохранить данные / удалить данные / другой [ТРЕБУЕТ УТОЧНЕНИЯ]. 4. Подтвердите Change. 5. Дождитесь Job. 6. Проверьте отсутствие orphaned resources. 7. Проверьте Audit. Что изменится: Модуль перестанет предоставлять функцию; его runtime/roles удаляются согласно lifecycle. Риск: Потеря stateful data и зависимых сервисов. Rollback: До destructive data deletion отмените операцию, если lifecycle позволяет. После удаления данных — reinstall + restore из compatible backup. Шаг 10. Проверка после удаления - module отсутствует в active modules; - зависимые Jobs завершены; - network rules/ports, созданные только для него, больше не нужны или удалены штатно; - данные сохранены/удалены строго согласно выбору; - secrets/credentials модуля отозваны, если больше не нужны; - capacity освобожден; - Audit сохранен. ПРОВЕРКА MARKET - [ ] Core Healthy; - [ ] module signature verified; - [ ] compatibility confirmed; - [ ] permissions reviewed; - [ ] capacity reviewed; - [ ] network impact reviewed; - [ ] backup configured для stateful module; - [ ] Module Health Healthy; - [ ] module update policy известна; - [ ] remove/data retention policy понятна; - [ ] все действия видны в Audit. ТИПОВЫЕ ОШИБКИ Симптом | Причина | Проверка | Решение Install blocked | incompatible Core/OS/capacity | manifest/preflight | устранить blocker; не форсировать install Module Degraded | зависимость/ресурс/сеть | Module Health | устранить конкретную причину После Core update module incompatible | версия модуля не поддержана | compatibility matrix | обновить/откатить по поддерживаемому пути Remove blocked | существует зависимость/data role | dependency report | удалить/перенести зависимость безопасно После remove остались правила/credentials | lifecycle не завершен или shared dependency | Actual/Audit/network | удалить только доказанно orphaned объекты штатным Change РЕКОМЕНДАЦИИ ДЛЯ PRODUCTION - устанавливайте минимально необходимый набор модулей; - проверяйте подпись и compatibility; - оценивайте permissions и blast radius; - учитывайте module load в Capacity Planner; - делайте backup перед update/remove stateful modules; - регулярно обновляйте модули в рамках поддерживаемой compatibility matrix; - не смешивайте модульный lifecycle с ручным package management ОС. ИТОГ Market расширяет Control Center отдельными устанавливаемыми модулями. Каждый модуль проходит signature/compatibility/capacity/permission preflight, устанавливается через Change/Job, контролируется через Health/Audit и удаляется только после проверки зависимостей и политики данных. ТРЕБУЕТ УТОЧНЕНИЯ ПЕРЕД ПУБЛИКАЦИЕЙ - VERSION; - Market UI names; - manifest schema; - signature/trust statuses; - entitlement/licensing behavior; - module placement model; - update channels; - module rollback; - disable semantics; - remove/data-retention options; - dependency cleanup behavior.