내가 Docker에 Podman으로 전환한 이유

 (codesmash.dev)
14P by GN⁺ | ★ favorite | 댓글 8개
  • Docker는 백그라운드 데몬(dockerd) 구조로 인해 보안 취약점과 자원 소모 문제가 꾸준히 지적되어 왔음
  • Podman은 데몬 없는 구조를 채택해 컨테이너가 사용자 권한에서 직접 실행되며, 공격 표면을 줄이고 안정성을 강화함
  • Systemd 통합, Kubernetes 친화적 설계, Buildah/Skopeo 등 유닉스 철학 기반의 분리된 도구 지원으로 운영 효율성이 높음
  • Docker CLI와 높은 호환성을 유지해, alias docker=podman만으로도 대부분 기존 워크플로우가 그대로 작동함
  • 실제 운영 환경에서도 보안과 리소스 관리가 단순해지며, 신규 프로젝트에서는 Podman이 더 합리적이고 미래지향적 선택지가 되고 있음

Docker의 한계와 보안 문제

  • Docker는 dockerd 데몬이 항상 root 권한으로 실행되는 구조를 가짐
    • 데몬 취약점이 발견되면 전체 호스트가 위험에 노출될 수 있음
  • 주요 보안 이슈 사례
    • 2019: runC 컨테이너 탈출(CVE-2019-5736)
    • 2022: Linux Dirty Pipe 취약점, cgroups v1 탈출
    • 2024: runC “Leaky Vessels”, BuildKit 취약점
    • 2024: Docker API 노출을 통한 크립토재킹 캠페인
  • 이런 사건들이 반복되며 데몬 기반 구조의 근본적 위험성이 드러남

Podman의 데몬리스 구조

  • Podman은 백그라운드 데몬을 사용하지 않음
    • podman run 실행 시, 컨테이너는 명령 실행자의 직접 자식 프로세스로 동작
    • rootless 모드에서 실행되므로 컨테이너 내 root 권한도 호스트에서는 일반 사용자 권한에 불과함
  • 장점
    • 보안 강화: 컨테이너 탈출 시 피해 범위 축소
    • 안정성 확보: 하나의 컨테이너가 죽어도 다른 컨테이너는 영향 없음
    • 리소스 효율: 불필요한 데몬이 상주하지 않아 메모리 사용량 감소

Podman의 차별화된 기능

  • Systemd 통합
    • podman generate systemd로 systemd 유닛 파일 자동 생성
    • 표준 systemctl 명령어로 서비스 관리 가능
  • Kubernetes 친화성
    • Pod 개념이 기본 내장되어 있어 멀티 컨테이너 앱 개발 용이
    • podman generate kube로 바로 Kubernetes YAML 생성 가능
  • 유닉스 철학
    • Podman은 컨테이너 실행에 집중, 이미지 빌드는 Buildah, 레지스트리 관리에는 Skopeo 사용
    • 목적별 최적화 도구 활용 가능

전환 과정과 호환성

  • Docker에서 Podman으로의 전환은 거의 무중단
    • CLI가 호환되어 docker 대신 podman을 그대로 사용할 수 있음
    • 기존 Dockerfile도 그대로 작동
  • 차이점
    • rootless 모드에서 1024 이하 포트 바인딩 불가 → reverse proxy 권장
    • 볼륨 권한 관리 필요
    • Docker 소켓 의존 도구는 Podman의 Docker API 호환 모드 사용 가능

실무 적용과 이점

  • 운영 환경에서 Podman 사용 후
    • 보안 점검 부담 완화, rootless 보안 기본 적용
    • 리소스 사용 패턴이 더 단순하고 예측 가능해짐
  • Docker는 여전히 대중적이지만, 새로운 프로젝트나 기술 선택 자유도가 있는 경우 Podman이 더 적합
    • Linux 관리 체계와의 자연스러운 통합
    • Kubernetes 지향적 아키텍처
    • 더 안전하고 합리적인 컨테이너 실행 환경 제공

