Docker vs Podman: Production에서 Podman을 선택한 이유

컨테이너 플랫폼에는 여러 종류가 있지만 가장 유명한 것은 역시 Docker다. Podman은 그에 비해 인지도가 낮고, 구글 트렌드에서도 큰 차이를 보인다.

그럼에도 나는 Production 환경에서 Podman을 사용하기로 했다. 그 이유를 정리한다.

Docker를 사용하며 불편했던 점

메모리

각 서버의 자원은 한정되어 있었고, 특히 메모리를 최대한 효율적으로 사용하는 것이 중요했다.

지속적으로 메모리 사용률이 높은 서버를 분석하던 중, 컨테이너 런타임인 dockerd 프로세스가 상시 메모리를 점유하는 구조임을 확인했다. 개별 사용량은 크지 않았지만 모든 노드에서 항상 실행되는 daemon 특성상 누적 오버헤드가 발생하고 있었고, 이를 제거하면 전체 자원 효율을 개선할 수 있다고 판단했다.

그래서 첫 번째 조건으로 데몬이 없는 컨테이너 플랫폼을 찾았다.

보안

dockerd는 root 권한으로 동작하기 때문에, 리소스 사용량을 넘어 보안 측면에서도 검토가 필요했다.

Docker 인증 플러그인(AuthZ Plugin)으로 dockerd에 임의의 명령을 수행할 수 없도록 제어도 해 봤지만, 그 과정이 복잡하고 설정해야 할 것이 너무 많았다. 인증 플러그인을 거치는 흐름은 다음과 같다.

[ User / CLI ]
        │
        ▼
[ docker client (CLI / API) ]
        │
        ▼
[ docker.sock (/var/run/docker.sock) ]
        │
        ▼
[ dockerd ]
        │
        ├───► [ AuthZ Plugin ]
        │         │
        │         ├─ 요청 검사 (who / what / resource)
        │         ├─ 정책 평가 (allow / deny)
        │         └─ 결과 반환
        │
        ▼
[ Container Runtime (containerd → runc) ]
        │
        ▼
[ Container 실행 ]

정리하면 내가 필요했던 것은 두 가지다.

• daemonless 구조
• rootless 기반의 보안 모델

그러다 찾은 것이 Podman이고, 마침 사용 중인 Linux 배포판 계열(Red Hat)에서 만든 도구였다.

Podman

Podman은 Red Hat에서 만든 오픈소스로, libpod 라이브러리를 사용해 컨테이너를 관리하는 도구다.

전용 데몬 없이도 Podman은 Linux 운영 체제를 위한 시스템 및 서비스 관리자인 systemd를 사용하여 업데이트하고 백그라운드에서 컨테이너를 지속적으로 실행할 수 있습니다. — Red Hat, Podman이란?

내가 원했던 두 조건을 모두 만족한다.

• 데몬이 없다.
• rootless로 설계되었다.

물론 Docker에도 rootless 모드가 있다. 하지만 Red Hat 계열을 쓰면서 Docker를 rootless로 운영하는 것보다, Red Hat이 처음부터 rootless로 만든 기술을 사용하는 편이 더 이점이 있다고 생각했다.

호환성

명령어

개발자들은 Docker에 익숙하다. docker images, docker run 같은 명령어가 더 손에 익을 텐데, 이는 podman-docker 패키지로 커버할 수 있다. docker 명령을 podman으로 alias한 것처럼 동작한다.

Compose

podman-compose는 docker-compose와 달리 Podman의 공식 내장 기능이 아니라, pip로 설치하는 별도의 Python 프로젝트다. 오케스트레이션은 Kubernetes 같은 도구로 하면 된다는 설계 방향 때문이라고 한다.

Pod

Podman은 Docker와 달리 여러 컨테이너를 pod라는 단위로 묶어 관리할 수 있다. Kubernetes의 Pod와 같은 개념이다.

전환 결과

• Docker를 Podman으로 변경한 뒤 docker.sock 관리 부담에서 벗어났고, 보안 조치해야 할 사항도 줄었다.
• 메모리 사용률도 20% 정도 낮아진 것으로 보인다.
• 개발자들은 Docker인지 Podman인지 크게 신경 쓰지 않는다. 기존 명령어가 그대로 잘 동작하기 때문이다.

다시 돌아가야 할 특별한 사정이 생기지 않는 한, 앞으로도 Podman을 쓸 것 같다.