Bu sayfa, Cloud Translation API ile çevrilmiştir.

Artifact Registry'nin Ayrıntılı İncelemesi

1. Genel Bakış

Artifact Registry, OCI container görüntülerinizi ve dil paketlerinizi (Maven ve npm gibi) yönetmek için birleşik bir araç sağlayan, tamamen yönetilen bir paket yöneticisidir.

Artifact Registry, aşağıdaki örneklerde gösterildiği gibi Google Cloud'un diğer birçok hizmetiyle tamamen entegredir:

Cloud Build, resim yapılarını doğrudan Artifact Registry'ye yükleyebilir.
Cloud Deploy, Artifact Registry resimlerini doğrudan çeşitli çalışma ortamına dağıtabilir.
Cloud Run ve GKE gibi kapsayıcı çalışma zamanlarına görüntüler sağlar ve görüntü aktarımı gibi gelişmiş performans optimizasyonu özelliklerini etkinleştirir.
Artifact Registry, bilinen güvenlik açıklarını sürekli olarak izleyen Artifact Analysis için bir algılama noktası görevi görebilir.
Cloud IAM, yapı erişimi ve izinleri üzerinde tutarlı ve ayrıntılı kontrol sağlar.

Bu laboratuvarda, bu özelliklerin çoğunu uygulamalı eğitim şeklinde adım adım işleyeceğiz.

Öğrenecekleriniz

Bu laboratuvarın öğrenme hedefleri nelerdir?

Kapsayıcılar ve dil paketleri için farklı depolar oluşturma
Artifact Registry ile container görüntüleri oluşturma ve kullanma
Yapı kayıt defterini kullanarak yapılarınızın güvenlik durumunu ve içeriğini analiz etme
Java Maven Bağımlılıkları için Artifact Registry'yi yapılandırma ve kullanma

2. Kurulum ve Gereksinimler

Kendi hızınızda ortam kurulumu

Google Cloud Console'da oturum açın ve yeni bir proje oluşturun veya mevcut bir projeyi yeniden kullanın. Gmail veya Google Workspace hesabınız yoksa hesap oluşturmanız gerekir.

Proje adı, bu projenin katılımcılarının görünen adıdır. Google API'leri tarafından kullanılmayan bir karakter dizesidir. Dilediğiniz zaman güncelleyebilirsiniz.
Proje kimliği, tüm Google Cloud projelerinde benzersizdir ve değiştirilemez (ayarlandıktan sonra değiştirilemez). Cloud Console, benzersiz bir dize otomatik olarak oluşturur. Bu dizenin ne olduğu genellikle önemli değildir. Çoğu kod laboratuvarında proje kimliğinize (genellikle PROJECT_ID olarak tanımlanır) referans vermeniz gerekir. Oluşturulan kimliği beğenmezseniz rastgele başka bir kimlik oluşturabilirsiniz. Alternatif olarak, kendi anahtarınızı deneyerek kullanılabilir olup olmadığını görebilirsiniz. Bu adımdan sonra değiştirilemez ve proje boyunca geçerli kalır.
Bazı API'lerin kullandığı üçüncü bir değer (Proje Numarası) olduğunu belirtmek isteriz. Bu üç değer hakkında daha fazla bilgiyi dokümanlar bölümünde bulabilirsiniz.

Ardından, Cloud kaynaklarını/API'lerini kullanmak için Cloud Console'da faturalandırmayı etkinleştirmeniz gerekir. Bu codelab'i çalıştırmak çok pahalı değildir. Bu eğitimden sonra faturalandırılmamak için kaynakları kapatmak istiyorsanız oluşturduğunuz kaynakları veya projeyi silebilirsiniz. Yeni Google Cloud kullanıcıları 300 ABD doları değerindeki ücretsiz deneme programına uygundur.

gcloud'u ayarlama

Cloud Shell'de proje kimliğinizi ve proje numaranızı ayarlayın. Bunları PROJECT_ID ve PROJECT_NUMBER değişkenleri olarak kaydedin.

export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')

Google hizmetlerini etkinleştirme

gcloud services enable \
  cloudresourcemanager.googleapis.com \
  run.googleapis.com \
  artifactregistry.googleapis.com \
  containerregistry.googleapis.com \
  containerscanning.googleapis.com \
  binaryauthorization.googleapis.com \
  cloudbuild.googleapis.com

Kaynak kodunu alma

Bu laboratuvarın kaynak kodu, GitHub'daki GoogleCloudPlatform kuruluşunda yer almaktadır. Aşağıdaki komutla klonlayın.

git clone https://github.com/GoogleCloudPlatform/java-docs-samples

3. Container Görüntüleri Yayınlama

Artifact Registry'de Docker deposu oluşturma

Daha önce de belirtildiği gibi Artifact Registry, container görüntülerini ve dil paketlerini yönetmenize olanak tanıyan farklı depolama alanı biçimlerini destekler. Farklı yapı depolama alanı türleriyle olan etkileşimler spesifikasyonlarda tanımlanır ve yaygın olarak kullanılan standartlardır. Örneğin, Maven bağımlılıkları ile ilgili istekler, Node bağımlılıkları ile ilgili isteklerden farklıdır.

Belirli bir yapı API spesifikasyonunu desteklemek için Artifact Registry'nin yapılarınızı ilgili depo türlerinde yönetmesi gerekir. Yeni bir depo oluşturduğunuzda, depo türünü belirtmek için --repository-format işaretini iletirsiniz.

Docker görüntüleri için ilk deponuzu oluşturmak üzere Cloud Shell'de aşağıdaki komutu çalıştırın:

gcloud artifacts repositories create container-example --repository-format=docker \
--location=us-central1 --description="Example Docker repository"

Cloud Shell yetkilendirme istemi görünürse Yetkilendir'i tıklayın.

Google Cloud Console - Artifact Registry - Repositories'e gidin ve container-example adlı yeni oluşturulan Docker deponuzu bulun. Depoyu tıkladığınızda şu anda boş olduğunu görebilirsiniz.

Docker kimlik doğrulamasını Artifact Registry için yapılandırma

Artifact Registry'ye bağlanırken erişim sağlamak için kimlik bilgileri gerekir. Docker, ayrı kimlik bilgileri oluşturmak yerine gcloud kimlik bilgilerinizi sorunsuz bir şekilde kullanacak şekilde yapılandırılabilir.

Docker'ı, us-central1 bölgesindeki Artifact Registry isteklerinin kimliğini doğrulamak için Google Cloud CLI'yi kullanacak şekilde yapılandırmak üzere Cloud Shell'de aşağıdaki komutu çalıştırın:

gcloud auth configure-docker us-central1-docker.pkg.dev

Komut, Cloud Shell Docker yapılandırmasını değiştirmek için onay ister. Bu durumda Enter tuşuna basın.

Örnek uygulamayı keşfetme

Daha önceki bir adımda klonladığınız git deposunda örnek bir uygulama sağlanır. Java dizinine geçin ve uygulama kodunu inceleyin.

cd java-docs-samples/run/helloworld/
ls

Klasör, basit bir web sayfası oluşturan örnek bir Java uygulaması içerir: Bu laboratuvarla alakalı olmayan çeşitli dosyaların yanı sıra src klasöründe kaynak kodu ve bir kapsayıcı resmi oluşturmak için kullanacağımız bir Dockerfile içerir.

Kapsayıcı görüntüsünü oluşturma

Container Registry'de container görüntüleri depolayabilmek için önce bir depo oluşturmanız gerekir.

Container görüntüsünü derlemek ve yapı kayıt otoritesinin tam yoluyla etiketlemek için aşağıdaki komutu çalıştırın:

docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1 .

Container görüntüsünü Artifact Registry'ye aktarma

Container görüntüsünü daha önce oluşturulan depoya aktarmak için aşağıdaki komutu çalıştırın:

docker push us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1

Artifact Registry'de görüntüyü inceleme

Google Cloud Console - Artifact Registry - Repositories'e gidin. container-example deposunu açın ve java-hello-world görüntüsünün orada olduğunu doğrulayın.

