# 부팅 가능한 컨테이너 만들기 모범사례

> Clean Markdown view of GeekNews topic #19473. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=19473](https://news.hada.io/topic?id=19473)
- GeekNews Markdown: [https://news.hada.io/topic/19473.md](https://news.hada.io/topic/19473.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2025-02-28T09:46:01+09:00
- Updated: 2025-02-28T09:46:01+09:00
- Original source: [developers.redhat.com](https://developers.redhat.com/articles/2025/02/26/best-practices-building-bootable-containers)
- Points: 6
- Comments: 0

## Summary

Red Hat Enterprise Linux(RHEL)의 이미지 모드는 부팅 가능한 컨테이너로 RHEL을 구축, 배포 및 관리하는 과정을 단순화하며, 개발자와 운영자가 동일한 도구로 애플리케이션과 운영 체제를 관리할 수 있게 합니다. 부팅 가능한 컨테이너는 기존의 컨테이너 기술을 사용하여 구축할 수 있으며, 전체 운영 체제와 Linux 커널을 포함하여 포괄적인 컨테이너 네이티브 워크플로우를 제공합니다. 또한, Containerfile을 사용하여 컨테이너 이미지를 구축하고, GitHub Actions와 같은 도구를 통해 디스크 공간 문제를 해결하며, Quadlet을 통해 systemd와의 통합을 지원합니다.

## Topic Body

- 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은 이미지 모드와 완벽하게 통합되며, 부팅 시 애플리케이션 컨테이너 이미지를 사전 가져오기 위해 논리적으로 바인딩된 이미지를 사용할 수 있음  
  
### 요약  
- [이미지 모드](https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux/image-mode)를 사용하면 RHEL 호스트 작업 방식에 패러다임 전환이 일어남  
- 클라우드 네이티브 도구를 사용하여 운영 체제를 구축, 배포 및 관리할 수 있으며, 시스템의 대부분이 읽기 전용으로 마운트되는 불변의 OS를 다루게 됨

## Comments



_No public comments on this page._