[Docker] 예시로 보는 이미지와 컨테이너

컨테이너와 이미지

도커 구조와 인프라에서 아래와 같이 컨테이너, 이미지를 설명한 적이 있다. 사실 도커에서 핵심이 되는 부분이 컨테이너, 이미지 이기 때문에 따로 문서로 남기게 되었다.

• 도커 객체
  • 이미지 이미지는 컨테이너 생성 지침이 포함된 읽기 전용 템플릿이다. 컨테이너 생성 정보들을 작성하고, 이를 통해 빌드 및 컨테이너 생성이 가능하다. 만약 고유한 이미지를 생성하려면, Dockerfile을 만들어서 직접 설정 할 수 있고, 수정사항이 있어 수정하고 이미지를 다시 빌드하면, 변경된 부분만 다시 빌드되어서 가볍고 빠르게 수행합니다.
  • 컨테이너 컨테이너는 이미지에서 설정한 내용을 통한 실행가능한 인스턴스이다. 컨테이너를 하나 이상의 네트워크에 연결하거나, 컨테이너에 스토리지를 연결하거나, 현재 상태를 기반으로 새 이미지를 생성할 수 있다. 각 컨테이너는 호스트 시스템과 다른 컨테이너와 격리되어있기 때문에 제어하기에도 편하고 취약성이 별로 없다.

문제는 해당 설명을 들어도 한번에 이해하기 어렵다는 것이다. 특히, 이미지가 읽기 전용 템플릿이라는 점, 컨테이너와 이미지의 차이 등 이 둘의 기능이 무엇인지 예시를 들어서 설명하고자 한다.

예시

컨테이너

컨테이너… 한국어로 “그릇”,”통”이라는 의미로도 해석이 가능하다. 해당 의미를 이용해 배달음식에 비유해서 설명하겠다. (지금 배가 고프다..)

최근엔 일회 용품을 사용하는 곳이 많지만, 옛날만 해도 중국집과 같은 곳에서는 그릇에 포장해서 배달해준다. 해당 그릇은 한 번 배달된 이후에 다시 수거해가서 다른 배달에도 쓰이는데, 컨테이너도 이와 같다. 배달을 할 때, 주로 소비자가 무엇을 먹을지에 따라서 그릇에 담기는 내용물도 다르다. 만약 사용자가 짜장면을 원하는 경우, 해당 그릇에는 짜장면이 담기고, 짬뽕을 원하는 경우에는 짬뽕을 넣는다. 이렇게 짜장면, 짬뽕처럼, 프로그램의 목적(소비자의 요구사항)에 따라서 개발자(요리사)가 해당 내용을 정해서 넣게 된다. 이렇게 담긴 음식은 결과적으로 소비자(서비스 이용자)에게 제공된다.

정리하면 컨테이너는 짜장면 그릇이고, 요리사는 개발자이다.

배달이 요청, 요리사가 짜장면을 짜장면 그릇에 담고 배달원에게 건네준다.

요리사 = 개발자
짜장면 그릇 = 컨테이너
짜장면 = 프로그램
배달 = 배포

자 여기까지 읽다보면 컨테이너는 배포하기(배달하기) 전 프로그램을 담는 프레임이라고 생각 할 수 있다. 이를 배달(배포)하면 소비자는 해당 음식을 먹는다.(실행한다)

즉 컨테이너는 작성한 프로그램을 실행 하는 객체이다.

비유로 따르면 짜장면 그릇이다. 그릇이 없으면 짜장면 배달도 소비자가 먹지도 못하기 때문에 어떻게 보면 실행하는 객체라는 표현이 적절하다고 생각된다.

이미지

이미지는 위에서 비유한 과정에서 요리를 그릇에 담을 때 어떤 그릇에 담을 것인가에 중점을 둔다. 만약 메뉴 중에 짬짜면이라는 메뉴가 있다고 하자. 짬짜면은 짬뽕과 짜장면을 한 그릇에 담게 된다. 일반적인 그릇과 다르기 때문에 이 그릇은 짬짜면 이외에 쓰일 곳이 별로 없다.

