콘텐츠로 이동

Windows 컨테이너 기본 사항

Windows 컨테이너를 사용하려는 이유

Windows 애플리케이션을 클라우드 네이티브로 이행하기 위한 가장 효과적이고 직접적인 방법은 Windows 컨테이너로 애플리케이션을 옮기는 것입니다.

컨테이너로 한 번 패키징하는데 성공하면, 흔히 이야기하는 컨테이너 워크로드 기반의 장점을 Windows Server에서도 고스란히 누릴 수 있습니다. 컨테이너 기반의 워크로드를 사용할 때의 장점은 다음과 같습니다.

  • 경량화: 컨테이너는 시스템 OS 커널을 공유하므로, 애플리케이션마다 완전한 OS 인스턴스를 둘 필요가 없습니다. 이로 인해 리소스 측면에서 컨테이너 파일은 작고 편리하며, 컨테이너는 크기가 작기 때문에 빠르게 시작할 수 있습니다.
  • 이동성: 컨테이너가 모든 종속 항목을 함께 전달하므로, 한 번 만든 소프트웨어는 재구성 없이 노트북, 클라우드, 온프레미스 컴퓨팅 환경에서 실행할 수 있습니다. 컴퓨팅 환경마다 소프트웨어가 다르게 배포되어 발생하는 복잡성을 예방할 수 있습니다.
  • 현대적인 개발 및 아키텍처 지원: 컨테이너는 플랫폼 간 배치 이동성/일관성과 작은 크기 덕분에 현대적인 코드를 배치하면서 조금씩 증분되는 개발 방식과 애플리케이션 패턴 (예: DevOps, 서버리스, 마이크로서비스)에 안성 맞춤입니다.
  • 사용률 향상: 컨테이너 각각은 독립적인 상태를 유지하며 분리된 상태로 실행되기 때문에, 한 서버 컴퓨터 안에 전혀 다른 컨테이너 여러개를 자유롭게 배치하여 시스템의 CPU 및 메모리 사용률을 높일 수 있습니다.
  • 자동화와 이식성 향상: 컨테이너는 수작업 스크립트를 대체하며, 더 나은 이식성을 제공합니다.
  • 보안과 거버넌스 향상: 컨테이너는 더 나은 보안과 거버넌스를 제공합니다.

Windows 컨테이너가 Windows VM과 다른 점

정확한 이해 없이 Windows 컨테이너를 처음 접할 경우, 제공하는 사용자 경험이나 리눅스 기반의 컨테이너와의 충분한 비교 지식이 없을 경우 VM 기술과 혼동할 여지가 많습니다.

다음의 그라운드 룰을 충분히 숙지하는 것이 오해나 판단 착오에 따른 과도한 기술 비용 지출을 예방하는데 도움이 됩니다.

  • Windows 컨테이너는 불변성을 준수해야 합니다: 기술적으로 컨테이너 내부의 파일 시스템 자체는 읽기 전용은 아니며, 파일 입출력을 수행할 수 있습니다. 또한 컨테이너 자체는 마치 VM처럼 실행을 중단하거나 재개하는 것도 가능합니다.

그러나 컨테이너는 VM처럼 오랫동안 유지 관리될 수 있음을 보장하지 않으며, 컨테이너 호스트는 서버의 디스크 공간이 부족해지거나 메모리가 부족해질 경우 언제든 컨테이너를 삭제하거나 다시 만들 수 있습니다.

따라서 컨테이너를 오랫동안 유지하면서 관리하려는 전략은 적절한 전략이 아니며, 이런 동작은 By-Design Behavior 입니다.

데이터 보관과 저장이 필요한 경우에는 외부 네트워크 호스트로 데이터를 보내거나, 컨테이너와 볼륨을 연결해서 컨테이너와는 분리된 저장소를 사용하도록 설정하는 것이 맞습니다.

  • Windows 컨테이너 상의 OS는 시스템 구성 변경이 어렵습니다: 일반적으로 Windows OS는 WIM (Windows Image) 방식으로 압축된 OS 사본을 디스크에 압축 해제 (Expanding)하는 방식으로 배포하며, WIM 이미지를 사전 편집할 수 있는 풍부한 옵션을 제공합니다. 1

    반면 Windows 컨테이너 상의 OS 이미지는 Microsoft가 제공하는 베이스 이미지가 최초에는 무조건 mcr.microsoft.com 아티팩트 서버로부터 다운로드되어야만 합니다.

    그리고 Windows 컨테이너 이미지는 기존에 보유하고 있는 Windows 설치 DVD로부터 제조할 수 없는 특수 이미지이며, Docker CLI가 제공하는 Import/Export 기능으로도 컨테이너 이미지를 재가공할 수 없습니다.

  • Windows 컨테이너에는 VM과 달리 “시스템 다시 시작”이라는 개념이 존재하지 않습니다: 리눅스 컨테이너와 마찬가지로 Windows 컨테이너 역시 컨테이너 안의 운영 체제를 다시 시작한다는 개념이 존재하지 않습니다.

    Windows 컨테이너의 경우 이 제약 사항이 좀 더 크게 작용합니다. 설치하는 소프트웨어나 시스템 구성 변경들 중 시스템을 다시 시작해야만 인식되는 변경 사항들은 컨테이너를 멈추고 다시 실행하는 방법으로는 반영되지 않으며, 새로운 컨테이너 레이어를 만들어서 시작해야만 제한적으로 반영할 수 있습니다.

  • Windows 컨테이너 내부의 기본 사용자 계정 선택: Windows VM에서는 ‘Administrator’ 혹은 이와 동등한 지위의 기본 사용자 계정에 로그인해서 사용하는 것이 설치 초기의 기본 동작으로 잘 알려져있습니다.

    호환성 보장을 위해, Windows 컨테이너 역시 ‘ContainerAdministrator’ 라는 변형된 관리자 계정을 제공합니다. 그러나 컨테이너를 프로덕션 환경으로 내보낼 때 이 계정을 그대로 사용하는 것은 안티 패턴으로, ‘ContainerUser’ 로 사용자 계정을 스위칭한 후에도 애플리케이션이 실행될 수 있도록 만드는 것이 권장됩니다.

이와 같은 차이점을 숙지하여, 기존의 Windows 워크로드 애플리케이션을 어떻게 현대화할 수 있을지, 혹은 현대화가 적절하거나 가능한지 여부를 빠르게, 그리고 올바르게 판단할 수 있습니다.

참고 자료

  1. 주로 이런 옵션은 Windows ADK (Assesment & Deployment Kit)와 DISM (Deployment Image Servicing & Management) Tool을 통해 활용할 수 있습니다. ↩