MXC는 컨테이너 사용의 복잡성을 관리하는 데 도움이 됩니다. MXC를 사용하여 정책을 설명하고 컨테이너의 수명 주기를 관리하지만 선택한 컨테인먼트 백엔드가 실제 적용은 담당합니다. 각 백 엔드는 다른 운영 체제 메커니즘을 기반으로 합니다. 결과적으로 백 엔드는 워크로드를 격리하는 방법과 파일, 네트워킹, UI 및 수명 주기를 처리하는 방식이 다릅니다.
워크로드에 필요한 것부터 시작한 다음, 백 엔드가 대상 호스트에 제공할 수 있는지 확인합니다. 운영 체제 이름 또는 버전만으로는 백 엔드가 지원되는지 여부를 알 수 없습니다.
호스트 및 워크로드 환경 이해
요청에서 포함 의도라고 하는 일종의 환경을 요청하거나 특정 백 엔드의 이름을 지정할 수 있습니다. 의도는 process 실행 중인 호스트의 네이티브 프로세스 격리 백 엔드에 매핑됩니다. 해당 백 엔드는 운영 체제에 따라 다르기 때문에 동일한 의도는 Windows, Linux 및 macOS에서 서로 다른 기능을 제공할 수 있습니다.
| Host | 기본 프로세스 백엔드 | 기타 환경 |
|---|---|---|
| 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를 사용하려면 isolation_session crate의 wslc 또는 mxc-sdk 기능을 사용하도록 설정합니다. 자세한 내용은 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 격리 계층 및 요청별 호환성 진단 |
| 러스트 | v1::platform_support() |
is_supported, available_methods, reason, 그리고 Linux에서는 Bubblewrap 네트워크 기능 |
| 러스트 | v1::available_backends() |
호스트 가용성, 선택적 기능 및 경고. 일부 실행 API는 여기에 나열된 모든 백 엔드를 사용할 수 없습니다. |
| 러스트 | v1::probe() |
Windows에서 컨테이너를 만들지 않고 요청이 받게 되는 ProcessContainer 격리 계층 및 요청별 호환성 진단 |
적용되지 않거나 감지할 수 없는 필드는 결과에서 누락될 수 있습니다. Discovery는 유용한 첫 번째 검사이지만 전체 정책의 유효성을 검사하지는 않습니다. 확실히 하기 위해 실행하려는 요청을 만들고 선택한 백 엔드가 필요한 모든 컨트롤을 적용할 수 있는지 확인합니다.
일부 호스트는 백 엔드가 작동하기 전에 추가 구성 요소 또는 관리자 설정이 필요합니다. 검색 결과 및 시작 오류는 누락된 내용을 알려줄 수 있지만 앱 또는 코딩 에이전트가 호스트를 변경할 수 있는 권한을 부여하지는 않습니다. 호스트를 관리하는 담당자에게 백엔드의 문서화된 설정 단계를 수행하도록 요청합니다.
Windows의 경우 OS-version policy support를 참조하세요. Windows 버전은 MXC에서 지원될 수 있지만 여전히 특정 정책 기능이 없을 수 있으므로 MXC 지원 여부와 해당 정책 기능 지원 여부를 모두 확인하세요.
사용자의 워크로드에 필요한 제한 사항을 확인하세요
두 백 엔드는 동일한 정책 구문을 수락하고 여전히 다르게 적용할 수 있습니다. 백엔드를 선택하기 전에 다음과 같은 영역을 고려하세요.
| 영역 | 질문할 사항 |
|---|---|
| Files | 백 엔드가 겹치는 것을 포함하여 필요한 읽기, 쓰기 및 거부 권한을 표현할 수 있나요? 호스트와 파일을 공유하거나, 마운트하거나, 복사하나요? |
| Network | 프라이빗 네트워크 및 호스트 루프백 규칙을 포함하여 직접 또는 프록시를 통해 네트워크 모델을 준수하도록 강제할 수 있나요? |
| 사용자 인터페이스 (UI) | 필요한 창, 클립보드 및 입력 제한을 적용할 수 있나요? |
| Lifecycle | 각 명령을 독립적으로 실행하나요, 아니면 명령 간에 환경을 유지할 수 있나요? 중지 후 유지되는 항목은 무엇인가요? |
| 학습 모드 | 호스트가 ProcessContainer 거부 이벤트 캡처를 지원하나요? 그렇지 않은 경우 백 엔드에서 제공하는 진단 워크플로는 무엇인가요? |
GitHub MXC 가이드에는 각 백 엔드에 대해 지원되는 기능, OS 빌드 및 요구 사항이 나열되어 있습니다.
요구 사항에 맞는 백엔드 선택
백엔드를 선택하기 전에 다음을 작성하세요.
- 앱에서 지원하는 호스트 운영 체제 및 프로세서 아키텍처입니다.
- 워크로드에 필요한 게스트 또는 도구 환경
- 워크로드에 필요한 파일, 네트워크, UI, 디바이스 및 호스트 도구 접근입니다.
- 각 명령이 자체적으로 실행되거나 이전 명령의 상태가 필요한지 여부입니다.
- 시작 시간, 리소스, 배포 및 사용자 상호 작용에 대한 귀하의 제한.
- 워크로드와 해당 데이터가 요구하는 격리 경계가 얼마나 강력한지.
- 백 엔드가 필요한 모든 정책 제어를 적용할 수 있는지 여부입니다.
그런 다음, 긍정 및 부정 테스트를 모두 사용하여 지원하는 모든 호스트 구성을 테스트합니다. 성공적인 시작은 MXC가 구성을 수락했음만 보여줍니다. 부여된 경로 외부에서 쓰려는 시도와 같은 부정 테스트는 제한이 실제로 유지되는지 여부를 보여 줍니다.
관련 콘텐츠
GitHub에서 Microsoft와 공동 작업
이 콘텐츠의 원본은 GitHub에서 찾을 수 있으며, 여기서 문제와 끌어오기 요청을 만들고 검토할 수도 있습니다. 자세한 내용은 참여자 가이드를 참조하세요.
Windows developer