MapleStory Finger Point

01. 가상화

컨테이너에 알아보기에 앞서 가상화 기반으로 진행되기 때문에, 가상화에 대해 먼저 알아보자.

좀 추상적인 개념이지만 한번 얕게라도 생각해보자면 ...

 

기업 입장에서는 하드웨어를 가진 서버, 스토리지, 네트워크, 애플리케이션 등 자원 배치 라던가, 리소스 관리를

효율적으로 사용해야 하며 장애 발생 시 빠른 대응, 빠른 재해 복구가 필수적이다.

 

그래서 결국 효율적인 자원 관리, 자동화, 재해 복구 등 장점을 극대화 하기 위해 하드웨어가 아닌 가상화 기술을

도입하여 물리적 하드웨어 유지 보수 대신에 소프트웨어적으로 추상화된 가상화를 통해 쉽게 유지보수를 할 수 있다.

 

1-1. 가상화 종류

 

💁‍♂️ Virtual Machine 가상화

  • VM 가상화에서 사용하는 이미지 기술을 OVF 라고 부른다.

쉽게 말해 하나의 HostOS (물리적 하드웨어) 위에서 여러개의 하드웨어 (GuestOS)를 실행하는 기술이다.

즉, HostOS에 별도의 GuestOS를 설치하여 하드웨어를 가상화 하는 기술이며, GuestOS는 별도의 독립적인 Kernel를 가지고 있다.

 

💁‍♂️ Container 가상화

  • 컨테이너 가상화에서 사용하는 이미지 기술을 OCI 라고 부른다.

VM 가상화에 비해 경량이면서 HostOS의 Kernel을 공유하는 OS 수준의 가상화를 구현한다.

즉, Kernel이 없기 때문에 하드웨어 수준의 가상화가 필요 없다.

 

요약을 하자면!

  1. VM 가상화의 장점은 물리적인 자원들을 가상화된 형태로 GuestOS에 리소스를 나눠서 할당하여 사용한다.
  2. Container 가상화의 장점은 이미지가 경량이므로 원하는 Application 환경을 빠르게 패키징을 할 수 있다.

 

02. 컨테이너화 기술

리눅스 컨테이너 기술은 LXC(Linux Container)를 이용한 시스템 컨테이너화로 시작했다.

  • 위에서 언급했던 대로, OS 수준의 가상화 도구
  • cgroup, namespace 등의 Kernel 기술을 공유하여 Container에 제공한다.

이후 점차 기술이 발전되면서, LXC를 기반으로 컨테이너 기반의 Docker 기술이 출시가 되었고,

초기 Docker는 LXC를 활용해 컨테이너를 생성하는 엔진 도구였으나!!

Docker가 모듈화가 되면서 Docker 데몬, Docker API, Docker CLI로 발전 하였다.

 

 

🐳 Docker 엔진 발전 개요

1. 초기 Docker (2013년 ~ 2015년 무렵)

  • Docker가 처음 공개될 때는 LXC(Linux Containers) 기반으로 동작했음.
  • 즉, Docker 엔진 = Docker 데몬(dockerd)이 직접 LXC를 호출해서 컨테이너를 실행.
  • 문제: LXC에 의존적이라 기능 확장성이 부족하고, 운영체제별 이식성도 낮음.

2. libcontainer (2014년 이후)

  • Docker 팀이 직접 만든 libcontainer 라이브러리를 도입.
  • 더 이상 LXC에 의존하지 않고, Docker 자체가 리눅스 커널 기능(cgroups, namespaces 등)을 직접 다룸.
  • Docker 엔진 구조: Docker CLI → Docker Daemon(dockerd) → libcontainer → 커널

3. Docker 엔진 단일 구조의 한계

  • dockerd 하나가 CLI API 서버 역할, 이미지, 네트워크, 볼륨, 실제 컨테이너 실행 관리 까지 모든걸 다 처리.
  • 문제: 구조가 모놀리식(Monolithic)이라 유지보수와 표준화에 한계.

4. containerd 등장 (2016년)

  • Docker 프로젝트에서 containerd라는 별도 컴포넌트 분리.
  • 역할: 컨테이너 실행 및 관리에 집중 (low-level runtime)
  • 이제 구조는 이렇게 나눔: Docker CLI → dockerd → containerd → runc → 커널
  • 여기서 runc는 OCI(Open Container Initiative) 런타임 규격을 구현한 실행기.
  • 즉, containerd는 컨테이너를 관리하고, runc는 실제 실행을 담당.

5. OCI(2015~2017) 표준화

  • Docker, CoreOS, Google 등이 모여 OCI(Open Container Initiative) 표준을 만듦.
    • OCI Image Spec: 컨테이너 이미지 규격
    • OCI Runtime Spec: 컨테이너 실행 방식 규격
  • runc는 이 OCI Runtime Spec의 레퍼런스 구현체.
  • 따라서 containerd + runc 조합이 표준 기반 컨테이너 실행의 기본이 됨.

6. 오늘날 Docker 엔진 구조 (2017년 ~ 현재)

Dockerd 기능

  • 현대 Docker는 이렇게 나눠짐:
    • Docker CLI (docker 명령어): 유저 인터페이스
    • dockerd (Docker Daemon): 고수준 API, 이미지 관리, 빌드 등
    • containerd: 컨테이너 라이프사이클 관리 (시작, 중지, 삭제 등)
    • runc: 실제 컨테이너 실행기 (OCI 런타임)
  • dockerd는 사실상 "관리자"이고, 실제 실행은 containerd + runc가 맡음.

 

이상 가상화부터 시작해서, Docker에 이르기 까지 개요를 한번 알아보는 시간이였습니다

감사합니다!

티스토리툴바