[개념] docker이해하기(1) - 이미지와 컨테이너

 

 

공부하느라 바빠서 조금 소홀해진 내 자신을 반성하며 다시 블로그에 돌아왔다.

(사실 어떤 내용을 작성해야할지 너무 막막해서 잠깐 쉬기도 했다ㅋㅎㅋㅎ)

오늘은 이미지와 컨테이너에 대해서 조금 자세히 알아 보려고 한다.

다들 처음 로컬에서 코딩을 할 때는 별 생각이 없다가 처음으로 EC2에 테스트 배포를 하려고 할 때, 혹은 협업을 시작하려고 할 때

한 번씩은 경험해 봤을 거라고 생각한다. (제가 그랬습니다,,ㅎㅎ)

 

https://tmi-t.tistory.com/25

[AWS] Docker을 사용한 서버 배포

(여기서 배포하는 내용만 작성하고 정작 개념 설명은 없는 것 같아서 가지고 왔다.)

 

개발을 시작하고 나면 한 번쯤 이런 말을 듣게 된다.

내 컴퓨터에서는 잘 되는데요?

 

이 말이 나오는 이유는 생각보다 단순하다.
개발자마다 사용하는 운영체제, 설치된 라이브러리 버전, 실행 환경이 모두 다르기 때문이다.

누군가는 Python 3.10을 쓰고, 누군가는 3.12를 쓴다.
누군가는 Node.js 18을 쓰고, 누군가는 20을 쓴다.

이 차이만으로도 같은 프로젝트가 어떤 환경에서는 잘 실행되고, 어떤 환경에서는 오류가 나기도 한다.

Docker는 바로 이 문제를 해결하기 위해 많이 사용된다.

그리고 Docker를 이해하려면 가장 먼저 이미지(Image)와 컨테이너(Container)라는 개념을 알아야 한다.

이번 글에서는 이 두 개념을 개발을 막 시작한 사람도 이해할 수 있도록 최대한 쉽게 정리해보려고 한다.

 

 

 

Docker를 이해하기 전에

 

Docker를 처음 보면 용어가 많아서 어렵게 느껴진다.

• 이미지
• 컨테이너
• Dockerfile
• 레지스트리
• 볼륨
• Compose

하지만 사실 시작은 단순하다.
처음에는 아래 두 가지만 정확히 구분하면 된다.

• 이미지는 실행을 위한 준비물 묶음
• 컨테이너는 그 준비물을 실제로 실행한 상태

 

이제 하나씩 보자.

 

이미지(Image)란 무엇일까?

 

Docker 이미지란 애플리케이션을 실행하는 데 필요한 것들을 하나로 묶어놓은 실행 템플릿이다.

예를 들어 어떤 웹 애플리케이션을 실행하려면 이런 것들이 필요할 수 있다.

• 운영체제 기반
• Python 또는 Node.js 같은 런타임
• 라이브러리와 패키지
• 애플리케이션 코드
• 실행 명령

Docker 이미지는 이런 요소들을 묶어서 “이 환경 그대로 실행하면 된다”라고 전달할 수 있게 만든다.

쉽게 비유하면 이미지는 레시피에 가깝다.

• 어떤 재료가 필요한지 적혀 있고
• 어떤 순서로 만들어야 하는지 정리되어 있고
• 결과물이 어떤 방식으로 실행되어야 하는지도 포함되어 있다

중요한 점은 이미지는 보통 읽기 전용 템플릿처럼 다뤄진다는 것이다.
즉, 이미지는 실행의 기준이 되는 틀이고, 그 자체가 실행 중인 것은 아니다.

한 문장으로 정리하면 이렇다.

이미지는 애플리케이션 실행에 필요한 환경과 파일을 담아둔 정적인 템플릿이다.

 

 

컨테이너(Container)란 무엇일까?

 

컨테이너는 이미지를 바탕으로 실제 실행된 결과물이다.

즉, 이미지를 가지고 실행을 하면 컨테이너가 만들어진다.

여기서 초보자가 가장 많이 헷갈리는 부분이 있다.
컨테이너를 뭔가 “작은 가상 컴퓨터”처럼 생각하는 경우가 많은데, 완전히 같은 개념은 아니다.

