Dev Featured

Podman 전환 기록 - Docker의 경쟁자인가, 그냥 대안일 뿐인가?

PainKiller

2024년 3월 11일 • 33 min read

💡

이 글은 작성자의 무지로 인해 당신에게 불쾌감을 줄 수 있습니다.
모든 반박은 님 말이 맞고 제가 틀렸습니다.

"진짜 잘했으면 이런 삽질 안 해 나도"

💡

이 글을 읽지 않아도 되는 사람 🥱
- Docker & K8s 로 충분히 먹고 사는데 문제 없는 개발자
- Docker & K8s 없어도 먹고 사는데 문제 없는 개발자
- 힙스터랑 엮이기 싫은 개발자
- 야 근데 솔직히 컨테이너 꼭 필요하냐? (소신발언)
- 아침 출근인데 새벽에 이거 읽는 사람

TL;DR - Podman 은 프로덕션에 적합한가?

Podman 은 Docker 의 어깨에 올라서서 세상의 빛을 보고 있으나 아직 커뮤니티, 포럼, knowledge base가 부족하다
Docker 또한 초창기, 2010 년대 중반에는 그다지 주목 받지 못했으며, 특히 국내에서는 듣보잡 취급을 당한 바 있으니, 시간이 해결할 문제다. (물론 그 사이에 새로운 대체제가 나올 가능성도 높다)
개인적인 평가로는, Docker 의 성숙도를 80% 이상 따라잡긴 했으나, 완벽한 마이그레이션은 불가능하다. 이미 Docker 로 운영 잘 하고 있으면 하지 마라
RHEL 이외의 ubuntu 배포판에서 100% 문제가 발생하며, 현재 5.0.1 버젼이 최신이나 ubuntu 에서는 3.4.4 버젼 만을 최신으로 제공한다.
프로덕션의 기준이 컨테이너 단독 운영 인지 K8s 기반으로한 운영인지에 따라 다르나, 컨테이너 단독 운영에서는 아쉬운 부분을 짊어지고 가야 할 수 도 있다.

Docker 의 새로운 경쟁자

1. 발단 - 그 놈의 돈이 문제

2021년, Docker 의 개발사 Docker Inc. 는 윈도우 및 Mac 사용자를 대상으로한 컨테이 관리 소프트웨어 "Docker Desktop" 의 Plan 을 정리 및 개정하였다

기업 사용자 (250인 이상 또는 연 $10m매출) 에 대해 유료 라이선스 전환을 요구하기 시작하면서, 일반 개인 사용자들에게도 언젠가 불이익이 닥칠 거라는 것을 짐작케 했다.

개발자들이 라이선스에 골머리 썩는 이유

물론 Docker 의 기반이 되는 컨테이너 기술 (LCX)는 GNU LGPL v.2.1, 명령어 서비스인 Docker CLI 는 Apache 2.0 라이선스를 준수하기 때문에 기반 기술 자체가 구독이나 요금제, 라이선스로 인해 사유화 될 가능성은 없다.

하지만 Windows , Mac 사용자 입장에서 Docker Desktop 은 유통기한 얼마 남지 않은 우유로 보였을 것이다.

더군다나 Docker Inc. 는 Docker 이미지 저장소인 Docker Hub 를 운영하고 있는데, 2020년에는 구독료를 지불하지 않는 무료 계정을 상대로 6개월 이미지 저장 기한을 선언하였다가, Reddit, Hacker News 등의 개발자 포럼을 상대로 돌팔매를 맞고 2개월 만에, 특정 기간 내 이미지 Pull 을 제한하는 식으로 트래픽을 줄이는 방향으로 정책을 변경하였다.

2023년에는 무료 Team 구독 요금제를 폐지하려다가 몇몇 오픈소스 프로젝트의 보이콧과 개발자들의 비판에 한발 다시 물러서며, 타 구독 요금제로의 전환을 부탁한 바 있다.

2. 전개 - 방랑하는 개발자들