FastAPI 전환 가이드 요약

  • 기존 Dockerfile 그대로 사용 가능
  • podman build, podman run으로 간단히 대체
  • podman generate systemd로 systemd 서비스 등록
  • Pod를 활용해 DB 등 멀티 서비스 환경 지원
  • Docker Compose 워크플로우는 podman-compose 또는 kompose 변환으로 대응 가능

함께 보면 좋은 글 β

shortstories   [-]

여기서는 무중단 전환이 가능하다고 적혀있지만 실제 운영환경에서는 이상한게 많더라고요. 예를 들어 mac환경에서 기본 설정으로 zstd 압축을 쓰다보니 빌드한 이미지가 레지스트리를 꽤 많이 가린다던가..

답변달기
codemasterkimc   [-]

Docker podman 모두....

securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL

securityContext:
runAsNonRoot: true
runAsUser: UID

답변달기
koxel   [-]

실제로는 도커 호환이 잘 안되서 사용성이 그리 좋지 않습미다...
rootless 생각하고 포드맨 갔다가 도커로 다시 되돌아왔어요.
다른분 말대로 쿠버네티스로 쓰려면 그냥 containerd 쓰고 말죠.

답변달기
click   [-]

Docker compose 가 잘 동작하지 않고 쿠버네티스 호환성이 좋다는게 장점이면 그냥 바로 쿠버네티스 쓰면 되는거 아닌가 하는 의문이 드네요
저도 써보려다가 한번에 동작하지 못하고 1024 미만 포트 매핑도 직접 못해서 그냥 k3s에 이미지 빌드용 nerdctl로 조합으로 씁니다

답변달기
ndrgrd   [-]

언젠가 교체하고 싶은 마음은 있는데 전에 시도해보았을 때에는 개발자들이 말하는 것과는 달리 너무 많은 docker compose 프로젝트들이 제대로 작동하지 않더라구요...

답변달기
afewgoodman   [-]

Docker network 지원 안하쟌아.

답변달기
devsepnine   [-]

도커와 유사하게 네트워크 기능 또한 지원하는걸로 알고 있는데
아직 제대로 안되는게 있나요 ?

