저장소 개요

Artifact Registry를 사용하면 여러 아티팩트 유형을 저장하고, 단일 프로젝트에 여러 저장소를 만들고, 특정 리전 또는 멀티 리전을 각 저장소와 연결할 수 있습니다. 이 페이지에서는 저장소의 위치와 조직을 계획하는 데 도움이 되는 고려사항을 설명합니다.

저장소를 만들 때 아티팩트를 만드는 내부 프로세스 및 아티팩트 소비자가 아티팩트를 사용하는 방법을 모두 고려하세요.

저장소 형식

각 저장소는 특정 아티팩트 형식과 연결됩니다. 예를 들어 Python 저장소는 Python 패키지를 저장합니다. 동일한 Google Cloud 프로젝트에서 각 형식에 대해 여러 저장소를 만들 수 있습니다.

저장소 모드

저장소 모드는 여러 가지가 있습니다. 모드마다 용도가 다르므로 저장소를 만든 후에는 저장소 모드를 변경할 수 없습니다.

표준 저장소

표준 저장소는 비공개 아티팩트에 대한 일반적인 Artifact Registry 저장소입니다. 이러한 저장소를 사용하여 직접 아티팩트를 업로드 및 다운로드하고 Artifact Analysis를 사용하여 취약점 및 기타 메타데이터를 스캔합니다.

원격 저장소

Docker Hub, Maven Central, Python Package Index(PyPI), Debian 또는 CentOS와 같은 사전 설정된 외부 소스와 지원되는 형식의 사용자 정의 소스 아티팩트를 저장하는 프록시 역할을 하는 읽기 전용 저장소입니다. 아티팩트 버전을 처음 요청하는 경우 저장소는 외부 소스에서 아티팩트 버전을 다운로드하고 해당 복사본을 캐시합니다. 저장소는 동일한 버전이 다시 요청될 때 캐시된 복사본을 제공합니다.

원격 저장소는 Google Cloud에서 빌드 및 배포에 대한 지연 시간을 줄이고 가용성을 향상시킵니다. 또한 Artifact Analysis를 사용하여 캐시된 패키지에서 취약점 및 기타 메타데이터를 스캔할 수 있습니다.

가상 저장소

하나 이상의 업스트림 저장소에서 동일한 형식의 아티팩트를 다운로드, 설치 또는 배포하기 위한 단일 액세스 포인트 역할을 하는 읽기 전용 저장소입니다. 업스트림 저장소는 표준, 원격, 가상 저장소일 수 있습니다.

가상 저장소는 아티팩트 소비자의 클라이언트 구성을 간소화합니다. 또한 공개 아티팩트를 캐시하는 원격 저장소보다 비공개 아티팩트가 있는 저장소를 우선시하도록 업스트림 정책을 구성하여 종속 항목 혼동 공격을 완화할 수 있습니다.

저장소 사용 예시

다음 다이어그램은 여러 모드에서 저장소를 함께 사용할 수 있는 여러 방법 중 하나를 보여줍니다. 이 다이어그램은 두 Google Cloud 프로젝트의 워크플로를 보여줍니다. 개발 프로젝트에서 개발자는 자바 애플리케이션을 빌드합니다. 별도의 런타임 프로젝트에서 다른 빌드는 Google Kubernetes Engine에 배포할 애플리케이션이 포함된 컨테이너 이미지를 만듭니다.

두 프로젝트에서 사용되는 표준, 가상, 원격 저장소

개발 프로젝트에서 자바 개발팀은 Cloud Build를 사용하여 자바 애플리케이션을 빌드합니다.
- 빌드는 가상 저장소를 사용하여 공개 자바 종속 항목을 요청할 수 있습니다. 가상 저장소는 Maven Central의 캐싱 프록시인 원격 저장소의 종속 항목을 제공합니다.
- Cloud Build가 구성요소 프로젝트의 표준 Maven 저장소에 패키지를 업로드합니다.
런타임 프로젝트에서 Cloud Build는 자바 애플리케이션을 컨테이너화합니다.

빌드는 Maven 가상 저장소를 사용하여 애플리케이션을 다운로드합니다. 가상 저장소는 개발 프로젝트의 표준 저장소에서 패키지를 제공합니다. 빌드는 동일한 가상 저장소에서 공개 자바 종속 항목을 다운로드할 수도 있습니다.
런타임 프로젝트에서 Cloud Build는 빌드된 컨테이너 이미지를 표준 Docker 저장소에 업로드합니다.
GKE는 Docker 가상 저장소에서 이미지를 가져옵니다.
- 업스트림 표준 Docker 저장소는 컨테이너화된 자바 애플리케이션과 같은 비공개 이미지를 제공합니다.
- 업스트림 원격 저장소는 GKE가 Docker Hub에서 요청하는 이미지를 제공합니다.

