도커와 관련된 프로젝트를 진행하면서, 도커 레지스트리를 건들 일이 생겼다.
가상 머신 vs 도커
도커에 대해 얘기를 시작할 때에면 흔히 가상머신과의 비교를 통해 시작한다. 도커 이전의 가상화 방식은 주로 os를 가상화하는 것이었다. 호스트 OS 위에 게스트 OS 전체를 가상화하여 사용하는 방식이다. 즉 각 VM 위에 필요한 OS, application, library 등의 전체 복사본이 각각 설치되었다. 이는 여러 종류의 OS 를 가상화하여 하나의 OS 위에 올려서 사용할 수 있었으나 너무 무겁고 느렸기에, 점차 확장되어 많은 서버와 리소스를 가지고 운영을 해야하는데에 기존의 방식으로는 한계가 생겼다.
이와달리, 도커는 OS를 설치하는 것이 아닌 croups, 커널 이름공간과 같은 리눅스 커널이 제공하는 기능들을 이용해 하나의 OS 위에서 분리된 프로세스로 실행된다. 이로부터 CPU, 메모리 등은 프로세스가 필요한 만큼만 사용하기에 성능적으로도 손실이 적고, VM에 비해 훨씬 가볍고 빠르다.
이미지
이미지와 컨테이너는 도커의 핵심적인 개념이다. 이미지는 컨테이너를 실행하는데에 필요한 파일 및 설정값들을 담고 있고, 이를 기반으로 빌드한 환경이 컨테이너이다. 이미지는 컨테이너를 실행하는데 필요한 의존성 등 모든 정보를 담고 있기 때문에 다른 잡업을 할 것없이 서버를 추가하고 싶다면 미리 만들어둔 이미지를 가져와서 컨테이너를 생성하기만 하면 된다.
이미지 레이어
이미지는 추가적인 파일이 필요할 때, 추가적인 파일을 추가하여 다시 다운 받는 것이 아닌 기존의 이미지에 추가하고자 하는 파일을 그대로 얹어서 사용할 수 있게 하는 개념이다. 이미지는 원래 여러개의 layer 로 구성이 된다. 이를 유니온 파일 시스템을 이용하여 여러개의 레이어를 하나의 파일시스템으로 사용할 수 있게 해준다.
이미지 태그
이미지는 url 방식으로 관리하며 태그를 붙일 수 있다. 아래 사진은 도커허브(이미지를 모아둔 퍼블릭 레지스트리)에 올라와있는 nginx 이미지의 태그이다. 이러한 방식은 이해하기 쉽고 편리하게 사용이 가능하며 롤백이나 테스트에도 유리하다.
Dockerfile
container를 실행하기 위해 필요한 기본적인 명령어를 담은 파일이다. 이미지에는 이 파일이 필수적으로 포함이 되어야 하고 이를 기반으로 컨테이너를 빌드하게 된다.
Docker Daemon
프로젝트를 진행하면서 알게된 가장 흥미로운 내용이다.
터미널을 통해 확인하게 되면 실제 도커는 /usr/bin/docker 에 위치하고 있다. 하지만 실제 도커 엔진은 /usr/bin/dockerd 파일로 실행이 된다. 이유는 도커를 설치하게 되면 크게 두 파트로 나누어져 설치가 되는데, 하나는 클라이언트로서의 도커이고 다른 하나는 서버로서의 도커이다.
그래서 실제로 컨테이너와 이미지를 실행하고 관리하는 주체는 서버로서의 도커(도커 데몬)이고, 이 실행은 클라이언트로서의 도커로부터 api 를 입력받아 작동하게 된다. 이 API 를 사용할 수 있도록 CLI 를 제공하는것이 클라이언트로서의 도커이다. 클라이언트 도커는 CLI 명령으로 부터 /var/run/docker.sock 에 있는 유닉스 소켓을 통해 도커 데몬의 API 를 호출한다. 이 때 통신은 REST API 를 사용한다.(그렇기에 엔드포인트만 안다면 다른 주소의 도커데몬과 통신하는 것 또한 가능하다)
