보안 강화된 Docker 대안, ‘Podman’ 탐구

 (betterstack.com)
6P by GN⁺ | ★ favorite | 댓글 1개
  • Podman은 Docker와 비슷한 컨테이너 실행 경험을 제공하면서도 데몬 없이 동작해 보안과 감사 추적 측면에서 차별화됨
  • Docker는 Docker daemon 중심의 클라이언트-서버 구조를 쓰지만, Podman은 사용자 세션에서 컨테이너를 직접 생성해 실행 사용자 추적이 더 명확함
  • OCI 표준을 따르기 때문에 Docker Hub의 hello-world, caddy, wordpress, mysql:5.7 같은 이미지를 실행할 수 있고, 많은 경우 docker 명령을 podman으로 바꿔 사용할 수 있음
  • 짧은 이미지 이름은 Docker처럼 자동으로 Docker Hub를 기본값으로 삼지 않으므로 완전한 이미지 이름, 별칭, unqualified-search-registries 설정 중 하나가 필요함
  • 다중 컨테이너 구성은 Podman Compose, pods, Kubernetes 매니페스트로 처리할 수 있지만, Docker Swarm 같은 내장 프로덕션 오케스트레이션은 없어 Kubernetes 같은 외부 시스템을 써야 함

Podman과 Docker가 갈라지는 지점

  • Podman은 Docker보다 더 안전하고 가벼운 대안을 목표로 하는 오픈소스 컨테이너 엔진임
  • 지속적으로 떠 있는 데몬 없이 컨테이너를 실행하며, 사용자가 컨테이너를 직접 관리하는 구조를 가짐
  • 기본 보안 방향은 rootless 컨테이너, 사용자 네임스페이스, 커널 capability의 더 신중한 사용에 맞춰져 있음
  • Docker 이미지와 명령 체계와의 호환성이 높아 Docker 대안을 찾는 개발자와 시스템 관리자에게 실용적인 선택지가 됨

아키텍처와 감사 추적

  • Docker는 클라이언트-서버 모델을 사용하며, 컨테이너 실행 요청은 Docker client에서 Docker daemon으로 전달됨
    • 컨테이너 프로세스는 사용자 세션이 아니라 Docker daemon의 자식 프로세스가 됨
    • Linux Audit 시스템인 auditd가 컨테이너 프로세스 이벤트를 감지할 때 audit user ID가 실제 사용자 ID가 아니라 unset으로 표시될 수 있음
    • 이 구조에서는 악성 활동을 특정 사용자와 연결하기 어려움
  • Podman은 데몬리스 아키텍처를 사용함
    • 각 컨테이너가 사용자 로그인 세션을 통해 직접 생성됨
    • 컨테이너 프로세스 데이터가 사용자 정보를 유지함
    • auditd가 특정 컨테이너 프로세스를 시작한 사용자 ID를 정확히 감지하고 기록할 수 있음
  • 이미지에 따라 Podman의 컨테이너 시작 속도는 Docker보다 최대 50% 빠를 수 있음

컨테이너 수명주기 관리

  • Podman은 데몬이 없기 때문에 컨테이너 수명주기 관리 방식도 Docker와 다름
  • Linux에서는 Systemd에 크게 의존함
    • --restart always 플래그로 지정한 컨테이너의 재시작 정책을 적용하기 위해 podman-restart라는 systemd 서비스를 사용함
    • 이 서비스는 시스템 재부팅 후 지정된 컨테이너를 자동으로 다시 시작함
  • 실행 중인 컨테이너에서 Systemd 서비스 파일을 생성하는 명령도 제공함
    • 컨테이너를 systemd 관리 아래에 두면 시작, 중지, 점검이 쉬워짐
  • Docker는 이런 작업을 daemon 내부에서 처리함