이 예시에서 모든 저장소, 빌드, GKE 클러스터는 동일한 리전에 있습니다. Google Cloud 서비스에 동일한 위치를 사용하면 저장소 위치에서 설명하는 이점이 있습니다.

gcr.io 도메인 지원

Artifact Registry는 gcr.io 도메인에서 이미지 호스팅을 지원합니다. Container Registry에서 Artifact Registry로 전환하는 경우 기존 자동화 및 워크플로에 대한 변경사항을 최소화하도록 gcr.io 저장소 Artifact Registry를 설정할 수 있습니다. 이러한 저장소는 다음을 제공합니다.

gcr.io 도메인으로 요청 리디렉션
Container Registry 동작과의 호환성을 위해 gcr.io 호스트 이름에 첫 번째 이미지를 내보낼 때 gcr.io 저장소 만들기

자세한 내용은 gcr.io 도메인 지원을 사용하는 저장소로 전환을 참조하세요.

저장소 위치

지원되는 리전 또는 멀티 리전에 하나 이상의 저장소를 만들 수 있습니다. 바람직한 저장소 위치는 데이터 소비자의 지연 시간, 가용성, 대역폭 비용이 균형 잡힌 위치입니다. 조직에 특정 규정 준수 요구사항이 있을 수도 있습니다.

위치 고려사항

다른 Google Cloud 서비스와 동일한 리전에 저장소를 만들면 다음과 같은 다양한 이점이 있습니다.

저장소와 상호작용하는 GKE, Cloud Run, Cloud Build, 기타 Google Cloud 서비스와 동일한 리전에 저장소를 만들어 지연 시간 및 네트워크 이그레스 비용을 줄입니다. Artifact Registry에서 동일한 리전의 다른 Google Cloud 서비스로 이그레스는 요금이 부과되지 않습니다.

멀티 리전에서 해당 리전의 Google Cloud 서비스로 이그레스는 요금이 부과되지 않지만 이 가격 책정은 제한된 리전 집합에만 적용됩니다.
- us 멀티 리전의 경우 us-central과 같은 미국 내 리전으로의 이그레스는 요금이 부과되지 않으며, 캐나다 또는 남미의 모든 리전으로의 이그레스는 요금이 부과됩니다.
- asia 멀티 리전의 경우 asia-northeast1과 같은 아시아 리전으로의 이그레스는 요금이 부과되지 않지만 오스트레일리아의 리전으로 이그레스는 요금이 부과됩니다.
컨테이너 이미지가 워크로드와 동일한 리전 또는 워크로드가 있는 리전에 해당하는 Artifact Registry 저장소에 있는 경우에만 GKE 및 Dataproc 서버리스에서 이미지 스트리밍을 사용할 수 있습니다. 이미지 스트리밍은 전체 이미지가 다운로드되기 전에 워크로드가 시작될 수 있으므로 더 큰 컨테이너 이미지를 사용할 때 워크로드 초기화 시간을 크게 줄일 수 있습니다.
Google Cloud 외부의 소비자 위치를 고려하세요. 예를 들어 오스트레일리아의 개발자가 Artifact Registry에서 로컬 워크스테이션으로 아티팩트를 다운로드해야 하는 경우 오스트레일리아 리전의 저장소는 지연 시간을 줄이고 다른 대륙에 있는 저장소보다 이그레스 비용을 낮춥니다.

저장소 위치 제한

특정 리전에 데이터를 저장해야 하는 규정이나 정책을 준수해야 하는 경우 규정을 준수하는 리전에서만 저장소를 만들 수 있는 리소스 위치 제약조건을 Google Cloud 조직 정책에 포함할 수 있습니다. Artifact Registry는 조직 정책에 제약조건을 포함한 후에만 제약조건을 적용합니다. 규정을 준수하지 않는 위치에 기존 저장소가 있는 경우 규정을 준수하는 위치의 저장소로 아티팩트를 이동한 후 규정을 준수하지 않는 저장소를 삭제해야 합니다.

프로젝트 구조

리소스 계층 구조는 Google Cloud 프로젝트 전체에서 리소스를 구성하는 방법입니다. 선택한 구조는 데이터 거버넌스 요구사항, 신뢰 경계, 팀 구조와 같은 요소에 따라 달라집니다.

다중 프로젝트 조직에서 저장소를 설정하는 두 가지 일반적인 방법이 있습니다.

