Модель ресурсов и владение

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

Стабильные идентичности

Права, привязки, настройки источника, конфигурация проверок состояния, история операций и состояние миграции относятся к идентичности ресурса Opfield. Имена в среде выполнения, идентификаторы процессов и Containers, IP-адреса и размещение могут меняться без создания нового ресурса продукта. Это позволяет Opfield пересоздавать или перемещать подходящие объекты среды выполнения, сохраняя связи, которые оператор настроил намеренно.

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

Для сопоставления ответов API, Tasks, событий, журналов и записей аудита используйте стабильные идентификаторы ресурсов и операций. Имена предназначены для операторов: они могут меняться или совпадать на разных нодах и в разных папках. Одного совпадения имени недостаточно, чтобы признать новый объект среды выполнения тем ресурсом, которым Opfield управлял ранее.

Границы владения

• Compose Project владеет своими служебными Containers, именованными томами и сетями, которые не отмечены как external.
• Сине-зелёный Deployment владеет обоими слотами среды выполнения и состоянием развёртывания.
• Управляемая база данных владеет своим Container базы данных и идентичностью владельца движка.
• Привязка базы данных владеет отдельной идентичностью приложения с минимальными правами.
• Route или Additional Route может владеть своей привязкой Secure Link.
• Внутренние Containers, принадлежащие Opfield, недоступны через пользовательские API жизненного цикла.

Эти границы не позволяют API нижнего уровня обходить жизненный цикл ресурса верхнего уровня, который создал дочерний объект. Дочерний объект может быть виден для диагностики, но не обязан допускать отдельное изменение. Например, слоты Deployment проверяются через Deployment, службы Compose — через Compose Project, а принадлежащий Route Secure Link — через создавший его Route.

Владение не распространяется автоматически на используемые зависимости. Route, использующий переиспользуемый сертификат или Access List, не владеет этими ресурсами и не удаляет их. Рабочая нагрузка, размещённая на ноде, не владеет этой нодой. Pages Route ссылается на Tag, но не владеет неизменяемым Deployment, выбранным этим Tag. Перед удалением или миграцией проверьте и принадлежащие дочерние объекты, и используемые зависимости: правила их очистки различаются.

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

Желаемое, сообщённое и фактическое состояние

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

Успешное сохранение означает, что желаемое состояние принято, но не гарантирует, что ответственный компонент уже применил его. Следите за долговременной Task и дождитесь свежего сообщённого состояния. Если нода отключена, Opfield может показывать очищенные данные последнего известного состояния, но блокирует изменения, которым требуется актуальное владение или доступная возможность. Восстановите ответственный компонент и дождитесь согласования состояния, прежде чем решать, что отсутствующий объект нужно пересоздать вручную.

Папки и навигация

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

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

Внешние ресурсы

Созданные вне Opfield Compose Project можно обнаружить по каноническим меткам Docker. Opfield может показывать их службы, состояние, работоспособность, журналы и инвентарь, но внешние проекты остаются доступными только для чтения, пока оператор явно не передаст их под управление Opfield с полной YAML-конфигурацией и необходимыми правами. Дальнейшее управление переходит к Opfield только после валидации и подготовки неизменяемой ревизии; Opfield не считает путь на хосте из метки доверенным источником конфигурации.

Внешние базы данных остаются в зоне ответственности оператора. Opfield хранит их параметры подключения в зашифрованном виде, проверяет соединение и может предоставлять разрешённые инструменты, но не управляет обновлениями движка, хранилищем, резервными копиями, доступностью или удалением. По тому же принципу глобальные образы Docker и намеренно внешние или общие ресурсы Compose не входят в очистку дочерних объектов проекта.

Безопасные изменения и удаление

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

Удаление — не просто создание в обратном порядке. Оно может снять разрешения, вывести из эксплуатации идентичности движка, принадлежащие Route связи, историю ревизий или слоты отката, намеренно сохранив переиспользуемые сертификаты, Access Lists, внешние ресурсы или постоянные тома. Прочитайте текст подтверждения, отсоедините или перенесите зависимости, сохраните необходимые данные и проследите Task удаления до завершения очистки. Если очистка прервалась, сохраните запись Opfield и используйте состояние операции для восстановления вместо принудительного удаления дочерних объектов.