솔직히, 지금까지의 인터넷 역사에서 컨테이너를 통한 운영/개발이 꼭 필요한가에 대한 물음에
Docker 의 장점과 매력만을 제시했을 뿐, 이것이 대체 불가능한가, 이거 없으면 죽냐에 대해서는 답을 하지 못하는 상황이다. (소신 발언 1)
옛날엔 뭐 이거 없어서 후달렸나고 한다면, 도커, 아니 컨테이너나 Hyper-V 같은 기술 없이도 잘만 운영했었다. (소신 발언 2)

그래도 맛있잖아? 재밌잖아? 편하잖아? 이 개발자란 사람들은 편하고 멋있는거 찾으면 이거 못참거든요. 앵간한 변태 아니고서야 이거 못 버리고 쓴다고..

A : "IDE 뭐 쓰십니까?" B : "저는 Notepad++ 씁니다"

게다가 개인이나 기업이나 돈 몇푼(?) 때문에 이걸 아깝게 버리고 썩히긴 그렇기도 하고

"ㄹㅇ ㅋㅋ"

이나저나, Docker 사용자들 입장에서는 Docker Deskop 의 라이선스, 그리고 Docker Hub 이미지의 영속성 문제가 신발에 들어간 먼지뭉치 마냥 계속해서 거슬릴 수 밖에 없었고.

어찌되었던 간에, Docker Desktop 의 WSL 호환 문제, 가상 네트워크 이슈 등 고질적인 문제가 발목을 잡기도 했기에 Docker 개발 환경을 Docker Desktop 에 구애받지 않는 리눅스로 넘어가거나,

Docker Hub 대신 Harbor 등의 사설 구축형 이미지 저장소로 개인/회사 이미지를 관리하는 우회로를 택하기 시작했지만,

Docker 가 컨테이너 솔루션 시장(?)에서 독점적인 지위를 가지고 있으니, 언젠가 찾아올 변화를 피할 수 는 없을 것이다

3. 위기(?) - 창천이사 황천당립, Podman

토탈워: 삼국' 황건적의 난 트레일러 (한국어 자막) - YouTube — 뭐 예상대로, 올게 오긴 했다

RedHat 은 이 상황이 맘에 들지 않았는지, 아니면 Docker 가 꿀을 빨면서 Yum 의 트래픽을 갉아 먹는게 눈에 거슬렸든지 간에 RHEL 의 컨테이너 환경과 개발 경험을 위해 Podman 을 개발했다.

Docker Desktop 의 라이선스 이슈를 의식했는지, Podman 과 Podman Desktop 은 여기저기 자랑하듯 Apache 2.0 라이선스를 이마에 붙이고 나왔고,
개발자들은 CentOS 개발 중단으로 미운털이 박힌 RedHat 의 행보에 관심을 가지기 시작했다.

- 호적에서 파인 쌍둥이 동생 -

RedHat 은 한 술 더떠 RHEL 에서 Docker 를 설치하면 Podman 이 설치되도록 유도했고, Docker 는 역으로 RHEL 을 상대로 Docker 데몬을 지원하지 않는 맞불을 두었다.

Podman 은 Docker 명령어의 완벽환 호환과 Rootless 를 지향한 보안을 위해 설계된 컨테이너 기술임을 명확히 하였다. 뭐 쉽게 말하면 사용법 똑같은데 뽁뽁이로 감싼느낌.

"이거 함 잡솨봐"

4. 절정 - 그래 함 까짓 꺼 해보자

로고 더럽게 못생겼다 진짜

나는 솔직히 힙스터 개발자와 협업하는 것을 어려워한다, 이게 뭔말인가 싶기도 할텐데, 그들의 노력과 지적 호기심은 존경할 만한 것들이지만.
꼭 필요한 데에서 "신기술" 과 "트렌드" 를 쫒다가 마찰을 빚고, 프로젝트를 말아먹은 적이 있어 반면교사 삼아 스스로를 다잡기도 했다

근데 내가 그 짓거릴 하고 있다....

Docker 에서 전환? 그냥 새로 하자

Podman 은 Docker 의 완벽한 호환을 외치며 DevOps 생태계의 야생에 발을 들여 놓았다

물론 말은 번지르르 했지, 앵간치 짬 찬 개발자들은 눈치 까고 무시했을 거라 본다.
저런 소리 한다고 다 믿는다면 전세계약은 꼭 혼자하지 말기 바란다

