Developer Holywater Jeong

컨테이너 기반의 가상화 기술인 Docker를 알아보자

2018. 06. 20 | 3 Minute Read

들어가며


필자의 개발자로서 "나중에 덜 귀찮기 위해 지금 귀찮아야한다"는 마인드를 가지고 있다. 그러기 위해 프로그래밍 영역에서 모듈화 부분에 대해서도 많이 신경을 쓰고, 개발 언어도 다양한 영역(클라이언트, 서버, 앱)에서 최대한 많은 것들을 공유할 수 있는 Javascript(React, Node.js)에 관심을 크게 두고 있다. 요즘에는 개발환경에 대해서도 어떻게 구성해야 더 효율적으로 개발할 수 있는지를 고민하는데 그런 의미에서 Docker라는 기술에 아주 큰 관심을 가지고 있다. 오늘은 컨테이너를 기반으로 하는 가상화 플랫폼 Docker라는 기술이 어떤 것인지 알아보도록 하자.

컨테이너란?

컨테이너는 흔히 말하는 가상 머신(VM, Virtual Machine)이랑은 다르다. 공통점이라면 일단 가상화를 목적으로 한다는 것이 있겠다. 그렇다면 각각의 특징이 무엇인지 알아보자.

  • 컨테이너여러 개 컨테이너가 한 OS에 올라가지만 VM은 작업 영역 분리 시 각각의 Guest OS가 필요하다.
  • VMHost OS와 상관 없이 OS를 자유롭게 선택 가능하지만 가상화 컨테이너는 그렇지 않다.
  • 컨테이너이미지를 기반으로하여 동일한 개발환경 구성과 배포에 용이하지만 VM은 비교적 쉽지 않다
  • 컨테이너보안에 취약하다.
  • 컨테이너가 VM에 비해 성능이 좋다(물론, 둘 다 Host OS보다는 떨어진다.)

위와 같이 둘 다 장단점이 존재한다. 그래서 꼭 "컨테이너가 가상머신을 대체할 것이다."라는 관점보다는 서로 상호 보완할 수 있는 존재로 여기는 게 좋지 않을까 싶다.

도커와 VM의 기술적인 차이

도커컨테이너 기술의 대표주자이기 때문에 도커가 거의 대명사처럼 불린다. 그래서 이번에는 도커와 VM이 어떤 형태로 구성이 되어있는지를 알아보자.

image 출처 docker blog
VM은 Host OS > HyperVisor > Guest OS(여러 개 나뉘기 시작) > Bins/Libs > App 이런 순서로 나뉜다. 도커는 Host OS > Docker Engine > Bins/Libs > App 순서로 나뉜다. 차이는 VMHost OS 위에 Guest OS로 분리 되지만 도커에서는 Host OS 하나만 존재하고 Docker Engine에서 작업 영역이 격리된다는 것이다. 그래서 도커가 성능에서 더 좋은 퍼포먼스를 보여주는 것이다. 반대로 도커는 한 컨테이너만 보안적인 이슈가 생겨도 나머지 컨테이너와 Host까지 위험할 수 있지만 VM은 한 영역의 공격은 한 영역에서 끝난다. 그래서 VM은 여러가지 OS에서 애플리케이션을 띄워야 하는 경우에 용이하다고 볼 수 있고 도커는 한 컨테이너 내에서 애플리케이션을 여러 개 띄울 경우 좋은 케이스가 될 수 있겠다.

도커의 중요한 개념. 이미지와 컨테이너

도커에는 중요한 개념인 이미지컨테이너가 있다. 이미지를 먼저 알아보자면 컨테이너를 구동하기 위한 기능과 환경설정 등이 포함되어 있다. 이런 것들은 사용자 정의를 통해서 재구성도 가능하다. 기본적으로 Dockerfile에 정의해서 사용한다. 컨테이너는 위에서도 말했지만 OS로 분리되지 않는다. 프로세스가 격리된다고 보면 되겠다.

의존성과 링크 기능을 제공하는 Docker Compose


Docker를 사용하면서 한 애플리케이션만 올리는 경우는 별로 없을 것이다. 그래서 애플리케이션을 여러 개 띄울 때 순서대로 띄우거나 링크 기능이 필요한 경우도 있다. 그럴 때 사용하는 것이 Docker Compose다. Docker Compose로 여러 개의 컨테이너를 한 번에 구동시킬 수 있는 편리성 제공이 우선이다. 여러 개의 컨테이너를 정의한 docker-compose.yml을 작성한 후 "docker-compose up" 명령어 하나면 쉽게 구동이 가능하다. 그리고 한 컨테이너가 먼저 구동되고 다른 컨테이너에서 실행이 되는 depends_on 기능, 다른 컨테이너에서 명시적으로 호출할 수 있는 link 기능으로 명시적인 url이나 ip를 사용하지 않고 호출 가능하다.

Docker Orchestration


서비스가 커지면 커질 수록 물리적인 서버 한 대로 커버하기 힘들 것이다. 그럴 때 Docker 또한 자유롭지 못하다. 그래서 Docker Orchestration라는 개념이 존재한다. 물리적으로 분리된 여러 대의 서버에서도 Docker를 사용하고자 할 때 사용하는 기술이다. 그 도커 오케스트레이션에서 가장 유명한 기술이 Docker Swarm이다. 이 부분은 공부를 자세히 하지 않아 모르겠어서 자세히 언급하지 않겠다.

Next.js와 Docker

Next.js를 공부하고 있다보니 이것을 어떻게 Docker에 잘 적용시킬 수 있을지를 고민한다. Production 서비스의 경우 큰 문제는 없다. Development에서는 HMR 기능을 사용하게 되는데 이 부분을 Docker에서도 사용할 수 있는지 파악 중이다. 일반적인 기술 사용에서 HMR에 대한 글은 있지만 Next.js HMR 기능과 Docker에 연관되어 쓰여진 글을 본 적이 없다. 이 부분을 연구해서 블로그 포스팅을 해보는 게 목표다.

끝.