Resmi tıklayın ve tag1 etiketli resmi not edin. containerscanning.googleapis.com hizmeti aracılığıyla resimlerin otomatik olarak taranmasını etkinleştirdiğimiz için güvenlik açığı taramasının devam ettiğini veya tamamlandığını görebilirsiniz. İşlem tamamlandıktan sonra bu resim düzeltmesi için algılanan güvenlik açıklarının sayısını görebilirsiniz. Güvenlik açıklarını ve diğer yapı analizlerini bir sonraki bölümde inceleyeceğiz.

4. Container Görüntülerini İnceleme

İlk resminizi container-example deposuna gönderdiğinize göre, bu konuyu daha ayrıntılı bir şekilde inceleyebiliriz. Sürümler sekmesinde, yeni oluşturduğumuz sürümü tıklayın. Resmi daha ayrıntılı olarak göstermek için:

Üstteki kopyala düğmesi, SHA karması da dahil olmak üzere söz konusu resim sürümünün tam nitelikli resim URI'sine kolayca erişmenizi sağladığı için özellikle kullanışlıdır. Bu URI daha sonra belirli bir görüntü sürümünü almak için veya Kubernetes dağıtımında ya da Cloud Run hizmetinde görüntü referansı olarak kullanılabilir. Görüntü URI'sini test etmek için Cloud Shell'de aşağıdaki komutu çalıştırabilirsiniz:

docker pull $IMAGE_URI

Bağımlılıkları anlama

Üst taraftaki "Bağımlılar" sekmesine giderek resminizde algılanan tüm bağımlılıkları görebilirsiniz. Bu sayfada hem dil bağımlılıkları hem de işletim sistemi bağımlılıkları listelenir. Bağımlılıkların her birine bağlı yazılım lisanslarını da görebilirsiniz.

Yakından bakarsanız SBOM bilgilerinin henüz doldurulmadığını görebilirsiniz. Öğeniz için SOM'u doldurmak üzere, üstteki içerik haritası çubuğundan kopyalayabileceğimiz tam nitelikli resim URI'sini kullanarak Cloud Shell'de aşağıdaki komutu çalıştırabilirsiniz.

gcloud artifacts sbom export --uri $IMAGE_URI

Sayfayı yenilediğinizde, Cloud Storage'da depolanan otomatik olarak oluşturulan SBOM'nin bağlantısı gösterilir. Görüntüleriniz için SBOM'lerden yararlanıyorsanız yapılarınız için SBOM'leri otomatik olarak oluşturmak ve oluşturma işlemini CI/CD ardışık düzeninizin bir parçası haline getirmek isteyebilirsiniz.

Görüntü güvenlik açıklarını keşfetme

Görünümün üst kısmındaki "Güvenlik açıkları" sekmesini tıkladığınızda resminizde algılanan tüm güvenlik açıklarını görebilirsiniz. Üst taraftaki güvenlik açıklarının özetine ek olarak, alttaki tabloda güvenlik açıklarının tam listesini görebilirsiniz. Her satır, önem derecesini ve kaynağını belirten CVE bültenine bağlantı verir. Düzeltme bulunan güvenlik açıkları için, güvenlik açığını düzeltmek üzere bağımlıların nasıl güncelleneceğine dair talimatlar da sağlanır.

5. Sanal ve Uzak Depolar

Önceki bölümde, resimlerimizi yüklemek ve almak için tek bir resim deposu kullandık. Bu yöntem küçük ölçekli kullanım alanları için mükemmel olsa da özellikle farklı ekiplerin kendi depoları üzerinde bağımsızlık gerektirdiği daha büyük kuruluşlar için zorluklar oluşturur. Ekiplerin veya iş birimlerinin kendi izinleri ve yapılandırmaları olan kendi görüntü depolarına sahip olması yaygındır. Artifact Registry, bu depolardaki görüntülerin kullanımını basitleştirmek ve tüketiciyi temel kuruluş yapısından korumak için birden fazla temel depodaki kaynakları toplayabilen sanal depolar sağlar. Olası bir mimari şu şekilde görünebilir:

Docker Hub için Uzak Depo

