[Docker #1] 도커, 뭐가 다른가

이번 클라우드 과정을 들으면서 세미 프로젝트 조원들과 도커 스터디를 하면 어떻겠느냐는 말이 나왔고, 인프런 강의를 각자 보며 정리한 내용을 이야기하면서 스터디를 진행하기로 했다.

첫 번째 장 도커의 개념 파트이다.

 

---

가상화 기술

가상화 기술은 실제로는 같은 곳(물리 자원)에 있는데 일부러 분리시켜 '별도의 공간인 것처럼' 하는 기술이다.

도커도 가상화 기술 중 하나이다.

 

가상화의 장점은

1. 서로 간의 의존성이 낮아진다.

2. 보안이 강화된다.

3. 자원을 효율적으로 사용할 수 있다.

 

가상화 이전에는 베어메탈(Bare Metal) 방식이었다.

다른 OS를 쓰고 싶어서 컴퓨터를 하나 더 사는 느낌이다.

당연히 좋지만 비싸고 효율적이지 않았다.

 

그래서 나온 기술이 가상화고 이 가상화 기술의 종류가 크게 2가지 있다.

 

지금 클라우드 과정에서 배우고 있는 방식인 하이퍼바이저 방식과

앞으로 배울 컨테이너 방식이다.

 

---

하이퍼바이저(Hyperviser)

먼저 하이퍼바이저((Hyperviser) 어원적으로 봤을 때 뭔가 Superviser 보다 한 수 위인 느낌이다.

게스트 OS의 커널이 슈퍼바이저라면 그 커널들을 관리하는 Hyperviser가 있는 것이다.

 

하이퍼바이저는 호스트의 CPU, RAM, Storage 논리적으로 분리하여 각각의 VM에게 할당해 가상화한다.

 

여기서 호스트 OS의 자원들을 사용하기 위해서는 호스트 커널에게 요청해야 시스템 콜로 자원들을 사용할 수 있다.

게스트 VM들은 각각 다양한 OS를 가질 수 있고, OS의 커널들도 각자 가진다.

각 OS마다 별도의 시스템 콜 방식이 존재한다.

여기서 하이퍼바이저가 커널 간의 통역을 해줘 구동 시킨다.

 

여기서 하이퍼바이저의 장점과 단점이 나온다.

 

장점

• 각자의 OS로 높은 보안
• 운영체제 단위의 격리로 격리성이 높음

단점

• 커널 간 통역으로 오버헤드 발생하고 느림
• OS가 포함된 VM들은 무거움

이 방식에는 VMware나 VirtualBox가 있다.

여기서 변화가 빠른 지금 개발 상황에서 무겁고 느린 이 방식보다 더 가볍고 민첩한 기술이 필요했다.

그렇게 나온게 컨테이너 방식의 가상화이다.

---

 

컨테이너 방식의 가상화

컨테이너 방식의 가상화는 리눅스 커널이 제공하는 LXC(Linux Containers)라는 기능에서 시작된다.
이는 하이퍼바이저 방식의 무거운 가상화와는 달리, 커널 자체의 격리 기능만으로도 독립된 실행 공간을 만들어낼 수 있다는 특징을 가진다.

이 격리는 리눅스 커널의 두 가지 기능에 의해 가능하다:

• Namespace: 각 컨테이너가 자기만의 공간(PID, 네트워크, 파일 시스템 등)을 가진 것처럼 보이도록 하는 기능
• CGroup(Control Group): CPU, 메모리, 네트워크, 디스크 등의 시스템 자원을 프로세스 단위로 제한 및 격리하는 기능

이처럼 커널만으로 가상화가 가능해지면서, 기존의 가상 머신(VM)과는 전혀 다른 형태의 경량 가상화가 등장하게 되었다.

 

VM vs 컨테이너

기존의 하이퍼바이저 기반 가상화는 각 VM마다 자체 운영체제와 커널을 포함하기 때문에 부팅 시간이 길고 무겁다.
하드웨어와 게스트 OS 간의 통신은 하이퍼바이저가 중재해야 하며, 이로 인해 시스템 콜과 같은 연산도 오버헤드가 크다.

반면, 컨테이너는 호스트의 커널을 공유한다.

운영체제 전체가 아닌, 실행할 애플리케이션과 라이브러리, 파일 시스템만을 담은 프로세스 단위의 격리 환경을 제공한다.
이 덕분에 부팅이 빠르고 자원 소모가 적으며, 경량화된 배포가 가능해졌다.

 

하지만 커널을 공유하기 때문에 호스트와 컨테이너가 같은 운영체제 계열이어야 한다는 제한이 있다.
또한, 커널 하나가 보안을 책임지기 때문에 보안 관점에서 VM보다 약할 수 있다.

 

왜 컨테이너가 필요했을까?

현대 소프트웨어 환경에서는 빠른 배포, 빠른 테스트, 빠른 복구가 중요하다.
VM은 느리고 무거웠고, 이 요구를 만족하기 어려웠다.

컨테이너는 이러한 문제를 해결하기 위해 등장했다.
하지만 LXC만으로는 관리 기능이 부족했고, 사용자 친화적인 인터페이스, 이미지 관리, API 기반 자동화가 필요했다.

그래서 나온 것이 Docker이다.

이런 컨테이너를 여러개 두고 하나의 커널이 이들을 실행하는 것이다.

---

 

Docker

도커는 컨테이너를 더 쉽게 만들고, 관리하고, 실행할 수 있도록 도와주는 컨테이너 플랫폼

 

도커 구성

• 컨테이너 엔진: 컨테이너를 만들고, 실행하고, 삭제하는 기능을 담당
• 컨테이너 런타임: 실제 격리된 공간을 생성하는 핵심 실행기 (runc 등, CRI 기반)
• Docker 데몬: 백그라운드에서 작동하며, API 요청을 받아 컨테이너 작업을 실행
• Docker CLI: 명령어 기반 클라이언트. 사용자의 명령을 API로 변환해 데몬에게 전달

도커 데스크탑 구성

• Docker 엔진: 리눅스 커널 위에서 실행되는 도커의 핵심 기능
• 경량화 VM: 도커 내부 리눅스 커널을 구동하기 위한 경량 VM
• Docker CLI: 명령어 기반 클라이언트

여기서 겹치는 부분은 도커 데스크탑이 리눅스가 아닌 OS에서 도커를 사용할 수 있도록 도와주는 기능을 하기 때문에 변환하는 기능까지 들어간 것이다.

 

 

컨테이너 실행 흐름

1. 사용자가 CLI로 명령어 입력 (예: docker run)
2. CLI가 이를 API로 변환해 Docker 데몬에게 요청
3. 데몬은 런타임을 통해 커널 기능(namespace, cgroups)을 사용해 격리된 환경 생성
4. 컨테이너가 실행되며, 결과가 CLI에 전달됨

컨테이너 내부 구성

컨테이너는 애플리케이션 실행 파일, 라이브러리/의존성, 그리고 리눅스 파일 시스템를 포함한다.
이 모든 것이 격리된 유저 스페이스 안에서 실행되며,
겉보기에는 마치 자신만의 운영체제를 가진 것처럼 동작한다.
하지만 실제 커널은 호스트와 공유된다.

 

이미지

이미지는 컨테이너를 실행하기 위한 압축된 실행 환경

• 유저 공간 수준의 OS
• 패키지, 라이브러리, 의존성
• 실행할 프로그램

이미지는 프로그램에 비유할 수 있고

컨테이너는 프로세스로 비유할 수 있다.

 

이미지 메타데이터

이미지에는 환경변수와 컨테이너가 실행될 때 같이 실행되는 명령어 등이 적혀있다.

컨테이너로 불러올 때 이 것들을 수정해서 만들 수 있다.

 

이미지 저장소

github 같은 개념

로컬이 아닌 원격에 저장, 관리, 배포 가능

퍼블릭/프라이빗 존재

 

---

 

마무리

가상화에 대해 알아봤고, 그걸 구현하는 방식인 하이퍼바이저, 컨테이너 방식에 대해 알아봤다.

특히 컨테이너 방식 중 하나인 도커의 이론적인 부분을 학습했다.