Microsoft의 컨테이너(Container) 기술, Windows Server 2016과 Docker.. Windows/Hyper-V Container

Linux 인프라를 메인으로 사용하시는 분들에게는 Docker라는 단어가 매우 익숙한 단어이실 것입니다. 운영 체제에 대한 배포, 그리고 운영 체제의 설정에 대한 배포, 나아가 그 위에서 동작하는 응용 프로그램과 응용 프로그램 데이터에 대한 배포 및 업그레이드를 보다 빠르고, 쉽게할 수 있는 컨테이너(Container) 기술입니다.

클라우드 형태의 인프라를 활용하면서, 필요시 빠른 스케일 아웃, 그리고 반대의 형태를 취할 수 있으며, 업그레이드나 자동화적인 측면에서도 컨테이너 기술이 매우 효율적인 것은 사실입니다.  Microsoft에서는 Windows Server 2016에서 컨테이너 기술인 Docker를 Windows Container와 Hyper-V Container 형태로 제공/지원할 예정입니다. 기존 Docker와 완전히 다른 형태가 아니라, Docker와 동일한 형태를 Windows Server에 구현한 형태입니다. (관련 Docker 블로그 아티클) 그렇기에, Docker 자체 명령어와 Windows PowerShell 형태의 관리를 제공합니다. (아래 스크린샷들 참고)

최근 발표된 Windows Server 2016 Technical Preview 3이 바로 이 컨테이너 기술을 제공하고 있습니다. 오늘 포스팅에서는 먼저 컨테이너 기술에 대한 이해를 살펴보도록 하겠습니다. 일반적인 일상 예제를 하나 들어보죠. 개발자와 IT 엔지니어 사이의 예가 될 수 있습니다.

• 개발자 A는 비즈니스 조직내 기간계 시스템을 개발하는 사람입니다. 이 분은 본인의 랩탑에서 코드를 개발하고, 이를 테스트를 마쳐 정상적으로 동작함을 확인하였습니다. 이 후, 테스트 서버에 해당 코드를 배포하여, 마지막 확인까지 마친 후, 응용 프로그램 관련 파일과 설정 방법등을 패키지화, 그리고 문서화하여 IT 팀에게 전달합니다.
• IT 엔지니어 B는 해당 문서를 참고하여, 응용 프로그램을 실제 서버에 배포하고, 설정하였습니다.

그러나 동작하지 않는 경우가 종종 발생합니다. (에러 발생)

• IT 엔지니어 B는 혹시나 본인이 어떤 설정을 잘못했나 싶어, 다시 배포를 진행해보았지만, 실패합니다. 이 후, 메일이나 전화를 걸어, 정상적인 동작이 되지 않는다고 이야기합니다.
• 개발자 A는 이상하다고 생각합니다. 본인의 랩탑 및 테스트 서버에서는 정상적으로 동작했기에.. IT 엔지니어가 잘못했다고 확신합니다. 다시 문서를 제대로 읽고, 혹시 문제에 대한 로그가 어떻게 발생했는지 요청합니다.

이 경우, IT 엔지니어나 개발자의 상호 상황은 누군가가 본인의 상위 관리자에게 서로가 무언가를 잘못했다고 주장하고, 논쟁하면서, 돌아올 수 없는 강을 건너게 됩니다. 다들 본인은 문제가 없었고, 상대방 측에서 설정이나 코드를 잘못 했기에, 문제가 유발되었다고 주장하는 셈이죠. 그렇다고 IT 엔지니어 입장에서 개발자에게 운영 서버에 대한 관리자 권한을 넘기고, 셋팅해달라고 하기에도, 부담스럽습니다.

왜 이런 문제가 발생했을까요? 바로 배포 방법론이 복잡했기 때문입니다. 보통 이러한 이유로 현업에서는 서비스를 새롭게 배포하거나, 업그레이드할 때, 아무 설정도 되지 않은 초기 설치 상태의 운영 체제를 요구하는 것이죠. 약 10년동안, 새로운 운영 체제의 구성을 요구할 경우, 가장 많이 생각할 수 있는 기술이 바로 가상화(Virtualization)입니다. 하드웨어와 운영 체제 사이에 추상화 계층(Abstraction)을 만들고, 개별적인 논리 컴퓨터를 생성하여, 상호 간섭을 하지 않게 만들어주는 기술이었죠.

오늘 소개해드릴 컨테이너는 하드웨어와 운영 체제 사이의 추상화 계층이 아닌, 운영 체제와 운영 체제위에 구성된 설정/설치된 응용 프로그램 사이의 추상화 계층을 의미합니다.

CExecSvc.exe가 보이시나요? Windows Server 2016 Technical Preview 3으로 구성된 Container 호스트내 서비스 프로세스입니다. 아직 감이 잘 안오실 수 있기에, 조금더 예를 들어 살펴보겠습니다.

• 운영 체제를 설치합니다. : 이미지 A
  
• 운영 체제 설치 후, 구성되면서, 변경된 사항들을 하나의 파일 형태로 저장합니다. (각종 운영 체제 설정) : 이미지 B
• 구성된 운영 체제위에 필요한 응용 프로그램 서비스를 설치합니다. (IIS, PHP, Node 등에 대한 구성) : 이미지 C
  
• 응용 프로그램 서비스에서 제공할 관련 파일들을 복사합니다. (웹 소스 파일에 대한 구성) : 이미지 D
  

