WSL 컨테이너 정식 출시

AI 요약

Microsoft가 WSL 업데이트를 통해 WSL 컨테이너를 정식 출시했습니다. Windows에서 Linux 컨테이너를 빌드하고 실행하는 CLI인 wslc.exe와, Windows 앱에서 컨테이너 기능을 호출하는 API를 제공합니다. container.exe 별칭으로 익숙한 컨테이너 명령도 사용할 수 있습니다.

컨테이너 관리와 관찰 기능

미리보기 이후 컨테이너 생명주기와 네트워크 관리, 상태 관찰 기능을 보강했습니다. wslc container restart로 컨테이너를 재시작하고, wslc container cp로 tar 아카이브를 이용해 파일을 복사합니다. wslc system info는 컨테이너 환경 상태를 보여주며, wslc events는 실시간 활동을 스트리밍합니다. 네트워크 연결·해제와 네트워크 드라이버 옵션 설정도 지원합니다.

컨테이너 상태 검사(health check), 실행 중지 대기 시간 설정, 생성·실행 시 볼륨 마운트, 기본 세션의 저장 경로 지정 기능도 추가했습니다. 중지 대기 시간에 -1을 지정하면 무기한 대기합니다.

기업 관리와 도구 연동

Microsoft Defender for Endpoint(MDE)는 WSL 컨테이너의 프로세스·파일·네트워크 활동을 수집하고 Windows 호스트 활동과 연결합니다. 보안팀은 별도의 보안 절차를 만들지 않고도 의심스러운 활동을 조사할 수 있습니다. Microsoft Intune에서는 WSL 컨테이너 기능의 허용 여부를 제어하고, 이미지를 내려받을 수 있는 레지스트리를 허용 목록으로 제한합니다.

VS Code 개발 컨테이너와 컨테이너 확장, Aspire에서 WSL 컨테이너를 사용할 수 있습니다. Lazywslc TUI 대시보드와 WSL Container Desktop 같은 관리 도구도 소개했습니다.

다음 개발 과제

다음 주요 요청 사항인 Compose 지원을 개발할 계획입니다. 기존 compose.yaml을 수정하지 않고 wsl compose up으로 사용할 수 있도록 작업을 시작했다고 밝혔습니다. WSL의 네트워킹과 운영체제 간 파일 성능 개선도 살피고 있습니다. Windows 파일에 접근할 때 최대 2배 빠른 성능을 지원하며, 컨테이너 작업용 consomme 네트워크 모드도 소개했습니다.

Lobsters 반응

• @ahelwer — 처음에는 컨테이너 경계에서 Linux 시스템 호출을 Windows 시스템 호출로 바꾸는 WSL 1 구조로 놀랍게 돌아가는 건가 생각했습니다. 하지만 아키텍처 블로그를 읽어 보니 컨테이너는 모두 Hyper-V의 WSL 2 방식, 즉 반가상화가 많이 적용된 Linux VM 안에서 실행됩니다. 이전과 달리 컨테이너 제어 기능만 VM 안이 아니라 Windows 쪽에 있습니다.
  • @BenjaminRi — 저는 Linux보다 Windows를 가상화해서 실행하는 편입니다. Windows는 하이퍼바이저로 쓰기에 끔찍합니다. 파일 시스템이 몹시 느리고, 업데이트와 재부팅이 잦으며, 많은 원격 측정 데이터를 보냅니다.
  • @kel — 그렇다면 WSL 소식에 댓글을 다는 건 왜 걱정하나요? 이 소식과 별로 관련 없어 보입니다.
• @JulianSildenLanglo — WSL에 Linux 배포판을 설치한 다음 Docker Engine을 설치하는 일반적인 방법 대신 쓰기 편한 대안 같네요.
  • @david_chisnall — Windows에서 일반적으로 쓰는 방법은 Docker Desktop입니다. Docker Desktop이 대신 처리해 줍니다. macOS도 마찬가지입니다. Docker Desktop은 Virtualization.framework로 Linux VM을 관리합니다. 회사 규모가 일정 수준을 넘으면 사용자별 라이선스 비용을 내야 해서 이제 문제가 되고 있습니다. Microsoft도 실제로 그 라이선스 비용을 냅니다. 이 기능을 개발하는 비용이 Microsoft의 연간 Docker 라이선스 비용보다 적었을 것 같습니다. 컨테이너 전체에 VM 하나를 쓰는 Docker Desktop과 같은 구조로 보입니다. Apple의 Container 도구는 컨테이너마다 VM 하나를 쓰는데, 보안 측면에서 더 나은 모델입니다. Docker Desktop의 macOS 동작을 자세히 살펴보지는 않았지만, Podman의 podman machine은 기본적으로 사용자 홈 디렉터리와 여러 항목을 VM에 마운트해 개별 컨테이너에 바인드 마운트합니다. 따라서 Linux VM에서 컨테이너 탈출이 발생하면 홈 디렉터리 전체를 읽고 쓸 수 있습니다. 반면 Apple의 Container 도구는 호스트 파일 시스템을 필요할 때 연결하고 VM마다 격리합니다. VM 안에서 컨테이너 탈출이 발생해도 컨테이너에 노출한 파일에만 접근할 수 있습니다. VM 자체를 탈출하면 더 많은 항목을 손상시킬 수 있지만, 그건 더 어렵습니다.

원문: Windows Developer Blog / 번역·요약: Trawling