Docker가 왜 아직 Podman보다 훨씬 인기 있는지 모르겠음. 구현만 보면 Podman이 분명 더 낫고, 새 네트워크 기능도 반가운 개선임

배포가 약간 더 번거롭고 서로 떨어진 단계가 더 많다는 게 주된 이유일 듯함. 특히 루트리스로 가려면 더 그렇고, 사실 그렇게 해야 함
Linux 우선이 아닌 사람, 예를 들어 앱 컨테이너화를 배우는 초보 개발자에게 systemd 유닛 파일이나 kubelet 설정을 다루고, 전용 로컬 서비스 계정을 만들고, linger 활성화까지 기억해야 하는 건 Docker 설치 후 docker compose 파일 만들고 “start” 누르는 것보다 꽤 위압적임
왜 이런 접근을 택했는지는 이해하지만, 꽤 투박하고 친절하지 않음

fuse-overlayfs가 Docker의 overlayfs 구성보다 눈에 띄게 느렸음. 재구성 방법이 있을 수도 있지만 최근에는 확인해보지 않음
Zig로 ghostty를 빌드할 때 Podman에서 애매한 “unknown file” 오류로 깨졌던 것 같고, 알고 보니 fuse-overlayfs가 확인하려던 일부 속성을 지원하지 않아서였음
전환하려 할 때마다 이런 임의의 작은 문제들이 계속 발목을 잡음. 단순한 용도에는 쓰고 있음

마지막으로 확인했을 때 podman compose는 docker compose와 겉모양만 비슷한 수준이었음. inotify 같은 것도 Podman 쪽에서 랜덤하게 자주 깨지는 듯함
Podman을 추천하고 싶지만, docker compose 호환성이 좋지 않고 볼륨에서 inotify가 빠지면 개발자 경험이 너무 문제됨

더 강한 브랜드명도 이유일 듯함. macOS에서는 Docker Desktop이 더 직관적이었음. 다만 최근에는 오류가 매우 잦아졌고, 파일 마운트나 네트워크 규칙 정리가 랜덤하게 실패하거나 갑자기 엄청 느려져 VM을 재시작해야 했음
macOS의 Podman은 훨씬 덜 다듬어진 느낌이고, OrbStack이 훨씬 나은 선택지임
Linux에서만 Podman을 쓰는데 거기서는 매우 빠름. 그래도 대부분 기능이 systemd와 결합해 Kubernetes를 대체하는 쪽에 맞춰진 것 같고, 정작 docker compose 지원은 불안정하며 TUI/UX도 원본보다 뒤처짐

사소한 이유들로 Podman을 포기했음. 하나는 Docker와 다르게 SELinux를 처리하기로 해서, 기본 CentOS 시스템에서 SELinux 보안 레이블을 바꾸는 작업이 필요했다는 점임. 이건 채택 불가였음
또 다른 문제는 Docker와의 작은 차이들인데, 패키징된 Docker compose가 그대로 동작하지 않을 정도였음. Docker로 바꾸면 바로 돌아가고 하루 일을 계속할 수 있는데, 그걸 디버깅하는 데 시간을 쓰고 싶지 않았음

Docker Desktop이 또 랜덤하게 엄청난 메모리를 먹기 시작한 뒤 Podman으로 바꿨고, 정말 설치한 다음 docker-compose.yml을 가리키는 것만큼 쉬웠음
변경은 전혀 필요 없었고, 이제 데몬을 계속 띄워둘 필요도 없음. 훌륭한 소프트웨어임

Docker의 AI 헛짓 때문에 결국 선을 넘어서 Podman으로 전환을 시도했지만, 몇 가지 호환성 문제를 만났음. 몇 달 전이라 세부 내용은 기억나지 않음
그래서 Rancher Desktop을 써봤고, 이름을 자꾸 잊는 것만 빼면 그냥 잘 동작했음. 필요한 사람에게는 또 하나의 단순한 선택지임

Docker에서 Podman으로 옮겨본 경험이 궁금함
홈랩/자동화 구성에 compose 파일이 많아서 그게 제일 걱정됨

약 15개월 전에 Docker에서 Podman으로 옮겼고, 다시는 돌아가지 않을 생각임. 개인적으로 quadlet, 즉 systemd 통합이 정말 좋고, 일반 systemd 서비스든 컨테이너든 실행 중인 서비스 묶음을 훨씬 쉽게 모니터링하게 해줌
루트리스 실행도 아주 직관적이고, Podman은 매우 빠름. 개인적으로 docker compose가 크게 그립지는 않지만, docker compose 부재가 다른 사람에게 치명적일 수 있다는 건 이해함. Podman의 compose 플러그인은 써본 적 없음

홈랩에서 거대한 docker compose 파일을 podman quadlet으로 바꿨음. 기억상 처음 몇 개 서비스를 옮길 때는 compose 파일에 비해 quadlet 문서와 예제가 많지 않아 시간이 좀 걸렸지만, 그 뒤로는 아주 쉬웠음. 강력 추천함
유일한 문제는 검증임. quadlet 파일을 검증하는 편리한 내장 명령이 없고, systemd도 생성 실패를 경고해주지 않음. 먼저 --dry-run을 하거나, 전체 명령을 적당한 별칭으로 만들고, 아니면 저널에서 오류를 확인해야 함