오케스트레이션 선택지

  • 로컬 개발에서 Docker 사용자는 보통 Docker Compose로 다중 컨테이너 애플리케이션을 정의하고 관리함
  • Podman은 Compose 파일을 기본으로 지원하지 않지만, Podman Compose를 호환 대안으로 제공함
    • 일반적으로 기존 docker-compose.yml 파일과 함께 동작함
    • Docker Compose에 익숙한 사용자는 기존 Compose 파일을 계속 사용할 수 있음
  • Podman의 네이티브 방식으로는 pods를 사용할 수 있음
    • Kubernetes에서 가져온 개념임
    • 여러 컨테이너를 하나의 단위처럼 관리할 수 있음
  • 프로덕션 배포에서는 Podman에 Docker Swarm 같은 내장 오케스트레이션 도구가 없음
    • 이 경우 Kubernetes 같은 외부 오케스트레이션 시스템이 대안이 됨
    • Kubernetes는 Podman과 통합될 수 있지만, 올바르게 동작하려면 추가 구성과 설정이 필요할 수 있음

보안 기본값

  • 컨테이너 보안에서 큰 위험은 컨테이너 탈출로 호스트 시스템이 침해되는 상황임
  • Podman은 Docker보다 강한 기본 보안 설정을 제공하도록 설계됨
    • rootless 컨테이너
    • 사용자 네임스페이스
    • seccomp 프로파일
  • Docker에서도 rootless 컨테이너, 사용자 네임스페이스, seccomp 프로파일을 사용할 수 있지만 기본으로 활성화되어 있지 않고 추가 설정이 필요한 경우가 많음
  • Podman 기본 구성은 격리된 사용자 네임스페이스 안에서 rootless 컨테이너를 실행해 잠재적 탈출의 영향을 제한함
  • Docker 기본 설정은 컨테이너 프로세스를 root로 실행해 탈출 시 더 높은 위험을 가짐
  • capability 기본값도 다름
    • Podman은 기본적으로 11개 capability로 컨테이너를 시작함
    • Docker는 더 허용적인 기본 설정으로 14개 capability를 사용함
  • 두 도구 모두 강한 보안 구성으로 설정할 수 있지만, Podman은 일반적으로 그 상태에 도달하는 데 필요한 노력이 더 적음

기능 비교에서 눈에 띄는 차이

  • Podman은 데몬리스 아키텍처와 Systemd 통합을 지원함
  • 컨테이너를 pods로 묶을 수 있고 Kubernetes YAML도 다룰 수 있음
  • Docker는 Docker Swarm을 지원하지만 Podman은 지원하지 않음
  • 그 외 대부분의 기능은 양쪽이 대체로 동등하다고 볼 수 있음

설치와 실행 환경

  • Podman은 Docker처럼 주요 운영체제에서 실행 가능함
    • macOS
    • Windows
    • 주요 Linux 배포판
  • 중요한 차이는 Linux에서는 네이티브로 실행되지만, Windows와 macOS에서는 가상 머신이 필요하다는 점임
  • 예시는 Debian 기반 Linux 배포판인 Ubuntu, Mint, Debian을 가정함
  • 최신 Podman을 설치하려면 비교적 최근 배포판이 필요함
    • 글 작성 시점의 최신 주요 Podman 버전은 4.x
    • Ubuntu 22.04 LTS는 Podman 3.x에 묶여 있음
    • 예시는 Ubuntu 23.10을 기준으로 함
  • 설치 후 예시 출력은 podman version 4.3.1이며, 로컬에서 podman 명령을 실행할 수 있음을 확인함

Docker 이미지 실행과 OCI 호환성

  • Podman은 Docker 생태계 도구로 빌드된 hello-world 이미지를 실행할 수 있음
  • 이 호환성은 Docker와 Podman이 모두 OCI(Open Container Initiative) 표준을 따르기 때문임
    • OCI는 이미지 형식 명세와 런타임 명세를 정의함
    • 서로 다른 컨테이너 런타임이 상호 운용될 수 있게 함
  • Docker Hub의 대부분 Docker 이미지와 컨테이너를 Podman에서 사용할 수 있음
  • 기존 워크로드를 수정 없이 Podman으로 옮기거나 Docker Hub의 이미지 라이브러리를 활용할 수 있음
  • hello-world 출력에 “Hello from Docker!”가 표시되더라도 실제 실행 주체는 Podman임
    • Docker client나 Docker daemon은 실행 과정에 관여하지 않음

