팟맨

팟맨은 루트리스(rootless)와 루트풀(rootful) 두 가지 모드로 컨테이너를 실행할 수 있다. 이는 팟맨의 핵심 보안 설계 철학을 반영한다. 루트리스 모드는 일반 사용자 권한으로 컨테이너를 실행하는 방식이다. 이 모드에서는 컨테이너 엔진이 루트(root) 권한을 갖는 데몬 없이 동작하며, 사용자 자신의 사용자 ID와 그룹 ID를 컨테이너 내부에 매핑한다. 이로 인해 컨테이너 프로세스가 호스트 시스템의 루트 권한을 획득할 수 없어, 보안 위협이 발생하더라도 그 영향이 해당 사용자 권한으로 제한된다.

반면 루트풀 모드는 전통적인 도커와 유사하게 루트 데몬을 통해 컨테이너를 실행하는 방식이다. 이 모드는 호스트 시스템의 루트 권한이 필요한 특정 작업이나 네트워크 포트 바인딩(1024번 이하) 등 특수한 경우에 사용된다. 하지만 루트풀 모드는 데몬에 대한 공격 표면이 존재할 수 있어, 팟맨은 기본적으로 보다 안전한 루트리스 모드 사용을 권장한다.

루트리스 모드의 구현은 user namespace, shadow-utils 패키지의 newuidmap 및 newgidmap 명령어와 같은 리눅스 커널 기능에 의존한다. 이를 통해 사용자는 호스트에서의 실제 UID(User ID)/GID(Group ID)와 컨테이너 내부의 가상 UID/GID를 분리하여 매핑할 수 있다. 결과적으로 팟맨은 중앙 데몬 없이도 완전한 컨테이너 생명 주기 관리가 가능한 데몬리스 아키텍처를 실현한다.

팟맨은 도커와 높은 수준의 명령어 및 API 호환성을 제공한다. 이는 기존에 도커를 사용하던 사용자나 시스템이 큰 학습 곡선 없이 팟맨으로 전환할 수 있도록 설계된 핵심 특징이다. 사용자는 docker 명령어 대신 podman 명령어를 사용하는 것만으로도 대부분의 컨테이너 작업을 동일하게 수행할 수 있다. 예를 들어, docker run 대신 podman run을, docker ps 대신 podman ps를 사용할 수 있다. 이러한 호환성은 레드햇이 개발한 libpod 라이브러리를 통해 구현된다.

이 호환성은 단순한 명령어 수준을 넘어 도커 데몬에 의존하는 도커의 클라이언트-서버 아키텍처와 달리, 팟맨은 데몬리스 아키텍처를 채택했다는 점에서 차이가 있다. 즉, 팟맨은 별도의 중앙 데몬 프로세스 없이 사용자 세션에서 직접 컨테이너를 실행하고 관리한다. 그럼에도 불구하고 팟맨은 도커의 REST API와 호환되는 API를 제공하여, 쿠버네티스나 지속적 통합/지속적 배포 파이프라인과 같이 도커 API에 의존하는 도구들과의 연동을 가능하게 한다.

이러한 높은 호환성 덕분에 팟맨은 많은 환경에서 도커의 직접적인 대체제로 사용된다. 사용자는 alias docker=podman과 같은 별칭을 설정하여 기존 스크립트나 작업 흐름을 변경하지 않고도 팟맨의 이점을 활용할 수 있다. 이는 보안 강화, 루트리스 컨테이너 지원, 시스템 자원 관리의 단순화 등 팟맨의 장점을 도입하는 진입 장벽을 크게 낮춘다.

팟맨의 가장 큰 특징 중 하나는 데몬리스 아키텍처를 채택하고 있다는 점이다. 이는 팟맨이 중앙 데몬 프로세스 없이도 컨테이너를 생성하고 관리할 수 있음을 의미한다. 사용자가 podman run과 같은 명령을 실행하면 팟맨은 직접 자식 프로세스를 포크하여 컨테이너를 시작한다. 이 방식은 전통적인 클라이언트-서버 모델을 따르는 도커와 근본적으로 다른 접근법이다.

데몬리스 설계는 보안과 격리 측면에서 상당한 이점을 제공한다. 루트 권한을 가진 중앙 데몬이 존재하지 않기 때문에, 만약 팟맨 프로세스 자체가 공격을 받더라도 그 영향이 시스템 전체로 확장될 위험이 줄어든다. 각 컨테이너는 실행한 사용자의 권한으로 격리되어 동작하며, 이는 보안 취약점의 공격 표면을 최소화한다. 또한, systemd와 같은 init 시스템을 통해 컨테이너를 서비스로 직접 관리할 수 있어 운영상의 유연성을 높인다.

