데이터센터에 애플리케이션을 전달하는 방법이 바뀌고 있다. 서비스형 모델로 변화하고 있는데, 이는 데브옵스(devops) 문화로의 이동과 밀접한 관련이 있다. 빌드 툴을 이용해 새 애플리케이션, 업데이트 된 애플리케이션을 전달하는 지속적인 전달 프로세스 구현이 그 중심에 자리하고 있다.
이와 함께 중요한 역할을 하는 것이 또 있다. 기본 OS에서 애플리케이션과 서비스를 추출해, 보안 사일로에서 운영하면서 기본 OS 서비스만 이용할 수 있도록 만드는 도커(Docker) 같은 컨테이너 기술이다.
동일한 호스트에서 여러 컨테이너를 실행시킬 수 있으며, 서로 보호가 되는 것이 특징이다. 컨테이너의 경우 하이퍼바이저 기반 가상화와 달리 별개의 OS 이미지가 필요 없다. 또 IaaS 클라우드 등 가상화 인프라에서도 아무 문제 없이 실행시킬 수 있다.
사실 컨테이너는 신기술이 아니다. 그 역사가 메인 프레임 시대로 거슬러 올라간다. 이는 프리BSD와 오픈솔라리스(OpenSolaris)의 핵심 기술이었다. 또 리눅스 커널에서 오랜 기간 지원했던 기술이기도 하다.
그러나 도커 컨테이너는 엔진의 ‘단순함’을 바탕으로 현대적인 데이터센터에 없어서는 안될 요소가 됐다. 도커는 쉬운 명령어 줄과 잘 정립된 API를 갖고 있다. 덕분에 리눅스는 물론 (이제는) 윈도우에서도 컨테이너를 구축, 공유, 관리할 수 있게 됐다.
Credit: Thinkstock
윈도우 서버와 도커
도커의 윈도우 툴은 상당 기간 존재해왔다. 그러나 윈도우 7과 윈도우 8.1만 지원했다. 마이크로소프트는 윈도우 서버에서도 도커를 지원하겠다고 약속했으며, 2015년 4월 빌드(Build) 개발자 행사의 무대에서 마침내 이를 시연해 보였다. 그리고 몇 주 전에는 윈도우 서버 2016 테크니컬 프리뷰 3용 버전을 처음 공개했다.
필자는 지금 테스트 서버에서 최신 윈도우 서버 2016을 운영하면서, 윈도우 서버 2016의 컨테이너 지원 방식을 조사하고 있다. 한 가지 주의점이 있다. 풀 UI 윈도우 서버에 파워셀(PowerShell) 컨테이너 cmdlets를 설치할 수는 있지만 권장하지는 않는다.
마이크로소프트가 서버 코어(Server Core)용 WIM(Windows Imaging) 디스크 이미지를 포함시키고, 표준 인스톨러와 함께 윈도우 서버 2016 TP3 다운로드 형태로 컨테이너를 지원하는 이유가 여기에 있다.
테스트 서버를 구축하면서 윈도우 서버 2016의 지원 프로세서 요건이 까다로워졌다는 사실을 발견했다. 하이퍼-V에 SLATA(Second Level Address Translation)이 필요하다. 이로 인해, 테스트 서버 중 하나를 사용할 수 없게 됐다.
서버코어 WIM을 하이퍼-V VM으로 바꾸거나, 베어메탈 서버에 윈도우 서버 2016을 구성할 수 있다. 그러나 MSDN에서 사전 설정된 하이퍼-V 이미지를 다운로드 해 윈도우 서버 컨테이너를 구축하는 것이 훨씬 쉬운 방법이다. 파워셸 스크립트로 이미지를 다운로드 해 설치하고, VM을 구성하는 것이다.
다운로드 스크립트는 진행 상태를 알려주지 않는다. 약 6GB 파일이기 때문에 다른 툴을 이용해 다운로드 할 때 주의를 기울일 필요가 있다. 필자의 경우 인터넷 연결 상태가 아주 불안정했기 때문에 작업 관리자(Task Manager)의 네트워크 트래픽 모니터링 도구를 이용했다. 대안으로 애저(Azure) IaaS를 호스트로 이용할 수 있다. 애저 갤러리에서 컨테이너를 지원하는 윈도우 서버 2016 코어 이미지를 입수할 수 있다.
가상 머신을 다운로드 받으면, 스크립트가 아카이브를 풀어 하이퍼-V 가상 머신을 설정한다. 그리고 다운로드 스크립트를 호출할 때 설정한 비밀번호로 실행된다. 하이퍼-V에 기본 탑재된 뷰어로 VM을 연결할 수 있다. 그러나 먼저 VM을 종료한 후, 하이퍼-V 가상 스위치에 연결하는 것이 좋다.
최초 이미지는 기본적인 윈도우 서버 코어 컨테이너다. 때문에 애플리케이션 일부로 사용하기 전에 파일이나 서비스를 추가할 필요가 있다. 파일을 추가하면, 도커 명령어로 새 이미지를 만들 수 있다. 그러면 새 컨테이너를 이용할 준비가 된 것이다.
이미지에서 컨테이너를 생성할 때마다 새 파일 시스템을 인스턴스화 한다. 다시 말해, 컨테이너를 폐기하면 컨테이너에 저장된 데이터가 파괴된다는 의미다. 물론 외부 파일 시스템이나 다른 애플리케이션, 서비스에 저장한 파일은 해당되지 않는다.
마이크로소프트의 윈도우 서버 컨테이너 & 도커 퀵스타트(Quick Start on Windows Server Containers and Docker)는 단계별로 도커 명령어로 새 이미지를 만들고, 컨테이너화 한 웹 서버를 외부 네트워크에 연결한다. 아주 쉬운 도구다. 리눅스나 윈도우 개발자 노트북에서 도커를 이용한 경험이 있다면, 이런 프로세스가 친숙할 것이다.
그러나 보편적인 도입을 위한 준비가 완료된 상태는 아니다. 아직 윈도우 서버 2016을 지원하지 않는 도커 명령어가 있기 때문이다. 예를 들어, ‘diff’를 이용할 수 없다. 또 컨테이너를’restart’할 수 없으며, ‘pause’ 및 ‘unpause’ 지원에도 의문이 남아있다.
기타 부분적으로만 기능하는 명령어들도 있다. 일부 옵션만 작동되는 ‘build’가 여기에 해당된다. 그러나 관리자 비밀번호를 설정하고, 올바른 방화벽 포트를 열었다면, 원격 데스크탑(Remote Desktop)을 이용해 컨테이너에 연결할 수 있다.
컨테이너에 도움을 주는 파워셸
마이크로소프트는 도커 대신 파워셸을 이용해 컨테이너를 구축해 관리하는 옵션을 제공하고 있다. 윈도우 서버 2016, 특히 새로 출시된 나노 서버(Nano Server)는 직접 또는 시스템 센터(System Center)를 이용한 원격 파워셸로 관리가 가능하게끔 설계되어 있다. 따라서 이를 이용해 윈도우 컨테이너(Windows Containers)를 관리하는 것이 더 합리적이다.
도커 윈도우 컨테이너와 파워셸 윈도우 컨테이너에는 차이점이 없다. 현재 테크니컬 프리뷰에서는 도커를 이용해 파워셸에서 생성한 컨테이너를 관리할 수 없지만, 둘 모두 동일한 라이브러리와 연동된다.
파워셸을 이용해 하이퍼-V 가상 스위치와 연결된 평가용 서버 코어 VM에 탑재된 이미지 하나로 컨테이너를 구현할 수 있다.
컨테이너를 생성한 후, 다른 파워셸 명령어를 이용해 컨테이너를 시작할 수 있다. 그리고 원격 파워셸 명령어로 관리를 할 수 있다. 컨테이너 cmdlets를 스크립트와 묶어, 더욱 능률적으로 컨테이너를 배치할 수 있다. 여러 데이터센터나 클라우드 인프라에서 컨테이너를 한층 용이하게 자동화 처리할 수 있는 방식이다.
과거 도커를 이용해 컨테이너를 구축해 운영한 경험이 있다면, 파워셸 cmdlet 신택스(구문)와 관련해 문제에 직면할 수도 있다. 파워셸의 컨테이너 관리 도구는 스크립트 구축이 전부다. 따라서 명령어 한 줄로 컨테이너를 실행시키는 대신 컨테이너 설명을 생성하고, 이를 변수로 만들고, 다른 cmdlet를 이용해 컨테이너를 실행시켜야 한다. 파워셸 코드를 작성하고 나면, 이 코드를 기본 스크립트로 비교적 쉽게 명령어를 만들어 낼 수 있다.
네트워킹이 컨테이너에 문제를 발생시킬 수 있다. 윈도우 컨테이너는 호스트 OS가 NAT를 처리하도록 하는 방법으로 이를 극복한다. 컨테이너는 호스트로부터 IP 주소를 획득한다. 그리고 해당 컨테이너의 포트 매핑과 방화벽 규칙을 처리하도록 호스트를 설정할 수 있다. 일부 경우, 파워셸이나 도커 명령어 중 하나를 이용해 고정 포트 매핑을 구성해야 한다. 또 호스트 OS의 기본 방화벽 규칙을 설정할 필요가 있다.
직접 어드레스로 불러낼 수 있는 컨테이너를 구현하고 싶다면, DHCP나 IPAM(IP Address Management)를 이용하는 다른 네트워크에서 IP 주소를 획득하도록 설정할 필요가 있다. 그리고 스크립트로 DNS를 업데이트한다. 실제 환경에서는 직접 액세스가 필요한 경우를 제외하고는 컨테이너에 이름을 지정하지 않는 것이 간편하다. 그리고 웹 종점에는 로드 밸런서로 마이크로서비스는 메시지 큐로 연결을 처리한다.
마이크로소프트의 문서는 컨테이너에 엔진X(Nginx) 웹 서버를 구성하는 방법을 단계 별로 소개하고 있다. 다른 컨테이너를 테스트하고 싶은 사람들을 위해 Node.js와 IIS 등 깃허브(GitHub) 샘플을 제공한다. 마인크래프트도 여기에 포함된다. 그러나 이 초기 릴리스는 윈도우 컨테이너에서 애플리케이션을 실행시키는데 목적이 있다. 자신의 코드가 컨테이너에서 어떻게 작동하고, 컨테이너를 확장 메커니즘으로 실험할 좋은 기회이다.
도커 vs. 파워셸
마이크로소프트는 현 시점에서는 파워셸과 도커의 컨테이너 관리 기능을 분리하는 방식을 선택했다. 관리 플랫폼에 기본적인 차이가 있는 부분들이 일부 존재하기 때문이다. 이를 어떻게 극복할지 불확실하다. 네이밍 같은 간단한 문제에서 상태 관리 같은 복잡한 문제까지 문제가 다양하기 때문이다. 마이크로소프트가 이 둘을 통합하기 전에는 한 가지 방식을 선택해 고수하는 것이 최상이다.
파워셸과 도커 모두 명령어 줄로 컨테이너를 제어할 수 있으며, 고수준의 관리 도구에서 이용할 수 있는 API를 제공한다. 윈도우 서버 컨테이너가 아직까지 큰 문제를 안고 있다는 의미다. 마이크로소프트가 파워셸 및 도커 통합에 노력하고 있지만, 로컬이나 애저 환경에서 컨테이너를 기반으로 지속적인 전달 프로세스를 구현하기 희망하는 시범 프로젝트에는 중대한 문제가 될 수 있다.
그러나 윈도우 서버의 컨테이너 지원 기능을 시험할 가치가 없다는 의미는 아니다. 새 파워셸 도구를 이용해 생산 환경에서 컨테이너를 실행시킬 때 필요한 관리 프레임워크를 구축하기 시작할 수 있다. 유사하게, 도커가 운영 중인 데이터센터에서 어떻게 작동하는지 탐구하고, 윈도우 서버 2016 출시 후 이용할 수 있는 호스트 컨테이너 환경을 구축해 운영할 수 있다.
하이퍼-V 컨테이너는 아직 공개되지 않은 상태다. 즉 윈도우 서버 2016의 컨테이너에 대한 그림이 완성되지 않았다. 그렇지만 윈도우 서버 2016 TP3는 출발점으로는 충분하다. 그리고 향후 테크니컬 프리뷰에서 더 많은 기능이 도입되기를 기대한다.
* Simon Bisson 는 학계 및 통신 분야에 종사해왔으며 기술 전략 컨설팅 업무를 수행해온 IT 전문 칼럼니스트다.dl-ciokorea@foundryco.com
