1. 왜 도커를 사용하는가??

컨테이너 기술은 도커 이전에도 존재하였지만 현재는 도커가 컨테이너 기술의 거의 표준처럼 자리잡았습니다. 어떤 이유 때문에 도커가 선택받게 되었는지 살펴봅시다.

1.1 가상 머신(VM)과의 비교

흔히 도커의 장점을 설명할 때 가상 머신과 많이 비교를 합니다.

가상 머신에서는 호스트 OS에 별도의 OS를 설치하는 방식입니다. hypervisor에 의해 하나의 호스트 OS에서 여러 게스트 OS를 실행 가능하도록 합니다. 가상 머신은 호스트와는 독립적인 커널 공간을 가져야 하므로 가상 머신을 구성하기 위해 OS, 애플리케이션, 바이너리 파일 등이 모두 필요합니다. 따라서 hypervisor를 거치면서 어느 정도 성능 손실이 있고, 배포 이미지로 만들었을 때 용량이 커서 꽤 무거워집니다.

반면 도커 컨테이너는 실행 환경은 컨테이너 내부에 격리되지만 OS는 호스트와 공유합니다. 따라서 컨테이너 내부에는 애플리케이션 실행에 필요한 파일들만 가지고 있어서 용량도 적고 성능 손실도 거의 없습니다.

1.2 간편한 배포

위에서 설명한 대로 실행할 애플리케이션 및 관련 라이브러리들은 도커 이미지 내부에 담겨 있습니다. 다시 말해서 해당 이미지만 있으면 사용자가 환경을 따로 구성할 필요 없이 어느때나 배포를 할 수 있습니다.


2. 컨테이너

컨테이너(container)는 애플리케이션을 실행하기 위한 실행 파일 및 자원, 네트워크 등이 구성되어 있는 격리된 공간입니다.

2.1 도커 이미지

도커 이미지는 컨테이너를 생성하기 위한 기반이 됩니다. 애플리케이션을 구성하기 위해 도커 허브와 같은 저장소에서 적합한 이미지를 가져오거나 혹은 Dockerfile 을 이용하여 추가적인 작업들을 명시할 수 있습니다.

하나의 도커 이미지는 여러개의 레이어로 구성되어 있습니다. 저장소에서 이미지를 pull 받을 때도 레이어 단위로 가져오게 됩니다. 컨테이너를 실행하게 되면 이러한 레이어들을 차례로 조합하여 컨테이터를 구성하게 됩니다. 이때 레이어들은 읽기 전용으로 한 번 저장되면 절때 변하지 않습니다.

컨테이너 상에 생기는 변화는 컨테이너 레이어에 별도로 저장됩니다. 컨테이너에 아무리 작업을 하여도 원본 이미지에는 아무 영향을 미치지 않으며, 컨테이너를 삭제하면 해당 데이터는 날아가게 됩니다.

2.2 도커 네트워크

도커에서 컨테이너를 생성하게 되면 각 컨테이너마다 IP를 할당합니다. 해당 IP는 컨테이터 내부에서만 사용되며 컨테이너가 재시작하면 변경될 수 있습니다. 호스트에서 ifconfig 를 조회해보면 docker0, veth.. 등의 네트워크를 확인 할 수 있습니다. veth 로 시작하는 네트워크 인터페이스는 컨테이너를 실행 할 때 생성되는데, 컨테이너 내부의 eth0 인터페이스와 연결됩니다. docker0 는 각 컨테이너의 veth 와 호스트의 eth0 를 연결하여 외부와 통신이 가능하도록 합니다.

도커 컨테이너는 기본적으로 docker0 브릿지를 통해 외부와 연결 가능하도록 되어있으나 용도에 따라 bridge, host, none, container 등의 네트워크 드리이버를 선택할 수 있습니다.

  • 브릿지(bridge) - docker0 이외에 사용자가 추가적으로 정의한 브릿지를 이용하여 컨테이너에 연결합니다.
  • 호스트(host) - 호스트의 네트워크 환경을 그대로 사용합니다.
  • 컨테이너(container) - 다른 컨테이너와 네트워크 환경을 공유합니다. 이 경우 추가적인 IP 할당이 이루어지지 않고 veth 인터페이스도 생성되지 않습니다.
  • none - 어떤 네트워크도 사용하지 않고 외부와 연결을 단절합니다.

References