1. 개요
Artifact Registry는 OCI 컨테이너 이미지와 언어 패키지 (예: Maven 및 npm)를 관리하는 통합 도구를 제공하는 완전 관리형 패키지 관리자입니다.
Artifact Registry는 다음 예와 같이 Google Cloud의 다양한 다른 Google Cloud 서비스와 완전히 통합됩니다.
- Cloud Build는 이미지 아티팩트를 Artifact Registry에 직접 업로드할 수 있습니다.
- Cloud Deploy는 Artifact Registry 이미지를 다양한 런타임 환경에 직접 배포할 수 있습니다.
- Cloud Run 및 GKE와 같은 컨테이너 런타임에 이미지를 제공하고 이미지 스트리밍과 같은 고급 성능 최적화 기능을 사용 설정합니다.
- Artifact Registry는 Artifact Analysis가 알려진 취약점을 지속적으로 모니터링하는 감지 지점 역할을 할 수 있습니다.
- Cloud IAM은 아티팩트 액세스 및 권한을 일관되게 세분화하여 제어할 수 있도록 지원합니다.
이 실습에서는 실습 튜토리얼 형식으로 이러한 기능을 자세히 안내합니다.
학습할 내용
이 실습의 학습 목표는 무엇인가요?
- 컨테이너 및 언어 패키지용으로 서로 다른 저장소 만들기
- Artifact Registry로 컨테이너 이미지 만들기 및 사용하기
- Artifact Registry를 사용하여 아티팩트의 보안 상태 및 콘텐츠 분석
- Java Maven 종속 항목에 Artifact Registry 구성 및 사용
2. 설정 및 요구사항
자습형 환경 설정
- Google Cloud Console에 로그인하여 새 프로젝트를 만들거나 기존 프로젝트를 재사용합니다. 아직 Gmail이나 Google Workspace 계정이 없는 경우 계정을 만들어야 합니다.
- 프로젝트 이름은 이 프로젝트 참가자의 표시 이름입니다. 이는 Google API에서 사용하지 않는 문자열이며 언제든지 업데이트할 수 있습니다.
- 프로젝트 ID는 모든 Google Cloud 프로젝트에서 고유하며, 변경할 수 없습니다(설정된 후에는 변경할 수 없음). Cloud 콘솔은 고유한 문자열을 자동으로 생성합니다. 일반적으로는 신경 쓰지 않아도 됩니다. 대부분의 Codelab에서는 프로젝트 ID (일반적으로
PROJECT_ID로 식별됨)를 참조해야 합니다. 생성된 ID가 마음에 들지 않으면 다른 임의 ID를 생성할 수 있습니다. 또는 직접 시도해 보고 사용 가능한지 확인할 수도 있습니다. 이 단계 이후에는 변경할 수 없으며 프로젝트 기간 동안 유지됩니다. - 참고로 세 번째 값은 일부 API에서 사용하는 프로젝트 번호입니다. 이 세 가지 값에 대한 자세한 내용은 문서를 참고하세요.
- 다음으로 Cloud 리소스/API를 사용하려면 Cloud 콘솔에서 결제를 사용 설정해야 합니다. 이 Codelab 실행에는 많은 비용이 들지 않습니다. 이 튜토리얼이 끝난 후에 요금이 청구되지 않도록 리소스를 종료하려면 만든 리소스 또는 프로젝트를 삭제하면 됩니다. Google Cloud 신규 사용자는 300달러(USD) 상당의 무료 체험판 프로그램에 참여할 수 있습니다.
gcloud 설정
Cloud Shell에서 프로젝트 ID와 프로젝트 번호를 설정하고 이러한 변수를 PROJECT_ID 및 PROJECT_NUMBER 변수로 저장합니다.
export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
Google 서비스 사용 설정
gcloud services enable \
cloudresourcemanager.googleapis.com \
run.googleapis.com \
artifactregistry.googleapis.com \
containerregistry.googleapis.com \
containerscanning.googleapis.com \
binaryauthorization.googleapis.com \
cloudbuild.googleapis.com
소스 코드 가져오기
이 실습의 소스 코드는 GitHub의 GoogleCloudPlatform 조직에 있습니다. 아래 명령어로 클론합니다.
git clone https://github.com/GoogleCloudPlatform/java-docs-samples
3. 컨테이너 이미지 푸시
Artifact Registry에서 Docker 저장소 만들기
앞서 언급한 대로 Artifact Registry는 컨테이너 이미지와 언어 패키지를 관리할 수 있는 다양한 저장소 형식을 지원합니다. 다양한 유형의 아티팩트 저장소와의 상호작용은 사양에 정의되어 있으며 널리 채택된 표준입니다. 예를 들어 Maven 종속 항목 요청은 Node 종속 항목 요청과 다릅니다.
특정 아티팩트 API 사양을 지원하려면 Artifact Registry에서 해당 저장소 유형의 아티팩트를 관리해야 합니다. 새 저장소를 만들 때 --repository-format 플래그를 전달하여 저장소 유형을 나타냅니다.
Docker 이미지의 첫 번째 저장소를 만들려면 Cloud Shell에서 다음 명령어를 실행합니다.
gcloud artifacts repositories create container-example --repository-format=docker \
--location=us-central1 --description="Example Docker repository"
Cloud Shell 승인 메시지가 표시되면 '승인'을 클릭합니다.
Google Cloud 콘솔 - Artifact Registry - 저장소로 이동하여 새로 만든 container-example라는 Docker 저장소를 확인합니다. 저장소를 클릭하면 현재 비어 있는 것을 볼 수 있습니다.
Artifact Registry에 대한 Docker 인증 구성
Artifact Registry에 연결할 때는 액세스 권한을 제공하기 위해 사용자 인증 정보가 필요합니다. 별도의 사용자 인증 정보를 설정하는 대신 gcloud 사용자 인증 정보를 원활하게 사용하도록 Docker를 구성할 수 있습니다.
Cloud Shell에서 다음 명령어를 실행하여 Docker가 Google Cloud CLI를 사용하여 us-central1 리전의 Artifact Registry에 대한 요청을 인증하도록 구성합니다.
gcloud auth configure-docker us-central1-docker.pkg.dev
명령어로 Cloud Shell Docker 구성 변경을 확인하라는 메시지가 표시되면 Enter 키를 누릅니다.
샘플 애플리케이션 살펴보기
샘플 애플리케이션은 이전 단계에서 클론한 Git 저장소에 제공됩니다. java 디렉터리로 변경하고 애플리케이션 코드를 검토합니다.
cd java-docs-samples/run/helloworld/
ls
이 폴더에는 간단한 웹페이지를 렌더링하는 Java 애플리케이션 예시가 포함되어 있습니다. 이 특정 실습과 관련 없는 다양한 파일 외에도 src 폴더 아래에 소스 코드와 컨테이너 이미지를 빌드하는 데 사용할 Dockerfile이 포함되어 있습니다.
컨테이너 이미지 빌드
Artifact Registry에 컨테이너 이미지를 저장하려면 먼저 컨테이너 이미지를 만들어야 합니다.
다음 명령어를 실행하여 컨테이너 이미지를 빌드하고 전체 아티팩트 저장소 경로로 태그를 지정합니다.
docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1 .
컨테이너 이미지를 Artifact Registry에 푸시
다음 명령어를 실행하여 이전에 만든 저장소에 컨테이너 이미지를 푸시합니다.
docker push us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1
Artifact Registry에서 이미지 검토
Google Cloud 콘솔 - Artifact Registry - 저장소로 이동합니다.. container-example 저장소를 열고 java-hello-world 이미지가 있는지 확인합니다.
이미지를 클릭하고 tag1 태그가 지정된 이미지를 확인합니다. containerscanning.googleapis.com 서비스를 통해 이미지 자동 스캔을 사용 설정했기 때문에 취약점 스캔이 실행 중이거나 이미 완료된 것을 확인할 수 있습니다. 완료되면 이 이미지 버전에서 감지된 취약점 수를 확인할 수 있습니다. 다음 섹션에서는 취약점 및 기타 아티팩트 통계를 살펴봅니다.
4. 컨테이너 이미지 검사
이제 첫 번째 이미지를 container-example 저장소에 푸시했으므로 이미지를 자세히 살펴보겠습니다. 버전 탭에서 방금 만든 버전을 클릭합니다. 이미지를 더 자세히 표시하려면 다음 단계를 따르세요.
상단의 복사 버튼은 SHA 해시를 포함하여 해당 이미지 버전의 정규화된 이미지 URI에 쉽게 액세스할 수 있는 방법을 제공하므로 특히 유용합니다. 그런 다음 이 URI를 사용하여 특정 이미지 버전을 가져오거나 Kubernetes 배포 또는 Cloud Run 서비스에서 이미지 참조로 사용할 수 있습니다. 이미지 URI를 테스트하려면 Cloud Shell에서 다음 명령어를 실행하세요.
docker pull $IMAGE_URI
종속 항목 이해
상단의 '종속 항목' 탭으로 이동하면 이미지에서 감지된 모든 종속 항목을 확인할 수 있습니다. 언어 종속 항목과 OS 수준의 종속 항목이 모두 표시됩니다. 각 종속 항목에 연결된 소프트웨어 라이선스도 확인할 수 있습니다.
자세히 살펴보면 SBOM 정보가 아직 채워지지 않은 것을 확인할 수 있습니다. 아티팩트의 SOM을 채우려면 Cloud Shell에서 상단의 탐색 메뉴에서 복사할 수 있는 정규화된 이미지 URI를 사용하여 다음 명령어를 실행합니다.
gcloud artifacts sbom export --uri $IMAGE_URI
페이지를 새로고침하면 Cloud Storage에 저장된 자동 생성 SBOM 링크가 포함됩니다. 이미지에 SBOM을 사용하는 경우 아티팩트의 SBOM을 자동으로 생성하고 생성 작업을 CI/CD 파이프라인의 일부로 만들 수 있습니다.
이미지 취약점 살펴보기
뷰 상단의 '취약점' 탭을 클릭하면 이미지에서 감지된 모든 취약점을 확인할 수 있습니다. 상단의 취약점 요약 외에도 하단의 표에서 취약점의 전체 목록을 확인할 수 있습니다. 각 행은 CVE 게시판으로 연결되며, 여기에서 심각도와 출처 패키지를 확인할 수 있습니다. 수정사항이 있는 취약점의 경우 취약점을 수정하기 위해 종속 항목을 업데이트하는 방법에 관한 안내도 제공합니다.
5. 가상 저장소 및 원격 저장소
이전 섹션에서는 단일 이미지 저장소를 사용하여 이미지를 푸시하고 가져왔습니다. 이는 소규모 사용 사례에는 적합하지만, 저장소에 대한 자율성이 필요한 여러 팀이 있는 대규모 조직에는 특히 문제가 됩니다. 팀이나 비즈니스 부서에는 자체 권한과 구성이 있는 자체 이미지 저장소가 있는 경우가 많습니다. 이러한 저장소에서 이미지 사용을 간소화하고 소비자를 기본 조직 구조로부터 보호하기 위해 Artifact Registry는 여러 기본 저장소의 리소스를 집계할 수 있는 가상 저장소를 제공합니다. 가능한 아키텍처는 다음과 같습니다.
Docker Hub용 원격 저장소
Docker Hub는 인기 있는 공개 이미지 레지스트리로, 많은 오픈소스 컨테이너 이미지를 호스팅합니다. 공개 저장소를 직접 사용하는 것은 간단하지만 프로덕션 환경에서는 여러 가지 문제가 발생할 수 있으며, 이러한 문제는 Artifact Registry의 원격 저장소를 사용하여 해결할 수 있습니다.
원격 저장소를 사용하면 업스트림 레지스트리에 요청을 프록시하고 그 과정에서 이미지를 캐시할 수 있습니다. 이렇게 하면 이미지의 다운로드 시간이 단축될 뿐만 아니라 외부 서비스의 가동 시간에 대한 종속 항목이 사라지고 자체 이미지에 적용하는 것과 동일한 보안 및 액세스 정책을 적용할 수 있습니다.
Docker Hub의 원격 저장소를 만들려면 Cloud Shell에서 다음 명령어를 실행합니다.
gcloud artifacts repositories create dockerhub \
--repository-format=docker \
--mode=remote-repository \
--remote-docker-repo=docker-hub \
--location=us-central1 \
--description="Example Remote Repo for Docker Hub"
이제 Artifact Registry 저장소 목록에 저장소가 하나 더 표시됩니다.
원격 저장소가 원격 저장소에 대한 요청을 프록시할 수 있는지 테스트하려면 Cloud Shell에서 다음 명령어를 실행하여 nginx 이미지를 가져옵니다.
docker pull us-central1-docker.pkg.dev/$PROJECT_ID/dockerhub/nginx:stable-alpine
가져오기가 완료되면 Cloud 콘솔에서 저장소를 확인할 수도 있으며, 캐시된 nginx 이미지에서 직접 빌드한 이미지에서 보았던 것과 동일한 종속 항목 및 취약점 보고가 제공됩니다.
가상 저장소 만들기
지금까지 사용한 프로세스를 따르면 팀 또는 비즈니스별로 여러 저장소를 만들고 각 저장소의 소유권과 IAM 권한을 명확하게 정의할 수 있습니다. 원격 저장소의 프록시를 만들어 서드 파티 이미지를 더 쉽고 안전하게 사용할 수도 있습니다. 이러한 이미지의 소비자 관점에서 보면 수많은 저장소의 단점이 분명해집니다. 개발자는 배포에 어떤 이미지 저장소를 사용해야 하는지 어떻게 알 수 있나요?
사용을 간소화하고 추상화 레이어 뒤에 기본 저장소를 숨기려면 Cloud Shell에서 다음 명령어를 사용하여 Artifact Registry에 가상 저장소를 만들 수 있습니다.
gcloud projects add-iam-policy-binding $PROJECT_ID \
--member serviceAccount:service-$PROJECT_NUMBER@gcp-sa-artifactregistry.iam.gserviceaccount.com \
--role roles/artifactregistry.reader
cat <<EOF > /tmp/upstream.json
[{
"id" : "hello-repo",
"repository" : "projects/$PROJECT_ID/locations/us-central1/repositories/container-example",
"priority" : 100
},{
"id" : "dockerhub",
"repository" : "projects/$PROJECT_ID/locations/us-central1/repositories/dockerhub",
"priority" : 101
}]
EOF
gcloud artifacts repositories create all-images \
--repository-format=docker \
--mode=virtual-repository \
--location=us-central1 \
--upstream-policy-file=/tmp/upstream.json \
--description="Example Virtual Repo"
이제 기본 구조를 노출하지 않고도 가상 저장소에서 이미지를 가져올 수 있습니다. 모든 것이 예상대로 작동하는지 확인하려면 Cloud Shell에서 다음 명령어를 실행합니다.
docker pull us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1
docker pull us-central1-docker.pkg.dev/$PROJECT_ID/all-images/nginx:stable-alpine
6. Cloud Run에 배포
이제 각 저장소와 이미지가 준비되었으므로 배포에서 이를 사용해 보겠습니다. 사용 사례의 예를 보여주고 추가 인프라를 배포하지 않기 위해 Cloud Run에 컨테이너를 배포합니다. 가장 간단한 형태로 배포하려면 Cloud Shell에서 다음 명령어를 실행하면 됩니다.
gcloud run deploy hello-world \
--image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
--region us-central1 \
--allow-unauthenticated
배포가 완료되면 서비스에 액세스할 수 있는 자동 생성된 URL이 표시됩니다.
Deploying container to Cloud Run service [hello-world] in project [my-project] region [us-central1] OK Deploying... Done. OK Creating Revision... OK Routing traffic... OK Setting IAM Policy... Done. Service [hello-world] revision [hello-world-00001-wtc] has been deployed and is serving 100 percent of traffic. Service URL: https://hello-world-13746229022.us-central1.run.app
새 브라우저 탭에서 이 URL을 열면 'Hello World' 메시지가 표시됩니다.
7. 공급망 보안 강화
이제 컨테이너 이미지가 실제 배포에 도달했으므로 엔드 투 엔드 공급망을 강화하는 방법을 살펴볼 때입니다. 이전 섹션에서는 Artifact Registry의 컨테이너 분석이 이미지에 사용되는 라이브러리 및 라이선스에 대한 유용한 정보를 제공하는 방법을 살펴봤습니다. 하지만 악의적인 행위자가 공급망을 통해 이미지에 유해한 콘텐츠를 도입할 수 있습니다. 이 섹션에서는 SLSA 프레임워크를 사용하여 빌드 아티팩트에 대한 증명을 도입하고 아티팩트 자체의 암호화 서명을 활용하여 신뢰할 수 있는 아티팩트만 Cloud Run 런타임에 배포할 수 있는 방법을 살펴봅니다.
Cloud Build를 사용한 SLSA 증명
SLSA 프레임워크는 공급망 아티팩트에 대해 다양한 수준의 증거를 제공합니다. 사양 및 구현은 언뜻 보기에 부담스러울 수 있지만 Cloud Build를 사용하면 SLSA 증명을 만드는 것이 requestedVerifyOption를 VERIFIED로 설정하여 cloudbuild.yaml 사양을 만드는 것만큼 간단합니다.
이 애플리케이션의 경우 Cloud Shell에서 다음 명령어를 실행하여 helloworld 폴더에 cloudbuild.yaml 파일을 만들 수 있습니다.
cat <<EOF > cloudbuild.yaml
steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', '\$_IMAGE_URI', '.']
- name: 'gcr.io/cloud-builders/docker'
args: ['push', '\$_IMAGE_URI']
images:
- '\$_IMAGE_URI'
options:
requestedVerifyOption: VERIFIED
substitutions:
_IMAGE_URI: us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:latest
EOF
이제 Cloud Shell에서 다음 명령어를 실행하여 새 버전의 Java Hello World 이미지를 빌드하는 새 Cloud Build 작업을 만듭니다.
gcloud builds submit --substitutions=_IMAGE_URI=us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build
빌드가 완료되면 Google Cloud 콘솔의 Cloud Build UI로 이동하여 빌드를 연 다음 빌드 요약 아래의 빌드 아티팩트를 확인하여 달성한 SLSA 등급을 확인할 수 있습니다. 이 이미지에는 '보안 통계'를 확인할 수 있는 버튼이 있습니다. 이 버튼을 클릭하면 SLSA 증명과 함께 로컬 빌드를 푸시할 때 Artifact Registry UI에서 보았던 익숙한 취약점 보고서가 표시됩니다.
Cloud Shell에서 다음 명령어를 실행하여 이미지의 SLSA 출처를 가져올 수도 있습니다.
gcloud artifacts docker images describe \
"us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build" \
--show-provenance
Binary Authorization을 사용한 Cloud Build 출처 요구
Cloud Build 파이프라인을 사용하면 프로덕션에 배포하는 모든 이미지가 프로그래매틱하고 재현 가능한 빌드 환경을 사용하여 빌드되었는지 확인할 수 있습니다.
이때 필요한 것이 바로 Binary Authorization입니다. 이를 통해 컨테이너 이미지를 검사하고 신뢰할 수 있는 증명의 존재를 확인하는 게이트키퍼를 컨테이너 런타임 앞에 배치할 수 있습니다. 증명이 발견되지 않으면 구성에 따라 감사 로그 항목이 생성되거나 배포가 완전히 차단됩니다.
Cloud Run에서 발급한 기본 증명을 요구하도록 프로젝트의 기본 Binary Authorization 구성을 변경하려면 Cloud Shell에서 다음 명령어를 실행합니다.
cat << EOF > /tmp/policy.yaml
defaultAdmissionRule:
enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
evaluationMode: REQUIRE_ATTESTATION
requireAttestationsBy:
- projects/$PROJECT_ID/attestors/built-by-cloud-build
name: projects/$PROJECT_ID/policy
EOF
gcloud container binauthz policy import /tmp/policy.yaml
여기에서 자체 커스텀 증명자를 추가할 수도 있지만 이는 이 Codelab의 범위를 벗어나며 선택적과외 과제로 남겨둡니다.
Cloud Run 서비스에 바이너리 승인을 적용하려면 Cloud Shell에서 다음 명령어를 실행합니다.
gcloud run services update hello-world \
--region us-central1 \
--binary-authorization=default
먼저 로컬에서 빌드한 이미지를 다시 배포하여 Binary Authorization이 올바르게 적용되는지 테스트해 보겠습니다.
gcloud run deploy hello-world \
--image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
--region us-central1
예상대로 이미지를 배포할 수 없는 이유를 설명하는 오류 메시지가 다음과 같이 표시됩니다.
Image us-central1-docker.pkg.dev/my-project/all-images/java-hello-world@sha256:71eebbf04bf7d1d023e5de5e18f786ea3b8b6411bf64c8def3301c71baca0518 denied by attestor projects/my-project/attestors/built-by-cloud-build: No attestations found that were valid and signed by a key trusted by the attestor
따라서 Cloud Run 서비스에 새 버전을 배포하려면 Cloud Build로 빌드된 이미지를 제공해야 합니다.
gcloud run deploy hello-world \
--image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:cloud-build \
--region us-central1
이번에는 배포가 성공하고 아래와 유사한 배포 완료 메시지가 표시됩니다.
Deploying container to Cloud Run service [hello-world] in project [my-project] region [us-central1] OK Deploying... Done. OK Creating Revision... OK Routing traffic... Done. Service [hello-world] revision [hello-world-00005-mq4] has been deployed and is serving 100 percent of traffic. Service URL: https://hello-world-13746229022.us-central1.run.app
8. Java Maven 언어 패키지 관리
이 섹션에서는 Artifact Registry Java 저장소를 설정하고 패키지를 업로드하여 여러 애플리케이션에서 활용하는 방법을 설명합니다.
Maven 패키지 저장소 만들기
Cloud Shell에서 다음 명령어를 실행하여 Java 아티팩트 저장소를 만듭니다.
gcloud artifacts repositories create java-repo \
--repository-format=maven \
--location=us-central1 \
--description="Example Java Maven Repo"
Cloud Shell 승인 메시지가 표시되면 '승인'을 클릭합니다.
Google Cloud 콘솔 - Artifact Registry - Repositories로 이동하여 새로 만든 Maven 저장소(이름: java-repo)를 확인합니다. 저장소를 클릭하면 현재 비어 있는 것을 볼 수 있습니다.
Artifact 저장소에 대한 인증 설정
다음 명령어를 사용하여 애플리케이션 기본 사용자 인증 정보 (ADC)의 잘 알려진 위치를 사용자 계정 사용자 인증 정보로 업데이트합니다. 그러면 Artifact Registry 사용자 인증 정보 도우미가 저장소에 연결할 때 이를 사용하여 인증할 수 있습니다.
gcloud auth login --update-adc
Artifact Registry용 Maven 구성
다음 명령어를 실행하여 Java 프로젝트에 추가할 저장소 구성을 출력합니다.
gcloud artifacts print-settings mvn \
--repository=java-repo \
--location=us-central1 | tee config.xml
helloworld 디렉터리 내에서 Cloud Shell에서 다음 명령어를 실행하여 Cloud Shell 편집기에서 pom.xml을 엽니다.
cloudshell edit pom.xml
반환된 설정을 파일의 적절한 섹션에 추가합니다.
distributionManagement 섹션 업데이트
<distributionManagement>
<snapshotRepository>
<id>artifact-registry</id>
<url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
</snapshotRepository>
<repository>
<id>artifact-registry</id>
<url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
</repository>
</distributionManagement>
저장소 섹션 업데이트
<repositories>
<repository>
<id>artifact-registry</id>
<url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
build 아래의 extensions 섹션 업데이트
<extensions>
<extension>
<groupId>com.google.cloud.artifactregistry</groupId>
<artifactId>artifactregistry-maven-wagon</artifactId>
<version>2.1.0</version>
</extension>
</extensions>
다음은 참고하실 수 있도록 전체 파일의 예입니다. <PROJECT>를 프로젝트 ID로 바꿔야 합니다.
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example.run</groupId>
<artifactId>helloworld</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<parent>
<groupId>com.google.cloud.samples</groupId>
<artifactId>shared-configuration</artifactId>
<version>1.2.0</version>
</parent>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring-boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<maven.compiler.target>17</maven.compiler.target>
<maven.compiler.source>17</maven.compiler.source>
<spring-boot.version>3.2.2</spring-boot.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<!-- [START Artifact Registry Config] -->
<distributionManagement>
<snapshotRepository>
<id>artifact-registry</id>
<url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
</snapshotRepository>
<repository>
<id>artifact-registry</id>
<url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
</repository>
</distributionManagement>
<repositories>
<repository>
<id>artifact-registry</id>
<url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
<build>
<extensions>
<extension>
<groupId>com.google.cloud.artifactregistry</groupId>
<artifactId>artifactregistry-maven-wagon</artifactId>
<version>2.2.0</version>
</extension>
</extensions>
<!-- [END Artifact Registry Config] -->
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>${spring-boot.version}</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>3.4.0</version>
<configuration>
<to>
<image>gcr.io/PROJECT_ID/helloworld</image>
</to>
</configuration>
</plugin>
</plugins>
</build>
</project>
Artifact Registry에 Java 패키지 업로드
Maven에 Artifact Registry를 구성하면 이제 Artifact Registry를 사용하여 조직의 다른 프로젝트에서 사용할 Java Jar를 저장할 수 있습니다.
다음 명령어를 실행하여 Java 패키지를 Artifact Registry에 업로드합니다.
mvn deploy
Artifact Registry에서 Java 패키지 확인
Cloud 콘솔 - Artifact Registry - Repositories로 이동합니다. java-repo를 클릭하고 helloworld 바이너리 아티팩트가 있는지 확인합니다.
9. 축하합니다.
축하합니다. Codelab을 완료했습니다.
다룬 내용
- 컨테이너 및 언어 패키지 저장소 생성
- Artifact Registry로 관리되는 컨테이너 이미지
- Cloud Code와 통합된 Artifact Registry
- Java 종속 항목에 Artifact Registry를 사용하도록 Maven 구성
삭제
Cloud Shell에서 다음 명령어를 실행하여 전체 프로젝트를 삭제합니다.
gcloud projects delete $PROJECT_ID