D/ DOBBYDEV DOCS

BLACKHOLE / DOCUMENTATION

Документация Blackhole

Понятные инструкции по настройке, работе и обслуживанию системы.

Руководство / 20

Обновление отдельных компонентов: online и offline

Версии контейнеров, совместимость, закрытый контур и безопасный план обновления.

Как читать страницу компонентов

  1. Откройте «Компоненты и мониторинг». Сверху показано число компонентов, прошедших healthcheck, требующих внимания и не имеющих подтверждённой проверки. Запущенный контейнер без healthcheck не считается исправным автоматически.
  2. Введите название службы или узла в поиск, при необходимости выберите состояние. Поиск фильтрует только уже полученный каталог; обновление состояния запрашивается отдельной кнопкой.
  3. Нажмите имя компонента или «Мониторинг». В карточке доступны измеренные CPU, память, процессы/потоки, сеть, дисковый ввод-вывод, время запуска и перезапуски. Если агент не поддерживает мониторинг, метрики не выдумываются.
  4. CPU 100% означает одно ядро. Память включает файловый кэш, лимит Docker не является почтовой квотой. Сеть и диск — накопленные байты, не скорость и не объём хранилища. Отсутствующие показатели обозначены «Нет данных».
  5. Проверяйте время снимка: данные кэшируются на несколько секунд, а устаревший снимок отмечен отдельно. Это просмотр текущего состояния, не долговременная история. Docker-сокет не выдаётся браузеру или админке; окружение, секреты, содержимое томов и логи не публикуются.

Чем «Архивы поставок» отличаются от «Компонентов»

Страница /ui/repository — отдельное хранилище загруженных файлов: загрузка, список и перенос в восстанавливаемую корзину. Она полезна для доставки архивов в закрытый контур, но не является Docker Registry или установщиком. Наличие файла, его имя версии и SHA-256 не подтверждают доверенную подпись, совместимость и разрешение установки. Страница /ui/components показывает фактически наблюдаемые контейнеры и отдельный журнал разрешённых обновлений. Загрузка в репозиторий не запускает импорт Docker или обновление. Автоматическая цепочка репозиторий → проверка полного пакета → план зависимостей → установка ещё не подключена; нельзя считать загруженный архив готовым обновлением.

Зачем нужен раздел «Компоненты»

Раздел нужен для выбора конкретного компонента, просмотра текущего образа, разрешённых обновлений и журнала. Он не должен превращаться в запуск произвольного контейнера. Установку выполняет глобальный администратор; куратор ИБ может просматривать состояние, а администратор домена не получает управление узлом или Docker. Пока отдельный агент не настроен, кнопки установки недоступны: это не означает, что почтовые службы не работают.

Что работает сейчас, а что ещё проектируется

Локальный Go-агент умеет заменить один заранее разрешённый stateless-компонент Compose образом из доверенного каталога, если этот образ уже загружен в Docker. Он проверяет проект, платформу, текущий digest и готовность сервиса, сохраняет прежнюю конфигурацию и ведёт журнал. Раздел также показывает фактический ID образа и его метки версии/revision; отсутствующая метка не заменяется версией продукта. Отдельная форма проверяет только подпись и формат offline-манифеста по заранее доверенному ключу. Архивы, зависимости и готовность к установке она не проверяет и задания не создаёт. Импорт пакетов, автоматическое вычисление зависимостей и обновление всего кластера ещё не реализованы. Поле compatibility в текущем каталоге означает проверку оператором, а не автоматический анализ совместимости.

Три версии вместо одного тега latest

  1. Версия поставки фиксирует проверенный состав всей системы: какие компоненты и схемы данных работают вместе.
  2. Версия компонента меняется независимо. Исправление веб-клиента не требует пересобирать неизменённые LDAP, Postfix и Dovecot.
  3. Digest фиксирует точный образ для выбранной платформы. Один и тот же текстовый тег не доказывает одинаковое содержимое.
  4. После частичного обновления сохраните новый состав: обновлённый digest и прежние digest остальных компонентов. История должна показывать частичное обновление, а не выдавать его за неизменённую поставку.

Когда можно обновить только один контейнер