RHEL vs Debian

필자의 환경은 다음과 같다

Ubuntu 22.04.3 LTS
Podman 3.4.4
Podman Compose 1.0.6

💡

현재 podman 최신 버젼은 5.0.1 이지만, ubuntu 를 대상으로는 3.4.4 가 최신 버젼이다.
의도적인 차별인지는 확인하기 어렵지만, 할 수 있다면 fedora 등의 redhat 계열로 진행하는 것이 좋다.

필자는 Ubuntu, Debian 배포판을 받아 설치 했다.
RHEL 이나 RedHat 기반 배포판을 쓸까 고민도 했지만, RHEL 은 고객사에서나 만져 봤고 그나마 Centos 도 6,7 외에는 써본적이 없기에, 그나마 프로덕션 경험이 있는 Ubuntu 로 진행했다.

잡설이기는 하지만 내 경험상 금융권이던 카드사던 RHEL 쓰는 장비는 나한테 안주고, Ubuntu 환경을 주로 제공해 줬다, 그나마 신경 쓰면 Centos 6 정도? 그 장비가 워낙 비싸긴 하겠지 뭐...

현재 사용중인 Podman 은 최신 버젼이 아닌 3.4.4 배포판이다. 지금이랑 다른 부분이 있을 수 있으니 아래 서술된 내용은 약간 다를 수 있다

새로 설치 하기 vs Docker 지우고 다시 깔기

두 가지 삽질을 다 해본 필자는 그냥 새로 설치하는 것을 추천한다.

💡

Docker 를 지우는게 싫다면 아래의 뻘짓을 잘 읽어보고, 따라하지 말자 그리고 운영중인 Docker 서비스에 문제가 없는지 면밀히 검토한 뒤
그냥 새로 설치하면 된다. 뭐

몇 가지 기억나는 뻘짓을 적자면..

Docker 의 기존 docker.sock 파일이 삭제되지 않고 podman 과 충돌
작성한 docker 의 network 가 podman 의 network 와 겹쳐서 port publish 불가능
CNI 버젼 이상
기존 바인딩된 볼륨 경로 사용 불가 (권한 이슈)
저장소 충돌
.... 등등

간략 Podman 설명

Podman 은 앞서 언급한 바, Docker 의 100%(?) 호환성을 과시하며 발표되었다.

Podman = Pod Manager tool 이라는 의미다
기본적으로 모든 컨테이너는 Rootless 모드로 실행, 운영된다
- Podman 의 운영 주체가 Root 사용자가 아니라 일반 사용자 즉 nobody 계정으로도 가능하다는 거다
daemon 이 없다
- 처음엔 이게 뭔 소린가 했는데, 내가 알고있던 containerd 가 도커 데몬이었다.(이런 병신이 다 있나...)

Docker 에서는 containerd 가 root 권한을 가지기 때문에 containerd 에 보안취약점이 발견되면 host 의 시스템에 치명적인 이슈를 가져올 수 있다.
containerd 는 Docker 데몬으로서 모든 컨테이너를 관리하는데 이 containerd 가 모종의 이유로 죽어버리면 모든 컨테이너의 장애로 이어질 수 있다는 것이다. 이를 SPoF (Single Point of Failure) 라고 부른다.
(근데 애초에 그게 죽을 정도면 호스트에 문제가 있는거 아닌가)
Podman 은 데몬 없이 runC 라는 OCI (Open Container Initiative) 컨테이너 런타임을 사용하여 Linux Kernal 에 연동해 컨테이너를 관리한다
데몬이 없기 때문에 리소스 사용을 줄일수 있다
(진짠지는 모르겠다)
데몬이 없기 때문에 systemd 를 통해 서비스를 생성, 관리해야 한다
(점점 배꼽이 커지는 느낌)

"Rootless, No daemon" 이 두가지가 Podman 의 알파이자 오메가,
그리고 앞으로 보게 될 그리고 당신들이 겪게 될 모든 후회와 절망의 원흉이다

설치

Podman

RHEL / Centos / Oracle / Amazon Linux

sudo yum install podman -y

Ubuntu

sudo apt-get install runc -y
sudo apt-get install podman -y

