들어가기

PODMAN에 대한 소개 및 용어해설

• 용어해설
• 컨테이너 기술의 이해
• PODMAN의 주요 옵션 설명
• 컨테이너 네트워크

용어해설

POD란?

가장 작은 논리적 리소스

또한 POD는 자원의 최소 단위이기도 하다. 하나의 pod에 하나의 container (app)가 권장 사양이긴 하나, 하나의 pod 안에 여러 개의 컨테이너가 포함되는 경우도 있다.

CRI

Container Runtime Interface

metric

성능지표

secret

자격증명. 파일 또는 문자열 형태가 있다.

Persistent Volume (PV)

컨테이너에 제공되는 디렉토리 또는 볼륨으로, 영구적으로 보존해야할 데이터가 있는 경우, 디렉토리 또는 볼륨을 컨테이너에 마운트하여 데이터를 저장할 수 있게 해주는 역할을 한다. 

PV는 컨테이너 사용자와 권한이 같아야 한다. 컨테이너 사용자는 이미지를 만들 때 정해진다.

YAML

보통 야믈이라고 읽는다. 마크업 언어(HTML도 마크업 언어이다)의 하나인데, podman (또는 docker)에서 보다는 컨테이너를 오케스트레이션 하기 위한 Kubernetes와 같은 솔루션에서 여러 설정을 파일로 보관할 때 주로 쓰인다.

YAML을 사용할 때 들여쓰기가 무척 중요하며, tab을 사용하면 안 되고 오직 space만을 사용해야 한다. tab을 사용하면 "Only one identity provider can be configured in single object"와 같은 에러를 뿜는다.

YAML 수정 시 vim에서 세로로 하이라이트 표시를 해주는 :set cursorcolum을 설정하면 조금 편하다.

:set cursorcolum

Orchestration

오케스트라 공연을 떠올려 보자. 하나의 공연이 되기 위해서는 지휘에 맞춰 많은 악기들이 협조를 내야한다.

컨테이너 기술에 있어 오케스트레이션이라고 하는 것은 Kubernetes, OpenShift, Rancher, Kubesphere와 같은 솔루션을 사용하여 다중 노드 다중 컨테이너를 관리하고 제어하는 것을 의미한다. 이러한 솔루션은 모니터링 및 자동 실행, 로드밸런싱과 같은 기능을 제공해 준다.

ingress

네트워크 서비스. 수식 규칙을 정의하고 제어한다.
받아들이는 쪽, 즉 라우터로부터 오는 패킷에 대한 정책을 적용.

egress

는 ingress와 반대로, 밖으로 나가는 패킷에 대한 정책을 적용한다.

etcd

etcd는 일종의 DB이다. kubernetes의 모든 정보가 담겨있다. controller는 etcd를 확인해서 작동한다.
리소스 정의 파일(manifest라고 하며, YAML 형식)이 etcd에 저장된다.

CNCF에 있는 프로젝트를 Kubernetes와 섞어서 만든 것이 오픈쉬프트이다. 매우 빠르게 기능이 업데이트 되고 있다. COREOS는 오픈쉬프트를 통해 관리 된다.

이그니션 파일

코어OS 설정 파일

scale-up과 scale-out

out: 병렬로 시스템을 확장 해 나감을 의미 함
up: 같은 서버에서 cpu나 mem 증가 또는 향상을 의미 함

statefull과 stateless

컨테이너를 띄울 때 2가지의 상태가 있는데 statefull과 stateless가 그것이다.

statefull - 상태 저장
stateless - 상태 비저장

stateless의 경우 APP이 컨테이너에 데이터를 저장하지 않아 스토리지가 필요치 않다.
log 정도만 남고, 실제 데이터는 외부의 DB등에 저장하는 APP의 형태가 많다.

SAN 스토리지는 기본 ReadWriteOnce 로 설정된 노드에서만 사용가능하다.

컨테이너 기술의 이해

POD는 가장 작은 논리적 리소스이자 자원의 최소단위이기도 하다.

하나의 pod에 하나의 container (app)가 담기는 것이 권장 사양이긴 하나, 하나의 pod 안에 여러 개의 컨테이너가 포함되는 경우도 있다.

APP 구동에 있어 컨테이너와 전통적인 OS를 사용하는 방식의 비교

종래의 방식은 호스트 OS에 탑재된 라이브러리를 각 앱이 공유하여 사용하였다. 때문에 종종 APP 1과 APP 2가 서로 다른 버전의 라이브러리를 요구할 때 의존성 문제가 발생하곤 했다.

또한 APP이 보안상 취약점이 있을 때 호스트 OS의 제어권에 영향을 줄수 있는 위험이 상대적으로 큰 편이기도 했다.

이에 반해 컨테이너 방식은 각각의 APP이 컨테이너(POD) 안에 사용할 라이브러리를 들고 독립적으로 사용하기 때문의 의존성 문제를 해결함과 동시에 보안적 관점에서도 상대적으로 호스트 OS의 제어권에 영향을 줄 위험도 줄여준다.

Virtualization과 containerization의 비교

