현재 재직중인 회사에서는 docker와 podman을 같이 사용하고 있다. 그래서 보통 나는 레퍼런스가 많은 docker를 주로 사용하고 docker가 설치되어있는 PC에서 주로 개발을 진행하였다. 하지만 이번에 개발하는 과정에서 podman을 사용하게 되었는데 기존에 docker에서 사용하였던 명령어들이 정상적으로 동작되지 않아 며칠을 고생해서.... 다음번에는 까먹지 않게 이번에 정리해보고자 한다.
Docker란?
Docker는 컨테이너 기술을 활용하여 애플리케이션을 독립적이고 이식성 높은 환경에서 실행하도록 설계된 오픈소스 플랫폼 입니다. 컨테이너를 통해 애플리케이션과 그에 필요한 모든 라이브러리, 의존성, 설정을 묶어 어디서든 동일한 환경에서 실행될 수 있도록 보장합니다.
"출처 ChatGPT"
특징
1. 컨테이너 기반 가상화
- VM(Virtual Machine)처럼 전체 운영 체제를 에뮬레이트하지 않고, 호스트 OS 커널을 공유하여 애플리케이션을 격리.
- 리소스 오버헤드가 적고, 빠르게 시작 및 종료.
2. 이식성(Portability)
- Docker 이미지는 OS와 독립적이어서 한 번 빌드한 이미지를 다양한 플랫폼(로컬, 클라우드, 서버)에서 실행 가능.
3. 경량화(Lightweight)
- 컨테이너는 필요한 라이브러리와 애플리케이션 코드만 포함하므로 VM에 비해 크기가 작고 실행 속도가 빠름.
4. 확장성(Scalability)
- Docker는 컨테이너를 클러스터로 관리하기 위한 오케스트레이션 도구(Kubernetes, Docker Swarm)와 통합 가능.
5. 버전 관리 및 복제 가능성
- Docker 이미지는 버전 관리를 통해 특정 버전의 상태를 저장하고 복원 가능.
- Dockerfile을 통해 컨테이너 이미지를 손쉽게 복제하거나 재생성 가능.
6. 개발-운영 간의 격차 해소
- 컨테이너 안에서 애플리케이션을 실행하므로 개발, 테스트, 프로덕션 환경의 차이를 줄여 "Works on my machine" 문제를 해결.
동작
1. 이미지 다운로드 및 생성
docker pull을 통해 Docker Hub 또는 다른 레지스트리에서 이미지를 가져옴.- Dockerfile 작성을 통해 이미지를 생성.
2. 컨테이너 실행
docker run명령으로1. 이미지 다운로드 및 생성과정을 통해 생성한 이미지를 기반으로 컨테이너를 생성하고 실행.
3. 애플리케이션 실행
- 컨테이너 내부에서 애플리케이션이 실행
4. 컨테이너 관리
docker ps,docker start,docker stop,docker logs등의 명령어로 컨테이너를 관리
Podman란?
Podman은 데몬리스(Daemonless) 컨테이너 관리 도구로, 컨테이너를 생성, 실행, 관리하는 기능을 제공합니다.
Docker와 비슷한 CLI 명령어를 제공하지만, 보안과 성능을 중시하며 설계된 도구입니다.
특히 루트 권한 없이도 컨테이너를 실행할 수 있는 Rootless Containers 기능이 주요 특징입니다.
특징
1. 데몬리스(Daemonless)
- Docker는 dockerd라는 데몬 프로세스를 사용하지만, Podman은 데몬 없이 컨테이너를 관리함.
- 사용자가 명령을 실행할 때만 Podman 프로세스가 실행되므로, 불필요한 리소스 소비가 적음.
2. 루트리스(Rootless) 컨테이너
- Podman은 루트 권한 없이 컨테이너를 실행할 수 있어 보안성이 높음.
- 컨테이너가 사용자의 네임스페이스에서 실행되므로 시스템에 대한 영향을 최소화.
3. Docker와의 CLI 호환성
- 대부분의 Docker CLI 명령어를 지원하며, alias docker=podman을 설정하면 Docker처럼 사용할 수 있음.
- Docker 이미지와 네트워크 설정도 호환.
4. Pod 지원
- Kubernetes의 Pod 개념을 기본적으로 지원하여, 여러 컨테이너를 하나의 단위로 관리 가능.
5. OCI 표준 준수
- 컨테이너 이미지 및 런타임을 관리하기 위해 OCI 표준을 따릅니다.
- 이미지를 Buildah(이미지 빌드 도구)나 Skopeo(이미지 복사 도구)와 연계하여 사용할 수 있음.
6. 보안 및 성능 강화
- 데몬이 없기 때문에 데몬 프로세스의 보안 이슈가 제거됨.
- 컨테이너가 사용자 권한으로 실행되므로 보안성이 뛰어남.
동작
1. 이미지 다운로드 및 생성
podman pull을 통해 Docker Hub 또는 다른 레지스트리에서 이미지를 가져옴.- Dockerfile 작성을 통해 이미지를 생성.
2. 컨테이너 실행
podman run명령으로1. 이미지 다운로드 및 생성과정을 통해 생성한 이미지를 기반으로 컨테이너를 생성하고 실행.
3. Pod 생성
- 다중 컨테이너를 단일 Pod로 묶어서 실행.
podman pod create --name mypod -p 8080:80
podman run --pod mypod -d nginx4. 컨테이너 관리
podman ps,podman start,podman stop,podman rm등의 명령어로 컨테이너를 관리
Docker와 Podman 차이점
1. 기본 구조
| 항목 | Docker | Podman |
|---|---|---|
아키텍처 | 클라이언트-서버 구조. Docker Daemon이 컨테이너를 관리. | 데몬리스 아키텍처로 데몬이 없어 개별 프로세스가 직접 컨테이너를 실행 |
데몬 | dockerd라는 중앙 데몬을 사용해 컨테이너를 관리. | 별도의 데몬 없이 독립적으로 컨테이너 실행 및 관리. |
2. 설치 및 실행
| 항목 | Docker | Podman |
|---|---|---|
설치 | Docker Engine과 Docker CLI를 설치. | 단일 바이너리로 설치가 간단. |
권한 요구 | Docker Daemon은 루트 권한으로 실행됨. | 루트리스 모드 지원으로 일반 사용자 권한으로 실행 가능. |
3. 컨테이너 관리 방식
| 항목 | Docker | Podman |
|---|---|---|
컨테이너 실행 | 중앙 데몬이 컨테이너를 실행하고 관리. | 프로세스 자체가 컨테이너를 관리. |
컨테이너 ID | 데몬이 컨테이너 프로세스의 부모 프로세스. | 컨테이너는 개별적으로 실행되어 독립적 프로세스. |
4. 보안
| 항목 | Docker | Podman |
|---|---|---|
보안 모델 | 루트 권한으로 실행되는 데몬은 보안 취약점이 될 수 있음. | 데몬이 없어 보안 취약점이 적으며, 루트리스 모드 지원. |
사용자 권한 | 기본적으로 루트 권한으로 실행됨. | 일반 사용자 권한으로 실행 가능하여 보안성이 더 높음. |
5. 이미지 관리
| 항목 | Docker | Podman |
|---|---|---|
이미지 포맷 | Docker 이미지를 사용. | Docker 이미지와 동일한 OCI(오픈 컨테이너 이니셔티브) 포맷을 사용. |
이미지 호환성 | Docker Hub 또는 개인 레지스트리를 사용. | Docker Hub와 호환되며 Podman 자체 레지스트리도 지원. |
6. 네트워킹
| 항목 | Docker | Podman |
|---|---|---|
네트워킹 | Docker 데몬이 네트워크를 생성 및 관리. | CNI(컨테이너 네트워킹 인터페이스) 플러그인 사용. |
네트워크 설정 | 기본적으로 Docker가 자동 설정. | 네트워크는 사용자가 명시적으로 구성해야 함. |
7. 툴링 및 에코시스템
| 항목 | Docker | Podman |
|---|---|---|
에코시스템 | 풍부한 Docker Compose, Swarm, Docker Desktop 등 다양한 도구 제공. | Podman Compose로 Docker Compose와 호환 가능. |
쿠버네티스 통합 | Kubernetes의 CRI를 직접 지원하지 않음. | Kubernetes와 직접 통합(CRI-O와 호환). |
8. 성능
| 항목 | Docker | Podman |
|---|---|---|
성능 | 데스크톱 개발 환경, 기존 Docker 중심의 워크플로우. | 보안이 중요한 환경(루트리스 모드), Kubernetes 연동. |
결론
- Docker는 오랫동안 컨테이너 관리의 표준으로 자리 잡아온 도구로, 강력한 에코시스템과 사용자 친화적 경험을 제공함.
- Podman은 데몬이 없고 루트리스 모드로 실행 가능해, 보안과 성능 면에서 이점이 있습니다. 특히 Kubernetes와의 통합이 강점임.
예시
- 현재 회사에서 생성이 필요한 이미지 정보로 이미지를 생성하는 대략적인 예시를 작성해보자.
- nvidia docker 설치가 필수
Dockerfile 작성
- Spring Boot 프로젝트에서 AI 서비스를 제공하기 위해 java 및 cuda 라이브러리를 설치하고 현재 서비스가 필요한 솔루션 패키지 구조를 같이 올려 해당 솔루션도 같이 실행하는 내용을 담은 예제이다.
FROM rockylinux:8.9-minimal
ADD docker/amazon-corretto-8-x64-linux-jdk.tar.gz /usr/lib/jvm/
RUN microdnf install -y glibc-langpack-ko \
&& microdnf clean all
# locale 설정
ENV LANG ko_KR.utf8
ENV LC_ALL ko_KR.utf8
# java 환경 설정
ENV JAVA_HOME /usr/lib/jvm/amazon-corretto-8.432.06.1-linux-x64
ENV PATH $PATH:${JAVA_HOME}/bin
RUN microdnf install -y wget \
&& wget --progress=bar:force:noscroll -P /tmp https://developer.download.nvidia.com/compute/cuda/11.6.2/local_installers/cuda-repo-rhel8-11-6-local-11.6.2_510.47.03-1.x86_64.rpm \
&& rpm -i /tmp/cuda-repo-rhel8-11-6-local-11.6.2_510.47.03-1.x86_64.rpm \
&& wget --progress=bar:force:noscroll -P /etc/yum.repos.d/ https://developer.download.nvidia.com/compute/cuda/repos/rhel8/x86_64/cuda-rhel8.repo \
&& microdnf install -y cuda-toolkit-11-6 \
&& microdnf install -y libcudnn8 libcublas-12-4 \
&& microdnf remove -y cuda-repo-rhel8-11-6-local \
&& microdnf clean all \
&& rm -f /tmp/cuda-repo-rhel8-11-6-local-11.6.2_510.47.03-1.x86_64.rpm \
&& rm -f /usr/local/cuda-11.6/targets/x86_64-linux/lib/*_static.a; \
fi
RUN chmod u+x ${WORKDIR}/entrypoint.sh
ENTRYPOINT [ "/bin/bash", "-c", "${WORKDIR}/entrypoint.sh" ]Docker
1. 이미지 생성
- 위에서 작성한 Dockerfile이 위치에서 실행
docker build -t test_image:0.0.1 .2. 컨테이너 실행
docker run --runtime=nvidia --gpus all -itd -p 8080:8080 --name test_container test_image:0.0.1Podman
1. 이미지 생성
- 위에서 작성한 Dockerfile이 위치에서 실행
docker build -t test_image:0.0.1 .2. 컨테이너 실행
podman run --device nvidia.com/gpu=all -itd -p 8080:8080 --name test_container test_image:0.0.1정리
현재 우리 회사의 주요 고객사는 금융업의 회사들이 많아 특히 보안적으로 관리되어야 하는 부분들이 많다. 그렇기에 제공하는 대부분의 소스들에 대해서 보안 점검을 하고 배포를 해야될 필요성이 있기 때문에 보안적으로 더 우수한 docker 보단 podman을 주로 다루는게 솔루션을 제공하는데 많은 이점이 될 수 있다고 생각한다.
이번에 가장 어려웠던 부분은 docker와 podman이 서로 비슷한 환경에서 동작을 한다고 느껴서 동일한 명령어로 이미지를 생성하고 컨테이너를 생성할려고 했다. 하지만 환경이 비슷할 뿐이지 대부분 옵션들의 사용법이 달라 많이 어려웠다.... docker 관련 레퍼스가 많아 podman을 사용안하고 docker만 사용한 내 잘못이다.... 이번 기회에 다시 알게되었으니 podman과 docker를 동시에 활용할 필요가 있다고 생각했다.
나아가서는 지금 현재 배포된 고객사들의 환경에 대한 컨테이너를 생성할려고 있는데 Kubernetes를 통해서 배포하고 자동화까지 하는 과정들을 공부하여 기록에 남겨보자.
