Skip to content

Руководство для разработчиков ядра

Это руководство описывает внутреннюю архитектуру Exordos Core: как элементы, манифесты и ресурсы хранятся и приводятся в соответствие (reconcile) на вычислительных нодах. Оно предназначено для тех, кто работает над самим Exordos Core. Если вы хотите разработать элемент поверх платформы, см. Руководство для разработчиков приложений.

Элементы, манифесты и ресурсы#

Установка элемента (exordos em elements install <manifest.yaml>) создаёт набор связанных записей, описанных в exordos_core/elements/dm/models.py:

Модель Таблица Назначение
Manifest em_manifests Разобранный YAML-манифест (resources, imports, exports, requirements)
Element em_elements Установленный элемент (имя, версия, статус)
Resource em_resources Отдельный задекларированный ресурс внутри элемента
Import em_imports Какой ресурс какого элемента импортирован
Export em_exports Ресурс, опубликованный для импорта другими элементами

Element engine#

ElementEngine — реестр в памяти со всеми установленными элементами и их ресурсами, загружаемый из базы данных через load_from_database(). Каждый элемент представлен как Namespace, а ресурсы внутри него адресуются по строке-ссылке (например, $my_element.compute.nodes.$my_node). Реестр перезагружается при установке, обновлении или удалении манифеста, а также лениво — на первой итерации цикла reconciliation.

Reconciliation: от задекларированного ресурса до работающей ноды#

Reconciliation выполняет ElementManagerBuilder (elements/services/builders.py) — сервисный цикл, тикающий примерно раз в 3 секунды:

  1. Перебрать все ресурсы, известные element engine.
  2. Отрендерить value ресурса в target_state, разрешив ссылки $link и интерполяции f"..." (см. Рендеринг значений манифеста).
  3. Создать или обновить запись TargetResource (таблица ua_target_resources из gcl_sdk) — это контракт с агентом на стороне ноды.
  4. Universal Agent, работающий на целевой вычислительной ноде, следит за ua_target_resources на предмет записей своего kind, применяет их к реальной системе (systemd-юнит, VM, диск, конфигурационный файл и т.д.) и записывает обратно actual_resource.
  5. ElementManagerBuilder сравнивает хэш actual_resource с target_state и обновляет Resource.status соответственно.
  6. Итоговый статус элемента выводится из статусов всех его ресурсов.

Жизненный цикл статусов#

Element и Resource используют общий enum Status с тремя значениями: NEW → IN_PROGRESS → ACTIVE. На этом уровне нет статуса ERROR — ресурс, который не может сойтись, просто остаётся в IN_PROGRESS.

У некоторых типов ресурсов есть собственный, более богатый жизненный цикл. Service (таблица em_services) и Config (таблица config_configs) добавляют статус ERROR к NEW/IN_PROGRESS/ ACTIVE, поскольку эти подсистемы способны обнаружить и сообщить о неудачном применении.

Рендеринг значений манифеста#

_render_value (elements/dm/models.py) превращает строку из манифеста в конкретное значение:

  • Строка, начинающаяся с $, разрешается как ссылка на ресурс.
  • Строка, начинающаяся с f", трактуется как inline-шаблон: плейсхолдеры {$element.type.$name:field} внутри неё подставляются.
  • Любая другая строка возвращается без изменений.

Автор манифеста, забывший префикс f", не получает молча пустое значение — буквальный текст {$...} остаётся в результирующем выводе, где бы это значение ни оказалось (в конфигурационном файле, в командной строке сервиса и т.д.). См. Диагностику проблем — там описаны симптомы, к которым это приводит.

Основные типы ресурсов ядра#

  • $core.compute.nodes / $core.compute.sets — виртуальные машины и группы нод (KVM/QEMU)
  • $core.em.services — systemd-сервисы на ноде или группе нод
  • $core.vs.variables — Variable Store, используется для платформенных значений по умолчанию
  • $core.config.configs — файлы, доставляемые на ноду; требует project_id и body.kind, см. Диагностику проблем

См. также#