6P by neo 6달전 | favorite | 댓글 1개

Podman 대 Docker 비교

  • Podman과 Docker는 모두 효율적이고 확장 가능한 방식으로 컨테이너를 실행, 관리 및 배포할 수 있음.
  • Podman은 데몬이 없는 아키텍처를 사용하여 사용자가 직접 컨테이너를 관리함.
  • Podman은 Systemd와 통합되어 있어 컨테이너의 생명주기를 관리함.
  • Docker Compose와 유사한 기능을 제공하는 Podman Compose를 사용하여 여러 컨테이너를 조정할 수 있음.
  • 보안 측면에서 Podman은 Docker보다 강화된 기본 설정을 제공함.

Podman 설치하기

  • Podman은 macOS, Windows 및 주요 리눅스 배포판에서 실행 가능함.
  • 리눅스에서는 네이티브로, Windows와 macOS에서는 가상 머신을 통해 작동함.
  • 설치 과정은 sudo apt updatesudo apt install podman 명령어를 통해 진행됨.

첫 번째 컨테이너 실행하기

  • "Hello World!" 이미지를 사용하여 Podman 설치가 정상적으로 작동하는지 확인함.
  • Podman은 OCI(Open Container Initiative) 표준을 따르므로 Docker 이미지와 호환됨.

짧은 이미지 이름 사용하기

  • Podman은 이미지를 참조할 때 완전한 이름을 사용하도록 권장함.
  • 짧은 이름을 사용할 경우, Podman은 설정 파일을 참조하여 정규화된 이미지 이름을 확인함.

개인 이미지 레지스트리 사용하기

  • Podman은 Docker와 마찬가지로 개인 레지스트리와 함께 사용할 수 있음.
  • Docker Hub 계정을 사용하여 개인 레지스트리 설정 예제를 따를 수 있음.

여러 컨테이너 조정하기

  • Podman Compose를 사용하여 여러 컨테이너를 조정할 수 있음.
  • Podman Compose는 Docker Compose와 유사한 기능을 제공하며, 기존의 docker-compose.yml 파일과 호환됨.

GN⁺의 의견:

  • Podman은 Docker에 비해 더 빠르고 보안 측면에서 강화된 기본 설정을 제공하는 컨테이너 엔진임. 이는 개발자와 시스템 관리자에게 매력적인 대안이 될 수 있음.
  • Podman의 데몬이 없는 아키텍처는 보안 감사 추적을 용이하게 하여 보안 사고 발생 시 사용자 식별을 가능하게 함.
  • Podman과 Docker의 호환성은 기존 Docker 사용자들이 Podman으로의 전환을 쉽게 할 수 있도록 도와줌. 이는 기존 인프라와 워크플로우를 유지하면서 보안과 성능을 개선하고자 하는 조직에게 유용함.
