Docker에 비해 Podman은 인지도가 많이 있지 않다.
구글 트렌드에서도 많은 차이를 보이고 있다.

그럼에도 불구하고 나는 Production 환경에서 Podman을 사용하기로 했다.
그 이유에 대해 알아보자.
각 서버의 자원은 한정되어 있었고, 특히 메모리를 최대한 효율적으로 사용하는 것이 중요했다.

그래서 첫 번쨰로 데몬이 없는 컨테이너 플랫폼을 찾고 있었다.
dockerd는 root 권한으로 동작하는 구조였기 때문에, 단순한 리소스 사용량을 넘어서 보안적인 측면에서도 검토가 필요했다.
물론 Docker 인증 플러그인을 사용하여 dockerd에 명령을 수행할 수없도록도 제어도 해 봤지만,
그 과정이 복잡하고 설정해야 할 것들도 너무 많았다.
Ex. 인증 플러그인을 거치는 과정
[ User / CLI ]
│
▼
[ docker client (CLI / API) ]
│
▼
[ dockerd ]
│
├───► [ AuthZ Plugin ]
│ │
│ ├─ 요청 검사 (who / what / resource)
│ ├─ 정책 평가 (allow / deny)
│ └─ 결과 반환
│
▼
[ docker.sock (/var/run/docker.sock) ]
│
▼
[ Container Runtime (containerd → runc) ]
│
▼
[ Container 실행 ]
그래서 내가 필요했던 건 다음과 같다.
그러다 찾게된 것이 Podman이고, 사용 중인 Linux 계열에서 만든 것이다!
Podman은 Redhat에서 만들어진 오픈소스이다
libpod 라이브러리를 사용해 컨테이너를 관리할 수 있는 툴이라고 설명되어 있다.
전용 데몬 없이도 Podman은 Linux 운영 체제를 위한 시스템 및 서비스 관리자인 systemd를 사용하여 업데이트하고 백그라운드에서 컨테이너를 지속적으로 실행할 수 있습니다
https://www.redhat.com/ko/topics/containers/what-is-podman
내가 원했던
물론 docker도 rootless 모드가 있지만,
RedHat 계열을 쓰면서 docker를 rootless로 쓰는 것 보다 RedHat에서 처음부터 rootless로 만든 기술을 사용하는게 더 이점이 있다고 생각했다.
개발자들은 docker에 익숙하다.
그래서 docker images, docker run과 같은 명령어가 더 익숙할텐데 이는 모두 podman-docker로 커버할 수 있다.
docker 를 podman 으로 alias한 느낌이다.
podman-compose는 docker-compose와 다르게 공식 기능이 아니다.
dnf install 처럼 쓸 수 없고, pip 라이브러리로 구동된다.
podman에는 docker와 다르게 pod라는 개념으로 관리된다.
( 당신.. 쿠버네티스 아니세요.. )
다시 돌아가거나, 특별한 사항이 있지 않은 이상 앞으로 Podman을 쓰지 않을까 싶다 ~
그럼 20000!
