Container Registry는 지원 중단되었으며 종료될 예정입니다. 2024년 5월 15일부터 Artifact Registry는 이전 Container Registry를 사용하지 않고 프로젝트의 gcr.io 도메인 이미지를 호스팅합니다. 2025년 3월 18일 이후에는 Container Registry가 종료됩니다.

Google Cloud에서 컨테이너 관리를 시작하려면 Artifact Registry를 사용하세요. Container Registry를 사용하는 경우 Artifact Registry로 전환하여 Google Cloud에서 컨테이너를 관리하는 방법을 알아보세요.

지원 중단 및 종료에 대한 자세한 내용은 지원 중단 페이지와 출시 노트를 참조하세요.

Container Registry 개요

Container Registry는 Google Cloud에 비공개 컨테이너 이미지를 저장하는 기존 서비스입니다.

이 서비스는 지원 중단되었습니다. 기존 이미지를 Artifact Registry로 이동하시면 gcr.io 도메인을 사용하여 계속 액세스할 수 있습니다. 2024년 5월 15일부터는 이전에 Container Registry를 사용하지 않은 프로젝트는 Artifact Registry의 gcr.io 도메인 이미지만 호스팅합니다.

Container Registry와 Artifact Registry간의 비교와 Container Registry에서 Artifact Registry로의 전환에 대한 자세한 내용은 Container Registry에서 전환을 참조하세요.

이미지 작업

많은 사람이 공개 Docker 이미지를 저장하는 중앙 레지스트리로 Docker Hub를 사용하지만, 이미지 액세스를 제어하려면 Artifact Registry 또는 Container Registry 같은 비공개 레지스트리를 사용해야 합니다.

보안 HTTPS 엔드포인트를 통해 레지스트리에 액세스하여 모든 시스템, VM 인스턴스 또는 자체 하드웨어로 이미지를 내보내고 가져오며 관리할 수 있습니다.

레지스트리를 Google Cloud CI/CD 서비스 또는 기존 CI/CD 도구와 통합합니다.
- Cloud Build의 컨테이너 이미지를 저장합니다.
- Google Kubernetes Engine, Cloud Run, Compute Engine, App Engine 가변형 환경을 포함하여 컨테이너 이미지를 Google Cloud 런타임에 배포합니다.
- ID 및 액세스 관리는 일관된 사용자 인증 정보 및 액세스 제어를 제공합니다.
컨테이너 소프트웨어 공급망을 보호합니다.
- Artifact Analysis를 사용하여 컨테이너 메타데이터를 관리하고 컨테이너 취약점을 스캔합니다.
- Binary Authorization으로 배포 정책을 적용합니다.
VPC 서비스 제어 보안 경계에서 레지스트리를 보호합니다.

레지스트리

Container Registry를 사용하여 Google Cloud 프로젝트마다 멀티 리전 호스트를 최대 4개까지 만들 수 있습니다. 별도의 액세스 정책으로 개별 저장소를 만들거나 멀티 리전 대신 리전에 이미지를 저장하려면 대신 Artifact Registry를 사용합니다.

Container Registry의 레지스트리는 호스트와 프로젝트 ID를 기준으로 명명됩니다. 이미지 작업(내보내기, 가져오기, 삭제 등)을 하려면, 다음 형식을 이용해 이미지를 식별해야 합니다.

HOSTNAME/PROJECT-ID/IMAGE:TAG

또는

HOSTNAME/PROJECT-ID/IMAGE@IMAGE-DIGEST

각 항목의 의미는 다음과 같습니다.

