gcr.io 도메인 지원을 사용하여 저장소 설정

이 문서에서는 Artifact Registry에서 gcr.io 저장소를 수동으로 설정하는 방법을 설명합니다.

Google의 자동 마이그레이션 도구를 사용하여 Artifact Registry에서 gcr.io 저장소로 전환하는 것이 좋습니다.

고객 관리 암호화 키(CMEK)를 사용하여 Artifact Registry에 gcr.io 저장소를 만들려면 시작하기 전에의 단계를 수행한 후 수동 저장소 만들기의 안내를 따릅니다.

시작하기 전에

1. 아직 설치되지 않았으면 Google Cloud CLI를 설치합니다. 기존 설치의 경우 다음 명령어를 실행하여 구성요소를 최신 버전으로 업데이트합니다.

   gcloud components update
   

2. Artifact Registry 및 Resource Manager API를 사용 설정합니다. gcloud CLI는 Resource Manager API를 사용하여 필요한 권한 중 하나를 검사합니다.

   다음 명령어를 실행합니다.

   gcloud services enable \
       cloudresourcemanager.googleapis.com \
       artifactregistry.googleapis.com
   

3. 전환을 시작하기 전에 Artifact Registry의 가격 책정에 대해 알아보세요.

필요한 역할

'gcr.io' 저장소를 설정하는 데 필요한 권한을 얻으려면 관리자에게 Google Cloud 프로젝트에서 다음 IAM 역할을 부여해 달라고 요청하세요.

• Artifact Registry 저장소를 만들고 개별 저장소에 액세스 권한 부여: Artifact Registry 관리자(roles/artifactregistry.admin)
• Cloud Storage 스토리지 버킷에 적용된 기존 Container Registry 구성 보기 및 관리: 스토리지 관리자(roles/storage.admin)
• gcr.io 호스트 이름에 이미지를 처음 내보낼 때 gcr.io 저장소 만들기: Artifact Registry Create-on-push 작성자(roles/artifactregistry.createOnPushWriter)
• 프로젝트 수준에서 저장소 액세스 권한 부여: 프로젝트 IAM 관리자(roles/resourcemanager.projectIamAdmin) 또는 폴더 관리자(roles/resourcemanager.folderAdmin)나 조직 관리자(roles/resourcemanager.organizationAdmin)와 같은 상응하는 권한이 포함된 역할

역할 부여에 대한 자세한 내용은 액세스 관리를 참조하세요.

커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.

참고: Artifact Registry 관리자 역할에는 다른 Artifact Registry의 미리 정의된 역할에 있는 권한이 대부분 포함되지만 gcr.io 저장소에 처음 내보내기를 위해 gcr.io 저장소를 만들기 위한 artifactregistry.repositories.createOnPush 권한이 포함되지 않았습니다.

제한사항

gcr.io 도메인 지원을 사용하는 저장소에는 다음 제한사항이 적용됩니다.

• Container Registry 호스트를 다른 프로젝트의 Artifact Registry 저장소에 매핑할 수 없습니다.
• 각 Container Registry 호스트 이름은 동일한 멀티 리전의 해당 Artifact Registry gcr.io 저장소에만 매핑됩니다.
• gcr.io 저장소의 이름은 사전 정의되며 수정할 수 없습니다.

저장소 위치를 더 세부적으로 제어해야 하는 경우 Artifact Registry pkg.dev 도메인에서 표준 저장소로 전환할 수 있습니다. 표준 저장소에서 gcr.io 도메인을 지원하지 않으므로 이 전환 접근 방식을 사용하려면 기존 자동화와 워크플로를 추가로 변경해야 합니다. 기능 차이에 대한 자세한 내용은 전환 옵션 선택을 참조하세요.

저장소 만들기

사용자에 대해 액세스 권한을 구성할 수 있도록 gcr.io 저장소를 만들고 리디렉션을 사용 설정하기 전에 기존 Container Registry 이미지를 Artifact Registry에 복사합니다.

빠른 저장소 생성

