Offcanvas

가상화 / 개발자 / 애플리케이션 / 클라우드

컨테이너 분야의 '요즘 애들', 포드맨을 아시나요?

2022.06.21 Jacqueline Primavera  |  InfoWorld
갑자기 플레이어가 많아지고 있는 새로운 컨테이너 지형에서 ‘포드맨(Podman)’은 떠오르는 스타다. 여기서는 포드맨이란 무엇이며, 도커와 어떻게 다른지 등을 살펴본다. 

포드맨은 ‘컨테이너 엔진’이다. 즉, 컨테이너 및 컨테이너 이미지를 개발, 관리, 실행하기 위한 도구다. 컨테이너는 사용자 정의 없이 어디서나 실행하는 데 필요한 모든 요소(예: 애플리케이션 코드, 지원 라이브러리 등)를 갖추고 있는 표준화된 독립형 소프트웨어 패키지다. 컨테이너 기반 애플리케이션은 분산형 및 클라우드 기반 시스템을 쉽게 배포하고 유지관리할 수 있게 하면서 소프트웨어 개발에 일대 혁신을 일으켰다. 

레드햇의 프로젝트인 포드맨은 오픈소스이며 무료로 다운로드할 수 있다. 이는 지난 2019년 버전 1.0이 출시됐으며, 컨테이너화 업계에서는 비교적 신참이다. 그 이후로 포드맨은 약진을 거듭했다. 게다가 여러 면에서 오늘날의 컨테이너 세계를 만든 프로젝트인 ‘도커(Docker)’의 점진적인 쇠퇴로 이러한 포드맨의 상승세가 더욱 부각되고 있다. 
 
ⓒGetty Images Bank

포드맨과 쿠버네티스
컨테이너 기반 개발을 조금이라도 안다면 ‘쿠버네티스(Kubernetes)’도 알 것이다. 컨테이너화된 애플리케이션이 점점 더 복잡해지면서 개발자들은 다양한 가상머신, 심지어는 서로 다른 물리적 머신에서 실행되면서 상호작용하는 컨테이너를 조정할 수 있는 도구가 필요했다. 

그러한 도구를 ‘컨테이너 오케스트레이션 플랫폼’이라고 하는데, 그중 쿠버네티스가 가장 유명하다. 쿠버네티스는 오픈 컨테이너 이니셔티브(Open Container Initiative; OCI) 이미지 사양을 충족하는 모든 컨테이너와 함께 사용할 수 있으며, 포드맨의 컨테이너도 마찬가지다.

쿠버네티스의 중요한 특징으로 ‘포드(pod)’ 개념이 있다. 포드란 쿠버네티스가 관리할 수 있는 최소의 컴퓨팅 단위인 하나 이상의 컨테이너를 임시로 그룹화한 것이다. 포드맨 역시 이름에서 알 수 있듯이 포드 개념을 기반으로 한다. 포드맨 포드에도 단일 네임스페이스, 네트워크, 보안 컨텍스트로 그룹화된 하나 이상의 컨테이너가 포함돼 있다. 이러한 유사점 때문에 포드맨과 쿠버네스는 자연스럽게 어울린다. 처음부터 레드햇의 목표는 포드맨 사용자가 쿠버네티스로 컨테이너를 오케스트레이션하는 것이었다.

포드맨 vs. 도커
컨테이너 세계에서 틀림없이 들어봤을 또 다른 거물급 이름은 도커다. 도커는 최초의 컨테이너 엔진은 아니었지만 여러 면에서 컨테이너화를 정의했다. 도커의 작동 방식 중 대부분이 컨테이너 기반 개발의 사실상 표준이고, 많은 사람이 컨테이너를 ‘도커’라고 부를 정도다.

도커와 포드맨은 컨테이너 생태계에서 비슷한 공간을 차지하지만 서로 같지 않다. 작동 방식의 철학과 접근 방식이 다르다. 예를 들면 도커는 특정 작업용 도구를 두루 갖춘 올인원 플랫폼인 반면, 포드맨은 특정 목적을 위해 다른 프로젝트와 협업한다. 가령 빌다(Buildah)를 활용하여 컨테이너 이미지를 빌드하는 식이다. 

