Offcanvas

가상화 / 애플리케이션 / 운영체제 / 클라우드

블로그 | 윈도우의 도커에 대한 오해와 사실

2017.02.06 Simon Bisson  |  InfoWorld
필자는 지난 주 소프트웨어 개발 기술을 주로 다루는 런던의 개발자 컨퍼런스인 몽키 그라스(Monki Gras)를 찾았다. 꽤 재미있는 이 이벤트의 올해 주제는 소프트웨어 패키징 방법이었다.

당연히 많은 발표자들이 데브옵스와 지속적 전달(continuous delivery)에서 컨테이너의 역할에 대해 이야기했다. 그러나 윈도우의 컨테이너 지원에 대해 오해하는 경우가 많았다. 흔히 윈도우의 컨테이너 지원을 리눅스 VM에서 실행되는 도커에 대한 지원으로 묘사한다.

이는 사실이 아니다. 윈도우에는 도커를 기반으로 하지만 마이크로소프트 특유의 색깔을 입힌 자체 컨테이너 기술이 있다. 바로 이 점이 혼동을 일으키는 듯하다. 윈도우 10에는 리눅스 하위 시스템에 대한 지원이 추가됐고, 비슷한 시기에 마이크로소프트는 윈도우 서버 2016에 도커 툴을 추가했다. 두 가지 모두 애저(Azure) 플랫폼의 발전을 위한 핵심 요소인 클라우드 네이티브 애플리케이션 개발을 향한 마이크로소프트의 접근 방식이다.

컨테이너는 지난 몇 년 동안 여러 산업에 걸쳐 중요한 기술로 부상한 만큼 마이크로소프트가 컨테이너에 전념하는 것은 지극히 당연한 일이다. 프로세스와 네임스페이스의 사용자 전체를 캡슐화해서 동일한 서버에서 실행되는 다른 인스턴스로부터 격리하는 최선의 방법으로 통하는 컨테이너는 빠른 속도로 데브옵스와 지속적 통합 및 구현의 핵심 구성 요소로 자리 잡았다. 마이크로소프트는 내부적으로 이러한 접근 방법을 일찌감치 도입했다. 그리고 항상 그렇듯이 마이크로소프트가 출시하는 도구에는 마이크로소프트 스스로 소프트웨어를 사용하고 애플리케이션을 구축하는 방법이 그대로 반영된다.

컨테이너에 대한 이해
현대의 컨테이너는 애플리케이션이 사용하는 서비스를 OS에 필요한 서비스와 분리함으로써 서버에서 애플리케이션을 패키징하고 배포하기 위한 강력한 도구로 부상했다. 컨테이너는 개발 시스템, 사내 데이터센터와 프라이빗설, 하이브리드, 퍼블릭 클라우드 사이에 이식성을 제공한다. 컨테이너로 래핑된 애플리케이션은 호스트 OS로부터 독립적이며 비슷한 컨테이너에서 아무런 변경 없이 실행할 수 있다.

애플리케이션을 컨테이너에 래핑한다는 것은 모든 적절한 구성 파일 및 종속성과 함께 손쉽게 애플리케이션을 배포할 수 있음을 의미한다. 즉, 컨테이너가 개발 시스템에서 실행되거나 모든 통합 테스트를 통과한다면 아무런 변경 없이 서버에서도 실행된다. 새 버전이 나오면 기반 OS에 아무런 영향을 미치지 않고 컨테이너를 변경할 수 있으며 코드를 그대로 두고 서버에서 서버로 컨테이너를 옮길 수 있다. 인프라와 애플리케이션을 별도로 배포하고 별도로 관리할 수 있게 해주는 컨테이너는 데브옵스 모델의 논리적인 종착점이다.

원래는 메인프레임 기술인 컨테이너(또는 최소한 비슷한 형태의 네임스페이스와 프로세스 격리)는 리눅스와 솔라리스를 포함한 다수의 유닉스 OS에 포함되어 있다.

윈도우 컨테이너의 내부
이제 윈도우 서버 2016 출시와 함께 윈도우도 자체 컨테이너 기술을 갖추게 됐다. 널리 사용되는 오픈 소스인 도커 컨테이너 서비스를 기반으로 하지만 파워셸 명령줄 지원이 추가됐고 씬(thin) 컨테이너와 가벼운 나노 서버(Nano Server), 그리고 하이퍼-V 컨테이너의 조합으로 부가적인 격리 기능을 제공한다.

