Архитектура

Opfield отделяет централизованное управление, намерения и идентификацию ресурсов от выполнения операций непосредственно на хостах. Благодаря этому вы можете управлять инфраструктурой из одного места, не открывая управляющие интерфейсы хостов в сеть.

flowchart TB
    users["Пользователи и автоматизация"] -->|"HTTPS / WebSocket"| gateway["Приложение Opfield"]
    gateway <-->|"Долговременное состояние и координация"| state[("PostgreSQL / Redis")]
    gateway <-->|"Аутентифицированный служебный канал"| relay["Opfield Relay<br/>TCP 9443"]

    subgraph hosts["Управляемые хосты"]
        direction LR
        daemons["Ролевые демоны<br/>nginx · Docker · Storage · Build Worker · Monitoring"]
        workloads["Приватные адреса приложений и баз данных"]
        daemons -.->|"Жизненный цикл на хосте"| workloads
    end

    relay <-->|"Исходящие управляющие сеансы"| daemons
    relay <-->|"Приватные потоки данных"| workloads

Полезная нагрузка передаётся напрямую между Relay и локальными адресами приложений или баз данных. Opfield авторизует и координирует эти пути, но само приложение Opfield не участвует в передаче полезной нагрузки.

Плоскость управления

Приложение Opfield образует контур управления. В его зоне ответственности находятся пользователи, группы, области доступа, определения ресурсов, желаемое состояние, записи аудита, зашифрованные учётные данные интеграций, состояние длительных операций и решения по восстановлению. PostgreSQL служит долговременным источником истины для этих данных. Redis обеспечивает необходимую кратковременную координацию — сеансы, кэши, очереди, ограничения частоты запросов и ограниченные резервирования, — но не заменяет долговременное состояние ресурсов.

Операторы и системы автоматизации передают свои намерения в контур управления через Operations Console, REST API, OAuth, удалённый MCP или AI Workspace. Все эти точки входа используют одинаковые серверные проверки авторизации, валидации, доступности функций по тарифу, владения и жизненного цикла. Скрытие действия в UI не создаёт границу безопасности, а обращение через API или AI-инструмент не позволяет обойти правила продукта.

Принятый запрос не считается доказательством того, что работа на хосте завершена. Изменения, для которых нужен демон, сохраняются и отправляются как ограниченные операции. Ответственный демон сообщает ход выполнения и наблюдаемое состояние, а Opfield показывает долговременные Tasks, состояние ресурса, события и журналы. По этим данным оператор может подтвердить, что фактическое состояние сошлось с желаемым.

Relay

Relay — обязательная долговременная служба контура данных и единственный публичный владелец 9443/tcp. Управляемые демоны устанавливают исходящие соединения через аутентифицированный транспорт; обычно их управляющие интерфейсы не открыты в сеть. Служба приёма gRPC-соединений приложения Opfield остаётся внутренней, а взаимодействие с Relay проходит через аутентифицированную межсервисную границу.

Relay передаёт управляющий трафик управляемых нод и поддерживаемые приватные потоки. При этом Relay не отвечает за конфигурацию nginx, Containers, базы данных, сборки или мониторинг на целевом хосте. Он также не создаёт правила межсетевого экрана, не обеспечивает обход NAT и не работает как универсальный VPN. Каждый управляемый хост должен иметь доступ к назначенному адресу Relay.

Если Relay недоступен, новые операции с управляемыми нодами и новые подключения приватных связей отклоняются по безопасному принципу: Opfield не может подтвердить идентичность и авторизацию. Отказ одного только приложения Opfield — другое дело: Relay допускает соединения по подписанной политике со сроком аренды (по умолчанию 72 часа), поэтому продолжает допускать разрешённые соединения, пока приложение Opfield остановлено или недоступно; см. Relay без Opfield. Ранее применённые рабочие нагрузки могут продолжать работать локально. Существующие сеансы контура данных сохраняются только там, где это допускают протокол и жизненный цикл авторизации; работающий процесс приложения сам по себе не означает, что управляющий путь восстановлен.

Управляемые демоны