저장소 중앙화: 단일 프로젝트에서 모든 저장소를 만든 후 저장소 수준에서 다른 프로젝트의 주 구성원에 액세스 권한을 부여합니다. 이 방법은 단일 사용자 또는 팀이 조직 전체의 저장소 관리 및 저장소 액세스를 처리할 때 더 효과적일 수 있습니다. 또한 Artifact Registry의 단일 인스턴스만 사용 설정하고 관리하면 되므로 Software Delivery Shield와 같은 가상 저장소 또는 솔루션을 간단하게 설정할 수 있습니다.
프로젝트별 저장소: 아티팩트를 저장하고 다운로드하는 프로젝트에 저장소를 만듭니다. 프로젝트 수준 분리 및 리소스 제어가 더 필요한 데이터 거버넌스 정책 또는 신뢰 경계가 있는 경우 이 방법이 필요할 수 있습니다.

액세스 제어

저장소는 공개 액세스를 위해 저장소를 구성하지 않는 한 적절한 권한이 있어야만 액세스할 수 있습니다. 프로젝트 또는 저장소 수준에서 권한을 부여할 수 있습니다.

Cloud Build, Cloud Run, GKE와 같은 일부 Google Cloud 서비스는 동일한 Google Cloud 프로젝트의 저장소에 대한 기본 권한이 있는 기본 서비스 계정을 사용합니다. 그러나 이러한 기본값은 소프트웨어 개발 프로세스에 적합하지 않거나 조직의 보안 또는 정책 요구사항을 준수하지 않을 수 있습니다. 다음과 같은 경우 저장소 관리자는 이러한 서비스에 저장소에 대한 액세스 권한을 명시적으로 부여해야 합니다.

Artifact Registry가 상호작용하는 서비스와 다른 프로젝트에 있는 경우
사전 정의된 역할 대신 기본 서비스 계정을 사용하는 커스텀 IAM 역할을 사용하고 있는 경우
Google Cloud 서비스의 기본 서비스 계정을 사용하지 않는 경우
가상 저장소를 설정하는 경우. Artifact Registry 서비스 계정에 업스트림 저장소에 대한 액세스 권한을 명시적으로 부여해야 합니다.

저장소에 액세스해야 하는 다른 주 구성원의 경우 저장소 관리자가 액세스 권한을 부여해야 합니다. 최소 권한의 보안 원칙에 따라 필요한 최소 권한을 부여합니다. 예를 들면 다음과 같습니다.

Artifact Registry의 컨테이너 이미지를 여러 프로젝트의 GKE 클러스터에 배포합니다. 이러한 클러스터의 노드에 대한 서비스 계정에는 저장소에 대한 읽기 액세스 권한만 필요합니다.
개발 중인 애플리케이션의 개발 저장소와 출시되는 애플리케이션을 위한 프로덕션 저장소가 있습니다. 개발자는 개발 저장소에 대해 읽기 및 쓰기 액세스 권한이 필요하며 프로덕션 저장소에 대해 읽기 전용 액세스 권한이 필요합니다.
샘플 애플리케이션이 있는 데모 저장소가 있습니다. 영업팀은 데모를 다운로드하기 위한 읽기 전용 액세스 권한만 필요합니다.

데이터 암호화

기본적으로 Google Cloud는 Google에서 관리하는 암호화 키를 사용하여 자동으로 저장 데이터를 암호화합니다. 데이터를 보호하는 키와 관련된 특정 규정 준수 또는 규제 요구사항이 있으면 고객 관리 암호화 키(CMEK)로 암호화된 저장소를 만들면 됩니다.

Artifact Registry는 리소스 보호를 위해 CMEK가 필요할 수 있는 조직 정책 제약조건도 지원합니다.

라벨 및 태그

라벨을 사용하면 Google Cloud 서비스와 관련된 리소스를 정리할 수 있습니다. Artifact Registry에서는 저장소에 라벨을 추가할 수 있으므로 저장소를 그룹화하거나 라벨별로 저장소 목록을 필터링할 수 있습니다. 예를 들어 자동화 또는 청구 목적으로 라벨을 사용하여 개발 단계 또는 팀별로 저장소를 그룹화할 수 있습니다. 저장소 라벨 만들기 및 사용에 대한 자세한 내용은 저장소 라벨 지정을 참조하세요.

저장소에 태그를 적용할 수도 있습니다. 라벨은 주로 서비스별 리소스를 구성하고 필터링하는 데 사용되는 태그이며 태그는 Google Cloud 조직의 정책을 프로그래매틱 방식으로 제어하는 데 사용됩니다. 자세한 내용은 저장소 태그하기를 참조하세요.