짜장면, 짬뽕도 마찬가지이다. 짬뽕은 짜장면과 달리 국물이 있기 때문에 깊이가 있는 그릇을 사용한다. 짜장면도 소스가 있지만, 면이 주가 되기 때문에 그릇이 넓게 퍼져있는 경우가 많다.

이미지는 메뉴 어떤 모양의 그릇에 담을까와 관련이 있다. 예를 들어, 짬짜면이 없던 시절 어떤 요리사가 짜장과 짬뽕을 같이 담은 짬짜면이라는 메뉴를 개발했다고 하자. 이때 짬짜면을 기존 그릇에 담는 경우 문제가 생긴다. (짬뽕 국물과 짜장소스가 버무려진…짬짜면처럼..) 이런 경우, 요리사는 처음에 각 메뉴를 다른 그릇에 담아서 배달하면 문제는 없지만, 그만큼 설거지 거리도 늘어나고, 비 효율적이라는 생각을 하게 된다.

또한, 다른 그릇에 담아서 배달하는 경우 기존 짜장, 짬뽕을 단일 메뉴로 시키는 것 보다 상품적 이미지가 살지 않는다.

“짜장과 짬뽕을 같은 그릇에 두어야 하는데… 가운데 벽이 있는 만든 그릇을 만들면 섞이지도 않고, 그릇 하나만 설거지하면 되기 때문에 이득이네?”

라고 생각한 요리사는 해당 설계를 간단히 그려서 그릇 공장에 의뢰한다. 이때 이미지는 해당 설계 그림과 같다. 요리(프로그램)을 잘 담을 그릇(컨테이너)를 만들 수 있는 설계 그림인 것이다.

즉, 이미지는 그릇(컨테이너)을 만들 설계도면이다.

하지만, 이렇게 짬짜면 처럼 특수한 메뉴가 아닌 이상 일반적으로 기존에 있는 그릇을 사용하게 될 것이다. 해당 요리를 담을 일반 적인 그릇(컨테이너)에 해당하는 것들은 도커 허브를 통해서 제공되고 있고, 짬짜면 처럼 프로그램에 따라서 컨테이너를 다르게 해야하는 경우 직접 이미지를 구성해서 컨테이너를 생성해야한다. 그 외에 해당 그릇이 어떤 역할을 할지 정할 수도 있다. 주전자 처럼 만들 수 있고, 병처럼 만들어서 내용물을 어떻게 먹을 지(실행할지) 명세하기도 한다. 더 세부적으로 살피면 해당 컨테이너가 실행될 때 필요한 의존성 라이브러리, 설정, 환경 변수 등등을 이미지에서 관리하게 된다.

당연한 이야기지만 설계도면에서 짜장면을 먹을 수는 없다…. 즉! 실제 프로그램을 담는 곳은 컨테이너라는 사실을 잊지 말자.

도커에서 컨테이너 이미지가 가지는 의미

도커의 가장 좋은 장점은 설명했듯이 OS에 구애하지 않고 실행가능 하다는 것이다. 그렇기 때문에 불변 인프라 방식으로 하더라도 빠르게 가능하다. 해당 배포 방식에 있어서 OS환경에 상관없이 하기 위해서 컨테이너, 이미지가 필요하다. 이미지를 통해서 어느 환경에서든 배포할 수 있고, 이미지에 작성된 내용을 통해 구성된 컨테이너를 실행시킨다. 이 두가지 구성 요소가 도커의 핵심 기능을 제공한다고 봐도 될거 같다.

요약

환경을 구성하는 이미지를 만들어 두면 해당 이미지를 토대로 각각 내용이 다른 컨테이너를 만들 수 있다. 해당 컨테이너를 통해 다양한 환경을 구성할 수 있고, 해당 환경은 각각 독립적이고 가볍기 때문에 개발하기에 좋다.