이 단계에서는 Google에서 관리되는 암호화 키로 암호화된 gcr.io 저장소를 만듭니다. 고객 관리 암호화 키(CMEK)를 사용하려면 수동으로 저장소를 만들어야 합니다.

gcr.io 저장소를 만들려면 다음 안내를 따르세요.

1. Google Cloud 콘솔에서 저장소 페이지를 엽니다.

   저장소 페이지 열기

   페이지의 배너에 You have gcr.io repositories in Container Registry라는 메시지가 표시됩니다.

   설정 페이지 열기

2. 배너에서 gcr.io 저장소 만들기를 클릭합니다.

   gcr.io 저장소 만들기 패널이 열립니다. 이미지 복사 섹션에는 생성되는 각 저장소의 정규화된 이름이 나열됩니다. 리디렉션을 설정하기 전에 Container Registry에서 이미지를 복사하려면 이러한 저장소 이름이 필요합니다.

3. 만들기를 클릭합니다.

Artifact Registry는 모든 Container Registry 호스트 이름에 대해 gcr.io 저장소를 만듭니다.

Container Registry 호스트 이름	Artifact Registry 저장소 이름
gcr.io	gcr.io
asia.gcr.io	asia.gcr.io
eu.gcr.io	eu.gcr.io
us.gcr.io	us.gcr.io

저장소의 Artifact Registry URL을 보려면 저장소 이름 옆의 경고 아이콘() 위로 포인터를 가져갑니다.

트래픽을 새 저장소로 리디렉션하기 전에 기존 자동화가 저장소에 액세스할 수 있는지 확인해야 합니다. 다음 단계는 저장소에 대한 액세스 권한을 부여하도록 권한을 구성하는 것입니다.

수동 저장소 생성

고객 관리 암호화 키(CMEK)를 사용하여 저장소 콘텐츠를 암호화하려는 경우 또는 Google Cloud 조직에 특정 위치에서 새 리소스 생성을 차단하는 위치 제약조건이 있는 경우 gcr.io 저장소를 수동으로 만듭니다.

gcr.io 저장소를 수동으로 만들려면 다음 안내를 따르세요.

1. CMEK를 사용하는 경우 이 저장소에서 사용할 키를 만들고 키를 사용할 권한을 부여합니다. 고객 관리 암호화 키 사용 설정을 참조하세요.

2. 저장소를 추가합니다.

   콘솔

   1. Google Cloud 콘솔에서 저장소 페이지를 엽니다.

      저장소 페이지 열기

   2. 저장소 만들기를 클릭합니다.

   3. 저장소 이름을 지정합니다.

      Container Registry 호스트 이름	Artifact Registry 저장소 이름
      gcr.io	gcr.io
      asia.gcr.io	asia.gcr.io
      eu.gcr.io	eu.gcr.io
      us.gcr.io	us.gcr.io

   4. Docker를 저장소 형식으로 지정합니다.

   5. 위치 유형에서 저장소의 멀티 리전을 지정합니다.

      Container Registry 호스트 이름	Artifact Registry 저장소 위치
      gcr.io	대한민국
      asia.gcr.io	asia
      eu.gcr.io	europe
      us.gcr.io	대한민국

   6. 저장소에 대한 설명을 추가합니다. 저장소 설명은 암호화되지 않으므로 민감한 정보는 포함하지 마세요.

   7. 암호화 섹션에서 저장소의 암호화 메커니즘을 선택합니다.

      • Google 관리 키 - Google 관리 암호화 키로 저장소 콘텐츠를 암호화합니다.
      • 고객 관리 키 - Cloud Key Management Service를 통해 제어하는 키로 저장소 콘텐츠를 암호화합니다. 키 설정 안내는 저장소의 CMEK 설정을 참조하세요.

   8. 만들기를 클릭합니다.

   gcloud

   다음 명령어를 실행하여 새 저장소를 만듭니다.

   gcloud artifacts repositories create REPOSITORY \
       --repository-format=docker \
       --location=LOCATION \
       --description=DESCRIPTION \
       --kms-key=KMS-KEY
   

   다음 값을 바꿉니다.

   • REPOSITORY는 저장소 이름입니다.

     Container Registry 호스트 이름	Artifact Registry 저장소 이름
     gcr.io	gcr.io
     asia.gcr.io	asia.gcr.io
     eu.gcr.io	eu.gcr.io
     us.gcr.io	us.gcr.io

   • LOCATION은 저장소의 멀티 리전입니다.

     Container Registry 호스트 이름	Artifact Registry 저장소 위치
     gcr.io	대한민국
     asia.gcr.io	asia
     eu.gcr.io	europe
     us.gcr.io	대한민국

   • DESCRIPTION은 저장소에 대한 설명입니다. 저장소 설명은 암호화되지 않으므로 민감한 정보는 포함하지 마세요.

   • 고객 관리 암호화 키를 사용하여 저장소 콘텐츠를 암호화하는 경우 KMS-KEY는 Cloud KMS 암호화 키의 전체 경로입니다. 경로 형식은 다음과 같습니다.

     projects/KMS-PROJECT/locations/KMS-LOCATION/keyRings/KEY-RING/cryptoKeys/KEY
     

     다음 값을 바꿉니다.

     • KMS-PROJECT는 키가 저장된 프로젝트입니다.
     • KMS-LOCATION은 키의 위치입니다.
     • KEY-RING은 키링의 이름입니다.
     • KEY는 키의 이름입니다.

   다음 명령어로 저장소를 나열하여 저장소가 생성되었는지 확인할 수 있습니다.

   gcloud artifacts repositories list
   