짧은 이미지 이름 처리 방식

  • Docker는 완전한 이미지 이름을 지정하지 않으면 Docker Hub인 docker.io를 기본 레지스트리로 사용함
  • Podman은 짧은 이름 사용을 권장하지 않으며, 기본 레지스트리를 자동으로 가정하지 않음
  • hello-world는 shortnames.conf에 별칭이 있어 docker.io/library/hello-world로 해석됨
  • caddy처럼 별칭이 없는 이미지를 짧은 이름으로 실행하면 다음 오류가 발생함
    • Error: short-name "caddy" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"
  • 해결 방법은 세 가지임
    • 완전한 이미지 이름을 사용해 docker.io/library/caddy처럼 명시함
    • registries.conf에 [aliases] 섹션을 추가해 "caddy"="docker.io/caddy"로 별칭을 정의함
    • unqualified-search-registries=["docker.io"]를 설정해 짧은 이름을 Docker Hub에서 찾도록 함
  • 사용자별 설정은 $HOME/.config/containers/registries.conf에 둘 수 있음
    • 이 파일은 /etc/containers/registries.conf보다 우선함
    • root 권한 없이 설정할 수 있어 rootless 접근 방식과 더 잘 맞음
  • Docker 대체품처럼 Podman을 쓰려면 별칭보다 unqualified-search-registries 설정이 장기적으로 편함

프라이빗 레지스트리 사용

  • Podman은 Docker처럼 프라이빗 레지스트리를 사용할 수 있음
  • Docker Hub 계정을 사용하는 예시는 다음 흐름을 따름
    • Docker Hub에서 access token을 생성함
    • 설명은 Podman tutorial, 권한은 Read & Write로 설정함
    • private repository를 생성함
    • podman login docker.io로 로그인함
  • docker.io가 registries.conf의 첫 번째 unqualified-search-registries 항목이면 생략할 수 있지만, 레지스트리를 명시하는 것이 좋은 관행임
  • 레지스트리를 제공하지 않으면 podman login은 다음 오류로 실패함
    • Error: no registries found in registries.conf, a registry must be provided
  • 로그인 후 hello-world 이미지를 private repository로 push하고, 로컬 public 이미지를 삭제한 뒤 private repository 이미지로 컨테이너를 실행할 수 있음
  • 유효한 로그인 자격 증명이 없으면 private 이미지 pull 시 접근 거부와 인증 필요 오류가 발생함
  • 프라이빗 레지스트리 사용에서 눈에 띄는 차이는 docker 대신 podman을 붙인다는 점이며, Podman은 널리 쓰이는 private registry와 함께 사용할 수 있음

Podman Compose로 다중 컨테이너 실행

  • 여러 컨테이너를 하나의 단위로 실행해야 할 때 Podman은 여러 선택지를 제공함
    • Podman Compose
    • pods
    • Kubernetes manifests
  • 예시는 Podman Compose를 사용해 WordPress와 MySQL을 실행함
  • Podman Compose는 커뮤니티 주도 도구이며 Compose specification을 구현하고 Podman과 통합됨
  • Python 3에 의존하며, 예시에서는 pipx로 설치함
    • 예시 설치 출력은 podman-compose 1.0.6
    • 사용된 Podman 버전은 4.3.1
  • pipx가 $HOME/.local/bin에 설치되면 해당 경로가 $PATH에 없을 수 있음
    • pipx ensurepath로 경로를 추가할 수 있음
    • 새 터미널을 열거나 셸 설정 파일을 다시 읽어야 함