이러한 아키텍처는 사용자 경험에서도 차이를 만든다. 도커는 dockerd 데몬이 실행 중이어야 명령을 처리할 수 있지만, 팟맨은 별도의 백그라운드 서비스 의존 없이 즉시 명령을 실행한다. 결과적으로 시스템 리소스 사용이 더 효율적이며, 데몬 중단으로 인한 관리 문제가 발생하지 않는다. 팟맨의 이러한 설계 철학은 리눅스 커널의 cgroups와 네임스페이스 같은 기본 컨테이너 기술을 보다 직접적이고 간결하게 활용하는 데 기반을 두고 있다.

팟맨의 핵심 기능 중 하나는 포드라는 개념을 중심으로 한 컨테이너 그룹 관리이다. 포드는 쿠버네티스에서 유래한 개념으로, 하나 이상의 컨테이너가 공유 네임스페이스와 스토리지를 사용하며 함께 배포되고 관리되는 최소 단위이다. 팟맨은 도커와 달리 포드를 일급 객체로 직접 생성하고 관리할 수 있어, 쿠버네티스 환경과의 일관된 워크플로우를 제공한다.

사용자는 podman pod create 명령어로 포드를 생성한 후, podman run --pod <포드명> 명령어를 통해 해당 포드에 컨테이너를 추가할 수 있다. 이를 통해 같은 포드 내의 컨테이너들은 localhost를 통해 서로 통신할 수 있으며, 공유된 볼륨에 데이터를 저장할 수 있다. 포드의 상태는 podman pod ps로 확인하고, podman pod stop 또는 podman pod rm 명령어로 전체 포드를 한 번에 중지하거나 삭제할 수 있다.

이러한 포드 중심의 설계는 특히 마이크로서비스 애플리케이션을 개발하고 테스트할 때 유용하다. 예를 들어, 웹 애플리케이션, 데이터베이스, 캐시 서버 등 서로 밀접하게 연관된 여러 컨테이너를 하나의 포드로 묶어 관리함으로써, 배포와 네트워킹을 단순화할 수 있다. 이는 최종적으로 애플리케이션을 쿠버네티스나 오픈시프트와 같은 오케스트레이션 플랫폼에 배포하기 위한 사전 단계로서 자연스러운 이행을 가능하게 한다.

libpod 라이브러리는 팟맨의 핵심 엔진으로, 컨테이너, 포드, 이미지, 볼륨의 수명 주기를 관리하는 기능을 제공한다. 이 라이브러리는 고 프로그래밍 언어로 작성되었으며, 팟맨의 모든 명령줄 기능과 API의 기반이 된다. libpod는 팟맨이 루트리스 모드로 안전하게 실행될 수 있는 아키텍처적 토대를 마련한다.

이 라이브러리의 중요한 특징 중 하나는 도커 API와의 호환성을 제공한다는 점이다. 이를 통해 기존에 도커 엔진을 위해 작성된 도구나 스크립트를 큰 수정 없이 팟맨과 함께 사용할 수 있다. libpod는 레드햇에 의해 주도적으로 개발되며, 오픈 소스 프로젝트로서 아파치 라이선스 2.0 하에 배포된다.

libpod 라이브러리는 팟맨을 단순한 명령줄 도구를 넘어 다른 애플리케이션에 통합 가능한 구성 요소로 만든다. 이를 통해 개발자는 팟맨의 강력한 컨테이너 관리 기능을 자신의 소프트웨어에 직접 활용할 수 있다. 이 라이브러리의 존재는 팟맨의 모듈화된 설계와 확장성을 보여주는 대표적인 사례이다.

Podman Desktop은 Podman의 공식 GUI 애플리케이션이다. 주로 레드햇이 주도하는 오픈소스 프로젝트로, 도커 데스크톱의 대안으로 개발되었다. 이 애플리케이션은 컨테이너, 이미지, 포드 및 볼륨을 시각적으로 관리할 수 있는 통합 환경을 제공하며, 리눅스, 윈도우, macOS 운영 체제에서 모두 사용할 수 있다.

주요 기능으로는 로컬 및 원격 Podman 엔진 관리, 컨테이너와 이미지의 생성/실행/모니터링, Docker Compose 파일 호환 지원 등이 있다. 또한 쿠버네티스 YAML 매니페스트 생성 및 배포 기능을 내장하고 있어, 개발자에게 친숙한 데스크톱 환경에서 컨테이너 기반 애플리케이션의 전체 수명 주기를 관리할 수 있게 한다.

팟맨은 기본적으로 리눅스 커널의 컨테이너 기술을 활용하도록 설계된 도구이다. 리눅스의 cgroups와 리눅스 네임스페이스 같은 핵심 기능을 기반으로 컨테이너를 생성하고 관리한다. 따라서 팟맨은 레드햇 엔터프라이즈 리눅스, 페도라, 우분투, 센트OS 등 대부분의 주요 리눅스 배포판에서 네이티브하게 실행된다.

리눅스 환경에서 팟맨의 가장 큰 장점은 루트리스 모드를 완벽하게 지원한다는 점이다. 이는 일반 사용자 권한으로도 컨테이너를 실행하고 관리할 수 있음을 의미하며, 이는 보안과 사용 편의성 측면에서 중요한 특징이다. 또한 systemd와의 통합을 통해 컨테이너를 시스템 서비스로 관리할 수 있어, 운영 체제 수준의 효율적인 관리를 가능하게 한다.

대부분의 리눅스 배포판은 공식 패키지 저장소를 통해 팟맨을 제공한다. 예를 들어, 레드햇 계열 배포판에서는 dnf install podman 명령어로, 데비안 계열 배포판에서는 apt install podman 명령어로 간편하게 설치할 수 있다. 설치 후에는 별도의 데몬을 실행할 필요 없이 즉시 명령줄 도구를 사용할 수 있다.

macOS와 윈도우 운영 체제에서는 팟맨을 네이티브로 실행할 수 없다. 이는 팟맨의 핵심이 리눅스 커널의 cgroups 및 리눅스 네임스페이스와 같은 기능에 의존하기 때문이다. 따라서 macOS나 윈도우에서 팟맨을 사용하려면 리눅스 커널 환경을 제공하는 가상 머신을 통해 간접적으로 실행해야 한다.

이를 위해 팟맨 프로젝트는 Podman Machine이라는 도구를 제공한다. 이 도구는 사용자 대신 가상 머신을 자동으로 프로비저닝하고 관리한다. macOS에서는 하이퍼바이저로 하이퍼키트나 QEMU를, 윈도우에서는 WSL2 또는 QEMU를 백엔드로 사용하여 리눅스 가상 머신을 생성한다. 사용자는 팟맨 클라이언트 명령어를 로컬 터미널에서 실행하면, 이 명령어는 자동으로 백그라운드에서 실행 중인 가상 머신의 팟맨 데몬에 전달되어 처리된다.

이러한 접근 방식은 도커 데스크톱의 아키텍처와 유사하지만, 근본적인 차이점이 존재한다. 팟맨은 가상 머신 내부에서도 기본적으로 루트리스 모드를 지원하며, 중앙 데몬(도커 데몬)에 의존하지 않는 데몬리스 아키텍처를 고수한다. 또한 Podman Desktop이라는 그래픽 사용자 인터페이스를 함께 설치하면, 컨테이너와 이미지를 시각적으로 관리하고 Podman Machine의 생명주기를 편리하게 제어할 수 있다.

팟맨은 도커와 유사한 명령어 구조를 제공하여 사용자들이 쉽게 적응할 수 있도록 설계되었다. 대부분의 기본적인 컨테이너 및 이미지 관리 작업은 docker 명령어를 podman으로 대체하는 것만으로도 수행 가능하다. 예를 들어, 컨테이너를 실행하려면 podman run을, 이미지를 풀하려면 podman pull을 사용한다.

주요 명령어는 다음과 같이 카테고리별로 구분된다. 이미지 관리를 위한 명령어로는 podman pull, podman images, podman rmi가 있다. 컨테이너 생명주기 관리를 위해서는 podman run, podman start/stop/restart, podman rm을 사용한다. 실행 중인 컨테이너를 확인하고 상호작용하기 위해서는 podman ps, podman exec, podman logs 명령어가 유용하다.

포드 관리 명령어는 팟맨의 특징적인 기능이다. podman pod create로 포드를 생성하고, podman pod ps로 목록을 조회하며, podman pod rm으로 삭제할 수 있다. 또한 podman generate kube와 podman play kube 명령어를 사용하면 포드 및 컨테이너 구성을 쿠버네티스 YAML 매니페스트로 생성하거나, 반대로 해당 매니페스트 파일을 실행할 수 있어 쿠버네티스 워크플로우와의 통합이 용이하다.

이러한 명령어들은 루트 권한 없이도 실행 가능한 루트리스 모드를 기본으로 지원하며, 도커 CLI와의 높은 호환성 덕분에 기존 도커 사용자나 스크립트의 마이그레이션 장벽을 낮춘다.

Buildah는 리눅스 컨테이너와 컨테이너 이미지를 빌드하기 위한 전용 도구이다. 이 도구는 팟맨 프로젝트와 밀접하게 연동되어 개발되었으며, 오픈 소스로 공개되어 있다. Buildah의 주요 목적은 도커 파일 없이도, 그리고 루트 권한 없이도 OCI 호환 컨테이너 이미지를 생성할 수 있는 기능을 제공하는 데 있다.

Buildah는 컨테이너 이미지를 빌드하는 데 특화되어 있어, 기존의 모놀리식 도구가 제공하던 이미지 빌드 기능을 보다 세분화하고 유연하게 만든다. 이를 통해 사용자는 베이스 이미지로부터 시작하거나 '스크래치'부터 완전히 새로운 이미지를 조립할 수 있다. 이 도구는 팟맨이나 쿠버네티스와 같은 런타임 환경에 의존하지 않고 독립적으로 이미지를 생성하고 관리할 수 있다.

Buildah의 핵심 장점은 세분화된 이미지 레이어 제어와 향상된 보안이다. 루트리스 모드로 실행될 수 있어 보안 취약점을 줄이고, 불필요한 데몬 프로세스 없이 작동하는 데몬리스 아키텍처를 채택한다. 이는 도커의 전통적인 이미지 빌드 방식과 대비되는 특징이다. Buildah로 생성된 이미지는 팟맨이나 도커를 포함한 모든 OCI 호환 런타임에서 바로 사용할 수 있다.

Buildah는 Skopeo 및 팟맨과 함께 레드햇의 컨테이너 생태계를 구성하는 핵심 도구 중 하나이다. 이들 도구는 각각 이미지 빌드(Buildah), 이미지 전송(Skopeo), 컨테이너 실행 및 관리(Podman)라는 명확한 책임을 분리함으로써 유닉스 철학에 따라 모듈화되고 강력한 워크플로우를 제공한다.

Skopeo는 컨테이너 이미지를 검사, 복사, 삭제, 동기화하는 데 특화된 명령줄 도구이다. 레드햇이 주도하는 컨테이너 생태계 프로젝트의 일부로, 팟맨 및 Buildah와 함께 사용되도록 설계되었다. Skopeo의 주요 목적은 컨테이너 레지스트리 간에 이미지를 복사하거나, 로컬 저장소의 이미지를 검사하는 등 이미지와 관련된 작업을 수행하는 데 있다. 이 도구는 도커 데몬이나 다른 컨테이너 엔진을 실행하지 않고도 이러한 작업을 직접 처리할 수 있다는 점이 특징이다.

주요 기능으로는 다양한 컨테이너 저장소 형식(도커 레지스트리, OCI 레이아웃, 도커 디렉토리 등) 간의 이미지 복사가 있다. 예를 들어, 한 프라이빗 레지스트리에서 다른 퍼블릭 레지스트리로 이미지를 옮기거나, 로컬 파일 시스템에 이미지를 저장할 수 있다. 또한 skopeo inspect 명령을 통해 원격 또는 로컬 이미지의 메타데이터(레이어, 태그, 아키텍처, 생성 날짜 등)를 쉽게 확인할 수 있어, 이미지를 풀(pull)하기 전에 내용을 미리 살펴볼 때 유용하다.

Skopeo는 루트 권한 없이도 동작할 수 있으며, 팟맨의 루트리스 모드 철학과 잘 맞아떨어진다. 이는 보안과 사용 편의성을 높이는 데 기여한다. 팟맨 생태계에서 Skopeo는 주로 이미지 전송 및 검증 도구로 활용되며, CI/CD 파이프라인이나 자동화 스크립트에 통합되어 이미지 관리 작업을 효율화하는 데 널리 사용된다.

CRI-O는 쿠버네티스의 컨테이너 런타임 인터페이스(CRI) 사양을 구현하는 경량 컨테이너 런타임이다. 레드햇을 비롯한 오픈 소스 커뮤니티가 개발했으며, 쿠버네티스 클러스터에서 포드와 컨테이너를 직접 실행하는 데 특화되어 있다. 도커 엔진이나 containerd와 같은 범용 런타임과 달리, CRI-O는 쿠버네티스와의 통합만을 목표로 설계되어 불필요한 기능을 제거함으로써 보안성과 효율성을 높였다.

CRI-O는 리눅스 컨테이너 표준 기술 스택을 기반으로 구축된다. 핵심 구성 요소로는 컨테이너 생명 주기를 관리하는 conmon, 이미지를 가져오고 관리하는 containers/image 라이브러리, 그리고 컨테이너 실행을 담당하는 runc 또는 다른 OCI 호환 런타임이 포함된다. 이 아키텍처는 쿠버네티스 kubelet이 CRI-O와 표준화된 gRPC 프로토콜로 통신하여 컨테이너를 생성하고 관리할 수 있도록 한다.

팟맨과의 관계에서 CRI-O는 중요한 하위 시스템 역할을 한다. 팟맨은 단일 호스트에서 컨테이너와 포드를 관리하는 데 사용되는 도구인 반면, CRI-O는 쿠버네티스와 같은 오케스트레이션 플랫폼이 여러 호스트에 걸쳐 컨테이너를 스케줄링하고 실행할 수 있도록 하는 인프라 런타임이다. 둘 다 레드햇의 컨테이너 에코시스템을 구성하며, Buildah 및 Skopeo와 함께 OCI 표준을 준수하는 워크플로우를 제공한다.