[Docker] 도커란, 그리고 도커 엔진의 이미지와 컨테이너

🔊 해당 포스팅은 시작하세요! 도커/쿠버네티스 서적을 읽고 개인적인 목적 하에 작성되는 글입니다. 포스팅에 사용되는 모든 자료는 제가 직접 재구성하였음을 알립니다.

이번 포스팅을 시작으로 도커와 쿠버네티스 관련 개발 서적을 통해 본격적으로 깊이 있는 공부를 시작해보려고 한다. 도커 관련해서는 이전에 생활코딩 이고잉님의 기초 강의만 공부했었고 제대로 동작 원리와 깊이 있는 공부를 하지 못했었다. 최근 컨테이너를 기반으로 하는 인프라를 구성하는 트렌드로 가게 되면서 도커와 쿠버네티스에 대한 공부를 언젠가는 해야 한다고 생각했다. 그 첫 번째 주제로 도커란 어떤 개념인지 알아보고 도커라는 컨테이너를 생성하고 관리하는 주체이자 핵심인 도커 엔진의 이미지와 컨테이너에 대해 알아본다.

 

Docker

---

1. 가상머신과 도커 컨테이너

우선 도커란, 리눅스 컨테이너에 여러 기능을 추가함으로써 어떤 애플리케이션을 컨테이너로서 좀 더 사용하기 쉽게 만들어진 오픈소스 프로젝트이다. 다른 종류의 컨테이너로는 OpenVZ, LXC, cri-o 등이 있다고 한다. 하지만 현재 개발 생태계에서는 도커가 사실상 표준으로 자리잡아 사용되고 있다. 참고로 도커는 Go언어로 작성되었다. 도커와 관련된 제품이자 프로젝트로는 도커 컴포즈, 도커 허브, 맥이나 윈도우에서 도커를 설치할 수 있는 Docker for Desktop 등 여러가지가 있다. 일반적으로 '도커'라고 하면 도커 엔진 혹은 도커와 관련된 모든 프로젝트를 의미한다. 여기서 도커 엔진이란, 도커라는 컨테이너를 생성하고 관리하는 주체로, 컨테이너를 제어하는 등 다양한 기능을 제공하는 역할을 하는 것을 의미한다. 도커 컴포즈나 도커 허브 등의 도커 관련 프로젝트들은 이 도커 엔진이라는 것을 사용하는 방법이자 수단에 불과하다. 따라서 우리가 가장 배워야할 기초이자 핵심인 부분은 바로 도커 엔진을 사용하는 방법이다.

그러면 도커라는 컨테이너가 등장하기 이전에는 어떤 것을 사용했을까? 바로 가상머신을 이용했다. 먼저 아래 그림을 보자. 아래의 그림은 하나의 물리적인 서버에 A, B라는 두개의 애플리케이션을 실행한다고 가정했을 때, 가상 머신을 이용할 때와 도커를 이용할 때의 구조 차이이다.

 

가상머신 vs 도커 컨테이너

먼저 가상 머신과 도커 둘다 물리적인 1개의 서버와 그 서버에 할당되어 있는 Host OS를 공통적으로 갖고 있다. 여기서 Host OS란, 서버를 부팅할 때 실행되는 운영체제를 의미한다.

이제 왼쪽의 가상 머신 구조부터 살펴보자. 가상 머신에서는 하이퍼바이저를 이용해서 여러개의 운영체제를 올려놓는다. 그리고 올려놓은 하나의 운영체제 당 하나의 가상머신(VM)이 할당된다. 그리고 이러한 가상머신 안에 우분투나 CentOS와 같은 운영체제들이 설치된다. 위 그림에서는 2개의 VM이 올려져 있다. 이렇게 하이퍼바이저에 의해 생성되고 관리되는 운영체제를 GuestOS 라고 한다. 이러한 각 GuestOS는 서로 완전히 독립된 공간과 시스템 자원을 할당받아 사용한다. 이러한 가상화 방식을 사용할 수 있는 툴로는 리눅스를 공부할 때 사용해보았던 VirtualBox, VMware 등이 있다. 그런데 이러한 방식을 사용하는 것은 하이퍼바이저를 반드시 거치기 때문에 일반 호스트에 비해 성능의 손실이 발생한다. 다시 말해 GuestOS들이 너무 용량이 커 무겁다는 것이다. 왜냐하면 하나의 VM 당 GuestOS를 사용하기 위한 라이브러리, 커널 등을 전부 포함하기 때문이다. 심지어 용량이 수 기가바이트(GB)까지 달하기도 한다. 만약 이러한 용량을 차지하는 GuestOS에다가 우리가 실행하고 싶은 애플리케이션 코드를 더하면 그 용량은 더 커질 것이고, 이렇게 뚱뚱해진(?) 애플리케이션을 배포하기란 부담스러운 단점이 있다.

