PODMAN과 DOCKER

Kubernetes에서 Docker가 제외되면서 어떤 기술들을 공부해야 할까 망설였는데

마침 Redhat의 전폭적인 지원을 받는 podman을 접하게 되었다!

docker image를 공유할 수 있고 명령어 체계도 비슷해서 공부를 시작해 본다.

 

1. podman?

 1.1. Linux 시스템에서 Container를 개발, 실행, 관리하기 위한 Open Source Tool

 1.2. Redhat과 OpenSource Community가 공동 개발

 1.3. 데몬이 없는 포괄적인 아키텍처 -> docker는 docker daemon이 모든 걸 처리한다.

 1.4. Buildah및 Skopeo와 같은 관련 툴과 기능을 통해 개발자는 컨테이너 환경을 사용자 정의 방식으로 요구 사항에 가장적합하게 설정

 

2. 특징: POD와 Podman

 2.1. POD: POD는 모두 함께 실행되며 동일한 리소스를 공유하는 컨테이너 그룹으로 K8S의 포드와 유사

  2.1.1. 각 포드는 하나의 인프라 컨테이너와 다수의 일반적인 컨테이너로 구성

  2.1.2. 인프라 컨테이너는 포드를 실행하고 사용자 네임스페이스를 유지 관리하여 컨테이너를 호스트로부터 분리

  2.1.3. 다른 일반 컨테이너는 프로세스를 추적하고 빈 컨테이너를 찾을 수 있는 모니터링 기능.

  2.1.4. 비기능성 컨테이너라도 리소스 일부가 여전히 사용되기 때문에 환경에서 제거할 수는 없음.

  -> Infra Container는 반드시 pod를 삭제해야만 제거

  -> 일반 container는 pod 삭제 시 제거되지 않음. # podman rm -f 로 제거 후 pod를 삭제해야 함.

 2.2. Podman

  2.2.1. 컨테이너, 포드, 컨테이너 이미지 및 볼륨을 위한 API를 제공하는 간단한 커맨드라인 인터페이스(CLI)와 libpod 라이브러리를 통해 이러한 포드를 관리

  2.2.2. Podman의 CLI는 컨테이너 런타임과 형식을 위한 업계 표준을 준수하도록 설계된 Open Container Initiative(OCI) 컨테이너를 생성하고 지원.

  2.2.3.  고도화된 빌드 기능은 상호 보완적인 프로젝트인 Buildah에서 제공됩니다.

 

3. Docker와 비교 

 3.1. Docker

  3.1.1. Docker 사용자인 경우 모든 Docker 명령을 서비스하기 위해 실행해야 하는 데몬 프로세스가 존재

  3.1.2. 모든 걸 Docker Daemon이 통합해서 관리를 한다는 것이 어쩌면 좋게 보일 수도 있으나

  3.1.3. Daemon을 Root권한으로 실행(최근에서 rootless 가능)하는 보안 취약점

  3.1.4. Daemon이 죽거나 재시작되면 모든 Container에 영향을 미침.

  3.1.5. Docker Daemon 역할

   3.1.5.1. 기본적으로 Docker 데몬은 레지스트리, 이미지, 컨테이너 및 커널과 관련된 모든 작업을 수행

   3.1.5.2. Docker 명령줄 인터페이스(CLI)는 데몬에게 사용자를 대신하여  작업을 수행하도록 요청

• 이미지 레지스트리에서 이미지 Pull, Push
• 로컬 컨테이너 스토리지에 이미지 사본 생성, 해당 컨테이너에 레이어를 추가.
• 컨테이너 comit 및 호스트 리포지토리에서 로컬 컨테이너 이미지 제거
• NameSpace와 cgroup 등으로 컨테이너를 실행하도록 커널에 요청.

https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users?extIdCarryOver=true&sc_cid=7013a0000038ArrAAE#how_does_docker_work_

 

  3.1.6. Docker 단점

   3.1.6.1. 단일 프로세스는 단일 실패 지점(single point of failure, SPOF) 가능.

   3.1.6.2. Docker Process는 모든 하위 프로세스(실행 중인 컨테이너)를 소유.

   3.1.6.3. 오류가 발생하면 분리된 프로세스가 존재하게 됨.

   3.1.6.4. 컨테이너를 구축하면 보안 취약점이 발생.

   3.1.6.5. 모든 Docker 작업은 동일한 전체 루트 권한을 가진 사용자(또는 사용자)가 수행.

 

 3.2. Podman 장점

  3.2.1. Podman 접근 방식은 runC 컨테이너 런타임 프로세스(데몬이 아님)를 통해 이미지 레지스트리, 컨테이너 및 이미지 스토리지, Linux 커널과 직접 상호 작용.

https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users?extIdCarryOver=true&sc_cid=7013a0000038ArrAAE#how_does_docker_work_

 

  3.2.2. Docker 데몬과 같은 데몬 프로세스를 시작하거나 관리할 필요가 없슴.

  3.2.3. Docker에서 익숙한 명령은 Podman에서 동일하게 작동.

  3.2.4. Podman은 컨테이너와 이미지를 Docker와 다른 위치에 저장.

  3.2.5. Podman과 Docker 이미지는 호환.

  3.2.6. K8S 환경을 위해 Docker 이상의 기능을 수행.

  3.2.7. Redhat 자료 참조

• 실행, 네트워크 연결, 체크포인트 설정, 삭제를 비롯한 전체 컨테이너 라이프사이클과 컨테이너 이미지를 관리합니다.
• 루트리스 컨테이너와 포드를 위한 리소스를 실행하고 분리합니다.
• OCI, Docker 이미지를 비롯하여 Docker와 호환 가능한 CLI를 지원합니다.
• 데몬이 없는 환경을 조성하여 보안을 강화하고 유휴 리소스 사용을 줄입니다. 
• REST API를 배포하여 Podman의 고급 기능을 지원합니다.
• 유저스페이스의 체크포인트/복원(CRIU) 툴로 Linux 컨테이너에 체크포인트/복원 기능을 구현합니다. CRIU는 실행 중인 컨테이너를 중지하고 메모리 콘텐츠 및 상태를 디스크에 저장하여 컨테이너화된 워크로드를 더 빠르게 재시작할 수 있습니다.
• 컨테이너를 자동으로 업데이트합니다. Podman은 업데이트된 컨테이너가 시작되지 않고 최종 작업 버전으로 자동 롤백하는 경우 이를 감지합니다. 따라서 애플리케이션 신뢰성을 한 차원 높은 수준으로 끌어올립니다. 

 

4. local repository 및 image Storage 

 4.1 Docker

docker local storage

 

 4.2. Podman

podman local storage

 

 4.3. 서로 다른 저장소 경로, 그러나 표준은 podman

  4.3.1. docker 에서 pull한 image가 podman 에서는 표시가 되지 않음

  4.3.2. Podman의 로컬 저장소 /var/lib/containers

  4.3.3. 스토리지 구조는 OCI(Open Containers Initiative) 표준.

  4.3.4. 2015년에 Docker, Red Hat, CoreOS, SUSE, Google 및 Linux 컨테이너 업계의 다른 리더들은 컨테이너 이미지 및 런타임을 정의하기 위한 표준 사양을 관리하는 독립 기관을 제공하기 위해 Open Container Initiative를 만듦. 

  4.3.5. 이러한 독립성을 유지하기 위해  Container/image 및Container/Storage 프로젝트 github 에 생성 .

 

 

새로운 기술의 공부가 스트레스가 될 수도 있지만 가끔은 이렇게 활력을 선사할 때도 있답니다.

그럼 힘차게 나가 볼까요!