다른 Container 기술이 설치된 서버에 이미지 A를 가져오고, 이후, 이미지 B를 가져와서 합치면, 각종 운영 체제 설정이 완료된 형태까지 제공할 수 있습니다. 만약 우리 조직에서 PHP를 주로 사용한다면, PHP 구성까지의 설정은 다 동일하기에, 이미지 A, B, C만 가져와서, 불러들이면, PHP 서비스를 하기 위한 기반은 구성이 완료되게 됩니다. 만약 이미지 B위에서 여러 이미지 C를 등록할 수 있다면, 어떨까요?

지금까지의 설명은 1:1:1로 연결되지만, 컨테이너 기술은 1:N으로 확장해서 올라갈 수 있습니다. 그러면서 상호간에는 고립(Isolation)된 형태이기에, 간섭을 일으키지 않습니다.

서버 1대가 사양이 높아, 여러 서비스를 제공하는데, 상호 간섭을 하지 않게 한다면, IT 엔지니어는 가상화 기술을 떠올리게 됩니다. 물론 의미있는 기술 선택입니다. 그렇지만, 가상화만 답이 아니라, 컨테이너 기술도 답이 될 수 있다는 것입니다.

이미지 A 하나 기반에서 2대의 이미지 B를 동작시키면, Container에서는 상호 알지 못하는 2개의 이미지 B가 동작합니다.

이 경우, 위 그림의 KOALRACON-01과 KOALRACON-02는 상호를 인지하지 못하고, 서로 다른 형태로 구성이 가능합니다.

가장 상단의 명령 프롬프트가 컨테이너를 제공하는 호스트에 대한 정보이며, docker ps 명령어에 대한 결과로 KOALRACON-01, KOALRACON-02가 나타납니다. 왼쪽 하단 명령 프롬프트가 KOALRACON-01이며, 별도의 디렉터리 생성이 되어 있습니다. 오른쪽 하단은 KOALRACON-02죠.

IP 주소도 다름을 알 수 있습니다. 완벽하게 분리된 두개의 운영 체제 공간인 것이죠. 이렇게 KOALRACON-01, KOALRACON-02에 대한 구성을 진행하여 완료하면, 이를 이제 다시 사용할 수 있는 이미지로 반영할 수 있습니다.

차후 PHP가 필요하면, phpservice 이미지를 불러오면, 되겠죠. 이 경우, phpservice 이미지와 하위 이미지였던 windowsservercore 이미지는 연결 고리가 있고, 하위 이미지가 있어야 동작합니다. 어찌보면, 가상화에서 차이점 디스크랑 비슷하다는 생각이 들기도 합니다. 앞서 생성한 iisservice 이미지에 대한 정보를 보면, windowsservercore가 하위 이미지임을 알 수 있습니다.

이를 또 두개 생성하면, 다른 환경의 IIS가 두대 생성되고.. 아주 신기하면서도, 재미있지 않으신가요?

두개의 컨테이너 인스턴스가 더 생성되어 구동중입니다. 상호간에는 역시나 모르는 형태인…

당연히 해당 이미지들을 Export하여, 다른 서버에 옮길 수 있습니다.

이제 용어를 좀 정리하고, 오늘의 포스팅은 마치겠습니다. 가상화 기술에서 가상 컴퓨터를 제공할 하이퍼바이져가 설치된 컴퓨터를 가상화 호스트라고 표현합니다. Windows Container에서도 컨테이너 기술을 제공할 호스트를 Container Host라고 부릅니다.

각 컨테이너 호스트에는 서비스할 운영 체제에 대한 기반 이미지가 필요합니다. 이를 Container OS Image라고 합니다. 현재, Windows Server 2016 TP3에서는 Windows Server Core만 제공되며, 별도로 기반 이미지를 생성하여, 넣는 기술은 제공하고 있지 않습니다. 차후, 다른 운영 체제도 제공될 예정입니다. Docker에서는 Docker Hub 웹 사이트 형태로 제공합니다. (Microsoft도 당연히 )

Container OS 이미지에 Core가 아닌, Full GUI 버전의 Windows Server는 제공되지 않을 예정입니다. (어찌보면 당연한 형태입니다. 컨테이너 기술 자체가 빠른 배포 및 구성을 목적으로 하기에, 용량이 큰 형태로 패키지가 만들어지면 안되겠죠.) 이미지를 구동하여 만들어진 컨테이너들은 상호간에 고립된 Sandbox 모델입니다. 그리고 컨테이너내에서 변경되어 저장된 이미지는 Container Image라고 부릅니다.

Container OS 이미지, Container 이미지를 모아서 저장해놓으면, 이를 필요시 꺼내서 사용할 수 있겠죠. 이를 Container Repository라고 부릅니다.

정리하면, 아래 그림과 같습니다. (MSDN 사이트 아티클)

Windows Server 2016 Technical Preview 3이 발표될 즈음, 많은 IT 엔지니어 분들께서 잘 아시는 Mark Russinovich께서 블로그에 Containers: Docker, Windows and Trends를 포스팅하였습니다. 이 글안에 인상적인 구문이 있죠. 바로 Microservices에 대한 이야기입니다. Microservices 형태로 개발된 모습이 클라우드 환경에서 적절하고, 이러한 형태에서 컨테이너 기술이 빛을 낼 수 있다는.. 시간이 되실 때 꼭 읽어보시면 좋겠습니다.

Windows Container라는 형태는 오늘의 포스팅에서 정리가 됩니다만, Hyper-V Container는 언급하지 않았습니다. Container 호스트를 실제 Windows 운영 체제에서 제공할지, VM 안에서 제공할지에 대한 차이입니다. Container 자체를 제공하는 기술은 동일합니다. 다음 포스팅에서는 간단하게 Container 호스트를 구성하고, 컨테이너들을 구동하는 실제 방법을 살펴보시죠!