MAC

brew install podman
podman machine init
podman machine start
# podman-desktop 설치
brew install podman-desktop

Podman Compose

💡

https://github.com/docker/compose/releases 의 릴리즈 정보 참고 후 아래 코드 수정하여 사용 할 것

참고 : https://docs.oracle.com/ko/learn/podman-compose/index.html#start-the-podman-socket

RHEL / Centos / Oracle / Amazon Linux

sudo yum install python3-pip -y

sudo pip3 install podman-compose

sudo yum install podman-docker -y

sudo curl -L "https://github.com/docker/compose/releases/download/v2.24.6/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
docker-compose --version

Ubuntu

sudo apt install python3-pip -y

sudo pip3 install podman-compose

sudo apt install podman-docker -y

sudo curl -L "https://github.com/docker/compose/releases/download/v2.24.6/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
docker-compose --version

MAC

brew install python3-pip

brew install podman-docker

Socket 설정

Unix 소켓을 만들어 Docker 작성 기능을 작동하려면 Podman 소켓을 활성화해야 한다
Docker Compose / Podman Compose 간 호환성을 위해 필요하다

sudo systemctl enable --now podman.socket
sudo systemctl status podman.socket

Alias 설정

podman 은 기본적으로 docker 와 명령어가 호환 가능하므로 alias 를 설정하여 docker 명령어로도 입력 가능하게끔 하자

alias docker=podman

설치 확인

Podman

$ podman -v

podman version 3.4.4

Podman Compose

$ podman-compose version

podman-compose version: 1.0.6
['podman', '--version', '']
using podman version: 3.4.4
podman-compose version 1.0.6
podman --version
podman version 3.4.4
exit code: 0

이슈 및 해결

💡

사실 이거 쓸려고 작성한 글임

CNI (Container Network Interface) 버젼 오류

내가 처음 마주한, 시작 3분 만에 만난 최종보스

뭔가 이상하다 싶기는 했다, Redhat 안쓰고 Ubuntu 로 고집한 벌이었을까? 이 오류에 5시간을 날려먹었다.
재설치 하는데 2시간, 테스트 하는데 2시간, 문서 뒤져보는데 1시간.

$ podman network ls

WARN[0000] Error validating CNI config file /home/orca/.config/cni/net.d/my-ecosystem_default.conflist: [plugin bridge does not support config version "1.0.0" plugin portmap does not support config version "1.0.0" plugin firewall does not support config version "1.0.0" plugin tuning does not support config version "1.0.0"]
NETWORK ID    NAME                  VERSION     PLUGINS
2f259bab93aa  podman                0.4.0       bridge,portmap,firewall,tuning
6dba0e056a86  my-ecosystem_default  1.0.0       bridge,portmap,firewall,tuning,dnsname

plugin bridge does not support config version "1.0.0"

생성한 Network 의 CNI Config 버젼을 지원하지 않는다는 오류, 아니 니들이 만들어 놓고 니들이 안된다면 어쩌자는거야?

Compose 를 통해 컨테이너를 실행하면 아래 에러가 발생한다

WARN[0000] Error validating CNI config file /home/orca/.config/cni/net.d/my-ecosystem_default.conflist: [plugin bridge does not support config version "1.0.0" plugin portmap does not support config version "1.0.0" plugin firewall does not support config version "1.0.0" plugin tuning does not support config version "1.0.0"]
WARN[0000] Error validating CNI config file /home/orca/.config/cni/net.d/my-ecosystem_default.conflist: [plugin bridge does not support config version "1.0.0" plugin portmap does not support config version "1.0.0" plugin firewall does not support config version "1.0.0" plugin tuning does not support config version "1.0.0"]
ERRO[0000] error loading cached network config: network "my-ecosystem_default" not found in CNI cache
WARN[0000] falling back to loading from existing plugins on disk
WARN[0000] Error validating CNI config file /home/orca/.config/cni/net.d/my-ecosystem_default.conflist: [plugin bridge does not support config version "1.0.0" plugin portmap does not support config version "1.0.0" plugin firewall does not support config version "1.0.0" plugin tuning does not support config version "1.0.0"]
ERRO[0000] Error tearing down partially created network namespace for container 5da6ae5d4a74eace95963032c366da67aa0830e84677650bfed9bbe620933f6c: CNI network "my-ecosystem_default" not found
Error: unable to start container 5da6ae5d4a74eace95963032c366da67aa0830e84677650bfed9bbe620933f6c: error configuring network namespace for container 5da6ae5d4a74eace95963032c366da67aa0830e84677650bfed9bbe620933f6c: CNI network "my-ecosystem_default" not found
exit code: 125

