[Podman] Deep Dive 0편: Podmman 아키텍처

Deep Dive를 시작하며

최근 Podman에 기여할 기회가 있었다.
작업을 진행하면서 단순히 코드를 수정하는 것보다, 그 코드가 Podman 전체 구조 안에서 어떤 위치에 있는지 이해하는 과정이 더 중요하다는 것을 느꼈다. 그래서 이번 시리즈에서는 내가 기여했던 이슈와 PR을 바로 소개하기보다는, 그 전에 이해해야 했던 Podman의 내부 아키텍처와 코드베이스 흐름을 먼저 정리해보려고 한다.

 

이 시리즈를 통해 Podman이 명령을 어떻게 처리하는지, local과 remote 실행 경로가 어떻게 나뉘는지, 그리고 특정 기능을 수정할 때 어느 계층을 봐야 하는지 코드 레벨에서 따라가 볼 예정이다. 나중에는 실제로 내가 기여했던 이슈와 PR 과정, 구현 방향, 리뷰를 받으며 고민했던 점들도 따로 정리할 생각이다. 혹시 이 글을 읽는 사람 중 큰 오픈소스 프로젝트에 기여해보고 싶은 사람이 있다면, 이 시리즈가 코드베이스를 이해하는데 도움이 되었으면 한다.

Podman 과 Docker의 차이

Podman은 널리 알려진 Docker와 유사하게 컨테이너를 생성하고 관리할 수 있는 오픈소스 도구다.

Docker는 일반적으로 root 권한으로 실행되는 Docker daemon을 중심으로 컨테이너를 관리한다. 사용자는 Docker CLI를 통해 daemon에 요청을 보내고, daemon이 컨테이너 생성, 실행, 삭제 같은 작업을 수행한다.

 

반면 Podman은 daemonless 구조를 지향하며, root 권한 없이 컨테이너를 실행할 수 있는 rootless 사용성을 중요한 특징으로 내세운다. 개인적으로 Podman이 처음 주목받은 이유도 이 지점에 있다고 생각한다. 보안에 민감한 환경에서는 컨테이너 관리 작업이 root 권한으로 수행되는 구조에 부담을 느낄 수 있기 때문이다.

📝 NOTE: 최근에는 Docker에서도 Rootless 실행을 지원한다.
Docker Rootless mode 문서

Podman 아키텍처

실제로 Podman은 내부에서 어떤 구조로 동작할까?

이 시리즈에서는 Podman을 단순히 사용하는 방법보다, 하나의 명령이 어떤 계층을 거쳐 처리되는지에 이야기 하려고 한다.

먼저 Podman의 큰 실행 흐름은 간략하게 다음과 같다.

User
  ↓
podman CLI
  ↓
cmd/podman
  ↓
pkg/domain
  ↓
ContainerEngine interface
  ├─ local: ABI Engine
  │    ↓
  │   libpod
  │    ├─ containers/storage
  │    ├─ containers/image
  │    ├─ network: netavark / aardvark-dns
  │    ├─ conmon
  │    ↓
  │   OCI runtime: crun / runc
  │    ↓
  │   container process
  │
  └─ remote: Tunnel Engine
       ↓
      pkg/bindings
       ↓
      Podman REST API
       ↓
      podman system service
       ↓
      pkg/api handlers
       ↓
      pkg/domain / ABI Engine
       ↓
      libpod
       ↓
      conmon
       ↓
      OCI runtime
       ↓
      container process

Podman에 사용자가 입력한 명령은 CLI 계층에서 시작해 pkg/domain의 ContainerEngine 인터페이스를 지나고, 실행 방식에 따라 local 또는 remote로 나뉜다.

local에서는 ABI Engine이 libpod를 직접 호출한다. 반면 remote에서는 Tunnel Engine이 pkg/bindings를 통해 Podman REST API에 요청을 보내고, 서버 쪽의 podman system service가 다시 API handler와 ABI Engine을 거쳐 libpod로 들어간다.

이 점을 보면 podman 명령이라도 local에서 실행하는지 remote에서 실행하는지에 따라 경로가 다르다는 것을 알 수 있다.

정리

이번 0편에서는 아주 대략적인 Podman 아키텍처에 대해서만 다루고 1편에서 podman run 명령어를 실행했을 때 내부적으로 일어나는 작업에 대해서 Step-by-Step으로 파일을 따라가면서 설명해보고자 한다.

💡 TIP: 일반적으로 봐야 하는 폴더 및 파일은 아래와 같다.

• cmd/podman: 사용자가 실행하는 podman run, podman ps, podman rm 같은 명령어가 파싱된다.
• pkg/domain: cmd와 실제 backend를 연결하는 중간 다리다.
• pkg/domain/entities: option, report, interface 등 CLI와 engine 사이에서 주고받는 타입들이 정의되는 곳이다.
• pkg/domain/infra/abi: local mode에서 사용하는 ABI Engine 구현이 위치한다.
• pkg/domain/infra/tunnel: remote mode에서 사용하는 Tunnel Engine 구현이 위치한다.
• pkg/bindings: remote client가 Podman REST API를 호출하기 위한 Go bindings가 위치한다.
• pkg/api: podman system service 쪽 API handler가 위치한다.
• libpod: 컨테이너와 Pod 생명주기를 관리하는 라이브러리다.