Let’s Bootc! [8] - Container Registry : bootc 이미지 저장소는 어디가 좋을까?

Summary bootc 이미지 저장소 선택 시 Docker Hub는 대용량 이미지 전송 시 타임아웃 문제가 발생하며, GHCR은 안정적인 대용량 전송과 Pull 제한이 없고 GitHub 생태계와 통합되어 운영 편의성이 좋다. Harbor는 완전한 프라이빗 환경을 제공하지만 직접 운영해야 하는 부담이 있다. 세 가지 모두 OCI 표준을 따르므로 필요에 따라 자유롭게 전환할 수 있다.

[7] bootc 이미지 저장소는 어디가 좋을까?

bootc를 본격적으로 운영하다 보면 필연적으로 마주치는 문제가 있습니다. 바로 이미지 저장소입니다. 컨테이너 이미지를 어디에 올려둘 것인가, 그리고 그 저장소가 얼마나 안정적으로 대용량 이미지를 감당할 수 있는가 하는 문제입니다.

일반적인 마이크로서비스 컨테이너는 수백 MB 수준입니다. 그런데 bootc 이미지는 다릅니다. KDE Plasma 데스크톱 환경에 한글 입력기, Wine, 그리고 각종 개발 도구를 포함하면 이미지 크기가 15GB에서 20GB 사이까지 커집니다. 제가 실제로 빌드한 CentOS 9 bootc 이미지의 최종 크기는 21.6GB였습니다. 일반 컨테이너와는 차원이 다른 규모입니다.

이 무거운 이미지를 어디에 올릴 것인가. 저는 세 가지 선택지를 검토했습니다.

Docker Hub: 익숙함의 함정

처음에는 가장 익숙한 Docker Hub를 선택했습니다. 대부분의 컨테이너 개발자가 처음 접하는 레지스트리이고, 저 역시 마찬가지였습니다.

그러나 첫 번째 이미지를 푸시하는 순간부터 문제가 시작됐습니다. 1.4GB짜리 레이어를 전송하던 중 갑자기 “Access Denied” 에러가 발생했습니다. 로그인을 다시 해도, 토큰을 재발급해도 같은 에러가 반복됐습니다. 처음에는 인증 문제인 줄 알았습니다. 그런데 원인을 분석해 보니 다른 곳에 있었습니다.

대용량 레이어 전송 중에 세션 타임아웃이 발생한 것입니다. 그런데 서버는 타임아웃을 타임아웃이라고 말해주지 않았습니다. 대신 “Access Denied"라는 엉뚱한 에러를 반환했습니다. 이것이 Docker Hub 무료 플랜의 고질적인 문제라는 것을 나중에야 알게 되었습니다.

Docker Hub는 마이크로서비스용으로 설계된 레지스트리입니다. 수백 MB 이미지를 빠르게 배포하는 데 최적화되어 있습니다. 21GB짜리 OS 이미지를 다루기엔 태생적으로 적합하지 않았던 것입니다. Docker Hub가 나쁜 서비스라는 것이 아닙니다. 단지 bootc의 유스케이스에는 맞지 않았을 뿐입니다.

GHCR: 현재 제가 선택한 저장소

GitHub Container Registry, 줄여서 GHCR은 Docker Hub의 대안으로 검토한 저장소입니다. 그리고 현재 제가 실제로 사용하고 있는 곳이기도 합니다.

GHCR을 선택한 이유는 몇 가지가 있습니다. 첫째, 대용량 파일 전송에 관대합니다. GitHub 인프라를 공유하기 때문에 Git LFS처럼 큰 파일을 다루는 데 익숙한 환경입니다. 실제로 21GB 이미지를 푸시했을 때 Docker Hub에서 겪었던 타임아웃 문제가 발생하지 않았습니다.

둘째, Pull rate 제한이 없습니다. Docker Hub 무료 플랜은 시간당 100회라는 Pull 제한이 있습니다. bootc 시스템에서 여러 대의 머신이 동시에 업그레이드를 시도하면 이 제한에 걸릴 수 있습니다. GHCR은 이런 제한이 없습니다.