도커는 여전히 마이크로소프트 컨테이너 전략의 중심이다. 스웜(Swarm), 머신(Machine) 등의 도구는 광범위하게 사용되며 데이터센터 제품은 윈도우와 리눅스 컨테이너를 모두 관리할 수 있다. 윈도우 10에 속하는 배시(Bash) 셸에서 도커의 클라이언트를 사용해서 리눅스용 윈도우 하위 시스템에 설치할 수도 있다. 다만 이를 위해서는 복잡한 인증서 작업이 필요하므로 도커의 윈도우 앱을 윈도우와 리눅스 컨테이너를 위한 개발 및 기본 관리 도구로 사용하는 편이 더 나을 수도 있다.

윈도우 컨테이너는 여타 윈도우 서버 기능과 마찬가지로 익숙한 윈도우 기능 대화 상자 또는 파워셸을 통해 설치할 수 있다. 윈도우 컨테이너 기능과 도커를 모두 설치하고 재부팅은 한 번만 하면 되는 원겟(OneGet) 파워셸 모듈이 있으므로 파워셸을 사용하는 방법이 더 낫다. (하이퍼-V 컨테이너를 사용하려면 하이퍼-V 가상화도 활성화해야 한다.)

개발, 운영 팀 모두 윈도우 컨테이너에 대해 예상을 뛰어넘는 호응을 보이고 있다. 마이크로소프트는 윈도우 서버 2016이 공식 출시된 이후 도커 허브 컨테이너에서 기본 윈도우 이미지가 100만 회 이상 다운로드됐다고 전했다.

윈도우에서 컨테이너 빌드, 배포
컨테이너는 서버 전용 도구가 아니다. 윈도우 10 1주년 기념 에디션 프로페셔널, 엔터프라이즈 버전도 컨테이너를 지원한다. 윈도우 기능 대화 상자에서 활성화한 이후 파워셸을 사용해서 개발용 PC에서 윈도우 컨테이너를 설치하고 관리할 수 있다. 윈도우 10은 하이퍼-V 컨테이너만 지원하므로 하이퍼-V도 설치해야 한다.

윈도우 컨테이너를 활성화한 다음에는 도커 엔진과 도커 클라이언트를 다운로드해서 설치하고, 애플리케이션 구성에 필요한 기본 이미지를 설치해야 한다.

새로 빌드된 윈도우 컨테이너용으로 마이크로소프트가 추천하는 기본 이미지는 클라우드 중심의 가벼운 서버 구현인 나노 서버다. 나노 서버는 컨테이너의 기반으로 여러 모로 적합하다. UI 없이 작고 빠르므로 배포 속도가 빠르고 상대적으로 안전하다.

한 가지 중요한 점이 있다. 나노 서버를 사용해서 Node.js와 같은 런타임을 호스팅할 수는 있지만 나노 서버의 원래 용도는 ASP.Net 코어와 같은 .Net 코어 애플리케이션을 호스팅하는 것이다. 즉, Node.js와 같은 런타임을 호스팅할 경우 익숙한 .Net 기능 중 일부는 이용할 수 없다. 친숙한 윈도우 서버와는 꽤 많은 차이점이 있으므로 나노 서버에 호스팅되는 윈도우 컨테이너는 기존 코드를 위한 호스트보다는 새로운 애플리케이션을 위한 도구로 생각하는 편이 낫다.

많은 기업이 윈도우 서버 코어를 기본 이미지로 사용하는 이유도 이러한 차이점에 있다. 윈도우 서버 코어는 나노 서버에 비해 몸집이 크고 배포 시간도 길지만 현행 윈도우 SDK와 전체 .Net 구현을 지원한다. 기존 코드를 서버 코어로 훨씬 더 쉽게, 신속하게 옮길 수 있다. 윈도우 서버 및 하이퍼-V 컨테이너 부문 수석 프로그램 관리자인 테일러 브라운의 표현을 빌자면, 기존 서버에서 컨테이너로 “들어서 옮기는” 옵션을 제공하므로 원하는 곳 어디에든 배포할 수 있다. 일단 컨테이너에 애플리케이션을 넣으면 개발자는 애플리케이션을 더 세부적으로 분해할 수 있다. 예를 들어 API 커넥터를 나노 서버 기반 컨테이너로 옮겨 애플리케이션 유지보수를 간소화할 수 있다.

컨테이너 지원은 가장 낮은 레벨에서 윈도우 도구에 내장되고 있으며, 현재 윈도우 컨테이너는 비주얼 스튜디오 2017의 배포 대상이다. 애플리케이션을 즉시 테스트할 수 있는 컨테이너로 빌드하고 제공할 수 있다. 마우스 클릭 한 번으로 간단히 컨테이너를 만들 수 있도록 한 것은 중요한 진전이다.

곧 윈도우 애저가 중첩 가상화를 지원하게 되면 퍼블릭 클라우드의 격리를 더 강화하는 이 기능은 규제 대상 업계가 컨테이너, 그리고 클라우드로 전환해야 할 또 다른 이유가 될 것이다. editor@itworld.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.