Самостоятельное обновление допустимо, когда компонент совместим с установленными версиями API, протоколов и схем БД, не требует изменения mounts, привилегий или других сервисов. Если новая функция требует другую версию LumosLink или миграцию БД, план должен включить зависимые изменения либо отклонить установку. Неизвестная совместимость означает запрет, а не разрешение на пробу. Новая отдельная служба с новыми правами — отдельная согласованная операция, не обычная замена image.

Открытый контур: доставка из реестра

  1. Сборку выбранного компонента выполняют явно в согласованном Linux-окружении. Push исходников сам по себе не должен запускать сборку или установку.
  2. Для одинакового результата в GitLab и GitHub публикуйте один собранный артефакт в оба реестра и проверяйте его digest. Две независимые сборки одинакового commit не гарантируют одинаковый образ.
  3. До остановки сервисов загрузите только нужные образы по digest из разрешённого реестра или корпоративного зеркала. Registry-токен храните отдельно от пакета и журналов.
  4. В текущей реализации оператор заранее проверяет совместимость, доставляет образы и готовит доверенный каталог агента. Автоматический online-менеджер пакетов — следующий этап, а не уже работающая кнопка.

Закрытый контур: без запросов в интернет

  1. На подключённой машине подготовьте необходимые образы точной платформы и перечень их версий, digest и зависимостей. Не включайте секреты, пароли и пользовательские данные.
  2. Docker image save переносит образы в архив, Docker image load загружает их на закрытом узле. Это доставка артефактов, а не проверка совместимости и не установка приложения.
  3. Сверьте контрольные суммы и доверенный источник, после импорта проверьте фактическую идентичность образов. Не останавливайте службы, пока все необходимые артефакты не доступны локально.
  4. Сейчас подпись и формат отдельного JSON-манифеста можно проверить без интернета в разделе «Компоненты» или CLI manifest-check. Успешная проверка не подтверждает архив: оператор по-прежнему отдельно проверяет и подготавливает локальные образы и root-owned каталог. Безопасный offline-import и расчёт плана — следующие этапы. Ключ подписи нельзя автоматически признать доверенным только потому, что он находится в загруженном архиве.

Проверка файла автономного пакета

Отдельная Go CLI package-check проверяет файл пакета без сети, Docker и распаковки: доверенную подпись, состав, размеры и SHA-256 архивов, ограниченный OCI image graph и платформу из image config. Принимается только описанный в OFFLINE-PACKAGE.md формат Blackhole USTAR, не произвольный docker save. Команда: package-check -catalog /etc/blackhole-updater/catalog.json -package /media/blackhole-update.tar. По умолчанию размер ограничен 32 GiB, параметр -max-bytes меняет бюджет. Успех означает проверку bytes, но не совместимость зависимостей/БД и не безопасность содержимого файловой системы внутри слоёв. installable остаётся false; импорта и перезапуска нет. Перед будущей установкой нужна повторная проверка неизменяемой копии. Веб-форма «Компоненты» пока проверяет только отдельный JSON-манифест, бинарный пакет через неё не загружается.

Порядок безопасного обновления

  1. Зафиксируйте текущий состав, конфигурацию и версии схем. Проверьте свободное место именно на файловых системах Docker и данных, а не только в каталоге установщика.
  2. Подготовьте совместимый образ, резервную копию, прежний digest и условия возврата. Для почтового хранилища, очереди, DAV и БД нужна отдельная стратегия согласованности.
  3. Обновляйте только выбранную службу. На единственном экземпляре возможен перерыв; наличие Compose само по себе не даёт бесшовного обновления.
  4. Проверьте readiness и реальную операцию через используемый пользователями nginx, а не только состояние running. Сохраните результат в журнале.
  5. При recovery_required остановитесь и проверьте фактическое состояние: незавершённое задание не повторяется автоматически. Откат образа не отменяет уже выполненную миграцию данных.

Очистка после проверки

Сохраняйте действующие образы и согласованный набор для возврата. Удаляйте только подтверждённо ненужные временные артефакты и build-cache с учётом других задач на сервере. Volumes, письма, базы, TLS и ключи не относятся к мусору обновлений. Не запускайте полную очистку Docker как штатный шаг установки пакета.