MXC 有助于管理使用容器的复杂性：使用 MXC 描述策略并管理容器的生命周期，但所选的包含后端会执行实际强制执行操作。 每个后端都基于不同的操作系统机制构建。 因此，后端在隔离工作负荷的方式以及处理文件、网络、UI 和生命周期的方式方面有所不同。
从工作负荷需要的内容开始，然后确认后端可以在目标主机上满足该需求。 操作系统的名称或版本不会告诉你后端是否受支持。
了解主机和工作负荷环境
在请求中，可以请求一种称为“包含意图”的环境，也可以指定具体的后端。
process 意图映射到当前运行所在主机上的本机进程隔离后端。 由于后端因操作系统而异，因此同一意图在 Windows、Linux 和 macOS 上可能具有不同的能力。
| 主机 | 默认流程后端 | 其他环境 |
|---|---|---|
| Windows | ProcessContainer | 独立的 Windows 会话、Windows VM，或在受支持的情况下通过 WSLc 运行的 Linux 工作负荷 |
| Linux | 气泡膜 | LXC 和专用虚拟化后端（在受支持的情况下） |
| macOS | 安全带 | 检查您安装的发行版本以获取其他受支持的选项 |
工作负载不必与主机使用相同的操作系统。 例如，WSLc 在 Windows 主机上运行 Linux 工作负荷。 它具有自己的先决条件，它与主机共享资源的方式与Windows进程沙盒不同。
检查发布状态和 SDK 覆盖范围
后端支持会因版本而异，因此请检查所安装的软件包版本的支持信息。
在 MXC v1.0.0 中，V1 SDK 可以使用以下后端创建容器：
- Windows：ProcessContainer、IsolationSession 和 WSLc
- Linux： Bubblewrap 和 LXC
- macOS： Seatbelt
Windows沙盒、MicroVM 和 Hyperlight 是实验性的。 它们需要显式的实验性授权，并且无法通过 V1 SDK API 进行创建。 如果你正在考虑其中一个或另一个专用环境，请先检查你所用版本的发行说明。
主机上可用的后端可能仍不支持你计划调用的 SDK 操作。 在 V1 SDK 中：
- 生命周期 API 仅适用于 IsolationSession 和 WSLc。
- 一次性 PTY 执行适用于 IsolationSession、Bubblewrap、LXC 和 Seatbelt。
- 现有容器中的 PTY 执行仅适用于 IsolationSession。
有关详细信息，请参阅 SDK 参考：
如果使用 Rust，后端支持也取决于启用的 crate 功能。 若要使用 IsolationSession 或 WSLc，请启用 mxc-sdk crate 的 isolation_session 或 wslc 功能。 有关详细信息，请参阅 Rust SDK 指南。
从运行时发现开始
每个 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 隔离层级以及针对该请求的兼容性诊断信息 |
不适用或无法检测到的字段可能在结果中缺失。 发现机制是一项有用的初步检查，但它并不能验证完整策略。 为确保无误，请创建计划运行的请求，并确认所选后端可以强制实施它所需的每个控制。
部分主机需要额外组件或管理员设置，后端才能正常工作。 发现结果和启动错误可以告诉你缺少的内容，但这不会授予应用或编码代理更改主机的权限。 让管理主机的人员按照后端文档中记录的设置步骤进行操作。
对于 Windows，请参阅 OS 版本策略支持。 某个 Windows 版本即使受 MXC 支持，也可能依然缺少特定的策略功能，因此这两项都需要检查。
检查工作负载所需的限制
两个后端可以接受相同的策略语法，但执行该策略的方式仍可能不同。 在选定后端之前，请考虑以下方面：
| Area | 应考虑的问题 |
|---|---|
| 文件存储 | 后端是否可以表达所需的读取、写入和拒绝授权，包括重叠的授权？ 它是否与主机共享文件、装载文件或复制文件？ |
| Network | 它能否强制执行网络模型（无论是直连还是通过代理），包括专用网络和主机环回规则？ |
| UI | 它是否可以对窗口、剪贴板和输入施加所需的限制？ |
| Lifecycle | 它是否独立运行每个命令，或者是否可以在命令之间保留环境？ 停止后保留什么？ |
| 学习模式 | 主机是否支持 ProcessContainer 拒绝捕获？ 如果没有，后端提供哪些诊断工作流？ |
GitHub上的 MXC 指南列出了每个后端支持的功能、OS 版本和要求。
根据需求选择后端
在选取后端之前，请记下：
- 应用支持的主机操作系统和处理器体系结构。
- 工作负荷所需的来宾或工具环境。
- 工作负荷所需的文件、网络、UI、设备和主机工具访问权限。
- 每个命令是自行运行还是需要先前命令的状态。
- 您在启动时间、资源、部署和用户交互方面的限制。
- 工作负荷及其数据所需的隔离边界有多强。
- 后端是否可以强制实施所需的每个策略控制。
然后测试支持的每个主机配置，同时进行正向测试和负向测试。 成功启动仅显示 MXC 已接受配置。 负面测试（例如尝试在授予的路径外写入）显示这些限制是否确实有效。