트래픽을 새 저장소로 리디렉션하기 전에 기존 자동화가 저장소에 액세스할 수 있는지 확인해야 합니다. 다음 단계는 저장소에 대한 액세스 권한을 부여하도록 권한을 구성하는 것입니다.

저장소에 권한 부여

Container Registry는 Cloud Storage 역할을 사용하여 액세스를 제어합니다. Artifact Registry에는 자체 IAM 역할이 있으며 이러한 역할은 Container Registry보다 읽기, 쓰기, 저장소 관리 역할을 더 명확하게 구분합니다.

스토리지 버킷에 부여된 기존 권한을 제안된 Artifact Registry 역할에 빠르게 매핑하려면 역할 매핑 도구를 사용하세요.

또는 Google Cloud 콘솔을 사용하여 스토리지 버킷에 액세스할 수 있는 주 구성원 목록을 볼 수 있습니다.

1. Google Cloud 콘솔에서 Cloud Storage 버킷 페이지로 이동합니다.
   

   버킷으로 이동

2. 보려는 레지스트리 호스트의 스토리지 버킷을 클릭합니다. 버킷 이름에서 PROJECT-ID는 Google Cloud 프로젝트 ID입니다.

   • gcr.io: artifacts.PROJECT-ID.appspot.com
   • asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
   • eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
   • us.gcr.io: us.artifacts.PROJECT-ID.appspot.com

3. 권한 탭을 클릭합니다.

4. 권한 탭에서 역할별 보기 하위 탭을 클릭합니다.

5. 역할을 확장하여 해당 역할이 있는 주 구성원을 확인합니다.

이 목록에는 버킷에서 직접 부여된 IAM 역할과 상위 프로젝트에서 상속된 역할이 포함됩니다. 역할에 따라 부여할 가장 적절한 Artifact Registry 역할을 선택할 수 있습니다.

Cloud Storage 및 기본 역할

현재 Container Registry에 액세스하는 사용자 및 서비스 계정에 Artifact Registry 저장소 액세스 권한을 부여합니다. 상위 프로젝트에서 상속된 Cloud Storage 역할의 경우 주 구성원이 현재 Container Registry를 사용하는지 확인해야 합니다. 일부 주 구성원은 Container Registry와 관련이 없는 다른 Cloud Storage 버킷에만 액세스할 수 있습니다.

IAM 이전에 존재하는 기본 역할 소유자, 편집자, 뷰어는 스토리지 버킷에 대해 제한된 액세스 권한을 갖습니다. 이것들은 본질적으로 이름이 암시하는 Cloud Storage 리소스에 대한 모든 액세스 권한을 부여하고 다른 Google Cloud 서비스에 대한 추가 권한을 제공합니다. 사용자 및 서비스 계정에 Artifact Registry 액세스 권한이 필요한지 확인하고 역할 매핑 테이블을 사용하여 Artifact Registry 액세스가 적합한 경우 올바른 권한을 부여하도록 합니다.

