요약:
Microsoft는 WSL 컨테이너를 공개 미리 보기에서 일반적으로 사용 가능한 버전으로 이동했습니다. 사용자는 "wsl --update"를 실행하여 명령줄 도구 wslc.exe 및 WSL 컨테이너 API를 포함한 관련 기능을 얻을 수 있습니다. GitHub의 공식 버전 버전 번호는 WSL 3.0.1이지만 이것이 Microsoft가 WSL 3을 출시했다는 의미는 아닙니다. Microsoft는 이전에 이 새 버전의 존재를 부인했습니다.
이전에는 Windows 개발자가 Linux 컨테이너를 실행하려면 일반적으로 Docker Desktop을 설치하거나 WSL Linux 배포판에서 Docker 엔진을 수동으로 구성해야 했습니다. WSL 컨테이너는 컨테이너 워크플로를 WSL에 직접 통합합니다. wslc.exe는 Windows에서 Linux 컨테이너를 빌드, 실행, 관리 및 배포하는 데 사용할 수 있습니다. 또한 별칭으로 Container.exe를 제공합니다. Docker에 익숙한 개발자도 유사한 명령을 사용할 수 있습니다. 지원 API를 사용하면 기본 Windows 애플리케이션이 코드를 통해 Linux 컨테이너를 만들고 제어할 수 있으며 C# 및 C++/WinRT 호출, 표준 입력 및 출력, 파일 탑재, 네트워크 및 GPU 액세스를 지원합니다.
여기서 "네이티브"는 컨테이너가 Windows 커널에서 실행된다는 의미는 아닙니다. 컨테이너는 실제로 WSL 가상 머신의 Linux 커널에서 실행됩니다. Microsoft는 컨테이너 세션 관리 방법을 재설계했습니다. 일반 WSL 애플리케이션은 Windows 서비스 wslservice.exe를 통해 더 높은 권한을 가진 가상 머신을 생성합니다. WSL 컨테이너는 이 서비스를 사용하여 사용자를 대신하여 컨테이너를 생성하고, 디렉터리를 탑재하고, 네트워크 포트를 바인딩하는 wslcsession.exe라는 하위 프로세스를 생성합니다. 마이크로소프트는 각 세션이 독립적인 프로세스에 의해 호스팅되어 격리를 강화할 수 있다고 밝혔습니다. 세션 작업에 필요한 권한도 wslservice.exe보다 낮아 보안 향상에 도움이 됩니다.
각 세션에는 사용자 애플리케이션 데이터 디렉터리에 저장되는 독립적인 가상 하드 디스크가 있습니다. 컨테이너는 볼륨 마운트를 통해 Windows 폴더를 사용할 수 있습니다. Microsoft는 virtiofs를 사용하여 가상 머신에 디렉터리를 공유하며 C 드라이브에 액세스하기 위해 기존 WSL 배포판에서 사용하는 Plan 9 솔루션보다 약 2배 빠르다고 밝혔습니다. 기본 Linux 파일 시스템이 필요하거나 제한된 스토리지 용량이 필요한 컨테이너의 경우 가상 하드 디스크 볼륨을 사용할 수 있습니다.
공식 버전에는 컨테이너 재시작, 파일 복사, 네트워크 연결 및 연결 해제, 더 많은 네트워크 드라이버 옵션, 컨테이너 상태 확인, 컨테이너 생성 및 실행 시 디렉터리 마운트 등의 명령이 추가되었습니다. 네트워크에는 Consommé라는 아키텍처도 도입되었습니다. Linux 가상 머신의 네트워크 트래픽은 이더넷 프레임 형태로 virtio 대기열에 들어간 다음 사용자로 실행되는 Windows 프로세스가 DNS 쿼리, TCP 및 UDP 트래픽, 포트 매핑을 처리합니다. Microsoft는 이 방법이 VPN 및 방화벽과 더 잘 호환되며 WSL 사용자가 오랫동안 겪었던 네트워크 문제를 개선할 것이라고 말했습니다. 이전 테스트에서 Windows는 추가 네트워크 구성 없이 localhost를 통해 컨테이너에서 실행되는 Flask 서비스에 액세스할 수 있었습니다.
Microsoft는 기업용 관리 및 보안 기능도 추가하고 있습니다. IT 관리자는 Microsoft Intune을 통해 WSL 컨테이너를 활성화 또는 비활성화하고 승인된 레지스트리에서만 컨테이너 이미지를 가져오도록 제한할 수 있습니다. 엔드포인트용 Microsoft Defender의 기존 WSL 통합도 컨테이너로 확장되어 컨테이너 내부의 프로세스, 파일 및 네트워크 활동을 표시하고 이를 Windows 호스트와 연결합니다. Microsoft는 Intune 및 Defender와 결합된 이러한 기능을 통해 기업 환경에 필요한 보안 제어를 제공할 수 있다고 밝혔습니다.
개발 도구 측면에서 Microsoft는 VS Code Dev Containers 확장이 wslc를 컨테이너 드라이버로 사용할 수 있다고 발표했습니다. VS Code Containers 확장 및 Aspire도 이 기능을 지원합니다. Microsoft WSL 제품 관리자 Craig Loewen은 사용자가 설정에서 wslc를 실행 프로그램으로 선택하기만 하면 된다고 말했습니다. 그러나 일부 개발자는 확장 프로그램이 공식 버전으로 교체되더라도 Dev Containers에서 여전히 docker 명령을 찾을 수 없다는 메시지를 표시하며 이는 현재 편집기 통합을 여전히 확인하고 조정해야 할 수 있음을 나타냅니다.
개발자가 가장 기대하는 Compose 지원은 아직 개발 중입니다. Compose는 프런트엔드, 백엔드 API, 데이터베이스 및 캐시와 같은 여러 컨테이너를 동일한 compose.yaml 구성 파일에 작성한 다음 하나의 명령으로 전체 서비스 세트를 시작할 수 있습니다. 마이크로소프트는 현재 wslc에서 가장 많이 요청되는 기능이 Compose라고 밝혔으며, 앞으로는 "wsl compose up"이 기존 구성 파일을 수정 없이 직접 실행할 수 있기를 희망한다고 밝혔다. 이전 테스트에서는 Compose가 부족하여 개발자는 다중 컨테이너 프로젝트에서만 서비스를 하나씩만 시작할 수 있었습니다.
일부 고급 장면에는 아직 공백이 있습니다. Microsoft 엔지니어는 개발자가 WSL 배포판 내에서 이미지를 빌드하고 푸시하기 위해 유지 관리하는 커뮤니티 프로젝트 wslc-remote를 사용할 수 있다고 언급했습니다. Microsoft는 앞으로 기본 지원을 지원하기를 희망하지만 여전히 많은 특수한 상황을 처리해야 합니다. 다른 사용자들은 "--privileged" 매개변수 지원이 부족하여 kind 및 k3d Kubernetes 클러스터를 실행하기 위해 Docker로 다시 변경해야 했다고 말했습니다. 마이크로소프트는 관련 기능이 곧 출시될 것이며 코드가 메인 브랜치에 진입했으며 곧 프리뷰 단계에 진입할 것으로 예상된다고 밝혔습니다. 따라서 공식적으로 사용 가능하다고 해서 wslc가 성숙한 컨테이너 플랫폼의 모든 기능을 갖추고 있다는 의미는 아닙니다.
WSL 컨테이너는 Windows 10 및 Windows Server도 지원합니다. Microsoft의 WSL 제품 관리자는 현재 시스템이 WSL을 지원하는 한 컨테이너를 실행할 수 있다고 말했습니다. Windows 최신 버전은 이전에 Windows 10에서 wslc를 테스트했으며 Flask 대시보드를 성공적으로 구축하고 실행했습니다. Microsoft는 Windows Server가 프로덕션 환경에서도 이 기능의 사용을 지원함을 확인했습니다.
보고서는 이러한 변화를 Linux에 대한 Microsoft의 과거 태도와 대조했습니다. 전 마이크로소프트 CEO인 스티브 발머는 한때 리눅스를 "암"이라고 불렀습니다. 현재 Microsoft는 계속해서 WSL을 개선하고 이를 오픈 소스로 제공하며 Windows와 Linux 간의 파일 액세스 및 네트워크 기능을 개선하고 있습니다. Microsoft는 Linux가 이제 더 이상 단순한 개발 환경이 아니라 AI 및 클라우드 네이티브 워크로드도 호스팅할 수 있다고 밝혔습니다. 기사에서는 또한 Google이 새로운 AI 도구에 대한 기본 Windows 11 및 WSL 지원을 제공하고 있다고 언급했으며 Canonical은 Windows 11에서 Ubuntu의 성장률이 기본 Linux 컴퓨터의 성장률을 초과했다고 말했습니다. 그럼에도 불구하고 저자는 대부분의 개발자가 Compose 및 일부 고급 기능이 완료되기 직전에 Docker Desktop을 포기하지 않을 것이라고 믿습니다. 수정되지 않은 Compose 구성을 나중에 직접 실행할 수 있다면 더 많은 사람들이 Docker Desktop 제거를 고려할 수 있습니다.
댓글