HOSTNAME은 이미지가 저장된 위치입니다.
- gcr.io는 현재 미국 내 이미지를 호스팅하지만 향후 위치가 변경될 수 있습니다.
- us.gcr.io는 미국 내 이미지를 gcr.io가 호스팅하는 이미지와는 다른 스토리지 버킷에서 호스팅합니다.
- eu.gcr.io는 유럽 연합의 회원국 내에서 이미지를 호스팅합니다.
- asia.gcr.io는 아시아의 이미지를 호스팅합니다.
이 위치는 Cloud Storage 스토리지 버킷의 멀티 리전에 해당합니다. 이미지를 새로운 호스트 이름으로 레지스트리에 내보내면 Container Registry는 지정된 멀티 리전에 스토리지 버킷을 만듭니다. 이 버킷은 레지스트리의 기본 스토리지입니다. 프로젝트 내에서 호스트 이름이 동일한 모든 레지스트리는 하나의 스토리지 버킷을 공유합니다.
PROJECT-ID는 Google Cloud 콘솔 프로젝트 ID입니다. 프로젝트 ID에 콜론(:)이 포함된 경우 아래의 도메인 범위 프로젝트를 참조하세요.
IMAGE는 이미지의 이름입니다. 이미지의 로컬 이름과 다를 수도 있습니다. Google Cloud 콘솔에서 프로젝트의 레지스트리는 이미지 이름으로 표시됩니다. 각 저장소는 이름이 같은 여러 이미지를 보유할 수 있습니다. 예를 들어 'my-image'라는 이미지의 다양한 버전을 보유할 수 있습니다.
:TAG 또는 @IMAGE-DIGEST를 끝에 추가하면 이미지의 특정 버전을 구별할 수 있지만 선택사항입니다. 태그 또는 다이제스트를 지정하지 않으면 Container Registry가 기본 태그 latest가 있는 이미지를 찾습니다. 아래 레지스트리 내의 이미지 버전을 참조하세요.

gcr.io/PROJECT-ID 레지스트리의 my-image 이미지의 경우 다음 형식을 사용하여 이미지를 내보내거나 가져옵니다.

gcr.io/PROJECT-ID/my-image:tag1

여기서 PROJECT-ID는 Google Cloud 콘솔 프로젝트 ID입니다.

저장소로 이미지 정리

레지스트리 내의 저장소 아래에 관련 이미지를 그룹화할 수 있습니다. 이미지를 태깅하거나 내보내거나 가져올 때, 이미지 경로의 프로젝트 아래에서 저장소 이름을 지정합니다.

Container Registry에서 저장소는 조직을 지원합니다. 이는 이미지 경로의 논리적 폴더와 같은 역할을 수행하지만 실제 파일 시스템 구조를 반영하거나 더욱 세밀한 액세스 제어를 지원하지 않습니다.

builds 프로젝트의 us.gcr.io 호스트에 저장된 다음 이미지를 고려합니다.

us.gcr.io/builds/product1/dev/product1-app:beta-2.0
us.gcr.io/builds/product1/stable/product1:1.0
us.gcr.io/builds/product2/dev/product2:alpha
us.gcr.io/builds/product2/stable/product2:1.0

사용자가 builds 프로젝트의 us.gcr.io 호스트에 대한 쓰기 액세스 권한을 가지고 있으면 모든 이미지가 동일한 스토리지 버킷에 있으므로 us.gcr.io/builds 아래의 모든 경로에 대한 쓰기 액세스 권한이 있으며 저장소 또는 이미지 수준에서 액세스를 제한할 수 없습니다.

더욱 세분화된 액세스 제어가 필요한 경우에는 대신 Artifact Registry를 사용할 수 있습니다. Artifact Registry에서 저장소는 개별 리소스이므로 us-docker.pkg.dev/builds/product1 및 us-docker.pkg.dev/builds/product2와 같은 저장소에 별도의 IAM 정책을 적용할 수 있습니다.

레지스트리 내의 이미지 버전

레지스트리는 다양한 이미지를 포함할 수 있으며, 이러한 이미지는 다양한 버전으로 구성될 수 있습니다. 레지스트리 내에서 이미지의 특정 버전을 식별하려면 이미지의 태그 또는 다이제스트를 지정하면 됩니다.

태그는 라벨의 역할을 합니다. 한 이미지에 여러 개의 태그를 적용할 수 있습니다. 예를 들어 이미지에는 버전 번호를 나타내는 v1.5 태그와 최종 테스트에 대한 준비 상태를 나타내는 release-candidate 태그가 포함될 수 있습니다.
다이제스트는 자동으로 생성되고 이미지 버전별로 고유하며 @IMAGE-DIGEST 형식입니다. 여기서 IMAGE-DIGEST는 이미지 콘텐츠의 sha256 해시 값입니다.