몇 년 전, 5.0 이전에 옮겼고 돌아보지 않았음. compose 파일은 quadlet 사용을 검토할 만함
빠른 변환에는 podman-compose를 직접 쓰거나, Podman 소켓을 가리키도록 docker compose를 설정할 수 있음[0]
compose 파일을 네이티브 quadlet으로 바꿔주는 podlet[1]도 있음. 단순하거나 중간 정도 복잡도의 compose 파일은 대부분 알아서 잘 처리하고 바로 동작함. 이를 라이브러리 형태로 만들어 다른 도구들이 compose 파일을 quadlet으로 투명하게 변환하게 하자는 이야기도 있어서, 앞으로 비슷한 도구가 더 나오길 기대함
systemd 유닛 파일에 조금이라도 익숙하다면 직접 Quadlet 파일을 쓰는 것도 어렵지 않음. 대부분의 docker run 또는 podman run 인자는 quadlet로 바로 대응되므로, YAML 대신 INI 형식에 익숙해지면 compose 파일을 보고 동등한 quadlet을 만들어내기 쉬움
[0] https://www.redhat.com/en/blog/podman-docker-compose
[1] https://github.com/containers/podlet

1~2년 전에 전부 루트리스 Podman으로 옮겼음. 일부 컨테이너는 예전 데이터를 읽을 때 권한 문제가 생겼는데, 다른 UID로 실행된 게 원인이었음
실제로 겪은 문제는 이게 전부였고, 루트 권한 Docker에서 루트리스 Docker로 옮겨도 같은 문제가 있었을 것임. 전혀 후회 없고 절대 돌아가지 않을 생각임

Podman에게는 git만큼 고마움을 느낌
Podman은 성숙하고 합리적이었음. 누군가의 컨테이너가 su 권한에 의존한다면 Podman이 아니라 그 누군가를 탓함

Podman에서 싫은 점은 Docker 호환인 척하지만, 나중에 물고 늘어질 작은 차이들이 있다는 것임. Docker 기반 프로젝트 사용자가 Podman으로 실행하려다가 결국 프로젝트 쪽에 와서 불평하게 됨

대부분의 차이는 소켓 API나 논리적 동작, 명령줄 차이에서 오지 않았음. Docker가 루트 권한으로 실행된다고 가정하는 반면, Podman은 기본적으로 그렇지 않다는 데서 주로 생김
그래서 Podman/Docker 비호환을 고치는 일은 대체로 그 가정을 처리하는 것임. Podman 명령에 몇 가지 플래그를 더해 컨테이너와 호스트 사이의 사용자 네임스페이스 매핑 방식을 바꾸는 식임

Mac과 Linux에서 Podman을 3년 써왔고, 안타깝게도 이 문제는 늘 사실이었음. 끈질기게 근본 원인을 찾아 버그를 올릴 의향은 있지만, 많은 사람에게는 그냥 고장난 것처럼 보일 것임
가장 최근에는 Netavark가 게시된 포트에서 브로드캐스트 트래픽을 받는 동작이 Docker와 맞지 않았음

맞음. 이 때문에 몇 년 동안 Podman을 꺼리게 됐음. 지금은 똑똑한 아이디어가 있다고 보고, RHEL을 쓴다면 당연한 선택이지만, 적응이 필요하다는 점을 더 솔직히 알려야 함
특히 루트 권한 Docker에서 루트리스 Podman으로 옮기는 경우에는 더 그렇음

요즘 Podman은 어떤지 궁금함. macOS에서는 OrbStack을 쓰고 있고 훨씬 빠른 것 같음. macOS 27이 WSL과 비슷하게 마이크로VM 기반의 더 네이티브하고 성능 좋은 Linux 컨테이너를 추가하면 판도가 어떻게 될지 모르겠음

macOS는 잘 모르겠지만, Linux에서는 내 용도에 매끄럽게 맞음. 한 가지 주의할 점은 Podman Compose가 기본 제공자로 docker-compose를 쓴다는 것임
podman-compose 제공자는 써보지 않았고, 이름이 Podman Compose와 헷갈리게 살짝 다름. Podman Compose는 docker-compose나 podman-compose 위의 상위 추상화임. 필요하면 Podman으로도 Docker 엔진을 통해 컨테이너를 실행할 수 있음

같은 질문이고 같은 상황임. MacOS에서 써봤는데, 처음 겪은 문제 하나를 이해하려고 Redhat 포럼 깊숙이 들어가야 했음. OrbStack으로 바꾸는 건 당연한 선택이었지만, 기능 관점의 명확한 트레이드오프는 있음

Quadlet과 루트리스 컨테이너는 Docker에서 Podman으로 옮기려는 두 가지 큰 이유임

루트리스가 몇 년 전 Podman으로 옮긴 이유였음. 정말 매끄럽고, 이제 애매한 권한 문제나 서비스 오류를 걱정하지 않아도 됨

Podman은 좋지만 저 회색 글자 색은 왜 그런지 모르겠음. 보기 안 좋고 명암비 4.96:1이라 읽기 어렵고, WCAG AAA 수준에도 못 미침

홈 서버를 약 2년 동안 podman + quadlets로 돌리고 있는데, 릴리스 노트에서 몇 가지 챙길 만한 걸 봤음 podman quadlet list는 v5.6.0에 추가됐고, quadlet과 그 컨테이너를 나열함 podman system migrate --migrate-db는 v5.8.0에 추가된 플래그임. 예전에 bolt DB 지원 중단 경고를 봤지만 sqlite로 마이그레이션하는 도구가 없었는데, 이제 생겼음. 아니면 podman 6.0.0으로 올리면 자동으로 처리됨

Docker가 아닌 CRI 런타임용 이미지 빌드에 Podman을 써본 경험이 궁금함
Podman으로 이미지를 빌드하면 cri-o, Docker, 그 외 여러 런타임에서 실행될까?
docker build에는 sudo가 필요해서 에이전트 기반 작업 흐름에서 귀찮아지다 보니, 루트리스 Podman으로 이미지를 빌드할지 고민 중임