Модели архитектуры и включения MXC

MXC отделяет намерение запуска рабочей нагрузки от механизма платформы, выполняющего рабочую нагрузку. Хост-приложение использует пакет SDK .NET, TypeScript или Rust для описания разрешений ресурсов и выполнения запроса. MXC преобразует запрос в операции бэкенда контейнера на текущем хосте.

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

Уровни архитектуры

Интеграция MXC состоит из четырех основных уровней:

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

Ведущее приложение по-прежнему отвечает за решения по политикам. Агент программирования может предложить модель или предоставление ресурсов, но он не должен выбирать или расширять свои собственные полномочия без доверенной логики или утверждения человека. Код, который узел выполняет за пределами MXC, остается вне изоляции рабочей нагрузки.

Параметры политики, конфигурации и среды выполнения

Политика описывает, к чему может получать доступ рабочая нагрузка. Запрос выполнения добавляет то, что нужно выполнить, где его запустить, и какое ограничение следует использовать. Параметры среды выполнения предоставляют значения, необходимые для выполнения, например конечную точку уже запущенного прокси-сервера.

SDK версии 1 хранят эти параметры в одном ContainerRequest. Его свойства файловой системы, сети и пользовательского интерфейса описывают доступ, а его свойства команды, рабочего каталога, среды, времени ожидания и изоляции описывают выполнение. Пакет SDK преобразует запрос в стабильный 1.0.0 контракт схемы, поэтому вам не нужно указывать версию схемы.

Конфигурация выполнения JSON не является взаимозаменяемой с сериализованным объектом SDK. Например, свойства запроса ui.allowInputInjection и timeoutMs соответствуют параметрам конфигурации process.timeout и ui.injection. Используйте типы пакета SDK или схему для версии конфигурации, которую вы описываете.

Однократные циклы и циклы с поддержкой состояния

MXC поддерживает два шаблона жизненного цикла.

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

Выполнение с учетом состояния предоставляет пять этапов: подготовка, запуск, выполнение, остановка и удаление ресурсов. Подготовка ресурсов возвращает непрозрачный ContainerIdобъект, который вызывающий объект передает без изменений на последующие этапы, и вызывающий объект может выполнять несколько команд до завершения. Используйте этот шаблон, только если рабочая нагрузка зависит от постоянного состояния, например профиля агента, установленных средств, конфигурации или среды операционной системы. В MXC 1.0 API жизненного цикла SDK V1 поддерживают IsolationSession и WSLc.

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

Выполнение, порождение и выполнение в PTY описывают взаимодействие узла с запущенным процессом, а не время существования среды. Вызов run возвращает захваченные выходные данные после завершения выполнения. При выполнении рабочей нагрузки вызов spawn предоставляет вашему хосту стандартные потоки ввода, вывода и ошибок в реальном времени. Вызов PTY подключает нагрузку к псевдотерминалу, которым управляет ваш хост, включая его размер. Проверьте, поддерживается ли выбранное сочетание SDK и серверной части.

Обязанности хоста

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

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

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

Выберите тип хранения

Начните с целей и ограничений рабочей нагрузки, например:

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

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

Изоляция сеансов отделяет пользователей и сеансы, но не ограничивает то, к чему рабочая нагрузка может получать доступ. В Windows IsolationSession отклоняет политики файловой системы и пользовательского интерфейса. Его запрос также должен задать исходящий трафик, входящий трафик и loopback хоста на allow, без правил сети или прокси-сервера. Если рабочая нагрузка нуждается в этих ограничениях, выберите бэкенд, который может применить их. Дополнительные сведения см. в разделе Выбор серверной части и параметры.

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

Ознакомьтесь с вариантами контейнеризации MXC и поддержкой платформы, чтобы получить рекомендации по выбору и ссылки на подробную документацию по серверной части.

Режим обучения в архитектуре

Режим обучения помогает в создании политик и диагностике для рабочих нагрузок Windows ProcessContainer. См. Создание и уточнение политик MXC с помощью Learning Mode.

Руководство по проектированию программирующих агентов

При использовании агента программирования для выбора типа контейнера попросите его оценить:

  1. Какие операционные системы и архитектуры процессоров должно поддерживать приложение?
  2. Какие файлы, сетевые пути, функции пользовательского интерфейса, устройства и инструменты хоста требуются рабочей нагрузке?
  3. Является ли каждая команда независимой, или должны ли идентификация и состояние сохраняться между командами?
  4. Какие ограничения при запуске, использовании ресурсов, развертывании и взаимодействии применяются?
  5. Требуются ли для рабочей нагрузки Windows, Linux, полный рабочий стол или другую операционную среду?
  6. Какая граница изоляции подходит для допущений о доверии и данных рабочей нагрузки?
  7. Какие запрошенные функции политики может применять каждый доступный серверный модуль?

Агент должен сравнить жизнеспособные типы изоляции, указать свои предположения и компромиссы, а также определить неподдерживаемые требования. Затем можно выбрать соответствующий тип изоляции и создать политику.

Связанные материалы

  • Последнее обновление: