Podman 대 Docker: 어느 것을 선택해야 할까요?

가상화 및 컨테이너화 세계에 관심이 있다면 Podman과 Docker를 접했을 가능성이 높으며 이들이 서로 어떻게 다른지 궁금할 것입니다.

이 게시물에서는 Docker와 Podman의 차이점을 살펴보고 어느 것이 귀하에게 적합한지 찾아보도록 하겠습니다!

도커

Docker는 모든 수준(개발 및 배포)에서 프로젝트 내 종속성 관리를 용이하게 하는 컨테이너화 기술입니다.

Linux, Windows 및 Mac OS에서 사용할 수 있는 Docker의 메커니즘은 컨테이너 및 해당 오케스트레이션을 중심으로 하며 여기에서 컨테이너화가 가상화와 다릅니다.

Docker에는 Docker CLI와 Docker Daemon이라는 두 가지 기본 빌딩 블록이 있습니다.

도커 데몬:

Docker 이미지, 컨테이너, 네트워크 및 스토리지 볼륨을 관리하는 데 도움이 되는 지속적인 백그라운드 프로세스입니다. Docker는 Docker 엔진 REST API를 사용하여 HTTP 프로토콜을 통해 액세스되는 Docker 데몬과 상호 작용합니다.

도커 CLI:

Docker 데몬과 상호 작용하기 위한 Docker 명령줄 클라이언트입니다. Docker 명령을 실행할 때 사용하는 것입니다.

Docker의 작동은 Linux 커널과 cgroup 및 네임스페이스와 같은 이 커널의 기능을 기반으로 합니다. 컨테이너의 목적은 여러 프로세스와 응용 프로그램을 개별적으로 실행하는 것이므로 이러한 기능은 독립적으로 실행할 수 있도록 프로세스를 분리합니다.

이는 별도의 시스템에 비해 보안 수준을 낮추지 않고 인프라 사용을 최적화할 수 있는 것입니다.

Docker와 같은 모든 컨테이너 도구는 이미지 기반 배포 모델과 함께 제공됩니다. 이 모델은 여러 환경에서 애플리케이션 또는 서비스 세트 공유를 단순화합니다.

또한 Docker는 컨테이너 환경 내에서 애플리케이션 배포를 자동화하는 데 도움이 됩니다. 이러한 다양한 도구를 사용하여 사용자는 애플리케이션에 대한 전체 액세스 권한을 얻고 배포를 가속화하고 버전을 제어하고 할당할 수 있습니다.

포드맨

Podman(POD MANager)은 OCI 컨테이너 및 컨테이너 이미지를 구축, 실행 및 관리합니다. Red Hat에서 개발했으며 원래 엔터프라이즈 Linux 8용으로 설계되었습니다. 컨테이너 관리에 사용되며 Docker의 공식 후속 제품 역할을 합니다.

결과적으로 Red Hat은 Docker에 대한 지원을 중단했지만 Podman은 원래 디버깅 도구로만 의도되었지만 Docker를 기반으로 하기 때문에 사용자가 전환하기 쉬울 것이라고 확신했습니다.

libpod 라이브러리를 사용하여 전체 컨테이너 생태계를 관리합니다. Podman은 Linux 플랫폼에서만 작동하므로 REST API 및 클라이언트는 현재 Mac 및 Windows 시스템에서 서비스를 호출할 수 있도록 개발 중입니다.

하지만,   현재 Linux 기반 Podman 서버와의 원격 통신을 허용하는 Mac 또는 Windows 플랫폼에서 작동하는 Varlink 기반 원격 클라이언트가 있습니다. libpod 라이브러리는 신뢰 및 이미지 확인을 포함하여 이미지를 안전하게 업로드하는 여러 방법을 지원합니다.

또한 OCI 및 Docker 이미지 형식을 비롯한 여러 이미지 형식과 컨테이너 그룹을 함께 관리하는 포드를 지원합니다.

매우 작고 관리하기 쉬운 환경에서 Podman은 Kubernetes의 선구자 역할을 할 수도 있습니다. 이는 컨테이너 과대 광고 초기부터 개별 인스턴스의 단일 관리와 Kubernetes를 사용한 현대적인 오케스트레이션 사이의 격차를 해소합니다.

야심 찬 컨테이너 사용자는 이미 포드로 다음 단계를 즐길 수 있습니다. Kubernetes 클러스터의 구축 및 운영은 더 이상 필요하지 않습니다. 가장 간단한 경우 새로 설계된 포드를 개별 작업에서 테스트하고 개선할 수 있습니다. Kubernetes로의 후속 전송도 가능합니다.

podman generate kube 명령은 해당 구성 파일을 제공합니다. 그런 다음 Kubernetes 도구 kubectl에 대한 입력으로 일대일로 제공됩니다.

현재 버전의 Podman은 systemd용 구성 파일도 생성할 수 있습니다. 이는 컨테이너 오케스트레이션을 위해 유비쿼터스 init 후속 프로그램을 사용하는 모든 사용자에게 유용한 서비스입니다.

Podman 대 Docker: 차이점

Docker는 컨테이너 관리를 위한 목마로 빠르게 자리 잡았습니다. 그러나 Docker에는 많은 장점이 있으며 무엇보다 빠르게 증가하는 이미지 레퍼토리와 단점 및 가능한 보안 위험이 있습니다. 또한 Docker는 더 이상 Kubernetes의 컨테이너로 지원되지 않습니다.

컨테이너는 가상 시스템과 달리 커널이 필요하지 않다는 사실이 일반적으로 큰 이점 중 하나로 간주됩니다. 그러나 Docker 컨테이너는 루트 권한으로만 실행할 수 있기 때문에 Docker에 중대한 보안 위험이 있습니다.

컨테이너에서 실행 중인 프로세스가 루트 권한으로 커널에 액세스하여 호스트 시스템을 공격할 수 있습니다.

첫 번째 차이점은 처음 사용할 때 분명합니다. Docker는 먼저 Docker 데몬을 시작해야 하지만 Podman 컨테이너는 명령줄에서 직접 시작할 수 있습니다. 따라서 백그라운드 프로세스가 없으며 애플리케이션은 필요할 때만 실행됩니다.

보안 관점에서 이것은 데몬이 수퍼유저 권한으로 연중무휴 24시간 실행하지 않아도 되는 경우 Podman이 공격에 덜 취약하기 때문에 좋습니다. Podman은 Docker와 근본적으로 다른 아키텍처로 인해 백그라운드 프로세스가 필요하지 않습니다.

Docker는 Docker 클라이언트가 API를 통해 Docker 데몬과 통신하는 클라이언트-서버 모델을 따르는 반면 Podman은 fork-exec 모델을 따릅니다. 각 컨테이너는 Podman의 하위 프로세스로 실행됩니다.

Podman이 일반 사용자 권한으로 실행될 때 처음 사용할 때 사용자 네임스페이스가 생성됩니다. 사용자 네임스페이스에서 Podman은 루트 권한으로 실행되며 파일 시스템을 마운트하고 컨테이너를 생성할 수 있는 권한이 있습니다.

따라서 Podman 컨테이너는 실행 사용자가 가진 권한만 가집니다. 사용자 네임스페이스를 사용한다는 것은 각 사용자가 자신의 컨테이너를 만들고 관리할 수 있지만 다른 사용자와 수퍼유저에게는 보이지 않는다는 것을 의미합니다.

Podman은 Docker와 독립적으로 운영되기 때문에 개발자는 많은 재량권을 갖고 있으며 커뮤니티의 요구에 부응할 수 있습니다. Podman에 흥미로운 추가 기능으로는 마운트/마운트 해제 명령과 시스템 통합이 있습니다.

호스트는 mount/unmount 명령을 사용하여 컨테이너의 파일 시스템을 마운트할 수 있습니다. 예를 들어 파일에 액세스하거나 파일을 변경한 다음 다시 마운트 해제할 수 있습니다.

Podman을 사용하는 Docker의 데몬으로 인해 systemd를 사용하여 컨테이너를 모니터링하는 것은 작동하지 않지만 systemd를 통해 컨테이너를 시작, 모니터링 및 다시 시작할 수 있습니다.

또한 Podman은 각 컨테이너에 해당하는 systemd 서비스를 생성하는 podman generate systemd 명령을 제공하므로 사용자가 systemd 서비스를 생성할 필요가 없으므로 호스트 시스템에서 통합이 가능합니다.

Podman과 Docker의 또 다른 중요한 차이점은 후자는 내부 네트워크를 생성할 수 있기 때문에 방화벽 규칙이나 현재 dnsmasq 설치를 변경하지 않는다는 것입니다. 반대로 Docker는 컨테이너 간 통신을 활성화하기 위해 방화벽 규칙을 덮어써야 합니다.

Docker에서 Podman으로 마이그레이션해야 하는 경우

RHEL 기반 환경에서 컨테이너를 배포하는 경우 RHEL 네이티브이므로 Podman을 사용하는 것 외에는 많은 옵션이 없습니다. 컨테이너가 적은 소규모 배포가 있는 경우 Docker로 마이그레이션하거나 Podman을 선택할 수도 있습니다.

그러나 그보다 더 복잡해지려면 네트워크를 통해 docker-compose/podman-compose를 사용하여 여러 컨테이너와 조정 컨테이너 스택을 사용하십시오. 네트워킹을 훨씬 더 잘 처리하므로 Docker를 사용하는 것이 좋습니다.

마찬가지로 컨테이너 세계에 막 진입하기 시작한 경우 Docker는 안정적이고 적절한 문서로 잘 확립되어 있으며 여전히 안정성이 부족한 Podman에 비해 학습 곡선이 얕고 잘 정의된 문서가 없습니다.

Podman에서 Docker로 마이그레이션

명령줄에 있는 경우 Docker 엔진에서 Podman으로 전환하는 것은 매우 쉽습니다. 가장 간단하게 $ alias docker=podman 명령이 대부분 작동합니다.

물론 이것은 적절한 소프트웨어가 시스템에 설치되어 있다고 가정합니다. Linux의 경우에도 문제가 되지 않습니다. 기성품 소프트웨어 패키지는 상업적으로 사용 가능한 배포판에 사용할 수 있습니다.

Windows 또는 macOS는 지원되는 운영 체제에 속하지 않습니다. 별칭 접근 방식은 많은 Docker 명령에 Podman에 해당하는 명령이 있기 때문에 작동합니다.

그러나 일부 Docker 명령에는 Podman 세계에 상응하는 명령이 없기 때문에 예외도 있습니다. 마찬가지로 일부 명령은 Docker에서 Podman 유니버스와 다르게 동작합니다. 현재로서는 이미 설정된 볼륨 처리에만 영향을 미칩니다.

Docker Desktop과 같은 그래픽 도구를 사용 중인 경우 전환이 조금 더 어렵습니다. 특히 Windows 또는 macOS로 작업하는 개발자에게 영향을 미칩니다.

Docker Desktop 사용자는 명령줄에 익숙해져야 하며 Docker Compose에도 동일하게 적용됩니다. 그러나 podman-compose 프로젝트가 있습니다. Python으로 작성된 이 소프트웨어는 Docker Compose를 대체합니다.

마지막 말

Docker를 Podman으로 교체하는 것은 거의 완료된 것으로 간주할 수 있습니다. 사용자와 관리자에게는 이러한 변경의 대부분이 쉽습니다. 많은 Docker 기능은 Podman에서 동일한 기능을 제공합니다.

실질적인 이점은 컨테이너 그룹의 자연스러운 사용은 말할 것도 없고 단일 데몬 프로세스와 루트 권한이 없다는 것입니다. 그러나 Docker는 컨테이너와 관련된 주요 기술로 남아 있지만 장기적으로 변경될 가능성이 높습니다.

컨테이너를 관리하기 위해 몇 가지 Docker 명령을 탐색할 수도 있습니다.