Ноды и демоны

Создание ВМ прямо из Opfield описано в разделе Хостинг-провайдеры. Подключённые учётные записи доступны в Nodes > Providers. В руководстве также описаны управление питанием ВМ, фаервол, снапшоты и права на финансы.

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

Opfield разделяет зоны ответственности Ingress, Docker, Storage, Build Worker, Monitoring и Relay. При регистрации выберите точную роль и не используйте одну идентичность демона для другой границы доверия.

Страница ноды — основное место для проверки соединения, несовпадения возможностей, готовности к обновлению, нагрузки на ресурсы, последних операций и последнего синхронизированного состояния. Устаревший снимок помогает диагностике только для чтения, но никогда не разрешает изменения.

Идентичность и состояние

При создании ноды сначала появляется ожидающая долговременная идентичность. Сгенерированный токен регистрации одноразовый и относится только к ней. Успешная регистрация устанавливает сертификат демона и переводит ноду в состояние подключённого управляемого хоста. Удаление и повторное создание записи намеренно создаёт другую идентичность.

Opfield различает несколько видов состояния:

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

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

Границы ролей

Роль	Зона ответственности
Ingress	конфигурация nginx, сертификаты, Routes, телеметрия доступа и трафика
Docker	Containers, Deployments, Compose Project, образы, тома, сети, сборки и адреса миграции
Build Worker	изолированное выполнение сборок Git и допуск артефактов
Storage	управляемые движки PostgreSQL, Redis и ClickHouse, управляемое объектное хранилище SeaweedFS (устаревшие кластеры MinIO продолжают работать), образы хранилища, прямые адреса, телеметрия баз данных, а также задания резервного копирования и восстановления; универсальные рабочие нагрузки отклоняются
Monitoring	метрики хоста без доступа к жизненному циклу рабочих нагрузок
Relay	аутентифицированный транспорт нод и поддерживаемые приватные туннели

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

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

Для каждой ноды в рабочей среде убедитесь:

• имя и отображаемое название указывают на правильный физический хост;
• служебные адреса доступны тем системам, которым они предназначены;
• версия и состояние совместимости актуальны;
• ожидаемые возможности работоспособны, а не просто присутствуют;
• для нагрузки на хранилище, память, CPU и диск настроены оповещения;
• процедуры обновления и восстановления документированы;
• нода находится в правильной папке и областях прав.

Владение и граница доверия

Запись ноды и сертификат демона — идентичности контура управления, а не псевдонимы IP-адреса. Переустановка хоста под заново созданной нодой создаёт нового владельца, даже если имя хоста и адрес не изменились. Ресурсы, разрешения, операции и кэшированный инвентарь старой идентичности не переходят автоматически только из-за совпадения отображаемого имени.

Защищайте хост в соответствии с ролью. Нода Docker или нода хранилища имеет доступ к данным приложений, нода Ingress хранит закрытый материал сертификатов, Build Worker обрабатывает потенциально враждебные данные репозитория, а Relay передаёт аутентифицированное управление и приватные потоки. Не объединяйте роли на одном хосте, если это разрушает границу безопасности или отказа. Opfield показывает роли отдельно, потому что их привилегии и область последствий различаются.

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

Приёмка после регистрации

Не размещайте ресурсы рабочей среды на ноде сразу после появления состояния online. Дождитесь свежих инвентаря и метрик, затем проверьте ожидаемые возможности роли и служебные адреса. Выполните одну малорисковую профильную операцию: валидацию конфигурации nginx на Ingress, просмотр тестовой рабочей нагрузки на Docker, допущенную тестовую сборку на Build Worker или предварительную проверку хранилища на ноде Storage.

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

Перед регистрацией прочитайте Роли нод и установка, а перед развёртыванием в рабочей среде — Обновления нод и поведение при отключении.