컨테이너 기술은 종래의 방식보다는 약간의 오버헤드가 있으나, VM을 사용하는 방식에 비해서는 훨씬 적은 오버헤드를 생성하기 때문에 VM을 밀어내고 대세로 자리 잡았다. 이를 컨테이너가 호스트 OS의 커널과 메모리 주소를 그대로 이용하는데 반하여 VM의 경우에는 게스트 OS의 커널과 별도의 메모리 주소를 이용하기 때문이다.

 

Rootful 컨테이너와 rootless 컨테이너의 이해

컨테이너는 보통 root 계정으로 실행 되나, 보안 상의 이유로 root가 아닌 계정으로 실행할 것을 권장하기도 한다.

보안 상의 이점도 있는데, 만약 APP의 제어권이 탈취당하여 이를 통해 호스트 OS에 접근하는 경우에도 공격자는 일반 사용자 계정의 권한을 가질 뿐이므로 피해를 줄일 수 있다.

• POD 기동 계정이 root면 rootful container 모드로, 그 외의 경우는 rootless 모드로 기동
• HOST OS의 1~1023 포트를 사용 가능한 것은 rootful 컨테이너만 가능
• POD 네트워크는 rootful 컨테이너만 가능

PODMAN의 주요 옵션 설명

 

-d

detach를 뜻하며 백그라운드로의 실행을 의미한다.

-d를 빼고 POD를 띄우게 되면 foreground로 실행 되어 커서가 잠기게 되며, 콘솔을 닫으면 해당 POD도 강제 종료 된다. 이러한 동작은 일반적인 프로세스와 동일하다.

-p 80:8080

80 : HOST OS의 포트
8080 : 컨테이너의 포트

-v와 :Z

-v 옵션을 줄 때 끝에 :Z 를 붙이면 자동으로 selinux 컨텍스트 적용을 해 준다.

podman의 자세한 정보 보기

설치 되어있는 podman의 여러 설정을 표출 해 준다.

podman --log-level=debug info

podman save

local에 저장 된 이미지를 추출하여 tar로 묶기

podman load

tar 형태로 묶여있는 이미지를 local에 저장. 인터넷이 되지 않는 환경 등에서 이미지를 전달할 때 사용.

컨테이너 내부에 접속하기

정확히는 exec는 해당 컨테이너에 있는 바이너리를 실행하는 것이다.
/bin/bash의 경우 쉘 프로그램이기 때문에 쉘이 뜨는 것. (추가적인 exec의 예제는 Ghost를 참조)

podman exec -it <POD의 이름 또는 ID> /bin/bash

예제) mariadb라는 이름의 POD로 접속하기

podman exec -it mariadb /bin/bash
mysql -u root -p

컨테이너 네트워크

컨테이너 네트워크의 특징

동일한 서비스를 여러 개 띄워도 포트 충돌 없이 사용할 수 있다. 예를 들어 웹 서비스를 제공하는 apache와 nginx를 동시에 띄운다던가, nignx를 여러 개 띄워 각기 다른 web app을 제공하는 등 다양한 활용이 가능하다. 이렇게 실행 된 웹 서버는 모두 80번, 또는 443 포트를 사용할 수 있다.

다만, 이렇게 각기 실행 된 웹서버에 접속하려면 reverse proxy를 사용하거나, 혹은 각기 다른 HOST port를 할당 해 주어야 한다.

예제) 1번 POD 8080, 2번 POD 8081 등

1. Docker 네크워크

docker의 네트워크 옵션과 그 속성

docker에서 포트를 사용하는 경우 아래 4가지 선언 방식이 있는데, 각기 작동이 상이하다.

    1. EXPOSE나 -p 둘다 선언하지 않는 경우
    2. EXPOSE만 선언하는 경우 
    3. EXPOSE와 -p를 모두 선언한 경우
    4. -p만 선언한 경우

경우 1
이 경우 해당 서비스는 오직 해당 POD 내부에서만 접속할 수 있다.
예를 들어, 하나의 POD 안에 여러 컨테이너가 포함되어있고, 내부에서 이 컨테이너끼리만 통신하면 되는 경우가 이 경우에 해당할 것이다.

경우 2 --expose
이 경우에 호스트 네트워크에서는 이 포트가 보이지 않는다. 오직 POD 사이에서만 포트가 인식 되며, POD 사이에서 통신이 가능해진다. 조금 더 기술적으로 이야기 하자면 expose는 127.0.0.1에 대한 포트이다.

경우 3 --publish-all
HOST 네트워크는 물론, POD 네트워크에서도 접속이 된다.

경우 4  --publish (-p)
HOST 네트워크를 경유해서만 접속이 가능하다. 이는 POD간 통신에서도 동일하다.

2. PODMAN 네트워크

podman은 docker 네트워크와는 달리 expose는 POD를 만들 때 외부랑 연결 되는 포트를 선언할 때만 쓰인다.

기본적으로 publish만 작동한다고 생각하면 된다. 또한 podman에서 모든 네트워크 명령은 rootfull 컨테이너에만 적용되고 사용할 수 있다.

목록 보기

podman network ls

port 매핑 확인하기

podman port -a

POD 네트워크 다시 불러오기

쓸일은 사실 많지 않지만 HOST OS의 네트워크가 변경 되었다던지 하는 경우 사용한다.

podman network reload

POD 네트워크의 설정정보 확인

설치 시 기본으로 제공되는 컨테이너 네트워크는 podman 이다.

podman network inspect <네트워크 이름>
podman network inspect podman