WordPress와 MySQL 예시

  • 예시는 .env 파일에 데이터베이스 사용자, 비밀번호, 이름을 정의하고 docker-compose.yml로 WordPress와 MySQL 서비스를 구성함
  • podman-compose up -d 실행 시 Podman Compose는 docker-compose.yml을 분석함
  • wordpress 서비스 처리 과정
    • 필요한 external volume을 찾고 없으면 생성함
    • 적절한 network를 찾고 없으면 생성함
    • wordpress 컨테이너를 실행함
    • 로컬 이미지가 없으면 설정된 docker.io 레지스트리에서 wordpress:latest를 가져옴
  • db 서비스 처리 과정
    • podman-tutorial_db volume을 생성함
    • 기존 네트워크를 확인함
    • mysql:5.7 컨테이너를 실행함
    • 로컬 이미지가 없으면 Docker Hub에서 가져옴
  • 실행 후 localhost:8080에서 WordPress 설치 페이지를 확인할 수 있음
  • podman ps 출력에는 wordpress와 db 컨테이너가 실행 중으로 표시됨
    • wordpress는 0.0.0.0:8080->80/tcp로 포트가 매핑됨
    • db는 mysql:5.7 이미지로 실행됨
  • 이미지 목록에는 docker.io/library/wordpress:latest와 docker.io/library/mysql:5.7이 표시됨
  • 네트워크 목록에는 기본 podman 네트워크와 Podman Compose가 만든 podman-tutorial_default 네트워크가 표시됨
    • podman-tutorial_default는 docker-compose.yml에 정의된 컨테이너를 같은 시스템의 다른 컨테이너와 분리하기 위해 생성됨
  • volume 목록에는 podman-tutorial_db와 podman-tutorial_wordpress가 표시됨
  • podman-compose down은 컨테이너를 중지하고 제거하지만 네트워크와 volume은 유지함
    • volume 제거에는 podman volume rm을 사용함
    • 네트워크 제거에는 podman network rm을 사용함
  • 명령은 Docker 및 Docker Compose와 거의 같고, docker와 docker-compose 대신 podman과 podman-compose를 입력하는 차이가 있음