혓바닥이 긴 게 딱 봐도 설정이 꼬였다 싶어 재설치에 ,캐시 삭제, 이미지 삭제 별의 별짓을 다했지만, 설치 오류나, 엔진 자체의 문제는 아닌 것으로 결론 내렸다

공식 Document 에서도 확인 불가능 했기에, 울며 겨자먹기로 Reddit 을 뒤져보니..

Podman automatically sets cniVersion 1.0.0 instead of 0.4.0
by u/Left-Affect3667 in podman

아 tq 좀

Ubuntu 즉, Debian 기반의 빌드에서 발생하는 이슈이며 podman 에서 network 를 생성할때 만들어지는 conflist 파일의 cniVersion 값이 0.4.0 이 아닌 1.0.0 으로 고정된다는 얘기

해결 방법
- ~/.config/cni/net.d/[네임스페이스]_[네트워크명].conflist 파일을 열고
- cniVersion 을 1.0.0 에서 0.4.0 으로 변경해 주자.

공유 마운트 문제

Docker 에서 Podman 으로 마이그레이션 시 공유 마운트가 정상적으로 동작하지 않는 경우가 발생할 수 있다

WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers

Podman 은 기본적으로 rootless 모드로 실행되기 때문에 root 권한이 없어도 컨테이너를 관리할 수 있다.
Podman 은 컨테이너를 실행할 때 컨테이너의 루트 디렉토리를 호스트의 루트 디렉토리와 공유하지 않는다

해결방법

findmnt -o PROPAGATION /
# or
sudo mount --make-rshared /

Permision Denied 이슈 (WSL 환경)

podman 사용시 아래와 같은 root 권한 문제가 발생

$ podman-compose up
podman-compose version: 1.0.6
['podman', '--version', '']
using podman version: 3.4.4
** excluding:  set()
['podman', 'ps', '--filter', 'label=io.podman.compose.project=my-ecosystem', '-a', '--format', '{{ index .Labels "io.podman.compose.config-hash"}}']
Error: error creating tmpdir: mkdir /run/user/1000: permission denied

systemd 가 비활성화 된 환경에서 (WSL) 등 사용자 세션을 유지하지 않는 환경에서 발생한다
해결 방법
- 테스트 한답시고, WSL 쓰지말고 그냥 리눅스 깔아서 쓰자
- 아니면 "loginctl enable-linger $UID" 함 해보고 안되면 그냥 리눅스 깔아서 쓰자

Rootless 에서의 80,443 포트 사용

계속 언급하지만 Podman 은 rootless 이기 때문에 Docker 가 당연히 할 수 있는 것을 Podman 은 하지 못한다 (이 아이는 잘하는 게 뭘까 싶기도 하다)
Docker 에서는 root 권한으로 80,443 을 Listen 할 수 있지만 얘는 따로 꼼수를 써야 한다
해결 방법 (2개)
- ip_unprivileged_port_start 수정하기

sudo sh -c "echo 0 > /proc/sys/net/ipv4/ip_unprivileged_port_start"

이 방식은 재부팅 시 초기화 되고, 타 서비스에도 영향을 미치기 때문에 테스트 환경에서만 사용한다.

포트 포워딩
- UFW 또는 Iptables 기능을 사용하여 80,443 의 포트로 인바운드 되는 패킷을 1024 이상의 rootless 가 listen 가능한 포트로 전달한다

# 패킷 전달 활성화
sudo vi /etc/ufw/sysctl.conf
# net.ipv4.ip_forward=1 의 주석 해제 또는 추가

# 포트 포워딩 설정
sudo vi /etc/default/ufw
# DEFAULT_FORWARD_POLICY="ACCEPT" 주석 해제 또는 추가

