- Red Hat Enterprise Linux(RHEL)의 이미지 모드는 부팅 가능한 컨테이너로 RHEL을 구축, 배포 및 관리하는 과정을 단순화함
- 개발, 운영 및 솔루션 제공자는 동일한 컨테이너 네이티브 도구와 기술을 사용하여 애플리케이션과 기본 운영 체제를 관리할 수 있음
부팅 가능한 컨테이너 vs. 애플리케이션 컨테이너 구축
- 일반적인 애플리케이션 컨테이너와 마찬가지로, Podman, Docker 또는 buildkit과 같은 기존 컨테이너 기술을 사용하여 부팅 가능한 컨테이너를 구축할 수 있음
- 이미지는 Quay.io, Docker Hub, GitHub Container Registry 또는 내부 컨테이너 레지스트리와 같은 컨테이너 레지스트리에 저장 가능
- 부팅 가능한 컨테이너는 컨테이너 기술의 자연스러운 진화로, 전체 운영 체제와 Linux 커널을 포함하여 포괄적인 컨테이너 네이티브 워크플로우와 사용자 경험을 제공함
Containerfile 사용
- Containerfile(Dockerfile이라고도 함)은 컨테이너 이미지를 구축하는 데 필요한 모든 정보를 포함하며, 여기에는 베이스 이미지, 소프트웨어 패키지 설치 지침, Git 저장소에서 파일 복사 등이 포함됨
- 부팅 가능한 컨테이너를 구축하기 위한 워크플로우와 도구는 애플리케이션 컨테이너와 본질적으로 동일함
- 그러나 부팅 가능한 컨테이너를 구축할 때 적용되는 몇 가지 모범 사례가 있음
린팅을 위한 모범 사례
- Containerfile의 마지막 단계로
bootc container lint 명령을 실행하는 것이 권장됨
- 이 명령은 컨테이너 이미지 내부에서 여러 검사를 수행하고 문제가 있을 경우 오류를 발생시킴
- 예를 들어,
/usr/lib/modules에 여러 커널이 있는지 확인하고, /usr/lib/bootc/kargs.d의 파일 구문을 검사하며, /etc 및 /usr/etc의 위생(hygiene) 상태를 점검함
GitHub Actions와 디스크 공간
- GitHub Actions를 사용하여 컨테이너를 구축할 때, 부팅 가능한 컨테이너 이미지의 크기 때문에 디스크 공간 관련 문제에 직면할 수 있음
- 이러한 문제를 해결하기 위해, 워크플로우 파일에
/opt/hostedtoolcache 디렉토리를 삭제하는 단계를 추가하여 디스크 공간을 확보할 수 있음
/var 이해하기
-
/var는 지속적이고 변경 가능한 머신 로컬 데이터와 상태를 위한 디렉토리로, 업데이트 중에도 컨테이너 이미지의 /var 내용은 변경되지 않음
- 따라서, 애플리케이션이
/var에 데이터를 쓰는 경우, 이를 /usr/share와 같은 다른 디렉토리로 이동하여 읽기 전용 마운트 문제를 피해야 함
useradd 명령 사용
- 패키징 스크립트에서
useradd를 호출하는 경우, /etc/passwd가 로컬에서 수정되면 상태 드리프트가 발생할 수 있음
- 이러한 문제를 피하기 위해,
systemd의 DynamicUser=yes 옵션을 사용하여 동적 사용자 생성을 고려할 수 있음
- 그러나 복잡한 경우에는
DynamicUser=yes로 전환하는 것이 어려울 수 있으며, 이 경우에는 systemd-sysusers를 사용하여 사용자를 생성하는 것이 좋음
Quadlet을 사용한 컨테이너 내장
-
systemd에서 컨테이너화된 워크로드를 실행하는 것은 신뢰할 수 있는 배포를 위한 간단하면서도 강력한 방법임
- Podman은
systemd와의 통합을 위해 Quadlet이라는 도구를 제공하며, 이를 통해 컨테이너화된 워크로드를 선언적으로 관리할 수 있음
- Quadlet은 이미지 모드와 완벽하게 통합되며, 부팅 시 애플리케이션 컨테이너 이미지를 사전 가져오기 위해 논리적으로 바인딩된 이미지를 사용할 수 있음
요약
-
이미지 모드를 사용하면 RHEL 호스트 작업 방식에 패러다임 전환이 일어남
- 클라우드 네이티브 도구를 사용하여 운영 체제를 구축, 배포 및 관리할 수 있으며, 시스템의 대부분이 읽기 전용으로 마운트되는 불변의 OS를 다루게 됨