답변달기
GN⁺   [-]
Hacker News 의견
  • 2001/2002년에 WiFi 핫스팟 박스를 구축해야 했음. 당시에 OpenBSD 팬이었고, Python으로 된 배포본을 최대한 경량화하고 싶었음. 불필요한 파일 복사와 의존성 문제를 피하고 싶어서 chroot와 jail 컨셉을 선택함. 내 배포 코드가 jail 환경 밖에서 소프트웨어를 실행하고, ptrace로 프로세스가 여는 파일을 모니터링함. 이 출력으로 의존성 목록을 뽑아내 패키지화했음. 결과적으로 배포가 작고 불변성이 유지되며 보안도 강화됨. Docker가 등장했을 때 예전 방식이 생각났고, 실제로 Docker 컨테이너 파일 사용 내역을 모니터해서 배포본을 줄이는 유사한 도구가 있을지 궁금함
    • 내가 써 본 최고의 CI/CD 파이프라인은 Django 프리랜서 배포였음. git post receive hook으로 git push마다 정적 파일 빌드와 httpd 재시작 자동화. 그냥 'git push live master'만 하면 배포됨. Docker를 많이 써봤는데, 이게 가장 쉬운 배포였음. Docker의 장점은 알지만, 우분투나 OpenBSD에서 HTTP 세팅하는 게 그리 어렵진 않음. Docker만의 재현성이 정말 그만큼의 관리 오버헤드를 감수할 만큼 가치가 있냐는 의문임
    • 구글 검색 첫 번째 결과에 22k 스타가 있는 slimtoolkit/slim 있음
    • OpenWrt 환경에서는 ujail이라는 도구가 있는데, ELF 실행파일을 전달하면 필요한 라이브러리 의존성을 파싱해서 tmpfs에 읽기 전용으로 필수 파일만 마운트해줌
      관련 코드 링크
  • Podman이 내게는 정말 훌륭한 경험임. Docker 사용은 어렵고 함정이 많다고 느꼈는데 Podman은 전혀 뒤처지지 않음. 무엇보다 소속된 회사에서 라이선스 걱정을 안 해도 됨. 완전 윈윈임
    • 회사에서 라이선스가 걱정거리였는지가 궁금함. Docker Desktop 유료 라이선스 정책은 합리적임. 직원 250명 미만이나 매출 1,000만 달러 미만은 무료임. 라이선스 비용이 연간 $90라도 미국 개발자 급여 생각하면 점심값도 안 되는 비용임. 게다가 공식 지원 툴을 모든 OS에서 쓸 수 있음
    • 사실 회사는 라이선스에 크게 신경안 써도 됨. Docker Engine은 완전한 오픈소스라서 무료임. Docker Desktop만 기업에서 쓸 때 별도 라이선스 필요함. 하지만 대부분의 기능은 Docker Engine에서 다 쓸 수 있음
    • Podman이 Docker보다 훨씬 나음. 사용자/그룹 권한 처리나 루트 프로세스 보안 문제 걱정이 없음. 데몬에 데이터를 보낼 필요도 없음
    • 몇몇 PC에서 Podman의 윈도우즈 언인스톨러가 모든 컴포넌트를 제대로 지우지 않아서 재실행 시 오류가 남. 수동으로 서비스를 삭제해도 문제가 남아있음. 꽤 잦은 짜증 유발 요소임
  • Podman을 매우 좋아하지만 모든 컨테이너에서 항상 잘 동작하는 것은 아님. 예를 들어, gitlab 같은 대형 컨테이너는 도커의 복잡한 역사와 특이점에 의존하기 때문에 podman에서 오류가 종종 발생함. 직접 만든 이미지는 대부분 podman에서 잘 돈다고 봄. 문제성 컨테이너는 incus VM을 띄우고 그 안에서 구동하는 식으로 우회함. Podman과 Docker 둘 다 GPU 접근 방식이 일관되지 않아 불편함. 그럼에도 불구하고 podman이 좀 더 낫다고 생각함. 특히 rootless가 큰 장점임
    • 대부분의 문제는 PID 1을 루트로 시작하는 이미지 때문일 거라 추측함. Podman은 기본적으로 rootless라서 이런 문제가 생김. Docker 없이 루트 기반 이미지도 쓰고 싶다면 Podman을 rootful과 rootless 모드로 따로 두고 --connection 플래그로 원하는 환경을 지정하면 됨. 필요하면 Podman이 자동 VM도 생성해줄 수 있음(lima 활용). Podman Desktop에는 Docker 호환 레이어도 있어 호환성 문제를 완화함
    • 어떤 컨테이너는 podman에서 안 된다는 점 자체가 블로그 글의 동기가 되었을 거라 봄. 사용자층이 충분히 커지면 퍼블리시 전에 podman 환경도 체크하는 관행이 자리잡을 것임
    • 우리는 GitLab 서버 및 러너를 모두 podman에서 돌리고 있음. 개인적으로 러너를 k8s로 옮기길 바라지만, 현재 Traefik을 써서 잘 동작함
    • buildx 관련 기능을 많이 쓰는데, 외관상 podman에서도 된다지만 실제론 잘 안 됨
  • Ubuntu에서 podman 지원이 가장 큰 문제임. Ubuntu 기본 podman 버전은 너무 옛날이라 바로 쓸 수가 없음. 나는 podman v5, GitHub Actions는 v3, 내 동료들은 docker를 사용함. 결국 내 스크립트가 구버전 podman, 최신 podman, docker 모두에서 돌아가게 만들어야 하는 복잡성이 생김
    • 신뢰할 만한 .deb 빌드 배포소가 없음. 공식 .deb가 없고 찾은 것도 다 오래됐거나 앞으로 업데이트 안 한다는 곳뿐임. 그렇다면 왜 Podman이 설치를 더 쉽게 안 해주냐는 질문이 남음. 내 생각엔 RedHat이 경쟁사 제품 지원에 개발 리소스를 쏟고 싶지 않아서일 것임. 당연하지만, RedHat 생태계 외엔 2등 시민처럼 대우받는 인상임
    • 이 점이 가장 큰 문제라고 생각함. Docker에 비해 낮은 인지도도 문제지만, 버전 불일치 문제가 훨씬 Podman을 틈새로 만드는 주 원인임. Ubuntu 등 배포판은 예전 SW를 제공하는 경우가 많고, 이건 유지자가 직접 해결해야 하지만 Podman 측은 그걸 활발히 하고 있진 않음. 이 때문에 내 홈서버도 최신 Podman 쓰려고 레드햇 계열로 교체하게 됨
    • 공식 업스트림 .deb가 꾸준히 제공되지 않는 점이 Podman을 내부적으로 못 쓰게 만듦. Docker는 공식 .deb repo가 잘 관리되니 부럽게 느껴짐
    • Ubuntu/Debian이 업데이트가 너무 느려서 쓰지 않는 이유 중 하나임. flatpak으로 쓸 수도 있겠지만, 이런 SW는 디폴트로 제공해주면 좋겠음
    • Podman은 오픈소스기 때문에 Ubuntu 같은 곳이 자체적으로 패키징하고 업데이트할 수 있음. RedHat이 직접 경쟁사 SW 패키징까지 지원하기 꺼리는 것도 이해됨
  • 최근 회사 업무 때문에 Podman 셋업을 경험했는데, 최악의 경험 중 하나였음. rootless Podman+SELinux+컨테이너 내 일반 유저 조합은 진짜 지옥임
    • 사실 삽질하려면 뭐든 할 수 있지만, 실제로는 대부분 잘 동작함. SELinux 활성화된 RHEL10 머신들에서 nginx 리버스 프록시 뒤에 rootless 컨테이너로 여러 서비스(Forgejo, runner, uptime-kuma 등)를 잘 돌리고 있음
    • rootless의 이점을 한 번도 못 느꼈음. 머신이 단일 보안 도메인이면 그냥 root로 돌려도 무방하고, 그게 아니면 진짜 격리 환경(예: Firecracker/Kata VM 등)을 써야 한다고 봄. rootless는 고생만 하고 실익이 의심스러움
    • 나도 회사에서 같은 상황을 겪었으나, podman만의 방식(docs 참고)으로 해결하면 쓸 만함. 최근 버전 기준 문서를 보는 게 핵심임
    • Fedora에서 podman만 7년 넘게 써오고 있음
    • 우리 조직은 Docker에서 Podman으로 전체 마이그레이션을 했고, 중간에 잡음이 있었지만 SysDev팀의 역량으로 무난히 해결함
  • Docker Compose 워크플로가 너무 복잡하면 바로 Kubernetes YAML로 변환하라는 말이 있는데, 내 경험상 K8s YAML이 docker compose보다 훨씬 복잡함. 그리고 모든 사람이 Kubernetes를 쓰는 게 아님
    • 내 의견은 반대임. K8s YAML이 docker compose랑 복잡도는 비슷하거나 오히려 간단할 때도 있음. 단지 엄청 장황할 뿐임. 100줄 compose가 20개 YAML(각 50줄)로 쪼개질 수 있음. kubectl이 간단/복잡 YAML 상호 변환용 sugar 기능이 있으면 좋겠음
    • docker compose를 k8s yaml로 변환할 때 LLM을 레이어로 쓰면 엄청 잘 됨. 참고로 podman도 k8s yaml 생성 기능이 있어서, 자연스럽게 이전할 수 있음
    • 나는 compose 파일을 만들 줄은 모르지만, k8s yaml은 만들 수 있음. 그래서 compose가 오히려 더 "복잡"하게 느껴짐
  • 기사에서 언급된 "podman generate systemd" 명령어는 이제 deprecated임. 대안으론 Podman Quadlets가 있는데, 이건 systemd unit 파일 안에 정의된 docker-compose.yaml과 비슷한 방식임
    • Compose/orchestration을 systemd로 넘기는 게 논리적임. docker처럼 client-server 구조가 아니라 실제 유저 프로세스이니까 명확히 맞는 선택임
    • 문서가 거의 안 나와 있다는 게 문제임
  • 멀티 UID 컨테이너를 단일 호스트 유저에 매핑하는 게 어려움. 기본적으로 컨테이너 내 root는 호스트의 실행 유저에 매핑되지만, 최근 많은 앱들이 컨테이너 내 비-root 유저(예: www-data, 1000번 유저 등)를 쓰기 시작했음. 이들은 호스트에서 보조 ID에 매핑되는데, 이러면 볼륨 매핑시 파일 소유자가 고아가 되어 혼란이 큼. 모든 UID를 단일 유저로 매핑하는 간단한 옵션이 아쉽고, 기존 옵션(crun의 uidmap, userns)이 잘 동작하지 않음. 보조 ID 매핑의 실효성에 의문이 있음
    • 내 이해가 맞다면, 이건 리눅스 네임스페이스의 한계임. Docker, Podman 같은 툴이 이런 매핑을 지원하려면 리눅스 지원이 필요함. 1:1 UID 매핑이 필수적인 이유는, 컨테이너 내 유저 1000과 0이 같은 호스트 유저로 매핑되면, 파일 소유자 정보가 꼬이기 때문임
    • idmapped 마운트를 검토해도 좋을 것 같음. 파일 시스템 리매핑만 지원하고, 커널 호출에 대해선 해결이 안 됨
    • 컨테이너 안에서 그냥 "자기자신"으로 동작하는 방법이 있으면 좋겠음. 로그에도 소유자가 그대로 찍히는 방식으로
    • ignore_chown_errors 옵션을 사용하면 root를 유저 ID로 매핑할 때 별다른 추가 매핑 없이 간단히 적용할 수 있음
  • Podman 마이그레이션을 여러 번 시도했지만 여러 부분에서 실패함. 첫째로, podman의 성능이 내 소형 VPS에서 docker보다 훨씬 나빴음(상세 내용은 생략). 둘째, 개발 에코시스템이 완전히 따라오지 못함. 많은 툴들이 Docker 소켓에 의존하는데 podman은 권한 문제 혹은 API 호환성 차이로 잘 동작하지 않음. podman이 완벽한 drop-in 대체는 아님
    • rootless podman 사용 시 느린 네트워크는 slirp4netns 때문일 수 있음. pasta가 더 빠른 방식임. Docker는 기본적으로 권한 있는 데몬이 네트워크를 셋팅하니까 만약 podman을 루트 유저로 쓴다면 성능 차이 없어야 함
    • podman 및 quadlet의 SELinux 권한 에러가 계속 골칫거리임. 웬만하면 호스트 전체 권한 pod를 만들어 필요한 /dev만 마운트하고 아주 제한적인 프로그램을 단절된 네트워크로 노출시키는 게 더 쉬움
    • 재미있게도 내 리소스 부족 시스템에선 podman이 docker보다 성능과 리소스 사용량이 훨씬 뛰어났음. crun과 runc의 차이 때문으로 보임. 그리고 podman은 데몬이 없어서 더 가벼움
  • Docker와 Podman 모두 버리고 FreeBSD Jails로 넘어감
    • 더 자세한 정보와 관리 툴들은 여기,
      여기,
      여기,
      여기에서 확인 가능함
    • FreeBSD jail 안에서 MS SQL Server나 수천 개의 docker 컨테이너를 즉시 실행할 수 있음? FreeBSD의 선택은 큰 대가(호환성 제한 등)를 요구함. 이게 jails가 대중화되지 못하는 이유임
    • 셋업이 정말 많은데, FreeBSD에도 containerd 같은 게 있는지 궁금함
    • FreeBSD jails는 배포판 특화적 특징임
    • Linux host에서 VM 돌리는 것과 FreeBSD jail이 뭐가 다른지 궁금함
답변달기