다음 표에서는 Container Registry 액세스에 대해 미리 정의된 Cloud Storage 역할로 부여되는 권한에 따라 Artifact Registry 역할을 매핑합니다.

필수 액세스 권한	현재 역할	Artifact Registry 역할	역할을 부여할 위치
이미지 가져오기 전용(읽기 전용)	스토리지 객체 뷰어 (roles/storage.objectViewer)	Artifact Registry 리더 (roles/artifactregistry.reader)	Artifact Registry 저장소 또는 Google Cloud 프로젝트
이미지 내보내기 및 가져오기(읽기 및 쓰기) 이미지 삭제	스토리지 기존 버킷 작성자 (roles/storage.legacyBucketWriter)	Artifact Registry 저장소 관리자 (roles/artifactregistry.repoAdmin)	Artifact Registry 저장소 또는 Google Cloud 프로젝트
프로젝트의 gcr.io 호스트 이름에 이미지를 처음 내보낼 때 Artifact Registry에서 gcr.io 저장소를 만듭니다.	스토리지 관리자 (roles/storage.admin)	Artifact Registry Create-on-push 저장소 관리자 (roles/artifactregistry.createOnPushRepoAdmin)	Google Cloud 프로젝트
저장소 만들기, 관리, 삭제	스토리지 관리자 (roles/storage.admin)	Artifact Registry 관리자 (roles/artifactregistry.Admin)	Google Cloud 프로젝트

프로젝트에서 상속된 서비스 에이전트 역할

Google Cloud 서비스의 기본 서비스 계정에는 프로젝트 수준에서 부여된 자체 역할이 있습니다. 예를 들어 Cloud Run용 서비스 에이전트에는 Cloud Run 서비스 에이전트 역할이 있습니다.

대부분의 경우 이러한 서비스 에이전트 역할에는 Container Registry 및 Artifact Registry에 대한 동일한 기본 권한이 포함되어 있으므로 기존 Container Registry 서비스와 동일한 프로젝트에서 Artifact Registry를 실행하는 경우 추가로 변경할 필요가 없습니다.

서비스 에이전트 역할의 권한에 대한 자세한 내용은 서비스 에이전트 역할 참조를 확인하세요.

커스텀 역할

역할 매핑 테이블을 사용하여 필요한 액세스 수준에 따라 사용자 또는 서비스 계정에 부여할 역할을 결정할 수 있습니다.

Artifact Registry 역할 부여에 대한 자세한 내용은 역할 및 권한 구성을 참조하세요.

Container Registry에서 컨테이너 복사

Google의 자동 마이그레이션 도구를 사용하여 Container Registry의 이미지를 Artifact Registry로 복사하는 것이 좋습니다.

다른 도구를 사용하여 이미지를 복사하려면 Container Registry에서 이미지 복사를 참조하세요.

기타 기능 설정

이 섹션에서는 Container Registry에서 설정했을 수 있는 다른 기능에 대한 구성을 설명합니다.

Artifact Analysis

Artifact Analysis는 Container Registry와 Artifact Registry를 모두 지원합니다. 두 제품 모두 이미지 메타데이터 및 취약점 스캔에 동일한 Artifact Analysis API를 사용하고 Artifact Analysis 알림에 동일한 Pub/Sub 주제를 사용합니다.

하지만 다음 작업은 리디렉션이 사용 설정된 경우에만 발생합니다.

• Artifact Registry에서 gcr.io 저장소 자동 스캔
• Pub/Sub 알림에 gcr.io 저장소 활동 포함

gcloud container images 명령어를 계속 사용하여 gcr.io 이미지 경로와 관련된 메모 및 일치하는 항목을 나열할 수 있습니다.

Container Registry

Artifact Registry

