도커를 공부하는 초보자를 위한 안내서 3편 - 도커 이해하기!

도커(Docker)의 정체를 알아보자.

저번 포스트에서는 컨테이너와 그 장점에 대해 공부하는 시간을 가졌습니다. 

컨테이너에 대해서 감이 잡혔다면, 이제 도커에 대해 본격적으로 공부해보도록 하겠습니다.

(https://ktcloudplatform.tistory.com/69 - 컨테이너 개념)

 

도커(Docker)는 그래서 뭐지?

<첨부 1> VM vs Docker

도커(Docker)는 무엇일까요? 많은 사람들이 '도커 = 컨테이너(Container)' 라고 생각하지만 위에서 살펴보았듯이 컨테이너 기술은 도커가 탄생하기 한참 전부터 존재헀습니다.

도커는 컨테이너 기술을 지원하는 다양한 프로젝트 중 하나일 뿐입니다. 그렇다면 도커만이 가지는 장점은 무엇이기에 이렇게 유명해 졌을까요?

 

도커는 오버레이 네트워크(Overlay Network), 유니온 파일 시스템(Union File System)등 이미 존재하고 있는 기술들을 정교하게 잘 조합하여 사용자 입장에서 정말 사용하기 편리하게 만들어 놓았습니다. 그리하여 도커는 컨테이너 기술 분야의 'De facto Standard'(사실상 업계 표준)이 될 수 있었습니다.

 

 

도커 이미지(Docker Image)

<첨부2> Docker Image

 

컨테이너라는 개념과 더불어 도커에서 가장 중요한 개념이 바로 '이미지(Image)' 입니다. 이미지는 우리가 흔히 생각하는 사진이라고 생각하시면 안됩니다. 도커에서 이미지는 컨테이너 실행에 필요한 모든 파일과 설정 값 등을 포함한 것으로 상태값을 가지지 않고 변하지 않는 것입니다.

 

'상태값'이 이해가 가지 않으면 일단 넘어가시고 전체적인 느낌을 봐주시면 됩니다. 이미지는 특정 프로세스(프로그램)을 실행하기 위한 모든, 정말 모든 파일과 설정값 등을 지닌 것으로 더 이상의 의존성(dependent) 파일을 컴파일 하거나 설치할 필요가 없습니다. redis 이미지는 redis 실행에 필요한 모든 파일을 가지고 있고, Gitlab 이미지는 centos를 기반으로 DB, Ruby, 포트정보등 필요한 모든 정보를 가지고 있습니다. 정말 이미지를 다운로드 받고(pull) 실행(run)하는것 만으로 하나의 컨테이너를 실행할 수 있습니다. 즉, 컨테이너는 '이미지를 실행한 상태' 라고 봐도 무방합니다.

 

새로운 서버가 추가되면 이것저것 설치할 필요없이 미리 만들어진 이미지를 다운로드 받고 컨테이너만 생성하면 되므로 서버 증설이 매우 용이합니다. 이러한 장점은 클라우드 환경에서 더욱 빛을 발하겠죠?

서버 사용량에 따라 클라우드 환경에서 on-demand로 서버를 증설하고 그 뒤 컨테이너를 띄우는 것만으로도 새로운 사용자를 받아들일 준비가 되는 것 입니다.

 

 

레이저(Layer) 저장방식

도커 이미지의 강력함을 조금이라도 느끼셨나요? 그런데 여기서 이런 의문이 생길 수도 있습니다. 실행에 관련 된 모든 파일을 포함하고 있다면 용량이 매우 클 것 같은데, 만약 기존 이미지에 파일하나 더 추가했다고 다시 그 큰 용량을 다운로드 받아야 하나? 그렇다면 굉장히 비효울적이지 않을까? 

 

맞습니다. 굉장히 비효율적입니다. 그래서 도커는 굉장히 영리한 저장방식을 사용합니다. 바로 'Layer 저장방식' 입니다. 레이어 저장 방식은 유니온 파일 시스템(Union File System)을 이용하여 여러개의 Layer를 하나의 파일시스템으로 만드는 방식을 의미합니다. 다음 그림을 보시면 직관적으로 이해하실 수 있을겁니다.

<첨부 3> Layer 저장방식

그림에서 살펴볼 수 있듯이, 이미지 하나는 여러개의 immutable layer로 구성됩니다. immutable의 의미는 '불변' 이라는 의미입니다. 즉 읽기 전용이지 쓰기는 되지 않는다는 것입니다. 이 immutable 레이어들은 절대로 변하지 않습니다.

 

우분투(ubuntu)의 이미지가 A, B, C 레이어로 이뤄져 있고 이미 우분투 이미지를 저장해서 가지고 있다고 가정해 보겠습니다. 우분투 이미지가 이미 있는 상태에서 우분투 기반의 nginx 이미지를 도커허브(Docker Hub)에서 가져온다면(pull) 어떻게 될까요? A+B+C+nginx 레이어로 이루어진 이미지를 통째로 가져올까요? 아닙니다. (예시를 A, B, C 레이어로 든 것이지 실제 우분투와 nginx의 컨테이너 이미지 구조와 동일하지는 않습니다.) 이 경우에는, 이미 존재하는 A+B+C 레이어는 다운로드 받지않고 새로 필요한 nignx 레이어만 다운로드 받아 새로운 이미지를 구성합니다.

 

웹 앱을 nginx 위에 올린 컨테이너를 실행하다가, 웹 앱 소스를 수정하게 된다면 A+B+C+nginx 레이어를 제외하고 소스레이어만 다운받으면 되기에 효율적으로 이미지를 관리할 수 있습니다. 또한 이미지를 공유할 때도 바뀐 레이어만 공유할 수 있는 장점을 가집니다. 제가 nginx 이미지를 pull 받아 그 위에서 웹 앱 소스를 추가하여 새로운 이미지를 생성하여 도커허브에 공유했다고 생각해 봅시다. 누군가 제가 올린 이미지가 필요한 상태이고, 이미 nginx 이미지를 저장하고 있는 상황이라면 nginx 이미지는 다운로드 받지 않고 웹 앱 레이어만 다운로드 받으면 되는 것입니다.

 

또한 이미지를 기반으로 컨테이너를 생성하게 되면 자동으로 R/W레이어가 추가되어 생성됩니다. 이미지 레이어(Immutable)를 그대로 사용하면서, 컨테이너 실행 중 생성하는 파일이나 변경사항은 모두 R/W레이어에 기록 됩니다. 기존의 이미지 레이어는 절대로 변하거나 영향을 받지 않습니다. 그래서 'Immutable', '상태값을 가지지 않고 변하지 않음' 이라는 표현을 사용하는 것입니다.

 

 

 

마무리

긴 글 읽어주셔서 감사합니다. 이미지라는 개념을 처음 접하셨다면, 아마 이해하기 힘드실 수도 있습니다. 보통 사진첩에 들어가는 이미지가 먼저 떠오르실 테니깐요...

하지만, 이 글을 읽으며 일단 핵심만 파악하셔도 앞으로 도커를 사용하는데는 큰 무리가 없으실거라 생각합니다! ^-^

 

핵심 내용을 짚어 보면서 이번 포스트 마무리 하겠습니다.

 

1.도커 이미지는 컨테이너 실행에 필요한 모든 파일과 설정 값 등을 포함한 것으로 상태값을 가지지 않고 변하지 않는 것입니다.

 

2.도커는 굉장히 영리한 저장방식을 사용합니다. 바로 'Layer 저장방식' 입니다. 이미지 하나는 여러개의 immutable layer로 구성됩니다.