Container Registry는 지원 중단되었습니다. 2025년 3월 18일부터 Container Registry가 종료되어 Container Registry에 이미지를 쓸 수 없습니다.
gcr.io URL이 포함된 Google 소유 이미지를 비롯하여 Artifact Registry에 호스팅된 gcr.io URL은 Container Registry 종료의 영향을 받지 않습니다.
Container Registry 지원 중단 및 Artifact Registry로 마이그레이션하는 방법에 관한 자세한 내용은 Container Registry 지원 중단을 참고하세요.
Artifact Registry는 Google Cloud에서 컨테이너 이미지 스토리지 및 관리를 위해 권장되는 서비스입니다. Artifact Registry는 Container Registry와 같은 동일한 컨테이너 관리 기능을 제공하고 추가 기능 및 이점을 포함합니다. Artifact Registry는 컨테이너 이미지 및 비컨테이너 아티팩트를 모두 지원하는 완전 관리형 서비스로서 Container Registry의 기능을 확장합니다.
자동 마이그레이션 도구를 사용하여 다운타임 또는 서비스 중단 없이 Container Registry 엔드포인트를 Artifact Registry gcr.io 저장소로 마이그레이션할 수 있습니다.
새 기능 요약
Artifact Registry는 Container Registry 기능을 다음과 같이 확장합니다.
이전에 Container Registry에 호스팅되었던 대부분의 Google 소유 이미지는 이제 gcr.io 저장소의 Artifact Registry에 호스팅됩니다. 이러한 이미지를 가져오기 위해 URL을 변경할 필요는 없습니다. 예를 들어 Cloud Build 공식 빌더 이미지는 계속 사용할 수 있습니다.
mirror.gcr.io에서 캐시된 Docker Hub 이미지
Artifact Registry는 mirror.gcr.io에서 자주 액세스되는 공개 Docker Hub 이미지를 캐시합니다. mirror.gcr.io 사용에 대한 자세한 내용은 캐시된 Docker Hub 이미지 가져오기를 참조하세요.
전환 옵션 선택
Artifact Registry로 전환하기 위해 사용할 수 있는 저장소는 두 가지 유형이 있습니다.
Artifact Registry의 gcr.io 저장소
Container Registry gcr.io 호스트 이름에 매핑된 저장소.
Artifact Registry는 Container Registry 호스트에 대한 gcr.io 요청을 동일한 Google Cloud 프로젝트에 있는 해당 Artifact Registry 저장소로 리디렉션합니다.
다음과 같은 경우 gcr.io 저장소를 사용하세요.
기존 이미지 자동화를 Artifact Registry로 전환하는 데 필요한 설정 및 구성의 양을 최소화해야 합니다.
다른Google Cloud 프로젝트 또는 리전에서 Artifact Registry 저장소를 설정할 필요가 없습니다.
Artifact Registry의 pkg.dev 저장소
pkg.dev 모든 기능을 지원하고 기존 Container Registry 호스트와 완전히 독립적인 Artifact Registry 저장소입니다.
다음과 같은 경우 pkg.dev 저장소를 사용하세요.
규정 준수 요구사항에 따라 특정 리전에 데이터를 저장해야 합니다. gcr.io 도메인을 지원하는 저장소는 Container Registry 호스트와 동일한 멀티 리전(asia, eu, us)에서만 사용할 수 있습니다.
Container Registry를 사용 중인 프로젝트와 다른 프로젝트에 Artifact Registry 저장소를 설정해야 합니다.
이미지 저장 방법과 위치를 다시 설계해야 합니다. 예를 들면 다음과 같습니다.
Cloud Run 및 Google Kubernetes Engine과 같은 런타임을 포함하여 다른 Google Cloud
지역 리소스와 동일한 리전에 저장소를 만듭니다.
팀과 더 가까운 리전에 저장소를 설정합니다. 예를 들어 asia 멀티 리전 대신 오스트레일리아 리전에 또는 us 멀티 리전 대신 남미 리전에 저장소를 만들 수 있습니다.
다른 Identity and Access Management 정책과 동일한 프로젝트 및 위치에서 다중 Docker 저장소를 만듭니다. 예를 들어 서로 다른 개발자 액세스 수준을 사용하여 us-east1 리전에서 개발 저장소와 프로덕션 저장소를 설정할 수 있습니다.
여러 업스트림 pkg.dev 표준 모드 저장소에서 다운로드하기 위한 단일 엔드포인트로 작동하는 가상 저장소를 만들려고 합니다.
외부 소스의 프록시 역할을 하는 원격 저장소를 사용하려고 합니다.
표준, 원격, 가상 pkg.dev 및 gcr.io 저장소가 공존할 수 있습니다. 예를 들어 Artifact Registry에서 gcr.io 저장소를 만들어 기존 Container Registry 설정을 전환하고 새 작업을 위한 pkg.dev 저장소를 만들 수 있습니다.
전환 도구 사용
다음 도구를 사용하여 Container Registry 사용량이 있는 프로젝트를 식별하고, Container Registry에서 Artifact Registry로 이미지를 복사하고, Container Registry에서 Artifact Registry로 여러 프로젝트를 자동으로 마이그레이션합니다.
Container Registry는 Google Cloud 프로젝트의 Cloud Storage 버킷에 이미지를 저장하고, 레지스트리 특정 권한 부여와 같은 작업을 버킷에 직접 적용해야 합니다.
저장소 만들기는 내보내기 및 가져오기의 개별 작업이며 저장소 사용으로부터 저장소 관리를 명확하게 구분합니다.
이전 버전과의 호환성을 위해서는 gcr.io 저장소를 설정할 수 있습니다. 초기 설정에는 프로젝트의 각 Container Registry 호스트에 대한 Artifact Registry 저장소 자동 생성과 해당 Artifact Registry 저장소에 대한 gcr.io 리디렉션이 포함됩니다.
pkg.dev 도메인에 대한 모든 내보내기 및 가져오기 요청의 경우 저장소가 이미 있어야 합니다.
Artifact Registry에는 Google Cloud 프로젝트에서 관리할 Cloud Storage 버킷이 없습니다. 저장소에서 직접 이미지 관리 작업을 수행합니다.
멀티 리전에 저장된 모든 이미지에 대한 액세스를 제한할 수 있지만 개별 저장소에 대한 액세스는 제한할 수 없습니다. 예를 들어 my-project 프로젝트에서 us.gcr.io로 액세스를 제한할 수 있지만 us.gcr.io/my-project/team1 및 us.gcr.io/my-project/team2의 이미지에 대해 특정 권한을 부여할 수 없습니다.
mirror.gcr.io는 모든 사용자 간에 가장 자주 요청되는 Docker Hub 이미지를 저장하는 플스루 캐시입니다.
mirror.gcr.io는 이제 Artifact Registry에서 호스팅됩니다.
mirror.gcr.io는 이제 Artifact Registry에서 호스팅됩니다. VPC 서비스 제어 경계에서 mirror.gcr.io를 사용하지 않는 경우 별도의 작업이 필요하지 않습니다. VPC 서비스 제어 경계에서 mirror.gcr.io를 사용하는 방법에 대한 자세한 내용은 VPC 서비스 제어와 함께 Artifact Registry 사용을 참조하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eContainer Registry is being deprecated and will be shut down after March 18, 2025, with Artifact Registry becoming the primary service for image storage.\u003c/p\u003e\n"],["\u003cp\u003eAfter May 15, 2024, projects without prior Container Registry usage will have their \u003ccode\u003egcr.io\u003c/code\u003e images hosted in Artifact Registry, in preparation for the complete shutdown.\u003c/p\u003e\n"],["\u003cp\u003eArtifact Registry offers enhanced features over Container Registry, including repository-level access control, multi-region hosting, virtual and remote repositories, and support for multiple artifact formats.\u003c/p\u003e\n"],["\u003cp\u003eYou can seamlessly transition from Container Registry to Artifact Registry using the automatic migration tool without any downtime or service disruption, by migrating \u003ccode\u003egcr.io\u003c/code\u003e endpoints to \u003ccode\u003egcr.io\u003c/code\u003e repositories.\u003c/p\u003e\n"],["\u003cp\u003eArtifact Registry provides \u003ccode\u003epkg.dev\u003c/code\u003e repositories, offering additional flexibility such as storing data in specific regions, supporting multi-project setups, and allowing greater customization for storing and managing images.\u003c/p\u003e\n"]]],[],null,["# Transition from Container Registry\n\nContainer Registry is deprecated. Effective March 18, 2025, Container Registry\nis shut down and writing images to Container Registry is unavailable.\n\n`gcr.io` URLs hosted on Artifact Registry, including Google-owned images\nwith `gcr.io` URLs, are not affected by the Container Registry shutdown.\n\nFor more details about the Container Registry deprecation and how to migrate to\nArtifact Registry, see\n[Container Registry deprecation](/container-registry/docs/deprecations/container-registry-deprecation).\n\nArtifact Registry is the recommended service for container image storage and\nmanagement on Google Cloud. Artifact Registry provides the same\ncontainer management features as Container Registry and includes additional\nfeatures and benefits. As a fully-managed service with support for both\ncontainer images and non-container artifacts, Artifact Registry extends\nthe capabilities of Container Registry.\n\nYou can migrate Container Registry endpoints to Artifact Registry\n`gcr.io` repositories without requiring any downtime or service disruption\nusing the [automatic migration tool](/artifact-registry/docs/transition/auto-migrate-gcr-ar).\n\n### Summary of new features\n\nArtifact Registry extends the capabilities of Container Registry with the following\nfeatures:\n\n- Repository-level [access control](/artifact-registry/docs/access-control).\n- Hosting artifacts in [regions](/artifact-registry/docs/repositories/repo-locations) to reduce latency and data transfer costs, and to comply with data residency requirements.\n- Streaming images to [Google Kubernetes Engine](/kubernetes-engine/docs/how-to/image-streaming) and [Dataproc Serverless](/dataproc-serverless/docs/guides/custom-containers#image_streaming) to reduce workload startup times.\n- [Deploying to Cloud Run from source](/run/docs/deploying-source-code).\n- [Audit logging](/artifact-registry/docs/audit-logging) for repository activity.\n- Enforcement of organization policy, including encryption with [customer-managed encryption keys](/artifact-registry/docs/cmek#org-policy) (CMEK) and [location constraints](/artifact-registry/docs/repositories/repo-locations#location-constraints).\n- [Scanning for OS and language package vulnerabilities](/artifact-analysis/docs/container-scanning-overview) in containers.\n- [Virtual repositories](/artifact-registry/docs/repositories/virtual-repo) that aggregate multiple repositories behind a single host.\n- [Remote repositories](/artifact-registry/docs/repositories/remote-repo) that cache artifacts from upstream sources such as Docker Hub or Maven Central.\n\nSee the [feature comparison](#feature-comparison) for more details about these\nfeatures.\n\nExisting Container Registry images maintained by Google\n-------------------------------------------------------\n\nMost Google-owned images previously hosted on Container Registry are now hosted\non Artifact Registry in `gcr.io` repositories. You don't need to change\nthe URLs to pull these images. For example, you can still use the\n[Cloud Build official builder images](https://github.com/GoogleCloudPlatform/cloud-builders).\n\nCached Docker Hub images on `mirror.gcr.io`\n-------------------------------------------\n\nArtifact Registry caches frequently-accessed public Docker Hub images on\n`mirror.gcr.io`. For more information on using `mirror.gcr.io`, see\n[Pull cached Docker Hub images](/artifact-registry/docs/pull-cached-dockerhub-images).\n\nChoose a transition option\n--------------------------\n\nThere are two types of repositories you can use to transition to Artifact Registry:\n\ngcr.io repositories in Artifact Registry\n\n: Repositories that are mapped to Container Registry `gcr.io` hostnames.\n Artifact Registry redirects `gcr.io` requests for your Container Registry hosts to\n corresponding Artifact Registry repositories in the same Google Cloud project.\n\n Use `gcr.io` repositories if:\n\n - You want to minimize the amount of setup and configuration required to transition your existing images and automation to Artifact Registry.\n - You don't need to set up Artifact Registry repositories in a different Google Cloud project or region.\n\n`pkg.dev` repositories in Artifact Registry\n\n: `pkg.dev` Artifact Registry repositories that support all features and\n are fully independent of any existing Container Registry hosts.\n\n Use `pkg.dev` repositories if:\n\n - You have compliance requirements to store data in a specific region. Repositories with `gcr.io` domain support are only available in the same multi-regions as Container Registry hosts: `asia`, `eu`, and `us`.\n - You want to set up your Artifact Registry repositories in a project that is different from the project where you are using Container Registry.\n - You want to redesign how and where you store images. For example:\n\n - Create repositories in the same regions as your other Google Cloud regional resources, including runtimes such as Cloud Run and Google Kubernetes Engine.\n - Set up repositories in regions that are closer to your teams. For example, you can create repositories in Australian regions instead of the `asia` multi-region, or in South American regions instead of the `us` multi-region.\n - Create multiple Docker repositories in the same project and location with different Identity and Access Management policies. For example, you can set up a development repository and production repository in the `us-east1` region with different levels of access for developers.\n - You want to create virtual repositories that act as a single endpoint for\n downloads from multiple upstream `pkg.dev` standard mode repositories.\n\n - You want to use remote repositories to act as proxies for external sources.\n\nStandard, remote, virtual `pkg.dev` and `gcr.io` repositories can co-exist. For\nexample, you can create `gcr.io` repositories in Artifact Registry to\ntransition your existing Container Registry setup and create `pkg.dev`\nrepositories for new work.\n\nUse our transition tooling\n--------------------------\n\nUse the following tools to identify projects that have Container Registry usage,\ncopy images from Container Registry to Artifact Registry, and automatically migrate\nmultiple projects from Container Registry to Artifact Registry.\n\n- [Check Container Registry usage](/artifact-registry/docs/transition/check-gcr-usage).\n- Use our automatic [migration tool](/artifact-registry/docs/transition/auto-migrate-gcr-ar) to migrate projects from Container Registry to Artifact Registry, copy images, and select your preferred transition repository type.\n- [Copy images](/artifact-registry/docs/docker/copy-from-gcr) from Container Registry to Artifact Registry using the automatic migration tool, gcrane, Docker, or the gcloud CLI.\n\nFeature comparison\n------------------\n\nThe following table summarizes differences between Container Registry and\nArtifact Registry.\n\ngcloud command comparison\n-------------------------\n\nThe following table summarizes Container Registry commands and the equivalent\nArtifact Registry commands in the gcloud CLI. Click a link\nin the table to view reference page for the command.\n\nThe table does not include all available Artifact Registry commands that\nhave no equivalent in Container Registry. See the\n[`gcloud artifacts`](/sdk/gcloud/reference/artifacts)\ndocumentation for the full Artifact Registry command reference."]]