컨테이너는 보통 격리된 프로세스로 이해하는 것이 더 정확하다.

예를 들어 하나의 프로젝트에 이런 요소가 있다고 해보자.

• 프론트엔드
• 백엔드 API
• 데이터베이스

이 3개를 각각 다른 컨테이너에서 실행할 수 있다.
그러면 각 컨테이너는 서로 분리된 환경에서 동작하고, 필요한 파일과 설정만 가지고 실행된다.

쉽게 말하면 컨테이너는 이미지를 실제로 실행한 인스턴스다.

비유로 설명하면 이렇다.

• 이미지 = 레시피
• 컨테이너 = 그 레시피로 실제 만든 음식

한 문장으로 정리하면 이렇다.

컨테이너는 이미지를 기반으로 만들어진 실행 중인 격리된 환경이다.

 

 

왜 이미지와 컨테이너를 나눌까?

 

처음에는 이런 생각이 들 수 있다.

“그냥 실행하면 되는 거 아닌가? 왜 굳이 이미지와 컨테이너를 나누지?”

이렇게 나누는 이유는 재사용성과 일관성 때문이다.

이미지가 있으면 같은 실행 환경을 여러 번 복제할 수 있다.
그리고 컨테이너는 그 이미지를 실제로 실행한 것이기 때문에, 어디서 실행하든 비슷한 결과를 기대할 수 있다.

즉, Docker는 이렇게 말하는 셈이다.

“내가 만든 애플리케이션이 어떤 환경에서 돌아가야 하는지 아예 묶어서 전달하자.”

이 접근 덕분에 다음과 같은 장점이 생긴다.

• 환경 차이로 인한 오류를 줄일 수 있다
• 팀원끼리 같은 환경을 공유하기 쉬워진다
• 배포 환경을 더 예측 가능하게 만들 수 있다
• 동일한 이미지를 기반으로 여러 서버에서 실행하기 쉽다

 

(처음으로 AI를 이용해서 개념을 이미지로 만들어본건데 이해에 도움이 되었으면 좋겠네요,,)

 

컨테이너와 VMware차이 

이제 컨테이너를 공부하다 보면 VMware랑 비슷한거 아닌가? 라고 생각할 수 있다.
여기서 정확히 말하면 VMware는 가상화를 위한 플랫폼이고, 비교 대상은 VMware 위에서 실행되는 가상머신과 컨테이너다.

둘 다 애플리케이션을 격리해서 실행한다는 공통점이 있지만, 동작 방식은 꽤 다르다.

 

	VMware 기반 가상머신(VM)	컨테이너(Container)
실행 단위	운영체제 전체를 포함한 가상 컴퓨터	애플리케이션과 필요한 의존성을 담은 격리된 프로세스
운영체제	VM마다 Guest OS가 따로 필요	호스트 OS의 커널을 공유
무게감	상대적으로 무겁다	상대적으로 가볍다
시작 속도	보통 느린 편	보통 빠른 편
리소스 사용량	CPU, 메모리 사용량이 더 큰 편	더 적은 자원으로 많이 실행 가능
격리 방식	하드웨어 수준에 가까운 강한 격리	프로세스 수준의 격리
배포 목적	OS 단위로 완전히 분리된 환경이 필요할 때	애플리케이션을 빠르게 배포하고 확장할 때
대표 사용 예	서로 다른 OS를 독립적으로 운영해야 할 때	웹 서버, API 서버, 배치 작업 등을 빠르게 배포할 때

 

쉽게 비유하면 이렇다.

• 가상머신은 집을 통째로 여러 채 짓는 방식 
• 컨테이너는 같은 건물 안에서 방을 나눠 쓰는 방식 

가상머신은 각자 운영체제를 포함하고 있어서 더 무겁지만, 그만큼 더 강하게 분리된다.
반면 컨테이너는 운영체제를 통째로 들고 다니지 않고 필요한 실행 환경만 담아서 훨씬 가볍고 빠르게 실행된다.

그래서 최근 애플리케이션 배포에서는 컨테이너가 많이 사용되지만, 운영체제 자체를 완전히 분리해야 하거나 강한 격리가 필요한 경우에는 여전히 가상머신이 유용하다.