Docker 대 Podman: 서버에 어떤 엔진이 속해 있나요?

핵심 내용

1. 데몬 문제는 갈림길입니다. Docker의 루트 데몬(docker.sock)은 노출된 배포에서 실제 공격 기록이 있는 루트와 동등한 단일 지점이며 Podman의 fork-exec 모델에는 동등한 중앙 집중식 권한 표면이 없습니다. 컨테이너가 신뢰할 수 없는 사용자와 접촉하거나 공유 영역에서 실행되는 경우 일반적으로 rootless가 논쟁에서 완전히 승리합니다.
2. 호환성은 정말 높습니다. CLI 어휘, OCI 이미지 및 레지스트리는 공유 영역입니다. 마찰은 엔진 자체가 아니라 docker.sock(일부 CI 러너, Portainer와 같은 특정 관리 GUI에 어댑터가 필요함)을 가정하는 생태계 도구에 있습니다.
3. Rootless는 작동 질감이 다릅니다. 사용자 네임스페이스를 통한 Podman rootless는 스토리지 드라이버와 포트 범위를 이동합니다(높은 포트에는 sysctl net.ipv4.ip_unprivileged_port_start와 같은 명시적인 노브가 필요함). 반면 Docker의 루트 없는 모드는 존재하지만 더 많은 주의 사항이 있습니다. 출시일에 네트워크 계층을 발견하는 대신 Podman 호스트의 네트워크 계층을 계획하십시오.
4. 서비스 통합은 철학적으로 다릅니다. Podman 측의 systemd 쿼드렛은 기본적으로 컨테이너 서비스(다시 시작 정책, 소켓 활성화, 리소스 제어)를 표현하는 반면 systemd의 Docker는 데몬 주변의 단위 래퍼를 사용하고 restart=always를 사용합니다. 두 작업 모두 쿼드렛 의미론이 감사자를 더 자연스럽게 만족시킵니다.
5. 생태계 중력은 Docker의 실제 해자입니다. 튜토리얼, CI 이미지, GPU 도구 및 Docker Desktop 통합은 docker를 먼저 가정하고 개발자는 소켓 경로에 하드 코딩된 도구를 찾을 때까지 Podman을 거의 알아차리지 못합니다. 보안 상태가 보장되는 호스트별로 Podman을 선택하고 CI가 도구 요구 사항에 Docker를 유지하도록 합니다.
6. 이 범주 전반에 걸쳐 우리가 사용하는 결정 규칙: RHEL 제품군 및 보안에 민감한 공유 자산은 기본적으로 Podman rootless로 설정됩니다. 개발자가 많은 자산과 GPU 또는 생태계에 고정된 모든 것이 혼합되어 Docker를 유지합니다. 엔진은 별도의 호스트에서 완전히 공존하므로 이는 종교가 아닌 호스트별 결정입니다.

현장 노트

양면 클라이언트의 정직한 결과: Docker는 개발자 워크스테이션 함대에 머물며(도구 요구에 따라) 뿌리 없는 Podman이 인터넷에 연결된 프로덕션 호스트를 실행합니다. 양측은 승리했다고 주장했다. 둘 다 옳으며, 재산이 분할될 때 더 안전합니다.

자주 묻는 질문