지원되는 OS가 포함된 이미지에서 주문형 스캔을 통해 OS 및 언어 패키지 취약점을 스캔합니다. 자동 스캔은 OS 취약점 정보만 반환합니다. 스캔 유형에 대해 자세히 알아보세요. 주문형 스캔 Google Cloud CLI 명령어인 gcloud artifacts docker images scan은 로컬 이미지의 취약점 또는 Container Registry의 이미지를 스캔합니다. Google Cloud CLI 명령어 gcloud artifacts docker images list-vulnerabilities는 취약점 스캔 결과를 반환합니다. 스캔은 지원되는 운영체제가 있는 Container Registry의 이미지에 대한 OS 및 언어 패키지 취약점 정보를 반환합니다. 자동 스캔 Google Cloud CLI 명령어 gcloud container images에는 취약점 및 기타 메타데이터를 포함한 스캔 결과를 보는 플래그가 포함됩니다. 스캔은 지원되는 운영체제가 있는 Container Registry의 이미지에 대한 OS 취약점 정보만 반환합니다.

주문형 스캔과 자동 스캔을 모두 사용하여 OS 및 언어 패키지 취약점을 스캔합니다. 스캔 유형에 대해 자세히 알아보세요. 주문형 스캔 Google Cloud CLI 명령어인 gcloud artifacts docker images scan은 로컬 이미지의 취약점 또는 Artifact Registry의 이미지를 검색합니다. Google Cloud CLI 명령어 gcloud artifacts docker images list-vulnerabilities는 취약점 스캔 결과를 반환합니다. 스캔은 지원되는 운영체제가 있는 Artifact Registry의 이미지에 대한 OS 및 언어 패키지 취약점 정보를 반환합니다. 자동 스캔 Google Cloud CLI 명령어 gcloud artifacts docker images에는 취약점 및 기타 메타데이터를 포함한 스캔 결과를 보는 플래그가 포함됩니다. 스캔은 지원되는 운영 체제와 지원되지 않는 운영 체제 모두에 대한 지원되는 운영체제 및 언어 패키지 취약성 정보가 있는 Artifact Registry의 이미지에 대한 OS 취약점 정보를 반환합니다.

Pub/Sub 알림

Artifact Registry는 Container Registry와 동일한 gcr 주제에 대한 변경사항을 게시합니다. Artifact Registry와 동일한 프로젝트에서 Container Registry와 함께 Pub/Sub을 이미 사용하는 경우 추가 구성이 필요하지 않습니다. 그러나 리디렉션을 사용 설정할 때까지 Artifact Registry는 gcr.io 저장소에 메시지를 게시하지 않습니다.

별도의 프로젝트에서 Artifact Registry를 설정하면 gcr 주제가 존재하지 않을 수 있습니다. 설정 안내는 Pub/Sub 알림 구성을 참조하세요.

gcr.io 트래픽 리디렉션 사용 설정

gcr.io 저장소를 만들고 서드 파티 클라이언트의 권한과 인증을 구성한 후에는 gcr.io 트래픽 리디렉션을 사용 설정할 수 있습니다.

리디렉션을 사용 설정한 후 문제가 발생하면 트래픽을 Container Registry로 다시 라우팅한 다음 문제를 해결하면 리디렉션을 다시 사용 설정할 수 있습니다.

리디렉션을 사용 설정할 권한 확인

리디렉션을 사용 설정하려면 프로젝트 수준에서 다음 권한이 있어야 합니다.

• artifactregistry.projectsettings.update: Artifact Registry 프로젝트 설정을 업데이트할 수 있는 권한입니다. 이 권한은 Artifact Registry 관리자 역할(roles/artifactregistry.admin)에 있습니다.
• storage.buckets.update - 전체 프로젝트에서 스토리지 버킷을 업데이트할 수 있는 권한입니다. 이 권한은 스토리지 관리자 역할(roles/storage.admin)에 있습니다.

이러한 권한이 없는 경우 관리자에게 프로젝트 수준의 권한을 부여해 달라고 요청하세요.

다음 명령어는 프로젝트에 대한 Artifact Registry 관리자 및 스토리지 관리자 역할을 부여합니다.

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:PRINCIPAL' \
    --role='roles/artifactregistry.admin'

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:PRINCIPAL' \
    --role='roles/storage.admin'