my-image 이미지의 특정 버전을 식별하려면 다음 안내를 따르세요.

이미지 태그를 추가합니다.
```
gcr.io/PROJECT-ID/my-image:tag1
```

또는 이미지의 다이제스트를 추가합니다.

gcr.io/PROJECT-ID/my-image@sha256:4d11e24ba8a615cc85a535daa17b47d3c0219f7eeb2b8208896704ad7f88ae2d

여기서 PROJECT-ID는 Google Cloud 콘솔 프로젝트 ID입니다. 프로젝트 ID에 콜론(:)이 포함된 경우 아래의 도메인 범위 프로젝트를 참조하세요.

Google Cloud 콘솔에서 이미지 화면의 태그 열에는 이미지의 태그가 나열됩니다. 이미지 다이제스트를 포함한 메타데이터를 확인하려면 이미지의 버전을 클릭하세요.

태그 수정 방법은 이미지 태그하기를 참조하세요.

도메인 범위 프로젝트

프로젝트 범위가 도메인인 경우 프로젝트 ID의 도메인 이름 뒤에 콜론(:)이 포함됩니다. Docker가 콜론을 처리하는 방법으로 인해 Container Registry에서 이미지 다이제스트를 지정할 때 콜론 문자를 슬래시로 바꾸어야 합니다. 다음 형식을 사용하여 이러한 유형의 프로젝트에서 이미지를 식별합니다.

HOSTNAME/[DOMAIN]/[PROJECT]/IMAGE

예를 들어 ID가 example.com:my-project인 프로젝트는 다음 이미지를 포함할 수 있습니다.

gcr.io/example.com/my-project/image-name

URL로서의 레지스트리 이름

https://HOSTNAME/PROJECT-ID/IMAGE URL은 Google Cloud 콘솔에 있는 이미지의 URL입니다. 레지스트리 호스트에 액세스할 수 있는 권한이 있는 인증된 사용자는 링크를 사용하여 저장된 모든 이미지를 볼 수 있습니다. 이미지 경로 형식에 대한 자세한 내용은 레지스트리를 참조하세요.

예를 들어 다음 URL은 Google Cloud 콘솔의 공개 레지스트리에 연결됩니다.

컨테이너 이미지 형식

Container Registry는 Docker 이미지 Manifest V2와 OCI 이미지 형식을 지원합니다. 자세한 내용은 컨테이너 이미지 형식을 참조하세요.

이미지 및 기타 유형의 아티팩트를 중앙에 저장하려면 Container Registry 대신 Artifact Registry를 사용하는 것이 좋습니다.

액세스 제어

Container Registry는 컨테이너 이미지의 태그와 레이어 파일을 레지스트리와 같은 프로젝트에 있는 Cloud Storage 버킷에 저장합니다. 버킷에 대한 액세스는 Cloud Storage의 ID 및 액세스 관리(IAM) 설정을 이용해 구성됩니다.

레지스트리 호스트에 대한 액세스 권한이 있는 사용자는 호스트의 스토리지 버킷에 있는 이미지에 액세스할 수 있습니다. 더욱 세분화된 액세스 제어가 필요한 경우에는 Artifact Registry를 사용하는 것이 좋습니다. Artifact Registry에서는 저장소 수준 액세스 제어를 제공합니다.

기본적으로 프로젝트 소유자와 편집자는 프로젝트의 Container Registry 버킷에 대한 내보내기/가져오기 권한을 가집니다. 프로젝트 뷰어는 내보내기 권한만 가집니다.

Container Registry 권한에 대한 자세한 내용은 액세스 제어 구성을 참조하세요.

이미지 메타데이터를 Cloud Storage에서 고성능 백엔드 데이터베이스로 옮기는 계획에 대한 내용은 Container Registry 지원 중단 알림을 참조하세요.

인증

