MXC 아키텍처 및 컨테인먼트 모델

MXC는 워크로드 의도를 워크로드를 실행하는 플랫폼 메커니즘과 구분합니다. 호스트 앱은 .NET, TypeScript 또는 Rust SDK를 사용하여 리소스 사용 권한을 설명하고 실행을 요청하는 데 사용합니다. MXC는 요청을 현재 호스트의 컨테인먼트 백엔드 작업으로 변환합니다.

이 디자인은 모든 백엔드가 동일한 기능 또는 격리 속성을 제공한다고 주장하지 않으면서도 앱에 일관된 통합 인터페이스를 제공합니다.

아키텍처 계층

MXC 통합에는 다음과 같은 네 가지 기본 계층이 있습니다.

계층 책임
호스트 앱 또는 에이전트 런타임 작업을 분류하고, 신뢰할 수 있는 정책 기본값을 선택하고, 입력을 제공하고, 출력 및 승인을 처리합니다.
MXC SDK 및 정책 계약 지원 항목을 검색하고, 워크로드 의도를 버전이 지정된 구성으로 변환하고, 샌드박스를 시작하고, 수명 주기 및 진단을 노출합니다.
MXC 실행 계층 구성의 유효성을 검사하고, 백엔드를 결정하고, 지원되는 인터페이스 계약을 플랫폼 작업으로 변환합니다.
컨테인먼트 백엔드 실행 환경을 만들고 플랫폼 및 백엔드에서 지원하는 정책 기능을 강제 적용합니다.

호스트 앱은 정책 결정을 계속 담당합니다. 코딩 에이전트는 모델 또는 리소스 사용 권한을 제안할 수 있지만 신뢰할 수 있는 논리 또는 사람의 승인 없이 자체 권한을 선택하거나 확장해서는 안 됩니다. 호스트가 MXC 외부에서 실행하는 코드는 워크로드의 격리 범위 밖에 유지됩니다.

정책, 구성 및 런타임 설정

이 정책은 워크로드가 액세스할 수 있는 내용을 설명합니다. 실행 요청은 실행할 항목, 실행할 위치 및 사용할 컨테이너를 추가합니다. 런타임 설정은 이미 실행 중인 프록시의 엔드포인트와 같이 실행에 필요한 값을 제공합니다.

V1 SDK는 이러한 설정을 단일 ContainerRequest에 담고 있습니다. 파일 시스템, 네트워크 및 UI 속성은 액세스를 설명하고 명령, 작업 디렉터리, 환경, 시간 제한 및 포함 속성은 실행을 설명합니다. SDK는 요청을 안정적인 1.0.0 스키마 계약으로 변환하므로 스키마 버전을 지정할 필요가 없습니다.

JSON 실행 구성은 직렬화된 SDK 개체와 상호 호환되지 않습니다. 예를 들어 요청 ui.allowInputInjection 및 timeoutMs 속성은 구성 ui.injection 및 process.timeout 설정에 해당합니다. SDK 형식 또는 작성한 구성 버전에 대한 스키마를 사용합니다.

원샷 및 상태 인식 수명 주기

MXC는 두 가지 수명 주기 패턴을 지원합니다.

원샷 실행은 샌드박스를 만들고, 하나의 워크로드를 실행하고, 샌드박스를 제거합니다. 독립 코딩 에이전트 도구, 생성된 명령, 빌드, 테스트 및 스크립트에 사용합니다. 각 작업마다 새로운 좁은 샌드박스는 유지되는 상태를 제한하고 하나의 광범위한 정책을 만들어야 하는 압력을 줄입니다.

상태 인식 실행 은 프로비전, 시작, 실행, 중지 및 프로비전 해제의 다섯 단계를 노출합니다. 프로비전은 불투명 ContainerId을 반환하며, 호출자는 이를 변경하지 않은 채 이후 단계에 전달하고 해체 전에 여러 명령을 실행할 수 있습니다. 워크로드가 에이전트 프로필, 설치된 도구, 구성 또는 운영 체제 환경과 같은 영구적 상태에 의존하는 경우에만 이 패턴을 사용합니다. MXC 1.0에서 V1 SDK 수명 주기 API는 IsolationSession 및 WSLc를 지원합니다.

상태 인식 실행은 MXC를 상태 소유자로 만들지 않습니다. 백 엔드는 샌드박스 리소스를 소유하고 호출자는 식별자를 저장하고 수명 주기를 관리합니다. 실행 중지 및 리소스 할당 해제는 서로 다른 작업입니다. 중지에서 정확히 어떤 상태가 유지되는지는 백엔드에 따라 달라집니다.

실행, 스폰 및 PTY 실행은 호스트가 환경이 존재하는 시간이 아니라 실행 중인 프로세스와 상호 작용하는 방식을 설명합니다. run 호출은 실행이 완료되면 캡처된 출력을 반환합니다. 생성 호출은 워크로드가 실행되는 동안 사용자의 호스트에 라이브 표준 입력, 출력 및 오류 스트림을 제공합니다. PTY 호출은 워크로드를 호스트가 크기를 포함해 제어하는 의사 터미널에 연결합니다. 선택한 SDK와 백엔드의 지원되는 조합을 확인하세요.

