컨테이너 기술:: Docker와 Podman

안녕하세요~!! 

다들 어떻게 지내고 계시나요? 저는 얼마전까지 오픈스택 관련 프로젝트를 하다가 얼마전부터 컨테이너와 관련된 일을 하기 시작했어요. 그래서, 컨테이너에 대한 관심도가 매우 높아졌습니다. 그래서, 이번에 스터디한 것들과 기존에 제 경험들을 정리하는 시간을 가져봐야겠다는 생각을 하게 되었어요. 가벼운 마음으로 가볍게 읽어주세요~!! 그리고, 조금이나마 여러분에게 도움이 되었으면 좋겠습니다.

가상머신과 컨테이너

요즘 기술 트렌드를 보면 가상화 기술에서 컨테이너 기술로 사람들의 관심이 많이 넘어가고 있는 추세입니다. 왜 이렇게 컨테이너 기술에 사람들은 열광을 하는걸까요? 기술은 계속 진화하여 메인프레임 시대에서 클라우드 컴퓨팅 시대로 넘어 왔습니다. 수개월이 걸리던 시스템 구성을 단 몇 분안이면 끝낼 수 있는 환경이 되었습니다. 어플리케이션 또한, 동일 서버에서 모든 프로세스가 실행되던 방식에서 여러 분산된 환경에서 프로세스가 독립적으로 실행이 되도록 변경되었습니다. 이는 무엇을 의미할까요? 이제 누가 더 빨리 비즈니스 어플리케이션을 시장에 출시하느냐가 중요한 핵심 포인트가 되었다는 뜻일 것입니다.  

 

따라서 이제는 가상화를 모르면 시스템을 운영하기조차 힘든 상황이 되어 버렸습니다. 이런 상황에서 기존에 사용하던 하이퍼바이저 위의 가상머신은 CPU, Memory, Network, Disk와 같은 물리자원을 가상화하여 사용함으로써 무거운데 반면, 운영체제 위의 컨테이너는 라이브러리 형식으로 가볍게 올라가 설치하고자 하는 어플리케이션만 실행하면 되기 때문에 매우 가볍습니다.

레드햇의 새로운 컨테이너 기술 Podman

아마도 컨테이너 하면 떠오르는 단어는 Docker일 것입니다. 그리고, Docker엔진을 통해 올라 가는 컨테이너를 관리하기 위한 가장 대표적인 관리 소프트웨어가 바로 Kubernetes일 것입니다. 그런데, 2017년에 Docker가 엔터프라이즈 버전을 상용화하면서 레드햇은 또다른 컨테이너 오픈소스 기술인 Podman을 사용하여 레드햇의 엔터프라이즈 제품들을 출시하였습니다. 

가장 먼저 2019년 3월에 릴리즈한 Red Hat Enterprise Linux 8에 Podman이 추가되었습니다. 그리고, 뒤이어 릴리즈 된 Red Hat OpenShift Container Platform 4와 Red Hat OpenStack Platform 16 모두 Docker에서 Podman으로 변경되었습니다. 

컨테이너 기술 Docker와 Podman

Docker와 Podman은 매우 유사한것 같지만, Docker와 Podman은 엄연히 크게 다른 부분이 존재합니다. 그럼 Docker와 Podman은 어떤 부분이 같고, 어떤 부분이 다른 걸까요? 지금부터 Docker와 Podman의 기술을 알아보겠습니다.

 

Docker는 애플리케이션을 빌드하고 컨테이너화하기 위한 Docker Engine, 컨테이너 이미지를 배포하고 제공하기 위한 Docker Registry, 여러개의 컨테이너 애플리케이션을 정의하고 실행하기 위한 Docker Compose, 사용자의 로컬 컴퓨터나 클라우드 인스턴스에 도커 호스트를 구성해주는 Docker Machine, 컨테이너 클러스터링 및 스케줄링을 위한 Docker Swarm으로 구성됩니다. Podman은 Docker의 핵심 기능인 Docker Engine 기능과 유사하다고 볼 수 있습니다. 

Docker Engine에는 컨테이너 이미지를 관리하고, 컨테이너 이미지를 이용해 컨테이너를 실행하기 위한 Docker daemon이 있습니다. 그리고, 이미지와 컨테이너를 사용자가 관리하고 사용할 수 있도록 커맨드 기반으로 된 Docker Client가 있습니다. Podman 역시 컨테이너를 실행하기 위한 컨테이너 이미지, 그리고, 이미지를 통해 실행된 컨테이너와 이를 사용하기 위한 커맨드 기반의 유틸리티가 있습니다. 