다음 값을 바꿉니다.

• PROJECT_ID는 Google Cloud 프로젝트 ID입니다.
• PRINCIPAL은 업데이트할 계정의 이메일 주소입니다. 예를 들면 user:[e-mail]입니다.

프로젝트 설정 검사

프로젝트 설정을 확인하려면 다음 명령어를 실행합니다.

gcloud artifacts settings enable-upgrade-redirection \
    --project=PROJECT_ID --dry-run

PROJECT_ID를 Google Cloud 프로젝트 ID로 바꿉니다.

Artifact Registry는 Container Registry 호스트 이름에 매핑되는 저장소를 확인합니다.

리디렉션을 사용 설정하면 Artifact Registry가 누락된 gcr.io 저장소를 자동으로 만들 수 있지만 리디렉션을 설정하기 전에 이러한 작업을 수행할 수 있도록 이를 먼저 만드는 것이 좋습니다.

• 저장소 수준 권한 구성
• 계속 사용하려는 Container Registry에서 이미지 복사
• 추가 구성 수행

리디렉션 사용 설정

gcr.io 트래픽 리디렉션을 사용 설정하려면 다음 안내를 따르세요.

콘솔

1. Google Cloud 콘솔에서 설정 페이지를 엽니다.

   설정 페이지 열기

2. Artifact Registry로 라우팅을 클릭합니다.

gcloud

리디렉션을 사용 설정하려면 다음 명령어를 실행합니다.

gcloud artifacts settings enable-upgrade-redirection \
    --project=PROJECT_ID

PROJECT_ID를 Google Cloud 프로젝트 ID로 바꿉니다.

Artifact Registry에서 리디렉션 설정이 시작됩니다.

현재 리디렉션 상태를 확인하려면 다음 명령어를 실행합니다.

gcloud artifacts settings describe

리디렉션을 사용 설정하면 결과는 다음과 같습니다.

legacyRedirectionState: REDIRECTION_FROM_GCR_IO_ENABLED

모든 Container Registry 호스트 이름에 대해 gcr.io 저장소를 만들지 않더라도 gcr.io, asia.gcr.io, eu.gcr.io, us.gcr.io에 대한 모든 트래픽은 리디렉션됩니다. 해당 Artifact Registry 저장소가 없는 호스트 이름에 이미지를 푸시할 경우 사용자에게 artifactregistry.repositories.createOnPush 권한이 포함된 역할이 있으면 Artifact Registry가 저장소를 만듭니다. 사전 정의된 역할인 Create-on-push 작성자(artifactregistry.createOnPushWriter) 및 Create-on-push 저장소 관리자(artifactregistry.createOnPushRepoAdmin)에 이 권한이 포함되어 있습니다.

리디렉션을 사용 설정하면 자동화를 테스트하고 새 gcr.io 저장소를 사용하여 이미지를 내보내고 가져올 수 있는지 확인할 수 있습니다.

리디렉션 확인

gcr.io 호스트 이름에 대한 pull 및 push 요청이 작동하는지 확인합니다.

1. gcr.io 경로를 사용하여 gcr.io 저장소 중 하나로 테스트 이미지를 내보냅니다.

   1. gcr.io 경로를 사용하여 이미지에 태그를 지정합니다. 예를 들어 이 명령어는 local-image 이미지에 us.gcr.io/my-project/test-image 태그를 지정합니다.

      docker tag local-image us.gcr.io/my-project/test-image
      

   2. 태그가 지정된 이미지를 내보냅니다. 예를 들어 이 명령어는 이미지 us.gcr.io/my-project/test-image를 내보냅니다.

      docker push us.gcr.io/my-project/test-image
      

2. 저장소의 이미지를 나열하여 이미지가 성공적으로 업로드되었는지 확인합니다. 예를 들어 us.gcr.io/my-project의 이미지를 나열하려면 다음 명령어를 실행합니다.

   gcloud container images list --repository=us.gcr.io/my-project
   