선택 기준

  • Podman은 컨테이너 워크로드 실행을 위한 Docker의 실용적인 대안임
  • Docker가 할 수 있는 대부분의 작업을 수행할 수 있고, 백그라운드 데몬이 필요 없다는 장점이 있음
  • Docker에는 없는 기능도 제공함
    • Kubernetes manifest 파일 작업
    • 개별 컨테이너를 pods로 구성
  • 더 가볍고 안전한 컨테이너 관리 솔루션이 필요하면 Podman이 더 나은 선택일 수 있음
  • 강력한 생태계와 광범위한 커뮤니티 지원을 우선하면 Docker가 더 적합할 수 있음
  • 추가 탐색 자료로 Podman 공식 웹사이트, 문서, 커뮤니티를 참고할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Podman이 systemd 유닛 파일을 지원하던 때가 좋았음. 컨테이너뿐 아니라 전체 pod도 systemd로 자동 시작·자동 업데이트할 수 있었기 때문임
    그런데 그 기능을 없애고 Quadlet을 밀기 시작했음. 단일 컨테이너는 유닛 파일로 할 수 있지만, pod는 Kubernetes 클러스터 정의를 써야 함
    게다가 Docker와 달리 컨테이너가 SELinux 정의를 따르다 보니, 매핑한 디렉터리에 접근하지 못해서 여러 번 고생했음
    결국 Podman은 뭘 하라는 건지 모르겠음. Kubernetes를 쓰라는 건가? 논리적인 경로를 매핑하지 말고 전부 전용 디렉터리를 만들라는 건가?

    • 이미 인프라를 docker-compose.yml로 정의하고 있었는데, podman-compose에 systemd 유닛을 생성하는 문서화가 빈약한 기능이 있다는 걸 알게 됨
      이 기능은 이제 폐기된 Podman 기능을 쓰지 않고 유닛 파일을 직접 작성하며, 개인적으로는 기존 Podman 방식보다 훨씬 매끄러웠음
      기능 활성화는 $ podman-compose systemd -a create-unit이고, systemd 유닛 등록은 $ podman-compose systemd -a register, $ systemctl --user enable --now "podman-compose@$PROJECT_NAME"로 함
      업데이트는 $ podman-compose pull 후 $ systemctl --user restart "podman-compose@$PROJECT_NAME"로 처리함. $PROJECT_NAME은 보통 디렉터리 이름임
      확인하고 싶다면 기능 소스 코드는 여기 있음: https://github.com/containers/podman-compose/blob/f6dbce3618...
      아직 podman 4.3.1을 쓰고 있긴 하지만, 이후 버전에서 이 방식이 멈출 이유는 없어 보임
    • “Docker와 달리 컨테이너가 SELinux 정의를 따른다”는 건 오히려 Docker의 버그임. 시스템이 SELinux용으로 설정되지 않았다면 꺼야 함
      그리고 podman-generate-systemd가 생성하던 systemd 파일은 결국 "podman start containername"을 실행하는 정도라 직접 쓰기도 쉬움. 다만 docker-compose 같은 것과 달리 컨테이너는 거의 블랙박스에 가까움
      Quadlet의 장점은 컨테이너 정의가 .container 파일에 선언된다는 점임. 예전에는 podman run 명령줄을 손으로 systemd 유닛에 적었는데, 그런 면에서 Quadlet은 큰 개선이고 docker-compose의 대안도 될 수 있음. 물론 장단점은 있음
    • 오래 써온 팬이지만, 이 부분은 동의함
      podman generate systemd [...]를 실행하려고 할 때마다 이 전환이 있었다는 걸 다시 떠올리게 됨
      자주 겪지는 않는 이유는 이걸 괜찮은 방식으로 처리하는 Ansible 역할을 직접 만들어뒀기 때문임
      그래도 Podman이 방향을 놓친 느낌이 강함. 이미 유닛 파일 유지보수와 관계 설계 쪽을 받아들였으니 그냥 생성기를 쓰게 해줬으면 함. Quadlet이든 그게 더 낫다는 얘기든 관심 없음
    • SELinux를 다루고 싶지 않다면 containers.conf에 다음을 추가하면 됨: [containers] label=false
      Podman의 기본 보안 수준이 마음에 들지 않으면 보통 끌 수 있는 방법이 있음
    • 최근 NixOS로 옮겼는데, NixOS는 컨테이너를 포함한 모든 것의 기준을 systemd로 다룸
      이 모델은 매우 직관적이었지만 Docker Compose에 적용하려면 수동 이전이 많이 필요했음
      그래서 Compose 파일을 NixOS 설정으로 변환해 네이티브하게 해석·관리할 수 있게 해주는 도구를 만들었음: https://github.com/aksiksi/compose2nix

  • Podman을 Docker보다 선호해야 하는 결정적 이유로 거의 거론되지 않는 장점이 있음. Docker는 네트워크 설정을 망가뜨림
    Docker와 KVM 가상 머신을 브리지와 함께 동시에 돌리려 하면 악몽이고, Podman은 기본 설정만으로도 훨씬 잘 어울림
    VPN도 Docker 때문에 깨지거나 Docker를 깨뜨린 적이 많았음. Podman의 네트워킹이 내부적으로 어떻게 되는지는 잘 모르지만, 적어도 다른 작업을 방해하지 않도록 잘 설계된 것 같음. Docker에 대해서는 절대 그렇게 말할 수 없음

    • 내 기준으로는 Buildah가 진짜 핵심 기능임. Docker와도 잘 동작할 수 있지만 Podman과 같은 계열 도구에 가까움
      Dockerfile은 순수한 쓰레기라고 봄. 기성 언어로 충분한데 “심심한 개발자”가 DSL이나 프로그래밍 언어를 새로 만드는 걸 정말 싫어함. 특히 YAML이면 더 그렇고, 이 경우는 아니지만 Dockerfile은 왜 이런 짓을 그만해야 하는지 보여주는 훌륭한 예임
      bud 없이 Buildah를 보면 이유가 드러남. 사용 사례가 조금만 표준 경로를 벗어나도 짜증나는 엉성한 DSL 대신 Bash, Fish, 원하는 무엇이든 쓸 수 있음
      이런 나쁜 결정은 Docker 생태계 전체로 이어짐. DCS와 늘 미완성인 그 대체재도 예시임. Cosign처럼 확립된 서명 프로토콜을 쓰는 대신, 자동화하기 어렵고 특히 키 교체가 까다로운 복잡한 시스템을 만들고 싶어 했음
    • Podman은 무료임. Docker도 무료지만 Docker Desktop 없이 Docker 설치하기가 귀찮음
    • Docker와 KVM 가상 머신을 브리지와 함께 지금도 돌리고 있는데, 악몽 없이 그냥 잘 동작함. 좀 이상함

  • Podman이 더 널리 쓰이게 되는 건 반가움. 너무 많은 도구가 사용자가 sudo docker 그룹을 추가한다고 가정하고 만들어져 있어서, 루트 접근을 무작정 주지 않는 식의 보안을 의식한 Docker 설정에서는 깨짐

    • 서버리스·컨테이너 같은 첨단 미래가 결국 루트로 온갖 것을 실행하는 기반 위에 만들어졌다는 게 늘 웃김

  • 인증된 RHEL 엔지니어로서 Podman은 이미 몇 년째 쓰고 있음
    솔직히 개인적인 컨테이너 사용에는 꽤 마음에 듦. 하지만 직장에서는 개발자들에게 여전히 Docker를 제공함. 지금까지는 docker compose의 단순함에 맞먹는 것을 개발자에게 제공할 방법이 없었음
    컨테이너 이미지를 만들 때 CI 파이프라인에서는 buildah도 쓰지만, 개발자 최종 사용자 관점에서는 docker compose가 여전히 지배적임

  • https://www.techrepublic.com/article/how-to-fix-the-docker-a...
    이 문제 때문에 거의 당할 뻔했음

    • Docker는 기본 설정·설치만으로도 iptables를 건드림. 특히 더 새로운 nftables를 쓰고 싶을 때 늘 골칫거리였음
    • Docker의 안전하지 않은 기본 선택 때문에, VPN 전용으로 쓰라고 되어 있던 GitHub 프로젝트의 개인 셀프호스팅 컨테이너 하나에 암호화폐 채굴기가 들어왔음. 아직도 짜증남
    • 네트워킹 문제 얘기를 하자면, 중첩 구성에서 네트워크 장치용 메모리가 부족해져 시스템 재시작이 필요했던 큰 문제가 있었음. 그게 아니었다면 훌륭한 lxc 대안이었을 텐데 아쉬움

  • Red Hat이 왜 Docker 대안을 만드는 데 투자하는지는 아직 잘 모르겠지만, 결과물은 정말 마음에 듦
    Podman은 Docker가 하는 거의 모든 일을 하면서도 pod 같은 기능이 더 있거나, 데몬 없는 컨테이너 생성 과정처럼 방식 자체가 더 나은 경우가 많음
    일반 개발자에게 가장 큰 문제는 Docker compose일 텐데, 단순한 compose 파일을 쓴다면 Docker compose 명세와 호환되려는 podman-compose 스크립트가 있음
    docker-compose의 백엔드로 Podman을 쓰는 방법도 있음 [1]. 전반적으로 2024년에 Linux 머신에서 Docker를 써야 할 이유는 보이지 않음. macOS나 Windows에서 Podman이 어떤지는 잘 모르겠음
    [1] https://www.redhat.com/sysadmin/podman-docker-compose

    • Red Hat은 원래 Docker와 협력해서 과거에 드러난 여러 문제, 예를 들면 특정 사용 사례의 systemd 호환성 문제를 고치려 했지만 별 성과가 없었음
      여기에 Docker가 예전에도 지금도 보안 문제가 유난히 많고, Docker식 컨테이너와 이미지가 개발자들 사이에서 매우 널리 쓰인다는 점을 합치면, RHEL의 가치와 접근 방식에 더 맞는 자체 구현을 만들 수밖에 없었음
      예를 들어 Docker는 rootless를 할 수 있는데도 여전히 기본값으로 쓰지 않음. 강화된 환경에서는 docker 사용자 그룹도, 그룹 없이 실행하는 방식도 보안상 많은 사용 사례에서 받아들이기 어려움
      초기 Docker는 비권한 컨테이너가 최소한의 격리라도 되도록 하는 데 너무 소극적이었고, 문제가 알려진 뒤에도 고치는 데 오래 걸렸음. 방화벽과 네트워크 규칙, SELinux와 상호작용하는 방식도 문제가 많음. 보안을 중시하는 전담 Linux 시스템 관리자가 있는 회사에서 Docker 금지가 드물지 않은 이유임
    • Windows에서 Podman을 쓰고 있음. Windows의 Docker는 끝없는 짜증과 좌절의 연속이었음
      시작부터 모든 문서가 공격적으로 사용자 친화적이지 않은 GUI 설치로 유도함. 부팅 시 무거운 프로세스를 띄우고, 무슨 이유인지 클라우드 계정 가입을 요구하며, 이른바 오픈소스 제품을 업무에 쓰면 안 된다고 또 잔소리함
      “명령줄 Docker만” 설치하는 비지원 대안은 불필요하게 복잡했고, 마지막으로 시도했을 때 대부분의 WSL VM은 기본 상태에서 지원하지도 않았음
      반면 Podman은 winget install podman이면 끝나고 방해하지 않음. 컨테이너를 실행해야 할 때만 Podman VM을 시작하고, 필요 없을 때는 시스템이 이전처럼 동작함
      compose 파일로 뭔가 실행해야 하면 podman-compose가 있음. 특이한 설정은 못 다룰 수도 있지만 내 용도에서는 잘 동작했음
      Podman이 제대로 못 하는 건 VS Code 통합 정도인데, Windows에서 Docker를 얌전히 굴러가게 만드는 고생이 VS Code 단축키 몇 개를 잃는 것보다 훨씬 짜증나서 문제 되지 않음
      Windows에서 컨테이너 기본 해법으로 Podman을 추천함. Docker를 쓸 이유는 회사가 비용을 내주거나, 복잡한 compose 구성이 있는 경우 정도인데, 그런 경우라면 Kubernetes로 옮길 가치가 있을 수도 있음
    • Red Hat이 투자하는 이유는 Docker가 Linux에서 일이 처리되는 방식과 너무 동떨어져 있기 때문임
      시스템을 망가뜨리는 일을 하고, rootless를 몇 년씩 힘들어했으며, 벤더 종속도 빼놓을 수 없음
      Podman은 개방적이고 규격을 따르며 Kubernetes와도 잘 맞음. 쉬운 컨테이너 시장에 먼저 나왔다는 이유만으로 개발자들이 Docker에 들인 노력이 말도 안 되게 많았음
    • “Linux에서는 Docker를 쓸 이유가 없다”는 관점이 다수파가 되지 않았으면 함. Docker는 RedHat/IBM이 아님
      Docker가 사라지면 RedHat은 더 강한 손으로 자기 기업 의제를 밀어붙일 수 있음
      Podman의 장점도 있지만, RedHat이 Docker의 모든 것을 대체하려는 과정에서 잘 실행되지 않은 부분도 있음
      RedHat이 컨테이너 영역에 접근해온 역사를 보면, 기여하고 개선할 수 있었던 많은 프로젝트에 시간과 노력을 낭비한 측면이 있음
      RedHat은 고객에게 옳은 일을 하려는 의제를 가진 회사가 아니니, 더 큰 그림에서 무엇을 바라는지 생각해봐야 함
    • macOS에서 Podman을 쓰고 있음. 대체로 Docker보다 경험이 좋았고, 특히 오래된 macOS 버전 지원에서 그랬음
      macOS용 Podman의 유일한 큰 단점은 컨테이너에서 호스트 네트워크를 쓸 수 없다는 점임. 하지만 컨테이너에서 호스트 네트워크를 쓰고 싶어 하는 경우는 드묾
      다만 컨테이너 안에서 네트워크 관련 실험을 하면서 호스트와 같은 호스트명과 IP 주소를 유지하고 싶다면 염두에 둬야 함. 그래도 이 제한은 우회해서 쓰고 있음

  • 보안 우선 접근과 결정들이 좋아 보임. 기본 설정부터 안전하고, docker compose와도 동작한다는 점이 마음에 듦
    다만 Podman이 충분히 인기를 얻으면 언젠가 명령과 yml 형식에서 독자 노선을 택할지 궁금함. 지금은 Docker와 Docker compose 파일 형식에 기대는 도구처럼 보임
    Podman에 Swarm 대안이 있으면 좋겠음. 지금은 오케스트레이션 부족 때문에 Kubernetes가 목발처럼 쓰이는 느낌임
    보안을 잘 고려하는 팀이라면, 기본값부터 안전하지 않은 Kubernetes를 박사과정처럼 파고들지 않고도 작은 규모에서 컨테이너를 합리적이고 단순하게 실행하는 방법을 만들 수 있을 것 같음. 그러면서 Docker compose 형식과의 호환성도 유지할 수 있을 것임

  • rootless 컨테이너와 격리된 이름공간이 중요한 보안 기능이라는 데 동의함. 하지만 Docker rootless로도 가능하고 복잡하지 않음. 그냥 그렇게 설정하면 됨
    현재 가능한 모범 사례를 모두 적용해서 Mastodon을 docker rootless로 설정하는 글을 쓴 적이 있음 [1]
    Docker를 계속 쓰는 장점은 접근성이 더 좋다는 것임. 커뮤니티와 블로그가 더 많고, docker compose 설정이 널리 있으며, 주변에 쓸 줄 아는 사람도 더 많음
    결국 Podman과 Docker 모두 호스트의 격리된 이름공간에서 프로세스를 실행함
    [1]: https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...

  • 오해는 없었으면 함. Podman은 훌륭하고 요즘은 Docker 대신 쓰고 있지만, 처음에 단순한 Docker 대체품이라고 생각하고 쓰기 시작했다가 UID/GID 매핑, SELinux 정책, 빠진 DNS 설정 등으로 크게 데였음
    문제를 고치려고 system migrate를 실행했다가 전체 설정을 망친 적도 여러 번 있음. 보안 ACL, ID 매핑, 레이블과 관련된 체계가 따로 있음
    홈 폴더 아래에서 chmod -R을 하면 아마 모든 컨테이너가 죽을 수 있음
    결과에는 만족하지만 Docker처럼 “그냥 동작하는” 해법과는 거리가 멀었음. 내가 쓰기 시작한 뒤로는 아마 많이 개선됐을 것 같음

    • 올해부터 쓰기 시작했는데, 여러 개발 환경을 격리하고 npm이 개발 머신 전체에 쉽게 접근하지 못하게 하려는 용도였음
      내 기준으로는 Docker보다 쓰기 쉬웠음. 위에서 겪은 상황보다 지금은 개선된 것 같음

  • 큰 그림에서 보면 Podman은 예전의 Linux처럼 필수적인 존재로 느껴짐
    아주 적은 사람이 쓰더라도, 그 존재만으로 훨씬 큰 사유 소프트웨어 형제들이 끔찍한 일을 하지 못하게 막아줌
    여기서 “예전의 Linux”라고 한 건 Linux가 덜 중요해졌다는 뜻이 아니라, 지금은 오히려 더 필수적이고 중심적이 됐기 때문임

    • “훨씬 큰 사유 소프트웨어 형제들”이 Docker를 뜻한다면 좀 아이러니함. RedHat과 IBM이 오픈소스 영역에서 하는 나쁜 일들도 많기 때문임
답변달기