docker

• https://www.docker.com/
  
  

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

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의 종료 코드로 판별한다.

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

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

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 처럼 명확하게 역활이 분리된 프로세스를 시스템 라이브러리와 같은 디펜던시와 상관없이 띄워주는 도구로 생각하는 것이 좋다.