반면에 오른쪽 그림의 도커는 전체 운영체제를 새로 설치하는 것이 아닌 단지 Host OS 위에서 프로세스 단위의 격리된 환경을 만들기 때문에 가상 머신을 사용할 때와 달리 성능 손실이 거의 없게 된다. 그러므로 컨테이너에 필요한 커널은 Host OS의 커널을 공유해 사용하고, 컨테이너 안에는 단지 애플리케이션을 실행할 때 필요한 라이브러리 및 실행 파일만 들어있기만 하면 된다. 이렇게 만들어진 컨테이너와 애플리케이션을 실행하기 위해 넣어준 여러가지 파일들을 합쳐서 하나의 '이미지(image)' 라고 한다. 참고로 가상 머신에서도 이미지라는 용어를 사용하는데, 우분투를 설치할 때 끝에 확장자가 .iso로 되어 있는 우분투 설치 프로그램도 이미지라고 한다. 어쨌건 도커는 가상 머신의 이미지와는 달리 커널을 포함하고 있지 않아(도커는 Host OS 커널을 공유하기 때문) 용량도 크지 않다. 또한 도커는 이미지 내용을 레이어 단위로 구성하며 중복되는 레이어를 재사용할 수 있다는 점도 있기 때문에 애플리케이션 배포 속도가 매우 빠르다는 장점이 있다.

그리고 도커를 사용하면 마이크로서비스 구조를 가능하게 한다. 마이크로서비스 구조와 반대 구조라고 할 수 있는 모놀리스(Monolith) 구조가 있다. 모놀리스 구조란 소프트웨어의 여러 모듈이 상호작용하는 로직을 하나의 애플리케이션(프로그램) 내에서 한 번에 구동시키는 방식을 의미한다. 소규모 서비스에는 이러한 구조가 적합할 수 있지만, 서비스가 커짐에 따라 기능도 더 많이 생기고 복잡해지면 이러한 모놀리스 구조로 만들어진 애플리케이션은 확장성과 유연성이 줄어들 가능성이 커진다. 반면에 마이크로서비스는 여러 모듈을 각각 독립시켜 언어에 종속되지 않고 변화에 빠르게 대응할 수 있으며, 각 모듈의 관리가 쉬워지게 된다. 이러한 마이크로서비스에는 컨테이너가 필수적이다. 컨테이너는 몇 초 내로 생성, 시작이 가능하며 각 모듈 간에 독립적인 환경을 제공할 수 있기 때문이다. 그리고 도커가 그러한 컨테이너 종류 중 가장 인기가 있다. 

 

모놀리스 vs 마이크로서비스 구조

 

이렇게 도커라는 컨테이너를 활용해서 만드는 마이크로서비스 구조는 개발자가 구조 자체를 직접 구현하기보다는 도커 스웜 모드, 쿠버네티스 등 같은 컨테이너 오케스트레이션 플랫폼을 통해 구현하는 것이 일반적이다.

 

지금까지 그럼 도커가 무엇이고 왜 필요한지 알아보았다. 다음 목차부터는 본격적으로 도커 엔진의 가장 기본인 이미지와 컨테이너를 다루는 방법에 대해 알아보자. 그에 앞서 마지막으로 도커 엔진을 리눅스에서 설치하는 방법에 대해 간단히 알아보자. 맥과 윈도우에서도 Docker for Desktop을 통해 설치할 수 있지만, 도커 자체가 리눅스의 기능을 기반으로 구현된 것이기 때문에 되도록 이면 리눅스에서 다루어 보는 것을 책에선 권장한다. 실제로 서비스에서 운영되는 서버는 모두 리눅스로 운용되기 때문에 리눅스에서 도커 엔진을 사용하는 것에 필자도 익숙해지려고 한다. 필자는 VirtualBox를 통해 Ubuntu 20.04를 설치했다.

 