Docker Hub, herkese açık popüler bir görüntü sicil dairesi olup birçok açık kaynaklı container görüntüsünü barındırır. Herkese açık deposu doğrudan kullanmak kolay olsa da üretim ortamında bazı zorluklarla karşılaşırsınız. Bu zorlukların üstesinden Artifact Registry'deki uzak depolarla gelebilirsiniz.

Uzak depolar, isteklerin yayın öncesi kayıt deposuna proxy'si olmanıza ve bu süreçte görüntüleri önbelleğe almanıza olanak tanır. Bu, resimlerin indirme sürelerini kısaltmanın yanı sıra harici hizmetin çalışma süresine olan bağımlılığı ortadan kaldırır ve kendi resimlerinize uyguladığınız güvenlik ve erişim politikalarını uygulamanıza olanak tanır.

Docker Hub için uzak bir depo oluşturmak üzere Cloud Shell'de aşağıdaki komutu çalıştırabilirsiniz:

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"

Artık Artifact Registry depoları listenizde ek bir depo göreceksiniz:

Uzak deponuzun uzak depoya istek proxy'si yapıp yapamayacağını test etmek için Cloud Shell'de nginx görüntüsünü çekmek üzere aşağıdaki komutu çalıştırın:

docker pull us-central1-docker.pkg.dev/$PROJECT_ID/dockerhub/nginx:stable-alpine

Alma işlemi başarılı olduğunda Cloud Console'daki depoya da bakabilirsiniz. Önbelleğe alınmış nginx resmi artık kendiniz oluşturduğunuz resim için gördüğümüz aynı bağımlılık ve güvenlik açığı raporlarını sağlar.

Sanal Depo Oluşturma

Şimdiye kadar kullandığımız süreçleri uygulayarak her ekip veya işletme için çeşitli depolar oluşturabilir ve her birinin sahipliğini ve IAM izinlerini açıkça tanımlayabilirsiniz. Ayrıca, üçüncü taraf resimlerinin kullanılmasını daha kolay ve daha güvenli hale getirmek için uzak depolar için proxy'ler de oluşturabiliriz. Bu kadar çok deponun dezavantajı, bakış açınızı bu resimlerin tüketicisine çevirdiğinizde açıkça görülebilir. Geliştiriciler dağıtımlarında hangi resim deposunu kullanmaları gerektiğini nasıl öğrenebilir?

Kullanımı basitleştirmek ve temel depoları bir soyutlama katmanının arkasına gizlemek için Cloud Shell'de aşağıdaki komutu kullanarak Artifact Registry'de sanal bir depo oluşturabilirsiniz:

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"

Artık temel yapıyı göstermeden resimleri sanal depodan çekebiliriz. Her şeyin beklendiği gibi çalıştığını doğrulamak için Cloud Shell'de aşağıdaki komutları çalıştırabilirsiniz:

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'a dağıt

İlgili depoları ve resimleri oluşturduktan sonra bunları dağıtımda kullanmaya başlayabiliriz. Örnek bir kullanım alanını göstermek ve ek altyapı dağıtmaktan kaçınmak için kapsayıcımızı Cloud Run'a dağıtacağız. En basit haliyle dağıtım, Cloud Shell'de aşağıdaki komutu çalıştırarak yapılabilir:

gcloud run deploy hello-world \
  --image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
  --region us-central1 \
  --allow-unauthenticated

Dağıtım tamamlandığında, hizmetinize erişebileceğiniz otomatik olarak oluşturulmuş URL gösterilir.

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

Bu URL'yi yeni bir tarayıcı sekmesinde açarsanız başarılı "Merhaba Dünya" mesajını görürsünüz.

7. Tedarik Zinciri Güvenliğini Güçlendirme

Kapsayıcı resminiz canlı dağıtıma geçtiğine göre uçtan uca tedarik zincirimizi nasıl güçlendirebileceğimize bakmanın tam zamanı olabilir. Önceki bölümde, Artifact Registry'nin kapsayıcı analizinin, resimde kullanılan kitaplıklar ve lisanslar hakkında nasıl analizler sağladığına baktık. Ancak kötü amaçlı kişilerin, tedarik zinciri boyunca resminize zararlı içerik eklemesi yine de mümkündür. Bu bölümde, derleme yapıları için doğrulama özelliğini tanıtmak amacıyla SLSA çerçevesini nasıl kullanabileceğimizi ve hatta Cloud Run çalışma zamanımıza yalnızca güvenilir yapıların dağıtılmasını sağlamak için yapıların şifreleme imzalarından nasıl yararlanabileceğimizi inceleyeceğiz.