이미지를 내보내거나 가져오려면 인증을 구성해야 합니다. Google Cloud CLI를 사용하여 Container Registry에 대한 요청을 인증하도록 Docker를 구성할 수 있습니다. Container Registry에서는 액세스 토큰이나 JSON 키 파일을 사용한 고급 인증 방식도 지원합니다.

Docker 사용자 인증 정보 도우미

Docker는 이미지를 내보내고 가져올 때 Container Registry에 액세스해야 합니다. Docker 사용자 인증 정보 도우미 명령줄 도구를 사용하면 Container Registry 사용자 인증 정보를 Docker에서 사용하도록 구성할 수 있습니다.

사용자 인증 정보 도우미는 Container Registry 사용자 인증 정보를 자동으로, 또는 --token-source 플래그로 지정한 위치에서 가져온 다음 Docker의 구성 파일에 기록합니다. 이렇게 하면 Docker 명령줄 도구 docker를 사용하여 Container Registry와 직접 상호 작용할 수 있습니다.

자세한 내용은 고급 인증을 참조하세요.

Container Registry 서비스 계정

Container Registry API를 사용 설정하면, Container Registry는 프로젝트에 서비스 계정을 추가합니다. 이 서비스 계정은 다음과 같은 ID를 가집니다.

service-[PROJECT_NUMBER]@containerregistry.iam.gserviceaccount.com

이러한 Container Registry 서비스 계정은 Container Registry가 프로젝트에서 서비스 업무를 수행하도록 특별히 설계되었습니다. Google 관리 계정이더라도 이 계정은 프로젝트에 따라 달라집니다.

이 서비스 계정을 삭제하거나 권한을 변경하면 특정 Container Registry 기능이 정상적으로 작동하지 않게 됩니다. 역할을 수정하거나 계정을 삭제해선 안 됩니다.

이 서비스 계정과 권한에 대한 자세한 내용은 Container Registry 서비스 계정을 참조하세요.

캐시 가져오기

mirror.gcr.io 레지스트리는 Docker Hub에서 자주 요청되는 공개 이미지를 캐시합니다.

캐시된 이미지를 사용하면 Docker Hub에서 가져오기 속도를 높일 수 있습니다. 클라이언트는 Docker Hub에서 직접 이미지를 가져오기 전에 항상 Docker Hub 이미지의 캐시된 사본을 확인합니다.

자세한 내용은 캐시된 Docker Hub 이미지 가져오기를 참조하세요.

알림

Pub/Sub를 사용하여 컨테이너 이미지의 변경 사항에 대한 알림을 받을 수 있습니다.

자세한 내용은 Pub/Sub 알림 구성을 참조하세요.

Google Cloud에서 Container Registry 사용

Compute Engine 인스턴스와 Google Kubernetes Engine 클러스터는 인스턴스의 Cloud Storage 범위를 기반으로 Container Registry 이미지를 내보내고 가져올 수 있습니다. Google Cloud에서 Container Registry 사용을 참조하세요.

Container Registry에 저장된 이미지는 App Engine 가변형 환경에 배포할 수 있습니다.

지속적 배포 도구 통합

Container Registry는 Cloud Build 및 Jenkins와 같은 타사 도구를 포함하여 많이 사용되는 지속적 통합과 지속적 배포 시스템에서 작동합니다.

Container Registry는 Google Cloud 서비스와 원활하게 통합됩니다. 예를 들어 Cloud Build는 기본적으로 동일한 프로젝트의 Container Registry 호스트에 이미지를 내보내고 가져올 수 있습니다. 기본적으로 Google Kubernetes Engine 및 Cloud Run과 같은 런타임 환경은 동일한 프로젝트의 레지스트리 호스트에서 이미지를 가져올 수도 있습니다.

또는 Jenkins와 같은 타사 도구를 사용하여 이미지를 빌드, 가져오기, 푸시할 수 있습니다. 타사 도구를 사용할 경우 도구를 대신하여 Container Registry와 상호작용할 계정의 권한 및 인증을 구성해야 합니다.

통합 예시를 살펴보려면 Container Registry가 포함된 Google Cloud 기술 가이드를 참조하세요.