패킷 전달 및 포트포워딩 설정을 마친 뒤 재부팅 하자

# 규칙 파일 열기
sudo vi /etc/ufw/before.rules 

# 아래 내용 추가 후 저장
COMMIT

*nat
:PREROUTING ACCEPT [0:0]
-A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 10080
-A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 10443

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

80 > 10080, 443 > 10443 으로 리다이렉트 한다

# 포트 Open
sudo ufw allow 80
sudo ufw allow 443
sudo ufw allow 10080
sudo ufw allow 10443
# ufw 설정 적용
sudo ufw reload

이제 http/s 접속이 필요한 컨테이너의 포트를 10080, 10443 으로 Publish 한 뒤 접속하자

/run/docker.sock 사용

/run/docker.sock 은 portainer 등의 컨테이너 관리 이미지가 호스트의 컨테이너 엔진에 접근할 수 있도록 소켓 통신을 제공한다
podman 에는 이게 없다
Docker 가 당연히 할 수 있는 것을 못하는 Podman 을 위해 docker.sock 을 사용하는 우회로를 제공해야 한다
해결 방법 (2개)
- podman.sock 심볼릭 링크 생성 (비추천)

sudo ln -s /run/podman/podman.sock /run/docker.sock

현재 사용자의 podman.sock 을 사용 (권장)
- /run/user/$UID/podman/podman.sock 은 rootless 컨테이너 소켓을 제공한다

Permission denied trying to use rootless Podman + docker-compose + Traefik with podman.sock

TL:DR: Trying to use rootless Podman with docker-compose through podman socket, and use a Traefik container (talking to podman socket) to proxy traffic to other containers, related to https://

Stack OverflowJanne Mattila

# 예시
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    restart: unless-stopped
    networks:
      - podman-bridge
    expose:
      - 9443
    volumes:
      - /run/user/1002/podman/podman.sock:/var/run/docker.sock
      - ./portainer:/data
      - ./cert/ssl.pem:/certs/ssl.pem:ro
      - ./cert/ssl.key:/certs/ssl.key:ro
    command:
      --ssl
      --sslcert /certs/ssl.pem
      --sslkey /certs/ssl.key

Rootless 에서의 지속 가능한 컨테이너 실행

일반 유저로 로그인 한 계정 에서 podman 을 rootless 모드에서 컨테이너를 실행하면 로그아웃시 컨테이너 도 같이 종료된다.
- 하지만 이는 각각의 컨테이너마다 서비스를 생성해야 하기 때문에 번거롭다
- linger 를 활성화하면 로그아웃시에도 사용자의 프로세스가 종료되지 않는다
만약 장비를 재부팅시 컨테이너가 자동으로 실행되지 않아도 무관하다면 아래 명령어를 사용한다

sudo loginctl enable-linger [UID]

loginctl

RedHat 에서는 systemd 를 통해 서비스를 생성, 관리하는것을 권장하고 있다

podman generate systemd --new --name [서비스명] [컨테이너_ID]

서비스를 통해 관리할 경우 컨테이너가 depends_on 에 따라 올라오지 않을 수 있다. 서비스 중지, 재시작, 그리고 호스트 장비 재부팅을 통해 테스트 하는 것을 권장한다

Bridge 네트워크 모드에서 외부에서 들어오는 패킷 Real IP 읽기 (미해결 , 작성중)

❗

해결되지 않은 이슈 입니다.
포럼이나 깃헙 이슈에서도 아직 계류중인 이슈일 수 있으므로 해결을 바라지 마십시오, 얘들 일 안하는거 같아

Nginx, HaProxy, traefik 등의 프록시 서비스를 Podman 컨테이너로 올릴 경우 기본 Bridge 모드가 적용되어, Bridge 네트워크 의 IP 가 Inbound 패킷에 등록되는 현상
Host 모드가 없기 때문에 slirp4netns 을 사용해서 host 의 IP 를 사용할 수 있으나, 성능 문제가 지속적으로 언급되고 있으며
타 Container 로의 Reverse Proxy 가 정상적으로 Upstream 되지 않는다던가.
hostname 을 통한 접근이 불가능하여 포트를 expose 하는 대신 publish 하여 외부에 노출해야 하는 위험 발생 (이럴거면 rootless 가 뭔 소용이야?)