호스트의 책임

실행 시간 제한을 설정하고 워크로드 실패, 시작 실패 및 취소를 별도로 처리합니다. SDK 대기를 취소하는 것은 반드시 워크로드를 종료하는 것과 동일하지는 않습니다. SDK의 종료 및 폐기 규약에 따라 필요한 대기를 완료하여 실행 및 선택적 거부 이벤트 캡처를 마무리할 수 있습니다.

상태 인식 실행의 경우 이후 단계가 실패하더라도 정리가 수행되도록 합니다. 중지에 실패했더라도 앱이 소유한 리소스의 프로비전을 해제하려는 시도를 방지해서는 안 됩니다.

샌드박스 해체는 일반적으로 부여된 호스트 디렉터리에 대한 쓰기 또는 허용된 네트워크 서비스를 통해 수행된 작업을 실행 취소하지 않습니다. 출력 위치를 의도적으로 선택하고 후속 작업에서 이를 사용하기 전에 유지할 결과를 결정합니다.

컨테이너 유형 선택

워크로드의 목표와 제약 조건부터 시작하세요. 예를 들면 다음과 같습니다.

워크로드 필요성 시작 유형 이유
시작 비용이 낮고 선택한 호스트 도구 및 경로가 필요한 명령 프로세스 격리 호스트 환경에서 작업 범위로 제한된 권한으로 실행
별도의 Windows 프로필 또는 대화형 세션이 필요한 워크로드 세션 격리 MXC 파일, 네트워크 또는 UI 필터링 없이 워크로드의 사용자 및 세션 상태를 대화형 사용자 환경과 분리합니다.
별도의 커널 또는 게스트 운영 환경이 필요한 워크로드 가상화된 환경 선택한 백 엔드의 기능에 따라 VM 또는 마이크로 VM 경계를 사용합니다.

Windows에서 프로세스 격리는 시작 비용이 낮고 특정 호스트 리소스가 필요한 많은 워크로드에 적합하기 때문에 일반적인 형식입니다.

세션 격리는 사용자와 세션을 구분하지만 워크로드가 액세스할 수 있는 것을 제한하지는 않습니다. Windows IsolationSession은 파일 시스템 및 UI 정책을 거부합니다. 또한 해당 요청은 송신, 수신 및 호스트 루프백을 allow로 설정해야 하며, 네트워크 규칙이나 프록시는 없어야 합니다. 워크로드에 이러한 제한이 필요한 경우 이를 강제할 수 있는 백엔드를 선택합니다. 자세한 내용은 백 엔드 선택 및 설정을 참조하세요.

이와 같은 process추상 의도를 통해 MXC는 플랫폼별 백엔드를 선택할 수 있습니다. 특정 운영 환경 또는 라이프사이클이 필요한 경우 구체적인 백엔드를 선택합니다. 추상 의도와 더 강력한 격리 메커니즘은 둘 다 모든 파일, 네트워크 또는 UI 컨트롤에 대한 지원을 보장하지 않습니다.

선택 지침 및 자세한 백 엔드 설명서에 대한 링크는 MXC 컨테인먼트 옵션 및 플랫폼 지원을 참조하세요.

아키텍처의 학습 모드

학습 모드는 Windows ProcessContainer 워크로드에 대한 정책 작성 및 진단에 도움이 됩니다. 학습 모드를 사용하여 MXC 정책 만들기 및 구체화를 참조하세요.

코딩 에이전트를 위한 설계 지침

코딩 에이전트를 사용하여 컨테이너 유형을 선택하는 경우 다음을 평가하도록 요청합니다.

  1. 앱에서 지원해야 하는 운영 체제 및 프로세서 아키텍처는 무엇입니까?
  2. 워크로드에 필요한 파일, 네트워크 경로, 사용자 인터페이스 기능, 디바이스 및 호스트 도구는 무엇인가요?
  3. 각 명령은 독립적입니까, 아니면 명령 간에 정체성과 상태를 유지해야 합니까?
  4. 어떤 시작 시간, 리소스 사용, 배포 및 상호 작용 제약 조건이 적용됩니까?
  5. 워크로드에 Windows, Linux, 전체 데스크톱 또는 다른 운영 환경이 필요한가요?
  6. 워크로드의 신뢰 가정 및 데이터에 적합한 격리 경계는 무엇인가요?
  7. 각 사용 가능한 백엔드가 적용할 수 있는 요청된 정책 기능은 무엇입니까?

에이전트는 실행 가능한 격리 유형을 비교하고, 가정 및 절충을 명시하고, 지원되지 않는 요구 사항을 식별해야 합니다. 그런 다음 적절한 포함 유형을 선택하고 정책을 빌드할 수 있습니다.

관련 콘텐츠

  • 에 마지막으로 업데이트됨