아키텍처의 차이점도 있다. 일례로 도커에는 네이티브 포드 개념이 없다. 또 다른 중요한 차이점은 도커는 지속적으로 실행되는 백그라운드 데몬 프로그램을 기반으로 이미지를 생성하고 컨테이너를 실행하는 반면, 포드맨은 컨테이너와 포드를 별도의 하위 프로세스로 실행한다. 도커 설계의 이러한 측면은 보안에 큰 영향을 미친다. 

한편 포드맨과 도커는 설계상(그리고 필요에 의해) 전체적으로 호환된다. 이러한 호환성은 부분적으로 개방형 표준을 준수하기 때문이다. 포드맨과 도커 모두 OCI 표준을 준수하는 컨테이너에서 작동하기 때문에 도커로 컨테이너를 생성한 후 포드맨에서 수정할 수 있거나 반대로 포드맨에서 컨테이너를 만든 후 도커에서 수정할 수 있으며, 해당 컨테이너를 쿠버네티스로 배포할 수 있다.

2019년 포드맨 출시 당시에는 도커가 우세했다. 도커의 명령줄 인터페이스가 많은 개발자의 프로그래밍 루틴으로 자리 잡았을 정도였다. 포드맨 개발팀은 도커에서 포드맨으로의 이동을 원활하게 만들기 위해 포드맨의 명령어와 구문에 도커를 최대한 반영하도록 했다. 심지어는 도커 명령어를 포드맨으로 다시 라우팅하는 별칭을 설정할 수 있게 하기도 했다. 

루트리스 컨테이너로 보안 강화
포드맨과 도커의 작동 방식이 여러 면에서 흡사하다면 굳이 한 쪽을 선택할 이유가 있을까? 한 가지 중요한 이유는 보안이다. 앞서 언급한 것처럼 도커는 데몬을 기반으로 진행 중인 작업의 대부분을 수행한다. 이 대몬은 루트로 실행되기 때문에 공격자의 잠재적인 진입점이 될 수 있다. 이것이 안전한 컴퓨팅을 위해 극복할 수 없는 장애물은 아니지만 도커 보안 문제와 관련해 어느 정도 주의를 기울여야 한다는 것은 분명하다.

호스트 시스템에서 루트 권한으로 컨테이너를 실행하고 싶다면 포드맨은 가능하다. 컨테이너를 안전하게 사용자 공간으로만 제한하고 싶을 때도 마찬가지다. 소위 ‘루트리스(rootless) 컨테이너’를 실행하면 된다. 루트리스 컨테이너의 권한은 컨테이너를 실행한 사용자보다 많지 않다. 컨테이너 내에서 해당 사용자가 루트 권한을 갖는다. 명령줄 플래그를 사용하여 컨테이너에 세부적으로 권한을 추가할 수도 있다.

성능은?
일각에서는 적어도 도커가 포드맨보다 우위에 있는 분야가 바로 성능이라고 말한다. 물론 구체적인 정보는 거의 없지만 해커뉴스(Hacker News), 스택 오버플로우(Stack Overflow), 레딧(Reddit) 등에서 포드맨의 성능, 특히 루트 없이 실행될 때의 성능에 불평불만을 하는 개발자를 찾기란 어렵지 않다. 한 스웨덴 대학생이 여러 컨테이너 플랫폼에서 벤치마크를 실행한 결과, 1.0 이전 버전이긴 했으나 포드맨의 성능이 부족한 것으로 나타났다

포드맨이 도커를 대체할까?
지금까지의 논의 내용으로는 도커를 포드맨으로 대체하려는 큰 움직임은 없어 보인다. 하지만 오랜 틈새시장 중 하나에서 도커를 대체할 중대한 변화가 오고 있다. 바로 쿠버네티스다. 

쿠버네티스와 도커는 수년 동안 컨테이너 세계의 양대 거물로 군림해 왔다. 그러나 이 둘의 공존은 언제나 다소 불안했다. 쿠버네티스의 부상은 도커가 그 틈새시장에 정착한 후 이뤄졌다. 아닌 게 아니라 쿠버네티스가 인기를 얻은 이유는 대규모 분산형 애플리케이션에서 조정이 필요한 모든 컨테이너 관리를 도커가 제대로 하지 못한 탓도 있다.