Cannot resolve DNS with allow_host_loopback=true

I am trying to give one container in a deployment the option to reach the host loopback IP. However, doing that on a container level will break the way other containers can be reached. The basic se…

Stack Overflowclemens

Getting external IP in traefik?
by u/Jaded-Replacement-65 in podman

Rootless communication between containers
by u/seralbdev in podman

Rootless reverse proxy
by u/Tomacco81 in podman

그 외

까먹을까봐 적어두는 명령어 모음

# Image 다운로드
## pull 명령어는 컨테이너 이미지를 다운로드한다
podman  pull [이미지명]:[태그]
# Image 목록
podman  images
# Image 삭제
podman  rmi [이미지명]:[태그]

# Image 빌드 (Dockerfile 필요)
podman build -t [태그명] .

# Image 기반으로 컨테이너를 실행
podman  run [옵션] [이미지명]:[태그]

# checkporint & restore
## 컨테이너의 현재 상황을 checkpoint 해서 디스크로 저장해뒀다가 restore해서 다시 올릴 수도 있다.
podman container checkpoint --leave-running --export=/tmp/backup.tar [컨테이너_ID_또는_이름]
podman stop [컨테이너_ID_또는_이름]
podman rm [컨테이너_ID_또는_이름]
podman container restore --import=/tmp/backup.tar

# 현재 실행 중인 Container 목록
podman ps
# 모든 Container 목록
podman ps -a

# 실행 중인 Container 중지
podman stop [컨테이너_ID_또는_이름]
# Container 재시작
podman restart [컨테이너_ID_또는_이름]
# Container 삭제
podman rm [컨테이너_ID_또는_이름]

# Pod 생성
podman pod create --name [Pod_이름]

# Pod 조회
podman pod ls
podman ps -a --pod

# Pod에 컨테이너 추가
podman run -dt --pod [Pod_이름] [컨테이너_ID]

# Pod 시작/중지/삭제
podman pod start [컨테이너_ID]
podman pod stop [컨테이너_ID]
podman pod rm [컨테이너_ID]

# Network 목록
podman network ls
# Network 상세 정보
podman network inspect [네트워크_ID_또는_이름]

# Volume 목록
podman volume ls
# Volume 상세 정보
podman volume inspect [볼륨_ID_또는_이름]

# generate systemd service file
podman generate systemd [컨테이너_ID]
#  kubernetes yaml 파일도 생성 가능
podman generate kube [컨테이너_ID]

Pod

함께 실행되며 동일한 리소스를 공유하는 컨테이너 그룹
쿠버네티스 Pod와 유사하지만, 쿠버네티스와는 별개의 개념이다
각 포드는 하나의 인프라 컨테이너와 다수의 일반적인 컨테이너로 구성된다
- 인프라 컨테이너는 포드를 실행하고 사용자 네임스페이스를 유지 관리하여 컨테이너를 호스트로부터 분리한다
- 일반 컨테이너는 프로세스를 추적하고 빈 컨테이너를 찾을 수 있도록 모니터를 가지고 있다
Podman은 컨테이너, Pod, 컨테이너 이미지 및 볼륨을 위한 API를 제공하는 간단한 커맨드라인 인터페이스(CLI)와 libpod 라이브러리를 통해 pod를 관리한다
Podman의 CLI는 컨테이너 런타임과 형식을 위한 업계 표준을 준수하도록 설계된 Open Container Initiative(OCI) 컨테이너를 생성하고 지원

Buildah, Skopeo

Podman은 Docker와 달리 build, push 명령어를 제공하지 않는다, 대신에 buildah, skopeo 를 사용한다.
buildah 는 Dockerfile 을 사용하여 이미지를 빌드하고, skopeo 는 이미지를 push, pull 한다.

(이 이상은 귀찮아서 대충 알아봄)

번외 - Ubuntu 잔혹사

솔직히 Podman 을 쓰면서 RHEL 로 넘어갈까 생각을 많이 했었다. Ubuntu 환경에 대응하지 않는 상황에 앞서 수많은 버그들도 8할은 업데이트 되지 않는 Ubuntu Podman 의 버그가 원인이기 때문이다