참고로 도커도 유료 제품을 사용하면 더 많은 기능을 활용할 수 있는 EE(Enterprise Edition)이 존재한다. 무료 버젼은 CE(Community Edition)이다. CE 버전도 도커 엔진의 핵심적인 기능을 모두 담고 있기 떄문에 우리는 CE 버전을 사용할 것이다. 또한 CE 버전에서도 stable과 edge 버전으로 나뉘는데, stable 버전은 3개월 마다, edge 버전은 1개월 마다 릴리즈 되는 차이점이 있다. 하지만 1개월 마다 릴리즈되는 버전을 사용하면 신규로 나오는 기능을 빠르게 사용할 수 있긴 하지만 각종 버그가 발생할 수 있기 때문에 책 저자는 stable 버전 사용을 권장한다.

 

리눅스에서 도커를 설치하기 이전에 확인해야 할 사항이 있다. 우선 최신 버전 커널을 사용하고 있는지 확인해야 한다. 아래 명령어를 통해 확인할 수 있으며 최소한 3.10 버전 이상을 사용해야 한다.

 

$uname -r

 

그리고 사용하는 리눅스 배포판이 도커의 지원 기간 내에 있는 배포판인지 확인해야 한다. 보통 우분투 18.04, 20.04, CentOS 7 이라면 현재 지원이 되고 있다.

 

다음은 64비트 리눅스인지 확인해야 한다. 도커는 64비트에 최적화 되어 있으며 아래 명령어를 사용해 자신의 리눅스 비트가 몇인지 확인할 수 있다.

 

$ uname -m

 

마지막으로 아래 명령어를 실행해주면 된다.(우분투 20.04, 18.04 기준) 단, 아래 명령어를 sudo 권한으로 실행하거나 su 명령어 입력을 통해 root 사용자 권한으로 바꾸어준 후 실행해주어야 한다. 혹여라도 리눅스에서 슈퍼(루트) 사용자 권한에 대해 모른다면 여기를 참고해보자.

 

# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

# add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

# apt-get update

# apt-get install docker-ce

 

추가적으로, CentOS 7, RHEL7 배포판에 대해서 도커 설치 명령어는 아래와 같다.

 

$ yum install -y yum-utils
$ yum-config-manager --add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
$ yum install -y docker-ce
$ systemctl start docker

 

위 명령어로 도커를 설치할 수 있다. 이후에 아래 명령어를 실행해서 설치한 도커의 정보를 확인해보자.

 

# docker info

2. 도커 엔진의 핵심, 이미지와 컨테이너

그러면 이제 도커 엔진의 기본 단위인 이미지와 컨테이너에 대해 알아보자. 이번 포스팅에서는 도커와 컨테이너가 무엇이고 어떤 방식으로 사용되는지만 살펴보도록 하자. 자세한 사용법은 다음 포스팅부터 알아본다.

2-1. 컨테이너 생성 시 필요한 것, 이미지!

이미지는 컨테이너를 생성할 때 필요한 요소이다. 하지만 이미지를 생성할 때도 컨테이너를 필요로 한다. 이렇게 얘기하면 무슨소린가 싶다.. 그래서 이미지와 컨테이너의 관계를 한다미로 표현하면 어떻게 할 수 있을까? 생각해보았다. 상위, 하위 관계는 아니다. 왜냐하면 내가 생성한 컨테이너를 이미지로 만들 수도 있기 때문이다. 하지만 컨테이너를 최초로 생성할 때는 무조건 이미지가 선행하여 존재해야 한다. 그래서 아래처럼 관계를 도식화 할 수 있을 듯 하다.

 

이미지와 컨테이너 관계

 

