Host-native без Docker: что упрощается, а что остаётся вашей работой

Отказ от Docker иногда воспринимают как обещание, что инфраструктура исчезает. Она не исчезает: меняется способ управления процессами. В host-native схеме приложение работает непосредственно на Linux-хосте под systemd, хранит состояние в PostgreSQL и подключает дополнительные службы по сети. Меньше слоёв — не то же самое, что ноль эксплуатации.

AiHummer разворачивается как релизный tarball и управляется systemd. Основной gateway объединяет административный API и движок обработки запросов. PostgreSQL хранит состояние. STT, TTS, SIP и другие sidecar-возможности, если они нужны, работают как отдельные host-сервисы и подключаются по URL. Плагины также проходят управляемый жизненный цикл и health-check.

Прозрачные процессы и каталоги

В контейнерной схеме оператор часто начинает с образа, volume и runtime. В host-native схеме он видит обычный процесс, пользователя, unit-файл, окружение службы и каталоги данных. Стандартные инструменты Linux отвечают на вопросы: кто запустил процесс, какие порты он слушает, сколько памяти потребляет и куда пишет журнал.

Эта прозрачность помогает расследовать проблемы, но требует дисциплины. Нельзя запускать сервис от случайного пользователя, смешивать данные и временные файлы или выдавать права 777. Определите владельца каталогов, минимальные разрешения и границу между конфигурацией, секретами, релизами и пользовательскими данными.

Systemd как оркестратор одного хоста

Systemd запускает службу, перезапускает её по политике, задаёт зависимости и собирает журнал. Unit должен отражать реальные зависимости: сеть, база данных, каталоги и sidecar-службы. После старта проверяйте не только состояние active, но и readiness приложения. Процесс может работать, пока обязательный внешний компонент недоступен.

Для плагинов AiHummer использует sandbox-unit и считает установку активной только после успешного health-check. Это важная граница: «файлы распакованы» не равно «сервис здоров». Тот же принцип применяйте к основному шлюзу и своим интеграциям.

PostgreSQL — отдельная эксплуатационная система

База данных не становится деталью, которую можно забыть. Нужны резервные копии, проверка восстановления, мониторинг соединений, место на диске, обновления и защита учётных данных. Миграции применяются автоматически по контракту релиза, но оператор всё равно обязан иметь план возврата сервиса и актуальную копию данных.

Отделяйте доступ владельца схемы от ограниченной роли приложения. В стандартном развёртывании RLS может включаться через отдельное соединение, но тарифные и конфигурационные условия нужно проверить. Не делайте вывод об изоляции только из наличия PostgreSQL.

Sidecar-службы по необходимости

Распознавание и синтез речи, телефония, память и браузерные возможности могут иметь отдельные ресурсы, порты и зависимости. Не включайте всё одновременно «на будущее». Для каждого sidecar запишите: владелец, endpoint, health-check, таймаут, лимиты, журнал, резервирование и поведение gateway при недоступности.

Отдельный процесс локализует сбой, но добавляет связь по сети. Даже loopback-соединение нуждается в аутентификации там, где проходит чувствительная операция. Внешний endpoint требует TLS, проверки адреса и политики egress.

Обновления и цепочка поставки

Host-native не означает загрузку случайного скрипта при каждом старте. Релизные артефакты и плагины должны проходить проверку целостности и подписи. В AiHummer официальные плагины проверяются по запиненному ключу, private side-load — по trust-store, неподписанное допускается только в dev-режиме.

Перед обновлением читайте changelog, проверяйте свободное место и резервную копию. После — версию, миграции, readiness и ключевые сценарии. Автоматизация обновления полезна лишь вместе с наблюдаемым результатом и процедурой восстановления.

Сеть и TLS

Gateway слушает порт, а production-доступ обычно завершается TLS на reverse proxy. Определите, какие интерфейсы доступны извне, кто управляет сертификатом и как закрыт admin API. IP-allowlist, SSO и scoped-ключи решают разные задачи: сеть отвечает «откуда», идентификация — «кто», scope — «что можно».

Не открывайте sidecar-порты наружу без необходимости. Составьте список слушающих сокетов до и после установки. Любой новый модуль должен появляться в этом списке с владельцем и назначением.

Журналы, метрики и ёмкость

Journald удобен для событий службы, но без retention способен занять диск. Настройте лимиты и экспорт, если он нужен. Метрики и health-check должны показывать не только факт процесса, но и состояние базы, очереди доставки и обязательных интеграций. Алерт без ответственного и инструкции — просто уведомление.

Ёмкость считайте для CPU, памяти, диска и сети. Локальная модель или распознавание речи меняют профиль нагрузки сильнее, чем сам gateway. Резерв на пики и обновление нужен заранее.

Что проверить перед production

• отдельный Linux-пользователь и корректные владельцы каталогов;
• подтверждённые системные требования;
• понятные unit-файлы и политика рестарта;
• TLS и закрытая административная поверхность;
• PostgreSQL-бэкап и тест восстановления;
• health/readiness для gateway и sidecar;
• ротация журналов и пороги диска;
• наблюдение CPU, RAM, очередей и ошибок;
• подписанные обновления и журнал версии;
• тест входящего сообщения, инструмента и исходящей доставки;
• план деградации при недоступной модели или интеграции.

Ограничения

Одна команда установки уменьшает механическую работу, но не выполняет архитектурную приёмку. Отсутствие Docker также не гарантирует меньшую стоимость: если команда уже стандартизировала контейнерную платформу, host-native может потребовать новые процедуры. Решение оценивается в контексте вашей эксплуатации.

Спроектируйте деградацию зависимостей

Host-native схема остаётся распределённой, если подключены PostgreSQL, модель и sidecar-службы. Для каждой зависимости определите таймаут, число повторов, пользовательский статус и условия отключения функции. Недоступный TTS не должен выдавать голосовой сценарий за успешный, а отказ необязательного модуля не обязан останавливать весь gateway. Граница зависит от процесса и должна быть записана.

Проведите контролируемые тесты: остановите sidecar, закройте соединение с моделью, временно сделайте базу недоступной. Наблюдайте systemd, readiness, журналы и восстановление. Не выполняйте такие эксперименты на рабочем трафике без окна и плана возврата. Итогом становится таблица зависимостей с критичностью и runbook. Именно она показывает, что меньше инфраструктурных слоёв действительно упростило эксплуатацию, а не просто перенесло скрытые связи в unit-файлы. Заодно проверьте, что после восстановления оператор видит единственный понятный статус зависимости, а пользователь получает спокойное объяснение без внутренних кодов и ложного обещания результата.

Источники

См. введение, установку, установку и обновления плагинов и публичный changelog. Версии и требования меняются, поэтому не переносите номера из статьи в runbook без свежей проверки.

Если host-native вам подходит, превратите этот список в приёмочный протокол: одна команда запускает установку, но только наблюдаемые проверки разрешают включить реальный трафик.