Edit Files
Login Register

Docker

Docker는 일종의 “실행 환경 가상화 도구”라고 할수 있다. 가상 머신과는 비슷 하면서도 다른 실행 방식을 보여주는데 주요한 차이점은 디바이스나 기타 다른 장치들을 소프트웨어로 가상화 하지 않는다는 것이다. 이를 통해 성능 상의 손실을 줄일 수 있게 되었으며 더욱 간편하게 격리된 실행 환경을 사용할수 있게 되었다.

Is Not Docker

docker is not vm

docker는 vm 이 아니다. docker container 그 자체는 단순히 linux process 에 지나지 않는다. 다만 해당 process가 독립적으로 동작할수 있도록, 별도의 namespce 를 제공하는 것이다. 이는 예전의 chroot와 닯은 구석이 있다고 할수 있다. docker container 의 kernel 은 컨테이너 외부의 kernel을 그대로 사용하고 있는 것이다. container 내부가 마치 독립적인 vm인것처럼 container 내부에서 실행시킨 process가 보이지만 이것은 사실 kernel 의 눈속임 이다. linux kernel의 namespace로 filtering 하여 보여줄 뿐인 것이다. 그래서 docker 명령어는 process를 관리하는 명령과 닯아 있다. 실제로 관리 대상도 처음 실행한 바로 그 process이다. 그 process가 죽으면 하위 프로세스는 전체가 다 죽는다. error code 또한 처음 실행한 process의 종료 코드로 판별한다.

다음 영상을 참고 하면 이해하는데에 도움이 될수있다. https://www.youtube.com/watch?v=Utf-A4rODH8

설치

2015년 5월 현재. 윈도우에서 부터 linux까지 운영체제를 가리지 않는다.

Docker Install Guide 참조.

활용

가볍고 가상환경 구축에 걸리는 시간이 매우 짧고 대부분의 운영체제에서 동작한다는 것을 활용해서 다음과 같은 부분에 활용할수 있다.

  • 사전 설정이 귀찮거나 어려운 프로그램의 배포1
  • 사전에 환경이 모두 같아야 하는 교육용 환경 설정
  • dockerfile을 활용한 간단한 paas 서비스2
  • 학습용 가상머신 할당
  • 개발 환경 구축

docker 를 개발 환경으로 사용하려는 사람들은 흔히 docker가 하나의 vm 으로 동작할것이라고 예상한다. 즉, docker container 내부에서 source 를 수정하고 이를 build 하고 test server를 띄우게 사용하려는 경향이 있다. 이는 잘못된것은 아니지만, docker의 방향과는 맞지 않다고 할수 있다. docker container 는 단순한 linux process 에 지나지 않으며, 따라서 여러개의 서로 다른 process를 제어하는 데에 적합하지 않다. 특히나 docker container 를 실행할 당시에 bind 되지 않은 resource는 실행 도중에 bind 할수 없다. 이는 portmapping이나 특정 disk의 mount, docker host와 docker container 내부의 directory mount 등등이 runtime 중에 바뀔수 없음을 의미한다3. 따라서 docker를 개발환경에서 활용하는 것은 단지 build를 하는 process, test server를 띄우는 process 처럼 명확하게 역활이 분리된 프로세스를 시스템 라이브러리와 같은 디펜던시와 상관없이 띄워주는 도구로 생각하는 것이 좋다.

swarm vs k8s

docker 에서 두가지 scheduler 가 흔히 언급 된다. 두 스케쥴러의 차이를 설명하기는 쉽지 않으나 대체적으로 다음과 같은 특성을 지닌다.

  • k8s는 멀티테넌시의 큰 cluster 에 적합하고, swarm 은 싱글 테넌시의 작은 cluster에 적합하다.
  • cloud service 를 쓸것이라면 k8s가 적합하다(AWS, GCE)
  • k8s를 직접 설치해서 쓰는 것은 많은 리소스가 필요하다.
  • swarm은 개발자의 PC 에서도 손쉽게 cluster 를 구성할수 있는 반면 k8s는 별도의 third party(mini kube, kube admin)를 써야 한다.
  • swarm에서 복잡한 디펜던시를 갖는 service 를 yaml 파일 하나, script 하나로 배포하기란 꽤 어렵다.
  • k8s가 사용자가 훨씬 많기 때문에, opensource platfom을 많이 띄워야 한다면 k8s 가 훨씬 유리하다.
  • k8s가 훨씬 많은 자유도를 보장한다.(swarm은 docker 기능 조차도 제한적인 경우가 많다)

개인적으로는 component 5개 내외의 MSA 구조에서는 swarm 이 개발환경의 손쉬운 구축이 가능하기 때문에 좋았으나 그 이상되면 어차피 별도의 cluster를 개발환경으로 꾸며야 하는 경우가 많아 k8s가 유리하다고 생각한다.

See Also

  1. 물론 안 귀찮아도 쓰면 좋다.
  2. https://github.com/progrium/dokku
  3. 물론 container 기술 자체는 이런것들이 가능하지만, docker 에서는 해당 기능을 제공 하지 않는다.