3. Container Registry 경로를 사용하여 저장소에서 이미지를 가져옵니다. 예를 들어 이 명령어는 us.gcr.io/my-project/test-image 이미지를 가져옵니다.

   docker pull us.gcr.io/my-project/test-image
   

이 초기 테스트 후에는 다음을 포함하여 이미지를 빌드하고 배포하는 기존 자동화가 예상대로 작동하는지 확인합니다.

• Container Registry를 사용하는 사용자 및 서비스 계정은 리디렉션이 사용 설정된 상태에서 이미지를 내보내고, 가져오고, 배포할 수 있습니다.
• 자동화는 이미지를 기존 저장소에만 내보냅니다.
• Artifact Analysis 취약점 스캔이 사용 설정된 경우 스캔은 gcr.io 저장소에서 취약점이 있는 이미지를 식별합니다.
• Binary Authorization을 사용하는 경우 gcr.io 저장소에서 배포된 이미지에 대해 기존 정책이 올바르게 작동합니다.
• 구성된 Pub/Sub 구독에는 gcr.io 저장소의 변경사항에 대한 알림이 포함됩니다.

Container Registry 이미지 삭제

리디렉션이 사용 설정되면 gcr.io 경로의 이미지를 삭제하는 명령어는 해당 Artifact Registry gcr.io 저장소의 이미지를 삭제합니다. gcr.io 경로에서 이미지를 삭제하는 삭제 명령어는 Container Registry 호스트에 저장된 이미지를 삭제하지 않습니다.

모든 Container Registry 이미지를 안전하게 삭제하려면 각 Container Registry 호스트 이름에 대한 Cloud Storage 버킷을 삭제합니다.

경고: 버킷을 삭제하면 버킷의 모든 이미지가 삭제됩니다. 삭제된 버킷에서 이미지를 복구할 수 없습니다.

각 Container Registry 스토리지 버킷을 삭제하려면 다음 안내를 따르세요.

콘솔

1. Google Cloud 콘솔의 Cloud Storage 페이지로 이동합니다.

2. 삭제할 스토리지 버킷을 선택합니다. 버킷 이름에서 PROJECT-ID는 Google Cloud 프로젝트 ID입니다.

   • gcr.io: artifacts.PROJECT-ID.appspot.com
   • asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
   • eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
   • us.gcr.io: us.artifacts.PROJECT-ID.appspot.com

3. Delete(삭제)를 클릭합니다. 확인 대화상자가 나타납니다.

4. 삭제를 확인하려면 버킷 이름을 입력한 다음 삭제를 클릭합니다.

gsutil

버킷에서 수십만 개 이상의 이미지를 일괄 삭제하려면 삭제 프로세스 완료에 오랜 시간이 걸리므로 gsutil을 사용하지 마세요. 대신 Google Cloud 콘솔을 사용하여 작업을 수행합니다.

버킷을 삭제하려면 gsutil rm 명령어를 -r 플래그와 함께 사용합니다.

gsutil rm -r gs://BUCKET-NAME

BUCKET-NAME을 Container Registry 스토리지 버킷 이름으로 바꿉니다. 버킷 이름에서 PROJECT-ID는 Google Cloud 프로젝트 ID입니다.

• gcr.io: artifacts.PROJECT-ID.appspot.com
• asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
• eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
• us.gcr.io: us.artifacts.PROJECT-ID.appspot.com

응답은 다음 예시와 같습니다.

Removing gs://artifacts.my-project.appspot.com/...

다른 Google Cloud 서비스가 동일한 Google Cloud 프로젝트에서 실행 중이면 Container Registry API를 사용 설정된 상태로 둡니다. Container Registry API를 사용 중지하려고 하면 구성된 종속 항목이 있는 다른 서비스가 프로젝트에서 사용 설정되어 있으면 Container Registry에 경고가 표시됩니다. Container Registry API를 사용 중지하면 해당 서비스를 사용하는 Container Registry를 현재 사용하지 않더라도 구성된 종속 항목이 있는 동일한 프로젝트의 모든 서비스가 자동으로 사용 중지됩니다.

다음 단계

• Docker 빠른 시작 사용해 보기
• gcr.io 저장소 알아보기