У каждого управляемого демона есть ограниченная роль и собственная идентичность. Профили Ingress, Docker, Storage, Build Worker, Monitoring и Relay предоставляют разные возможности и имеют разные границы доверия. Docker-демон не может стать демоном базы данных только потому, что клиент изменил запрос, а пользовательские API жизненного цикла не могут изменять внутренние Containers, принадлежащие Opfield.

Демоны сообщают о доступных возможностях, инвентаре, состоянии, метриках, служебных адресах и результатах операций. На основании этих отчётов Opfield решает, может ли хост безопасно выполнить действие. Одного наличия установленных пакетов недостаточно: демон должен подтвердить, что функция доступна и работоспособна. Если нода отключена или отчёт о возможностях устарел, данные для чтения могут оставаться доступными из очищенного снимка, но изменения, которым требуется актуальное состояние хоста, отклоняются.

Демон отвечает за выполнение на своём хосте: например, nginx применяет конфигурацию, Docker управляет объектами среды выполнения, а нода хранилища запускает движки баз данных. Opfield отвечает за долговременную идентичность и желаемую конфигурацию управляемых ресурсов. Такое разделение позволяет рабочей нагрузке продолжать работу при временном сбое контура управления, но не позволяет хосту самостоятельно создавать новое авторизованное состояние.

Плоскость данных

Публичный трафик приложений обслуживают ноды Ingress с nginx. Domain определяет размещение, Route задаёт поведение трафика, а Opfield передаёт сертификат только тем нодам, где включены использующие его TLS Routes. Поэтому nginx относится к контура данных, а записи Domain, Route, сертификата, доступа и желаемого состояния остаются в контура управления.

Для приватных путей используются узкие специализированные механизмы, а не единая плоская сеть. Secure Link между nginx и рабочей нагрузкой использует принадлежащий Opfield коннектор и транспорт Relay. Привязки управляемых баз данных, привязки хранилища и связи контейнеров работают через один общий коннектор защищённых связей на каждой ноде Docker, каждая связь — в собственной приватной сети; у привязки базы данных также есть отдельная идентичность движка. Все эти механизмы обеспечивают приватное подключение, но имеют разные зоны ответственности и способы диагностики.

Opfield Inference образует ещё одну отдельную контур данных. Контролируемое ядро вывода обращается к поставщикам и доступно через прокси Opfield. Опубликованные идентификаторы моделей, подключения поставщиков, пользовательские лимиты, учёт и авторизация остаются в зоне ответственности контура управления Opfield.

Эксплуатационные границы

Чтобы определить ответственный за сбой уровень, начните со страницы ресурса и долговременной истории операций. Сохранённое желаемое состояние при отключённой ноде указывает прежде всего на хост, демон, системное время, DNS, идентичность сертификата или соединение с Relay. Подключённая нода с неуспешной Task указывает на среду выполнения или предварительное условие конкретной роли. Работоспособная среда выполнения при неудачном публичном запросе указывает на цепочку Domain, TLS, Route, Secure Link или на само приложение.

Не пытайтесь исправить нарушение владения прямым редактированием внутренних дочерних объектов. Слоты Deployment управляются через Deployment, Containers и сети Compose — через Compose Project, Secure Links конкретного Route следуют за этим Route, а идентичности управляемых баз данных — за жизненным циклом привязки. Прямое изменение на хосте может создать расхождение, которое Opfield не сможет безопасно устранить.

Модель отказов

Пока нода отключена, представления для чтения могут использовать очищенные снимки последнего известного состояния. Эти данные помогают диагностике, но не подтверждают текущую авторизацию. Изменения остаются недоступными, если Opfield не может доказать владение, наличие нужной возможности, доступность функции по тарифу или актуальное состояние.

Желаемое состояние и записи операций хранятся долговременно, поэтому Opfield может согласовать состояние после перезапуска приложения, Relay, демона или ноды. При восстановлении сначала верните в работу ответственный за сбой компонент, дождитесь свежего инвентаря и отчёта о возможностях, затем проверьте каждое семейство зависимых ресурсов. Не удаляйте и не создавайте идентичности заново первым действием: это может отозвать права, нарушить связи или помешать прежнему демону безопасно переподключиться.

Подробная матрица отказов для каждого пути — включая различие между работающим Relay, локальным Relay на потерянном хосте Opfield и независимым внешним Relay — приведена в разделе Доступность, совместимость и пределы.