docker 와 podman

Docker 와 Podman, 둘의 차이의 핵심은
아키텍처(데몬의 유/무) 이다.

 

Docker 와 Podman 등장

클라우드와 컨테이너 시장이 폭발적으로 성장하게 된 배경에는 Docker의 등장이 있습니다.

 

도커 이전에도 컨테이너 기술은 존재했지만,
도커는 이를 쉽게 빌드·배포·실행할 수 있는 형태로 패키징하면서:

• 개발자가 로컬에서 컨테이너 이미지 빌드
• 테스트 환경에 그대로 배포
• 운영 환경에서도 동일한 이미지 그대로 실행

이라는 흐름을 만들었고,
덕분에 “한 번 만든 이미지를 어디서나 똑같이 돌리는” 문화가 자리 잡았습니다.

그래서 여전히 많은 분들이

“컨테이너 = 도커(Docker)”

 

를 가장 먼저 떠올립니다.

 

하지만 이제는 단일 Docker 호스트가 아니라,
쿠버네티스(Kubernetes)를 중심으로 한 오케스트레이션 환경이 사실상 표준이 되었습니다.

여기서 한 번쯤 이런 질문을 던져볼 수 있습니다.

“쿠버네티스를 운영하는 지금도,
도커만 쓰는 게 최선일까?”

 

최근 몇 년 사이에는 도커의 대안으로 파드맨(Podman) 이 급부상하고 있습니다.

 

Docker vs Podman

도커와 파드맨 두 도구는 표면적으로 90%는 똑같습니다.

 

명령어 구조가 비슷함에 기존 스크립트를 그대로 사용하기 위해

alias docker=podman

이렇게 설정하여 사용하는 사람도 있을 정도입니다.

 

두 도구의 명령어 형태는 아래와 같습니다.

# Docker
docker run ...
docker ps
docker logs ...

# Podman
podman run ...
podman ps
podman logs ...

 

이렇듯 비슷해보이나, 내부 구조(아키텍처)는 완전히 다른 철학을 가지고 있고, 이 차이가 운영 환경에서 어떤 런타임을 쓸지 결정할 때 매우 중요한 포인트가 됩니다.

 

데몬의 유무

Docker 는

잘 알려진 것과 같이 client-server 구조로 중심에 dockerd 데몬을 항상 띄워둡니다.

백그라운드에서 항상 떠있으면서 docker run, docker ps 등의 명령 뿐만 아니라 컨테이너의 생성, 유지, 삭제 등 데몬을 중심으로 도커와 관련된 모든 작업이 이루어 집니다.

 

이는 개발, 빌드, 배포(운영)까지 직관적으로 봤을 때 매우 편리한 구조를 가지지만, 동시에 단점도 가지고 있습니다.

 

1. SPOF(Single Point of Failure)

말 그대로, 중심부에 dockerd 데몬으로 api 통신을 하며 컨테이너들을 관리하기 때문에 dockerd 데몬이 죽어버리면 그 데몬이 관리하던 컨테이너 전체에 영향을 줍니다.

 

2. root 권한 보안 리스크

dockerd 는 전통적으로 root 권한으로 실행되어, 보안의 이슈가 있습니다.

 

3. 리소스 문제

dockerd 데몬이 백그라운드에서 항상 상주하고 있다라는 말은 곧 리소스(메모리)를 상시 점유한다는 말과 같습니다.

나 혼자 사용하는 서버라면 크게 문제가 되지 않지만 여러 애플리케이션이 운영 중인 환경이라면 문제를 야기할 수도 있습니다.

 

Podman 은

도커와 달리 별도의 중앙 데몬 없이(Daemonless) 동작합니다.

사용자가 명령을 날리면 그 때 그 때 마다 필요한 프로세스가 직접 리눅스 커널에 시스템 콜(fork-exec 방식 등) 을 날려 컨테이너를 띄우고, 각각 독립된 프로세스로 실행 및 운영됩니다.

 

1. docker 와 달리 일반 사용자 계정으로 컨테이너를 돌리는 rootless 가 기본 시나리오 입니다.

 

2. 필요할 때만 프로세스를 실행시키므로 리소스가 효율적으로 운영됩니다.

 

3. podman = pod manager 이란 이름으로, 쿠버네티스의 기본 단위인 pod 개념을 native 로 지원하며 로컬 pod 구성 과 kubernetes yaml 을 쉽게 오갈 수 있습니다.