최초의 컨테이너를 생성할 때만 이미지가 필요하다. 그 외 일반적인 경우에는 이미지가 컨테이너를 낳고, 그 컨테이너가 또 다른 이미지를 낳는 재귀적인 관계가 형성된다고 할 수 있다.

 

이미지는 가상 머신을 생성할 때 사용했던 확장자가 .iso인 iso 파일과 비슷한 개념이다. 이미지는 여러 계층으로 된 바이너리 파일로 존재하며 컨테이너를 생성하고 실행할 때는 이미지가 읽기 전용으로 사용된다. 도커에서 사용하는 이미지의 이름은 아래와 같은 형식으로 사용된다.

 

#형식 : [Repository name]/[image name]/[tag]

zedd_repo/ubuntu20.04/v1
younghun/python3.10/latest

 

docker images 명령어를 입력하면 생성된 이미지 목록을 출력한다

 

이미지의 이름을 나타내는 형식의 각 구성요소가 무엇을 의미하는지 하나씩 살펴보자.

 

• Repository name : 저장소라고 부르며 이미지가 저장된 장소를 의미한다. 쉽게 말하면 우리가 핸드폰에서 게임을 다운로드할 때 들어가는 앱 스토어 또는 구글 플레이 스토어 같은 곳이다. 이미지 이름 형식에서 저장소 이름이 명시되지 않은 이미지는 기본적으로 도커가 제공하는 이미지 저장소인 Docker Hub의 공식 이미지를 뜻한다. 참고로 내가 만든 컨테이너를 이미지로 생성할 때, 도커 허브에 저장시킬 이미지를 뜻하기 위해 docker.io 를 명시하면 된다. 비슷한 것으로는 구글 클라우드 컨테이너 레지스트리를 의미하는 gcr.io가 있고 깃헙 컨테이너 레지스트리인 ghcr.io 가 있다. ghcr.io 에 이미지를 생성하는 것은 일전에 포스팅한 적이 있다.
• image name : 이미지의 이름이자 이미지가 어떤 역할을 하는지 나타낸다. 예를 들어, Ubuntu, CentOS 같은 운영체제가 될 수도 있고, Python, Java, Go 같은 프로그래밍 언어 애플리케이션이 될 수도 있다.
• tag : 이미지의 버전을 뜻하며 이미지의 버전을 관리하는 즉, 리비젼 관리에 사용된다. 명시하지 않으면 도커 엔진이 자동적으로 latest 라는 키워드를 태그에 붙인다.

2-2. 독립된 환경을 제공하는 곳, 컨테이너!

다음은 컨테이너에 대해 알아보자. 컨테이너가 생성되면 생성 시에 사용한 이미지의 목적에 맞는 파일이 들어 있는 파일시스템과 격리된 시스템 자원 및 네트워크를 사용할 수 있는 독립된 공간이 생성된다. 이러한 공간이 바로 도커 컨테이너이다. 또한 컨테이너는 이미지를 읽기 전용으로 사용하되 이미지에서 변경된 사항만 컨테이너 계층에 저장하기 때문에 컨테이너에서 어떤 것을 하던지 원래 이미지에는 영향을 받지 않는다.

 

예를 들어, Ubuntu20.04 라는 이미지를 사용해서 컨테이너를 생성했고, 그 컨테이너 안에 git, python 등 필요한 라이브러리를 내가 설치했다고 한들 원본 이미지인  Ubuntu20.04에는 영향을 받지 않는다(즉, Ubuntu20.04 이미지 원본 안에 git, python이 설치되어 있지 않음) 

 

어떻게 보면 개발할 때 자주 사용하는 가상환경과 비슷한 느낌이다. 독립된 환경을 제공하는 것은 비슷하지만 가상환경과는 달리 파일시스템, 네트워크까지 더 많은 독립된 환경을 제공하는 것이 바로 컨테이너이다.

---

이렇게까지 해서 이번에는 도커라는 컨테이너 기반 인프라가 필요한 이유, 그리고 그것이 무엇인지 알아보았고 그 핵심인 도커 엔진의 기본 단위인 이미지와 컨테이너 개념에 대해 알아보았다. 다음 포스팅부터는 도커 이미지와 컨테이너를 사용하는 방법, 명령어 등에 대해 자세히 알아보도록 하자.