Hacker News 의견
  • Podman과 systemd

    • Podman은 systemd 유닛 파일을 지원할 때 좋았음. 컨테이너와 포드를 자동으로 시작하고 업데이트할 수 있었음.
    • 그러나 Quadlet을 선호하면서 이 기능을 제거함. 이제 단일 컨테이너는 유닛 파일로 가능하지만, 포드를 위해서는 쿠버네티스 클러스터 정의가 필요함.
    • Docker와 달리 Podman의 컨테이너는 SELinux 정의에 따라 작동하여, 매핑된 디렉토리에 접근하지 못하는 문제가 반복됨.
    • Podman을 사용해야 하는지, 쿠버네티스를 사용해야 하는지, 논리적인 위치 대신 전용 디렉토리를 만들어야 하는지에 대한 혼란이 있음.
  • Podman의 네트워크 호환성

    • Podman의 주요 장점 중 하나는 Docker와 달리 네트워크 설정을 망치지 않는다는 것임.
    • Docker를 사용할 때 KVM 가상 머신과 함께 브리지를 운영하는 것이 악몽이었지만, Podman은 기본적으로 잘 작동함.
    • VPN이 Docker에 의해 손상되거나 중단되는 문제도 있었지만, Podman의 네트워킹 방식은 아직까지 다른 작업에 방해가 되지 않음.
  • Podman의 점점 증가하는 인기

    • 많은 도구들이 sudo docker 그룹을 추가하는 것을 가정하고 만들어졌지만, 보안을 의식한 Docker 설정에서는 문제가 발생함.
    • Podman은 루트 권한 없이도 사용할 수 있어 보안 면에서 긍정적임.
  • RHEL 엔지니어의 Podman 사용 경험

    • 인증된 RHEL 엔지니어로서 개인적인 컨테이너 사용에 Podman을 즐겨 사용함.
    • 그러나 개발자들을 위해서는 여전히 Docker를 사용하고 있으며, Docker Compose의 단순함을 대체할 만한 것을 제공하지 못함.
    • CI 파이프라인에서는 Buildah를 사용하지만, 개발자 사용자를 위해서는 Docker Compose가 여전히 우세함.
  • Docker와 UFW 보안 결함

    • Docker와 UFW 보안 결함에 거의 피해를 입을 뻔했음.
  • 루트리스 컨테이너와 독립된 네임스페이스의 중요성

    • 루트리스 컨테이너와 독립된 네임스페이스는 중요한 보안 기능임.
    • Docker에서도 루트리스를 사용할 수 있으며, 설정이 복잡하지 않음.
    • Docker를 고수하는 이점은 접근성이 더 좋다는 것임: 더 많은 커뮤니티, 블로그, Docker Compose 설정의 넓은 이용 가능성, 사용 방법을 아는 동료 등이 있음.
    • 결국 Podman과 Docker 모두 호스트에서 독립된 네임스페이스에서 프로세스를 실행함.
  • Red Hat의 Docker 대안, Podman

    • Red Hat이 Docker 대안을 만드는 이유는 명확하지 않지만, Podman이 마음에 듦.
    • Podman은 Docker가 하는 거의 모든 것을 할 수 있으며, 더 많은 기능을 가지고 있거나 (예: 포드), Podman의 방식이 더 나음 (예: 데몬 없는 컨테이너 생성 과정).
    • 개발자에게 주요 문제는 Docker Compose일 수 있으나, 간단한 Compose 파일을 사용한다면, Docker Compose 사양과 호환되려는 podman-compose 스크립트가 있음.
    • Podman을 Docker Compose의 백엔드로 사용하는 것도 가능함. 2024년 현재, 적어도 리눅스 상자에서는 Docker를 사용할 이유가 없어 보임. Podman이 macOS나 Windows에서 어떻게 작동하는지는 확실하지 않음.
  • Podman의 보안 중심 접근 방식

    • Podman의 보안 중심 접근 방식과 일부 결정들이 마음에 듦. 기본적으로 안전한 기본 설정을 제공하며, Docker Compose와 호환됨.
    • Podman이 충분한 인기를 얻는다면, 명령어와 yml에 대해 독자적인 방향으로 나아갈 수도 있음. 현재는 Docker와 Docker Compose 파일 형식에 '의존하는' 도구처럼 보임.
    • Podman에는 k8s가 없는 오케스트레이션의 부족을 대체할 수 있는 swarm 대안이 필요함. 좋은 보안 관점에서 작은 규모의 컨테이너를 운영하는 간단하고 합리적인 방법을 제시할 수 있을 것임.
  • Podman 사용 시 겪는 문제들

    • Podman은 훌륭하지만, Docker 대체제로 사용하기 시작했을 때 UID와 GID 매핑, SELINUX 정책, 누락된 DNS 설정 등으로 문제를 겪음.
    • 문제를 해결하기 위해 시스템 마이그레이션을 실행하다가 설정을 망친 적이 여러 번 있음. 보안 ACL, ID 매핑, 레이블에 대한 복잡한 문제가 있음.
    • 결과에 만족하지만, Docker처럼 '그냥 작동하는' 솔루션은 아니었음. 사용을 시작한 이후로 개선되었을 가능성이 있음.
  • Podman과 Apple 실리콘

    • Podman은 Docker와 달리 Apple 실리콘에서 x86 이미지를 Rosetta를 통해 실행할 수 있는 기능이 없음.
    • QEMU는 실제 사용에는 너무 느림.