이에 도커(개발사)는 지난 2015년 ‘스웜(Swarm)’이라는 자체 컨테이너 오케스트레이션 플랫폼을 개발했다. 스웜은 화려하게 출시됐지만 쿠버네티스를 따라잡진 못했다. 물론 스웜에도 열성 팬이 있긴 하지만 쿠버네티스가 사실상 컨테이너 오케스트레이션의 표준으로 자리 잡았다. 컨테이너 생태계의 다른 측면에서 도커가 사실상의 표준이 된 것과 마찬가지다.

게다가 도커는 컨테이너 런타임 측면에서 쿠버네티스와의 궁합이 좋지 않았다. 컨테이너 런타임은 기본 OS 커널에서 작동하고 개별 컨테이너 이미지를 마운트 하는 컨테이너 엔진의 하위 수준 구성요소다. 도커와 쿠버네티스 모두 쿠버네티스가 컨테이너에 빌드된 이미지를 조정하는 데 사용하는 OCI 이미지 사양을 준수한다. 하지만 쿠버네티스는 도커가 구축한 적 없는 표준화된 플러그인 API와 호환되는 컨테이너 런타임 ‘ CRI(Container Runtime Interface)’를 활용한다. 

오랫동안 도커의 인기로 인해 쿠버네티스는 어쩔 수 없이 도커심(Dockershim)을 사용해야 했다. 도커심은 쿠버네티스와 도커 데몬 사이의 중개자인 CRI 호환 계층이다. 하지만 도커심 사용은 언제나 일종의 꼼수였다. 올해 초 쿠버네티스는 도커심 지원을 중단했다(반대로 포드맨은 CNCF의 호환 CRI-O 런타임을 사용한다).

간단히 말해, 도커는 쿠버네티스에서 완전히 벗어나지 못했다. 반면에 쿠버네티스는 더 이상 예전만큼 도커가 필요하지 않다.

포드맨이 도커를 대체할지는 불분명하지만 경쟁자 중 하나가 될 것이라는 점은 확실하다. 포드맨이 수익화를 꾀하는 주력 제품이 아니라 큰 회사가 제공하는 단일 오픈소스 기술이라는 점도 유리하다. 앞으로 당분간은 포드맨과 쿠버네티스가 서로 얽혀 있으리라 예상할 수 있다.  

어떤 컨테이너 엔진을 사용해야 할까?
이 논의가 두 컨테이너 엔진 중 양자택일에 도움이 되길 바란다. 포드맨은 더 안전한 아키텍처를 기반으로 하는 반면, 도커는 역사가 더 깊다. 또한 포드맨은 쿠버네티스 네이티브인 반면, 도커는 도커 스웜과도 연동된다. 아울러 도커에는 많은 컨테이너 작업에 필요한 모든 기능이 들어 있다. 포드맨은 모듈식이고, 다양한 목적에 맞게 다양한 도구를 실험할 수 있다.

하지만 ‘포드맨이냐 도커냐’의 이분법적 문제로 보는 건 잘못된 측면이 있다. 두 플랫폼 모두 OCI 사양을 따르는 이미지를 생성하며 동일한 명령어로 구동되기 때문에 양쪽을 원활하게 오갈 수 있다. 예를 들면 도커를 로컬 개발용으로 사용한 후 포드맨은 쿠버네티스 내부에 구축한 컨테이너를 배포하는 용도로 사용하면 좋다.

도커의 한 가지 차별화 요소는 유료 지원이다. 물론 여기에도 반갑지 않은 이면이 있다. 도커(개발사)가 주력 제품의 수익화를 시도하면서 도커 데스크톱 개발 환경에 비용을 청구하기 시작한 것이다. 반면 레드햇은 현재로서는 포드맨을 (마치 맥주처럼?) 계속 무료로 제공하는 데 만족하는 것 같다. ciokr@idg.co.kr
 
Sponsored
추천 테크라이브러리

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.