셋째, GitHub 생태계와 자연스럽게 통합됩니다. GitHub Actions를 통한 CI/CD 파이프라인 구성이 용이하고, 리포지토리와 컨테이너 이미지를 한 곳에서 관리할 수 있습니다. 이것은 부수적인 장점이지만, 운영 편의성 측면에서 무시할 수 없는 요소입니다.

마이그레이션 과정은 단순했습니다. GHCR에 로그인하고, 기존 이미지에 새로운 태그를 붙이고, 푸시하면 됩니다. 기존 bootc 시스템에서는 bootc switch 명령으로 이미지 소스를 전환하고 재부팅하면 끝입니다. 이렇게 간단하게 전환할 수 있었던 이유가 있습니다. 바로 OCI 표준 덕분입니다.

Harbor: 프라이빗 운영이 필요하다면

Harbor는 CNCF에서 관리하는 오픈소스 컨테이너 레지스트리입니다. 직접 서버를 운영해야 한다는 부담이 있지만, 완전한 프라이빗 환경이 필요한 경우 유력한 선택지가 됩니다.

기업 환경에서 보안 정책상 외부 레지스트리를 사용할 수 없거나, 네트워크가 격리된 환경에서 bootc를 운영해야 하는 경우가 있습니다. 이런 상황에서 Harbor는 좋은 대안입니다. 취약점 스캐닝, 이미지 서명, 접근 제어 같은 엔터프라이즈 기능도 제공합니다.

다만 저는 아직 Harbor를 직접 운영해 본 경험은 없습니다. 현재로서는 GHCR로 충분히 요구사항을 충족하고 있기 때문입니다. Harbor에 대해서는 추후 프라이빗 환경 구축이 필요해지면 더 깊이 다뤄볼 생각입니다.

핵심은 OCI 표준입니다

여기서 강조하고 싶은 것이 있습니다. Docker Hub에서 GHCR로, 혹은 GHCR에서 Harbor로 저장소를 바꾸더라도 podman push, podman pull 명령어가 그대로 작동한다는 사실입니다. bootc upgrade 명령도 레지스트리 주소만 바꾸면 동일하게 동작합니다.

이것이 가능한 이유는 이 모든 레지스트리가 OCI(Open Container Initiative) 표준을 따르기 때문입니다. OCI는 컨테이너 이미지 포맷과 배포 방식을 표준화했습니다. 덕분에 어떤 레지스트리를 사용하든 호환성 문제 없이 운영할 수 있습니다.

이것이 OCI가 가져온 혁신적인 변화입니다. 특정 벤더에 종속되지 않고 자유롭게 인프라를 선택할 수 있습니다. Docker Hub가 불안정하면 GHCR로 옮기면 됩니다. 보안 요구사항이 바뀌면 Harbor로 전환하면 됩니다. 이미지를 다시 빌드할 필요도, 배포 스크립트를 크게 수정할 필요도 없습니다.

bootc에서 컨테이너 레지스트리는 단순한 이미지 저장소가 아닙니다. OS 배포 인프라 그 자체입니다. 레지스트리가 불안정하면 시스템 업데이트가 실패합니다. 그래서 저장소 선택이 중요한 것이고, 동시에 OCI 표준 덕분에 그 선택을 언제든 바꿀 수 있다는 것이 중요합니다.

정리

세 가지 저장소를 비교하면 다음과 같습니다.

Docker Hub는 용량 제한은 없지만 대용량 이미지 전송 시 타임아웃 문제가 발생합니다. 마이크로서비스용으로는 여전히 좋은 선택이지만, bootc 이미지에는 적합하지 않았습니다.

GHCR은 대용량 전송이 안정적이고 Pull 제한이 없습니다. GitHub 생태계와 통합되어 있어 운영 편의성도 좋습니다. 현재 제가 선택한 저장소입니다.

Harbor는 완전한 프라이빗 환경이 필요할 때 고려할 수 있는 선택지입니다. 직접 운영해야 하는 부담은 있지만, 엔터프라이즈 기능과 완전한 통제권을 얻을 수 있습니다.

그리고 이 세 가지 모두 OCI 표준을 따르기 때문에, 필요에 따라 자유롭게 전환할 수 있습니다. 이것이 이 섹션에서 기억해야 할 핵심입니다.