Варианты изоляции MXC и поддержка платформы

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

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

Изучите среды узла и нагрузки

В запросе можно запросить тип среды, который называется containment intent, или указать конкретный backend. Intent process сопоставляется со встроенным механизмом изоляции процессов на узле, на котором вы работаете. Поскольку этот бэкенд различается в зависимости от операционной системы, одно и то же намерение может предоставлять разные возможности в Windows, Linux и macOS.

Host Бэкенд процесса по умолчанию Другие среды
Windows ProcessContainer Отдельный сеанс Windows, виртуальная машина Windows или рабочие нагрузки Linux через WSLc, если поддерживается
Linux Пузырчатая пленка LXC и специализированные бэкенды виртуализации, если поддерживается
macOS Ремень безопасности Проверьте установленную версию на наличие других поддерживаемых параметров

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

Проверка состояния релиза и поддержки SDK

Поддержка серверной части меняется от выпуска к выпуску, поэтому проверьте сведения о поддержке устанавливаемой версии пакета.

В MXC версии 1.0.0 пакеты SDK версии 1 могут создавать контейнеры с этими бэкендами:

  • Windows: ProcessContainer, IsolationSession и WSLc
  • Linux: Bubblewrap и LXC
  • macOS: Seatbelt

Windows Sandbox, MicroVM и Hyperlight являются экспериментальными. Для них требуется явное разрешение на использование экспериментальной функции, и их нельзя создать с помощью API пакета SDK версии 1. Если вы рассматриваете одну из этих или другую специализированную среду, сначала проверьте заметки о выпуске для вашей версии.

Серверная часть, доступная на узле, может по-прежнему не поддерживать операцию пакета SDK, которую вы планируете вызвать. В пакетах SDK версии 1:

  • API жизненного цикла работают только с IsolationSession и WSLc.
  • Однократное выполнение PTY работает с IsolationSession, Bubblewrap, LXC и Seatbelt.
  • Выполнение PTY в существующем контейнере работает только с IsolationSession.

Дополнительные сведения см. в справочниках по пакету SDK:

Если вы используете Rust, поддержка бэкенда также зависит от включенных вами функций crate. Чтобы использовать IsolationSession или WSLc, включите функцию mxc-sdk crate isolation_session или wslc. Дополнительные сведения см. в руководстве по пакету SDK Rust.

Начните с обнаружения среды выполнения

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

Используйте поддержку платформы, чтобы узнать, можно ли вообще запускать контейнеры, доступные бэкенды — для получения более полной информации об узле, а проверку — чтобы протестировать конкретный запрос в Windows перед его выполнением.

SDK Discovery API Что требуется проверить
.NET MxcPlatform.GetPlatformSupport() IsSupported, Reason и AvailableMethods, в которых перечислены бэкенды, которые пакет SDK может запускать
.NET MxcPlatform.GetAvailableBackends() Доступность узла, необязательные возможности и предупреждения. Некоторые API выполнения не могут использовать каждый бэкенд, указанный здесь.
.NET MxcContainer.Probe() В Windows запрос получит уровень изоляции ProcessContainer и диагностику совместимости для конкретного запроса без создания контейнера.
TypeScript getPlatformSupport() isSupported, reason, availableMethods и все предупреждения и поля возможностей для конкретного хоста
TypeScript getAvailableBackends() Доступность узла, необязательные возможности и предупреждения. Некоторые API выполнения не могут использовать каждый бэкенд, указанный здесь.
TypeScript probe() В Windows запрос получит уровень изоляции ProcessContainer, который ему будет назначен, и диагностику совместимости для конкретного запроса без создания контейнера.
Rust v1::platform_support() is_supported, reason, available_methods и, в системе Linux, сетевая возможность Bubblewrap
Rust v1::available_backends() Доступность узла, необязательные возможности и предупреждения. Некоторые API выполнения не могут использовать каждый бэкенд, указанный здесь.
Rust v1::probe() В Windows запрос получит уровень изоляции ProcessContainer и диагностику совместимости для конкретного запроса, не создавая контейнер.

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

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

Для Windows см. политику поддержки версий ОС. Версия Windows может поддерживаться MXC и по-прежнему не иметь определенной функции политики, поэтому проверьте и то и другое.

Проверьте ограничения, которые нужны вашей рабочей нагрузке

Две серверные части могут принимать один и тот же синтаксис политики и по-прежнему применять его по-разному. Прежде чем остановитесь на выборе бэкенда, обратите внимание на такие аспекты:

Area Вопросы, которые стоит задать
Files Может ли серверная часть выразить необходимые вам разрешения на чтение, запись и запреты, включая перекрывающиеся? Предоставляет ли он общий доступ к файлам с хостом, монтирует их или копирует?
Network Может ли она обеспечить соблюдение вашей сетевой модели, будь то прямое подключение или подключение через прокси-сервер, включая правила частной сети и loopback хоста?
Пользовательский интерфейс Может ли это применить необходимые ограничения для окна, буфера обмена и ввода?
Lifecycle Выполняет ли она каждую команду независимо, или может ли она сохранять окружение между командами? Что сохраняется после остановки?
Режим обучения Поддерживает ли хост фиксацию отказов ProcessContainer? Если нет, какой рабочий процесс диагностики предоставляет серверную часть?

В руководствах MXC на GitHub перечислены поддерживаемые возможности, сборки ОС и требования для каждого бэкенда.

Выберите серверную часть исходя из ваших требований

Прежде чем выбрать серверную часть, запишите:

  • Операционные системы хоста и архитектуры процессора, поддерживаемые приложением.
  • Гостевая среда или среда инструментов, необходимая для выполнения рабочей нагрузки.
  • Доступ к файлам, сети, пользовательскому интерфейсу, устройству и host-tool, необходимый рабочей нагрузке.
  • Выполняется ли каждая команда самостоятельно или требует состояния из предыдущих команд.
  • Ограничения на время запуска, ресурсы, развертывание и взаимодействие с пользователем.
  • Какая степень изоляции требуется рабочей нагрузке и ее данным.
  • Способность серверной части применять каждый требуемый элемент управления политикой.

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

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

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