What’s the recommended way of installing Podman 4 in Ubuntu 22.04?

Ubuntu 22.04 only has Podman 3.4.4 in its repos and the former PPA for latest Podman was discontinued for 22.04 Kubic packages have been discontinued for Ubuntu 22.04 LTS. Current users of the Kubic

Ask Ubuntualexanderadam

Ubuntu 22.04 가 22년 4월에 업데이트 되면서 LTS 릴리즈에 대한 업데이트도 이루어져야 했으나 podman 은 아직 공식 repository 에서 3.4.4 만을 내놓고 있다.

2024년도 4월 기준 현재 릴리즈는 5.0.1. ubuntu 의 3.4.4 와는 2년간의 격차가 있다.

나도 딱히 뾰족한 해답을 내놓지 못한 채 방황하고 있는 가운데 brew 를 통한 설치에 성공했다는 의견이 있어 헐레벌떡 시도해 보았다.

# Brew 설치
sudo apt-get install build-essential curl file git
sh -c "$(curl -fsSL https://raw.githubusercontent.com/Linuxbrew/install/master/install.sh)"

# PATH 설정
touch ~/.zshrc
# 아래 내용 추가
export PATH="/home/linuxbrew/.linuxbrew/bin:$PATH"
export MANPATH="/home/linuxbrew/.linuxbrew/share/man:$MANPATH"
export INFOPATH="/home/linuxbrew/.linuxbrew/share/info:$INFOPATH"

# source
source ~/.zshrc

# podman 설치
# https://formulae.brew.sh/formula/podman
brew install podman
podman -v

일단은 정상적으로 podman 5.0.1 이 설치되었다. 아쉽게도 현재 5.0.1 이 stable 이면서도 네트워크 관련해서 권한 문제가 있는 상황이다.

rootless + quadlets: slirp4netns -> pasta
by u/Isystafu in podman

일단 brew 로 올라온 패키지 5.0.1 만 제공하므로 이전 stable 인 4.9.3 을 설치 할 수 없다.

버그가 수정된 다음 릴리즈를 기대해보도록 한다...

같이 보기

Podman 공식 Page

Podman

podman

Podman 공식 문서

What is Podman? — Podman documentation

Podman

Podman Redhat 소개

Podman RHEL 9 문서

Reddit - Podman 채널

Reddit - Dive into anything

Hacker News

기타 포럼 글

TL;DR - Podman 은 프로덕션에 적합한가?

Docker 의 새로운 경쟁자

1. 발단 - 그 놈의 돈이 문제

2. 전개 - 방랑하는 개발자들

3. 위기(?) - 창천이사 황천당립, Podman

4. 절정 - 그래 함 까짓 꺼 해보자

Docker 에서 전환? 그냥 새로 하자

RHEL vs Debian

새로 설치 하기 vs Docker 지우고 다시 깔기

간략 Podman 설명

설치

Podman

RHEL / Centos / Oracle / Amazon Linux

Ubuntu

MAC

Podman Compose

RHEL / Centos / Oracle / Amazon Linux

Ubuntu

MAC

Socket﻿ 설정

Alias 설정

설치 확인

이슈 및 해결

CNI (Container Network Interface) 버젼 오류﻿

공유 마운트 문제﻿

Permision Denied 이슈﻿ (WSL 환경)

Rootless 에서의 80,443 포트 사용﻿

/run/docker.sock 사용﻿

Rootless 에서의 지속 가능한 컨테이너 실행﻿

Bridge 네트워크 모드에서 외부에서 들어오는 패킷 Real IP 읽기 (미해결 , 작성중)

그 외

까먹을까봐 적어두는 명령어 모음

Pod﻿

Buildah, Skopeo﻿

번외 - Ubuntu 잔혹사

같이 보기

Socket 설정

CNI (Container Network Interface) 버젼 오류

공유 마운트 문제

Permision Denied 이슈 (WSL 환경)

Rootless 에서의 80,443 포트 사용

/run/docker.sock 사용

Rootless 에서의 지속 가능한 컨테이너 실행

Pod

Buildah, Skopeo