Podman Compose vs Docker Compose 차이점
Podman Compose vs Docker Compose 차이점, 배포에 대해 알려드립니다.
Podman Compose vs Docker Compose 차이점
컨테이너 오케스트레이션 도구인 Podman Compose와 Docker Compose 사이의 주요 차이점에 대해 알아보겠습니다. 이 두 도구는 모두 여러 컨테이너를 정의하고 관리하는 데 사용되지만, 몇 가지 중요한 차이점을 가지고 있습니다.
- 데몬: Docker Compose는 Docker 데몬에 의존합니다. 이는 모든 Docker 컨테이너가 해당 데몬을 통해 관리되어야 함을 의미합니다. 반면에 Podman은 “데몬 없음” 원칙을 따르며, 각각의 컨테이너가 별도의 프로세스로 실행됩니다.
- 권한: Docker Compose를 실행하려면 일반적으로 root 권한이 필요합니다. 이는 보안 문제를 야기할 수 있습니다. 반면에 Podman과 Podman Compose는 기본적으로 root 권한 없이 실행됩니다.
- 호환성: 현재 Podman Compose는 대부분의 Docker Compose 기능을 지원하지만, 아직 모든 기능을 완벽하게 지원하지 않습니다.
- OCI표준: Podman은 OCI(Open Container Initiative) 표준을 준수합니다, 즉 다양한 컨테이너 런타임 환경에서 호환성을 유지하는 것에 중점을 둡니다.
- 컨테이 저장소 위치: Docker compose가 /var/lib/docker 내부에서 이미지와 컨테이너를 저장하는 반면, podman compose은 사용자 계정 내부에서 저장소를 만들어서 관리합니다.
예) /home/{username}/.local/share/containers
Podman Compose를 통한 배포
이번에는 간단한 실습으로 podman-compose를 직접 사용해 보도록 하겠습니다.
Podman 설치
Red Hat Enterprise Linux(RHEL)에서 Podman을 설치하는 방법은 다음과 같습니다.
RHEL 8이상에서는 Podman이 기본적으로 사용 가능합니다. 만약 Podman 패키지가 없다면, 아래의 명령어로 설치할 수 있습니다.
$ sudo yum -y module install container-tools
위의 명령어를 통해 Podman을 설치한 후, 다음과 같이 버전 정보를 확인하여 정상적으로 설치되었는지 검증할 수 있습니다.
$ podman --version
또한 podman info
명령어를 통해 시스템의 컨테이너 환경에 대한 상세 정보도 확인할 수 있습니다. 참고로, RHEL 7에서는 yum 패키지 관리자를 사용하여 아래와 같이 Podman을 설치할 수 있습니다:
$ sudo yum -y install podman
Podman-Compose 설치
Podman-compose는 Python 패키지로 제공되므로, pip를 사용하여 설치할 수 있습니다. 먼저 Python과 pip가 시스템에 설치되어 있는지 확인해야 합니다. 또는 시스템 전체에 대해 root 권한으로 설치하려면 다음과 같이 실행합니다:
/* python2인 경우 */
$ sudo pip install podman-compose
또는
/* python3인 경우 */
$ sudo pip3 install podman-compose
설치가 완료된 후, 아래의 명령어를 통해 정상적으로 설치되었는지 확인할 수 있습니다:
$ podman-compose --version
Podman-Compose를 통한 컨테이너 배포
다음은 docker-compose.yml 파일을 사용하여 WordPress와 MySQL을 실행하는 간단한 예제입니다.
version: '3.1'
services:
db:
image: mysql:5.7
restart: always
environment:
MYSQL_ROOT_PASSWORD: example
wordpress:
image: wordpress:latest
ports:
- 8080:80
restart: always
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: root
WORDPRESS_DB_PASSWORD: example
위의 docker-compose.yml 파일을 저장한 후, 다음 명령어를 실행하여 컨테이너를 시작할 수 있습니다:
$ podman-compose up -d
$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0dd1be411a7b docker.io/library/mysql:5.7 mysqld 41 seconds ago Up 42 seconds root_db_1
be4d8bda9cbb docker.io/library/wordpress:latest apache2-foregroun... 40 seconds ago Up 40 seconds 0.0.0.0:8080->80/tcp root_wordpress_1
이제 웹 브라우저에서 localhost:8080으로 접속하면 WordPress 사이트를 볼 수 있습니다. 간단하게 command 창에서 확인하시고 싶으시면 curl localhost:8080 통해 확인 가능합니다.
참고로, 위 예제에서는 MySQL과 WordPress에 대한 간단한 환경 설정만 포함하였으며 실제 운영 환경에서는 보안과 성능 최적화 등 추가적인 설정이 필요합니다.
Docker Compose 와 Podman-Compose 비교 표
Docker Compose와 Podman Compose는 컨테이너 오케스트레이션 도구로서, 유사한 목적을 가지고 있지만, 일부 가능 및 특성에서 차이가 있습니다. 다음은 Docker Compose와 Podman Compose를 표로 비교한 것입니다.
특성/기능 | Docker Compose | Podman Compose |
컨테이너 관리 | Docker 엔진 사용 | Podman 엔진 사용 |
컨테이너 정의 파일 | docker-compose.yml 파일 사용 |
podman-compose.yaml 파일 사용 |
Rootless 모드 지원 | 아니요 | 예 |
컨테이너 실행 | docker-compose up 명령어 |
podman-compose up 명령어 |
컨테이너 중지 및 제거 | docker-compose down 명령어 |
podman-compose down 명령어 |
컨테이너 로그 확인 | docker-compose logs 명령어 |
podman-compose logs 명령어 |
컨테이너 스케일링 | 지원 | 지원 |
다중 컴포즈 파일 지원 | 아니요 | 예 |
컨테이너 네트워크 설정 | 기본적으로 도커 네트워크 사용 | CNI 네트워크 사용 가능 |
커스텀 컨테이너 빌드 지원 | 지원 | 지원 |
컨테이너 환경 변수 설정 | environment 필드 사용 |
environment 필드 사용 |
볼륨 마운트 설정 | volumes 필드 사용 |
volumes 필드 사용 |
포트 포워딩 설정 | ports 필드 사용 |
ports 필드 사용 |
환경 변수 파일(.env) 지원 | 지원 | 아니요 |
컨테이너 의존성 설정 | depends_on 필드 사용 |
depends_on 필드 사용 |
사용자 정의 브리지 네트워크 | 지원 | 예 |
커스텀 로깅 드라이버 설정 | 지원 | 아니요 |
보안기능 | 도커 보안 기능 사용 | Podman 보안 기능 사용 |
자료출처: ChatGPT (https://chat.openai.com/)
이러한 차이점을 고려하여 Docker Compose와 Podman Compose 중 어떤 것을 사용할지 선택할 수 있습니다. 만약 루트리스(Non-root) 환경에서 컨테이너를 관리하려는 경우나 Docker를 대체할 수 있는 도구를 찾고 있다면, Podman Compose를 고려해볼 만합니다. 그러나 기존에 Docker Compose를 사용하고 있거나 Docker의 기능에 의존하고 있다면 Docker Compose를 계속 사용하는 것이 더 간편할 수 있습니다.
마치며…
이처럼 Podman Compose는 데몬 없이 작동하고, rootless 모드를 지원하는 등 Docker에 비해 간단하고 보안성이 향상된 컨테이너 관리 도구입니다.
Docker Compose와 호환성을 가지며 벤더 독립적인 오픈소스 프로젝트로서 새로운 가능성을 제공 받고 싶으신 사용자에게 큰 도움이 될 것 같습니다.
이제는 클라우드 네이티브 (Cloud Native) 기반 온프레미스 2.0 시대
/in Cloud, Tech Talk/by 오픈마루 마케팅3레드햇 주요 제품 life-cycle 업데이트 소식 – RHEL, OpenShift, Red Hat OpenStack, Red Hat OpenJDK
/in OPENMARU, Tech Talk/by 오픈마루 마케팅3잠깐! 클라우드 네이티브 사업에 HCI 서버를 검토하시나요?
/in Tech Talk/by 오픈마루 마케팅3