Cloud Build ile SLSA Onayı

SLSA çerçevesi, tedarik zinciri yapıları için farklı düzeylerde kanıt sağlar. Spesifikasyon ve uygulama ilk bakışta göz korkutucu görünebilir ancak Cloud Build ile SLSA onayı oluşturmak, requestedVerifyOption değeri VERIFIED olarak ayarlanmış bir cloudbuild.yaml spesifikasyonu eklemek kadar basittir.

Uygulamamız için Cloud Shell'de aşağıdaki komutu çalıştırarak helloworld klasöründe bir cloudbuild.yaml dosyası oluşturabiliriz.

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

Şimdi Cloud Shell'de aşağıdaki komutu çalıştırarak Java Hello World görüntümüzün yeni bir sürümünü oluşturan yeni bir Cloud Build işi oluşturuyoruz.

gcloud builds submit --substitutions=_IMAGE_URI=us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build

Derleme tamamlandıktan sonra Google Cloud Console'daki Cloud Build kullanıcı arayüzüne gidebilir ve derlemeyi açıp Derleme Özeti bölümündeki Derleme Öğeleri'ne bakarak elde ettiğimiz SLSA düzeyini görüntüleyebiliriz. Burada gösterilen resimde "Güvenlik Analizleri"ni görmenizi sağlayan bir düğme vardır. Bu öğeyi tıkladığınızda SLSA tasdikinin yanı sıra yerel derlememiz gönderirken Artifact Registry kullanıcı arayüzünde daha önce gördüğümüz tanıdık güvenlik açığı raporlarını görürsünüz.

Görüntümüz için SLSA kaynağı, Cloud Shell'de aşağıdaki komutu çalıştırarak da alınabilir:

gcloud artifacts docker images describe \
"us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build" \
 --show-provenance

İkili Program Yetkilendirmesi ile Cloud Build Kaynak Bilgisi'ni zorunlu kılma

Cloud Build ardışık düzeni kullanıma sunulduğunda, üretime dağıttığımız tüm görüntülerin bu programlanabilir ve yeniden üretilebilir derleme ortamı kullanılarak derlendiğinden emin olmak harika olmaz mı?

Bu noktada İkili Program Yetkilendirmesi devreye girer. Bu sayede, kapsayıcı çalışma zamanlarınızın önüne kapsayıcı görüntüsünü inceleyen ve güvenilir bir doğrulamanın varlığını doğrulayan bir kapı bekçisi koyabilirsiniz. Doğrulama bulunamazsa yapılandırmaya bağlı olarak denetleme günlüğü girişleri oluşturulur veya dağıtım tamamen engellenir.

Projemizin varsayılan Binary Authorization yapılandırmasını, Cloud Run tarafından verilen yerleşik doğrulamayı gerektirecek şekilde değiştirmek için Cloud Shell'de aşağıdaki komutu çalıştırırız:

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

Burada kendi özel Onaylayıcılarınızı da ekleyebilirsiniz ancak bu, bu kod laboratuvarının kapsamı dışındadır ve isteğe bağlı ek müfredat dışı bir ödev çalışması olarak bırakılmıştır.

Cloud Run Hizmetimizde ikili yetkilendirmeyi zorunlu kılmak için Cloud Shell'de aşağıdaki komutu çalıştırırız:

gcloud run services update hello-world \
  --region us-central1 \
  --binary-authorization=default

Öncelikle yerel olarak oluşturulan görüntüyü yeniden dağıtarak ikili program yetkilendirmemizin doğru şekilde uygulanıp uygulanmadığını test edelim.

gcloud run deploy hello-world \
  --image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
  --region us-central1

Beklenen şekilde, resmin neden dağıtılamadığını açıklayan şuna benzer bir hata mesajı alırsınız:

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