Docker는 컨테이너 레지스트리로부터 이미지를 받아와 Docker 내부의 이미지 저장소에 저장을 합니다. 그리고, 이미지 저장소에 저장된 이미지를 이용하여 컨테이너를 실행할 수 있으며, 실행 중인 컨테이너를 이미지로 빌드할 수도 있습니다. Docker는 이런 다양한 작업들을 Docker daemon을 통해 수행합니다. 그렇기 때문에 데몬에 문제가 발생했을 경우 모든 컨테이너와 이미지에 영향이 가며, 커맨드 명령어로 컨테이너를 제어할 때도 영향을 미칩니다. 

반면에 Podman은 daemon 없이 커맨드로 컨테이너 레지스트리로부터 이미지를 받아와 Podman 호스트의 로컬 이미지 저장소에 이미지를 저장하고, 해당 이미지를 이용하여 컨테이너를 실행합니다. 이때 podman 라이브러리를 통해 바로 컨테이너를 실행하기 때문에 컨테이너 간에 서로 영향을 주지 않으며, 컨테이너와 이미지 사이, 커맨드 명령어로 컨테이너를 제어하거나 이미지를 관리할 때도 서로 영향을 주지 않습니다.

내가 경험한 컨테이너 이야기

이는 Docker 기반이였던 Red Hat OpenStack Platfom 13을 사용했을때와 현재 Red Hat OpenStack Platform 16에서 확실하게 경험할 수 있었습니다. 사실 Red Hat OpenStack은 11버전 (Ocata)부터 오픈스택의 모든 서비스들을 컨테이너화하기 위한 준비를 하고 있었습니다. 그리고, 13버전 (Queens)에서 Docker기반으로 오버클라우드의 오픈스택 서비스들이 모두 컨테이너 화가 되었습니다. 이 당시 모 프로젝트에서 OpenStack 13버전을 구축하게 되었는데, 그 당시  구축했던 버전의 Https Health-Check에서 메모리 누수 현상이 발생을 했었습니다. 메모리를 사용하면 메모리를 다시 반환해야 하는데, 반환하지 않아 사용 가능한 메모리가 줄어드는 현상이였습니다. 이런 경우 Docker 엔진이 영향을 받고, Docker 엔진이 정상적으로 수행할 수 없는 상태가 되면, 그 위에 올라가 있는 모든 컨테이너가 정상 동작을 하지 않습니다. 이렇게 되면 시스템 재부팅시 컨테이너를 모두 종료하고 시스템이 다운되는데, Docker 엔진이 정상적으로 종료되지 않기 때문에 컨테이너들을 제대로 종료할 수 없었습니다. 따라서, 강제 종료를 해야만 하는 상황이 발생을 합니다. 물론 이 문제는 그 다음 릴리즈에서 모두 해결되어 현재 설치하는 OpenStack 13 버전에서는 찾아볼 수 없는 현상이 되었습니다.

그런데, 이번에 릴리즈한 OpenStack 16(Train) 버전에서는 Docker 기반이 아닌 Podman으로 변경이 되었고, 설상가상으로 위와 같은 상황이 동일하게 발생한다고 하더라도, 특정 데몬 위에서 컨테이너가 실행되는 것이 아니므로 모든 컨테이너에 영향을 주지는 않을 것입니다. 문제가 발생한 특정 컨테이너만 트러블 슈팅을 하고 조치를 취하면 되기 때문입니다.

마무리

2000년대로 넘어오면서 기술은 빠르게 발전하고 있습니다. 가상화 개념이 나오고, 이를 이용하여 클라우드 컴퓨팅이라는 개념이 나왔습니다. 그리고, 가상화에 이어 컨테이너 개념이 나오기 시작 했으며, 이런 환경들은 개발 방법 뿐 아니라 IT 비즈니스 산업 흐름을 바꾸어 놓았습니다. 본 글을 통해 IT 비즈니스 산업 흐름의 중심에 있는 컨테이너 기술을 이해하는데 조금이나마 도움이 되었으면 좋겠습니다. 

 

 

::: 참고자료 :::

[Container] Podman 설치 및 사용법 

https://chhanz.github.io/container/2020/03/02/podman/

[Linux] RHEL 8, CentOS 8 주요 기능 정리 

https://sysops.tistory.com/97

Linux Container Technology 101 

https://www.slideshare.net/insideHPC/linux-container-technology-101

Podman, Buildah, and Quarkus - The latest in linux containers

https://www.slideshare.net/DanielOh20/podman-buildah-and-quarkus-the-latest-in-linux-containers-technologies