저장소 개요

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

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

저장소 형식

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

저장소 모드

저장소 모드는 여러 가지입니다. 각 모드는 서로 다른 용도로 사용되므로 저장소를 만든 후에는 저장소 모드를 변경할 수 없습니다.

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

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

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

가상 저장소

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

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

저장소 사용 예시

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

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

  1. 개발 프로젝트에서 Java 개발팀은 Cloud Build를 사용하여 Java 애플리케이션을 빌드합니다.

    • 빌드는 가상 저장소를 사용하여 공개 Java 종속 항목을 요청할 수 있습니다. 가상 저장소는 Maven Central의 캐시 프록시인 원격 저장소의 종속 항목을 제공합니다.
    • Cloud Build가 구성요소 프로젝트의 표준 Maven 저장소에 패키지를 업로드합니다.

  2. 런타임 프로젝트에서 Cloud Build는 Java 애플리케이션을 컨테이너화합니다.

    빌드는 Maven 가상 저장소를 사용하여 애플리케이션을 다운로드합니다. 가상 저장소는 개발 프로젝트에서 표준 저장소의 패키지를 제공합니다. 이 빌드는 동일한 가상 저장소에서 공개 Java 종속 항목을 다운로드할 수도 있습니다.

  3. 런타임 프로젝트에서 Cloud Build는 빌드된 컨테이너 이미지를 표준 Docker 저장소에 업로드합니다.

  4. GKE는 Docker 가상 저장소에서 이미지를 가져옵니다.

    • 업스트림 표준 Docker 저장소는 컨테이너화된 Java 애플리케이션과 같은 비공개 이미지를 제공합니다.
    • 업스트림 원격 저장소는 GKE가 Docker Hub에서 요청하는 이미지를 제공합니다.

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

저장소 위치

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

위치 고려사항

다른 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는 조직 정책에 제약조건을 포함한 후에만 제약조건을 적용합니다. 규정을 준수하지 않는 위치에 기존 저장소가 있는 경우 규정을 준수하는 위치의 저장소로 아티팩트를 이동한 후 규정을 준수하지 않는 저장소를 삭제해야 합니다.

삭제 정책

Artifact Registry 삭제 정책은 더 이상 필요하지 않은 아티팩트 버전을 자동으로 삭제하거나 무기한 저장하려는 아티팩트를 유지하기 위한 기준을 정의합니다.

삭제 정책은 여러 버전의 아티팩트를 저장하지만 프로덕션에 출시하는 특정 버전만 유지해야 할 경우에 유용합니다. 아티팩트 삭제 기준이 포함된 삭제 정책과 아티팩트 보존 기준이 포함된 보존 정책을 정의할 수 있습니다.

아티팩트 버전이 삭제 정책 및 유지 정책 모두의 기준과 일치하면 Artifact Registry에 유지 정책이 적용됩니다.

삭제 정책

삭제 정책은 다음 필수 기준과 일치하는 아티팩트를 삭제합니다.

  • 태그 상태: 정책에서 태그 지정된 아티팩트 또는 태그 지정이 해제된 아티팩트를 검사할지 여부를 나타냅니다. 이미지를 저장소로 내보내거나 가져올 때 아티팩트에 태그가 지정됩니다. Docker 태그에 대한 자세한 내용은 컨테이너 개념을 참조하세요.

    • 모든 태그 상태: 태그 상태를 무시하고 태그 지정된 아티팩트와 태그가 없는 아티팩트에 모두 적용됩니다.
    • 태그 지정: 태그가 지정된 아티팩트에만 적용됩니다.
    • 태그 없음: 태그가 없는 아티팩트에만 적용됩니다.

    태그를 지원하지 않는 형식은 untagged로 처리됩니다. 변경할 수 없는 태그가 있는 저장소의 태그 지정된 아티팩트는 삭제할 수 없습니다.

    삭제 정책에 적용되는 태그 상태에 대한 자세한 내용은 TagState 참조를 확인하세요.

다음은 삭제 정책을 정의하는 선택적 방법입니다.

  • 태그 프리픽스: 쉼표로 구분된 태그 프리픽스 목록입니다. 예를 들어 프리픽스 test 및 staging은 testenv 및 staging-1.5 태그가 있는 이미지와 일치합니다. 태그 프리픽스를 사용하려면 tagState를 TAGGED로 설정해야 합니다.
    • 버전 프리픽스: 쉼표로 구분된 아티팩트 버전 프리픽스 목록입니다. 예를 들어 v1, v2는 v1.5, v2.0alpha, v10.2 버전과 일치합니다.
  • 패키지 프리픽스: 아티팩트 이름 프리픽스 목록입니다. 프리픽스 사이의 Enter 또는 ,를 눌러 여러 프리픽스를 입력할 수 있습니다. 예를 들어 red, blue는 두 개의 프리픽스 red 및 blue를 만들고 아티팩트 이름 red-team, redis, bluebird와 일치합니다.
  • 다음보다 오래됨: 아티팩트 버전이 저장소에 업로드된 이후의 최소 시간(기간)입니다. 예를 들어 30d는 30일입니다. 각각 s, m, h, d를 추가하여 초, 분, 시간, 일로 기간을 지정할 수 있습니다.
  • 다음보다 최신: 아티팩트 버전이 저장소에 업로드된 이후의 최대 시간(기간)입니다. 예를 들어 30d는 30일입니다.

유지 정책

유지 정책은 삭제 정책과 동일한 조건 또는 설정된 최신 버전 수와 일치하는 아티팩트를 유지합니다.

예를 들어 다음 아티팩트가 포함된 저장소의 경우 다음과 같습니다.

IMAGE: us-central1-docker.pkg.dev/my-project/release-xyz-v1
DIGEST: sha256:1b0a26bd07a3d17473d8d8468bea84015e27f87124b2831234581bce13f61370
TAGS:
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:10

IMAGE: us-central1-docker.pkg.dev/my-project/release-xyz-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

IMAGE: us-central1-docker.pkg.dev/my-project/release-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

최신 버전 유지 정책이 패키지 프리픽스 {release-xyz}와 일치하는 3가지 버전의 패키지를 유지하도록 설정된 경우 release-xyz-v1 및 release-xyz-v2만 유지됩니다.

삭제 정책에 의해 트리거된 삭제는 Artifact Registry 프로젝트당 삭제 요청 할당량에 포함됩니다.

삭제 정책을 만들고 저장소에 적용하려면 삭제 정책 구성을 참조하세요.

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 프로젝트에서 리소스를 구성하는 방법입니다. 선택한 구조는 데이터 거버넌스 요구사항, 신뢰 경계, 팀 구조와 같은 요소에 따라 달라집니다.

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

저장소 중앙화
단일 프로젝트에서 모든 저장소를 만든 후 저장소 수준의 다른 프로젝트에서 주 구성원에 액세스 권한을 부여합니다. 이 접근 방식은 단일 개인 또는 팀이 조직 전반에서 저장소 관리 및 저장소 액세스를 처리하는 경우 더 효과적일 수 있습니다. 또한 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 조직의 정책을 프로그래매틱 방식으로 제어하는 데 사용됩니다. 자세한 내용은 저장소 태그하기를 참조하세요.

다음 단계