Bu nedenle, Cloud Run hizmetimize yeni bir sürüm dağıtmak için Cloud Build ile oluşturulmuş bir görüntü sağlamamız gerekir.

gcloud run deploy hello-world \
  --image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:cloud-build \
  --region us-central1

Bu sefer dağıtım başarılı olur ve aşağıdakine benzer bir başarılı dağıtım mesajı gösterilir:

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 dil paketlerini yönetme

Bu bölümde, Artifact Registry Java deposu oluşturmayı ve bu depoya paket yüklemeyi, ardından bu paketlerden farklı uygulamalarda yararlanmayı öğreneceksiniz.

Maven paket deposu oluşturma

Java yapıları için bir depo oluşturmak üzere Cloud Shell'de aşağıdaki komutu çalıştırın:

gcloud artifacts repositories create java-repo \
    --repository-format=maven \
    --location=us-central1 \
    --description="Example Java Maven Repo"

Cloud Shell yetkilendirme istemi görünürse Yetkilendir'i tıklayın.

Google Cloud Console - Artifact Registry - Repositories (Öğe Kaydı - Depolar) bölümüne gidin ve java-repo adlı yeni oluşturduğunuz Maven deposuna dikkat edin. Bu depoyu tıkladığınızda şu anda boş olduğunu görebilirsiniz.

Artifact Repository için kimlik doğrulamayı ayarlama

Uygulama Varsayılan Kimlik Bilgileri'nin (ADC) bilinen konumunu kullanıcı hesabı kimlik bilgilerinizle güncellemek için aşağıdaki komutu kullanın. Böylece Artifact Registry kimlik bilgisi yardımcısı, depolara bağlanırken bu kimlik bilgilerini kullanarak kimlik doğrulaması yapabilir:

gcloud auth login --update-adc

Maven'i Artifact Registry için yapılandırma

Java projenize eklemek için depo yapılandırmasını yazdırmak üzere aşağıdaki komutu çalıştırın:

gcloud artifacts print-settings mvn \
    --repository=java-repo \
    --location=us-central1 | tee config.xml

Cloud Shell'de helloworld dizininden aşağıdaki komutu çalıştırarak pom.xml dosyasını Cloud Shell Düzenleyici'de açın:

cloudshell edit pom.xml

ve döndürülen ayarları dosyanın ilgili bölümlerine ekleyin.

distributionManagement bölümünü güncelleyin

<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>

Depo bölümünü güncelleyin

 <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>

Derleme bölümündeki uzantılar bölümünü güncelleyin.

   <extensions>
     <extension>
       <groupId>com.google.cloud.artifactregistry</groupId>
       <artifactId>artifactregistry-maven-wagon</artifactId>
       <version>2.1.0</version>
     </extension>
   </extensions>

Referans olarak kullanabileceğiniz dosyanın tamamını aşağıda bulabilirsiniz. <PROJECT> değerini proje kimliğinizle değiştirdiğinizden emin olun.

<?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>

Java paketinizi Artifact Registry'ye yükleme

Maven'de yapılandırılmış Artifact Registry ile artık kuruluşunuzdaki diğer projeler tarafından kullanılmak üzere Java Jar'ları depolamak için Artifact Registry'yi kullanabilirsiniz.

Java paketinizi Artifact Registry'ye yüklemek için aşağıdaki komutu çalıştırın:

mvn deploy

Artifact Registry'de Java paketini kontrol etme

Cloud Console - Artifact Registry - Repositories (Cloud Console - Artifact Registry - Depolar) bölümüne gidin. java-repo simgesini tıklayın ve helloworld ikili yapının orada olup olmadığını kontrol edin:

9. Tebrikler!

Tebrikler, kod laboratuvarını tamamladınız.

Kapsamınız

Container'lar ve Dil Paketleri İçin Oluşturulan Depolar
Artifact Registry ile yönetilen container görüntüleri
Cloud Code ile entegre Artifact Registry
Maven, Java bağımlılıkları için Artifact Registry'yi kullanacak şekilde yapılandırıldı

Temizleme

Projenin tamamını silmek için Cloud Shell'de aşağıdaki komutu çalıştırın

gcloud projects delete $PROJECT_ID