6장. Reproductible Container Build의 소개


Red Hat Enterprise Linux(RHEL)는 이제 Red Hat 도구 Podman 및 Buildah를 사용하여 재현 가능한 컨테이너 빌딩을 지원합니다. 이 새로운 기능은 사용자가 동일한 입력으로 그러나 다른 시간에 이미지를 구축할 때 이미지의 변경을 줄입니다. 이미지 간의 변경이 적으면 이미지의 한 버전에서 그 이미지의 최신 버전으로 이동할 때 레지스트리에서 인출해야 하는 데이터 양이 줄어들 수 있습니다. 복제 가능한 컨테이너 빌딩은 공급망 보안을 보장하고, 안정적인 소프트웨어 deployment 촉진하며, 효과적인 디버깅을 촉진하는 데 매우 중요합니다.

이전에는 컨테이너 이미지의 크기가 증가하고 업데이트 유용 로드 크기에 대한 고객의 걱정이 증가하여 타르볼 생성과 관련된 기존의 도전과 제한 사항이 강화되었습니다. Konflux와 같은 시스템에서, 각 Git commit 는 새로운 tarballs를 생성하여 전체 이미지를 완전히 다시 다운로드해야 합니다. mtime 변경과 같은 요인은 사용자가 동일한 RPM를 설치하는 경우에도 기본 데이터에 변경이 없음에도 불구하고 스토리지 요구 사항이 두 배로 증가한다는 것을 의미합니다. 이것은 레지스트리 스토리지에 부담을 부담할 뿐만 아니라, 변경이 발생하지 않은 경우에도 클라이언트가 새로운 레이어를 끌어당길 강요합니다. 이 상황은 rhel-bootc 및 RHEL AI와 같은 환경에서 문제를 더욱 악화시켜 더 빠른 업데이트를 우선시합니다.

6.1. Reproductible Container Build의 이점

RHEL 컨테이너용 재생 가능한 빌딩은 소스 코드와 빌딩 환경이 변경되지 않은 상태에서 이미지 레이어가 일관되도록 유지함으로써 레지스트리 저장 공간을 줄이고 업데이트 유용 로드를 작게 만듭니다. 이 프로세스는 레이어 캐싱의 효율성을 극대화하여 이중 저장 및 동일한 데이터의 전송을 방지합니다. 재생 가능한 컨테이너 빌드의 주목할만한 이점은 다음과 같습니다.

  • 레지스트리 저장 공간 감소: 이미지가 업데이트되면 변경된 레이어만 저장됩니다. 재생 가능한 빌드는 동일한 소스 코드의 동일한 이미지를 보장하여 비 결정적인 요인(타임스탬프, 파일 순서, 메타데이터)이 변경을 일으키는 것을 방지하여 추가 저장 공간을 피합니다.
  • 효율적이고 소규모 업데이트 페이로드: 컨테이너 소규모 업데이트(예: 보안 패치)의 경우 변경된 레이어만 다운로드해야 하며 전체 이미지가 다운로드되지 않습니다. 재생 가능한 빌드는 또한 소스 업데이트로 영향을받는 레이어만 변경되도록 보장합니다. 작은 코드 변경이 여러 레이어를 변경할 수 있는 재생할 수 없는 빌드와는 달리.
  • 더 빠른 다운로드: 컨테이너 재생 가능한 빌딩은 효율적인 캐시를 통해 더 빠른 다운로드를 가능하게 하고 네트워크 트래픽을 줄여서 빌딩 시스템과 최종 사용자를 모두 최적화합니다.
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 문서 정보

Legal Notice

Theme

© 2026 Red Hat
맨 위로 이동