Container Registry

Dockerfile로 이미지를 빌드했다고 해서 바로 배포가 되는 것은 아닙니다. 이미지 파일이 빌드한 머신에만 있으면 다른 서버에서는 쓸 수 없습니다. 이미지를 tar 파일로 내보내 직접 복사하는 방법이 있지만, 이미지 수가 늘고 버전이 쌓이면 어느 서버에 어떤 버전이 있는지 추적이 안 됩니다. 롤백해야 할 때 지난주 이미지가 어디 있는지 찾는 것부터 시작해야 합니다. 팀원이 여러 명이면 누가 어떤 버전을 쓰고 있는지 맞추는 것도 별도 관리가 됩니다. 이미지를 중앙에서 관리하고, 버전별로 태그를 달고, 필요한 곳에서 pull 한 줄로 가져올 수 있는 장소가 없으면 컨테이너의 이식성이라는 장점이 배포 단계에서 막힙니다.

컨테이너가 팀 단위 배포 도구가 되자, 이미지를 한 머신에서만 들고 있는 방식으로는 CI/CD와 롤백을 감당할 수 없었습니다. 빌드가 끝난 이미지를 공통 장소에 올리고, 환경마다 같은 태그를 pull해 실행해야 배포 자동화가 성립했기 때문입니다. 여기에 접근 제어, 지역별 복제, 취약점 검사 같은 운영 요구가 붙으면서 레지스트리는 단순 저장소를 넘어 빌드와 실행 사이를 잇는 필수 인프라로 자리잡았습니다.

레지스트리의 핵심 구조는 repository와 tag입니다. repository는 하나의 이미지 이름에 해당하고, tag는 그 이미지의 특정 버전을 가리킵니다. 예를 들어 myapp:v1.2.0에서 myapp이 repository, v1.2.0이 tag입니다. docker push를 하면 이미지의 레이어가 레지스트리에 업로드됩니다. 이때 이미 존재하는 레이어는 다시 올리지 않습니다. 같은 베이스 이미지를 쓰는 여러 이미지가 레이어를 공유하므로 저장 공간과 전송 시간이 줄어듭니다. docker pull도 마찬가지로, 로컬에 이미 있는 레이어는 건너뛰고 부족한 레이어만 내려받습니다. 접근 제어는 퍼블릭과 프라이빗으로 나뉩니다. 퍼블릭 repository는 누구나 pull할 수 있고, 프라이빗은 인증된 사용자만 접근 가능합니다. 조직 내부 이미지는 대부분 프라이빗 레지스트리에 두고, 접근 권한을 팀이나 서비스 계정 단위로 관리합니다.

Container Registry와 소스코드 저장소(GitHub, GitLab 등)는 둘 다 버전을 관리하는 중앙 저장소라는 점에서 닮았지만, 관리 대상이 다릅니다. 소스코드 저장소는 텍스트 파일의 변경 이력을 다루고, 레지스트리는 빌드가 완료된 바이너리 이미지를 다룹니다. 소스코드에서 커밋 해시가 버전을 식별하듯, 레지스트리에서는 태그와 다이제스트(SHA256 해시)가 이미지 버전을 식별합니다. 퍼블릭 레지스트리와 프라이빗 레지스트리의 차이도 중요합니다. Docker Hub 같은 퍼블릭 레지스트리는 오픈소스 이미지를 공유하기 좋지만, 기업 내부 코드가 들어간 이미지를 올리기에는 접근 제어와 네트워크 위치 측면에서 맞지 않을 수 있습니다. 프라이빗 레지스트리는 조직 네트워크 안에서 운영하거나 클라우드 관리형으로 쓸 수 있어서 보안 요구와 pull 속도를 함께 충족합니다.

레지스트리는 CI/CD 파이프라인의 중심 연결점입니다. 코드가 커밋되면 CI가 Dockerfile로 이미지를 빌드하고, 테스트를 통과한 이미지에 태그를 달아 레지스트리에 push합니다. 배포 시스템은 레지스트리에서 해당 태그의 이미지를 pull해 운영 환경에 띄웁니다. 장애가 나면 이전 태그로 pull해서 롤백합니다. 운영에서 실질적으로 중요한 것은 태그 전략과 이미지 정리입니다. latest 태그만 사용하면 어느 버전이 운영에 올라가 있는지 확인이 안 됩니다. 시맨틱 버전(v1.2.0)이나 Git 커밋 해시를 태그로 쓰면 코드와 이미지의 대응이 명확해집니다. 오래된 이미지를 정리하지 않으면 저장 비용이 계속 늘어나므로 보존 정책(retention policy)도 설정해 둬야 합니다. 레지스트리를 선택할 때는 팀의 배포 환경과 보안 요구를 먼저 봅니다. 개인 프로젝트나 오픈소스는 퍼블릭 레지스트리로 충분하지만, 기업 서비스라면 프라이빗 레지스트리에서 접근 제어, 취약점 스캔, 지역별 복제를 활용하는 것이 일반적입니다.