Podman: 데몬이 없는 컨테이너

핵심 내용

1. 아키텍처는 데몬이 아닌 포크 실행입니다. 각 컨테이너는 Docker 데몬의 단일 권한 있는 리스너와 소켓 공유 공격 표면을 제거하는 podman 명령(컨테이너/스토리지가 라이브러리로 분할됨)의 하위 프로세스입니다. 충돌이 발생한 CLI는 컨테이너를 가져오지 않습니다.
2. 기본적으로 루트 없음: 권한이 없는 사용자는 사용자 네임스페이스(호스트의 UID 범위에 매핑된 사용자)를 통해 실제 작업 부하를 실행합니다. 이는 '컨테이너 이스케이프' 질문을 일반 파일 권한 질문으로 바꿉니다. 거래는 스토리지/드라이버 뉘앙스(fuse-overlayfs 클래스) 및 조정 없이 1024 미만의 포트 제한입니다.
3. Docker 호환성은 마이그레이션 경로입니다. CLI는 주로 드롭인(podman-compose 또는 compose 플러그인을 통한 실행, 빌드, 작성)이고, 주장하는 도구를 위한 docker.sock 에뮬레이션이 존재하며, 동일한 레지스트리에서 이미지 푸시/풀이 있습니다. Docker로 출시되는 CI 시스템 및 도구는 일반적으로 변경되지 않은 채로 유지됩니다.
4. 포드 및 인프라 컨테이너: Podman은 컨테이너를 Kubernetes DNA가 표시되는 포드(공유 네트워크 네임스페이스)로 그룹화합니다(podman은 podman play kube를 통해 로컬 개발을 위해 kube YAML과 잘 작동합니다). 소규모 자산은 오케스트레이터 작업 없이 오케스트레이터 모양의 그룹화를 얻습니다.
5. Systemd 통합은 조용한 초강대국입니다. 쿼드렛(컨테이너용 systemd 생성기)은 기본적으로 다시 시작 정책, 소켓 활성화 및 종속성을 통해 '이 컨테이너는 서비스입니다'를 표현하여 Docker 원시 배포가 항상 만든 사용자 지정 단위 파일의 혼란을 대체합니다. systemd에 있는 서버의 경우 이는 해당 카테고리에서 가장 깨끗한 답변입니다.
6. 정직한 한계: 생태계 가중치(문서, 타사 도구, 자습서)는 여전히 Docker를 기울이며 일부 도구는 docker.sock 경로를 가정하고 Mac/Windows 데스크톱은 컴퓨터 VM 내에서 실행됩니다(Docker 데스크톱 모델과 동일). Linux 서버에서 격차는 기술적인 것이 아니라 대부분 문화적인 것입니다.

현장 노트

클라이언트의 강화된 공유 호스트는 소켓 바인딩 관리 도구를 사용하여 Docker를 실행했습니다. 우리는 느린 주에 워크로드를 뿌리 없는 Podman으로 옮겼습니다. 이어진 보안 검토는 기록상 가장 짧았으며 작전 팀은 이전 장치 파일보다 더 마음에 들었던 시스템 쿼드렛만 발견했습니다.

자주 묻는 질문