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

1. Genel Bakış

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

Artifact Registry, Google Cloud'un aşağıdaki örneklerde olduğu gibi çok çeşitli diğer Google Cloud hizmetleriyle tamamen entegredir:

Cloud Build, görüntü yapıtlarını doğrudan Artifact Registry'ye yükleyebilir.
Cloud Deploy, Artifact Registry görüntülerini doğrudan çeşitli çalışma zamanı ortamlarına dağıtabilir.
Cloud Run ve GKE gibi kapsayıcı çalışma zamanlarına görüntüler sağlar ve görüntü akışı gibi gelişmiş performans optimizasyonu özelliklerini etkinleştirir.
Artifact Registry, bilinen güvenlik açıklarını sürekli olarak izlemek için Artifact Analysis'in algılama noktası olarak kullanılabilir.
Cloud IAM, yapay nesne erişimi ve izinleri üzerinde tutarlı ve ayrıntılı kontrol sağlar.

Bu laboratuvarda, uygulamalı bir eğitim şeklinde bu özelliklerin birçoğu adım adım açıklanacaktır.

Öğ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
Güvenlik durumunuzu ve yapay nesnelerinizin içeriğini analiz etmek için Artifact Registry'yi kullanma
Java Maven bağımlılıkları için Artifact Registry'yi yapılandırma ve kullanma

2. Kurulum ve Gereksinimler

Yönlendirmesiz 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ı için görünen addır. Google API'leri tarafından kullanılmayan bir karakter dizesidir. Bu bilgiyi istediğiniz zaman güncelleyebilirsiniz.
Proje kimliği, tüm Google Cloud projelerinde benzersizdir ve sabittir (ayarlandıktan sonra değiştirilemez). Cloud Console, benzersiz bir dizeyi otomatik olarak oluşturur. Genellikle bu dizenin ne olduğuyla ilgilenmezsiniz. Çoğu codelab'de proje kimliğinize (genellikle PROJECT_ID olarak tanımlanır) başvurmanız gerekir. Oluşturulan kimliği beğenmezseniz başka bir rastgele kimlik oluşturabilirsiniz. Dilerseniz kendi adınızı deneyerek kullanılabilir olup olmadığını kontrol edebilirsiniz. Bu adım tamamlandıktan sonra değiştirilemez ve proje süresince geçerli kalır.
Bazı API'lerin kullandığı üçüncü bir değer olan Proje Numarası da vardır. Bu üç değer hakkında daha fazla bilgiyi belgelerde bulabilirsiniz.

Ardından, Cloud kaynaklarını/API'lerini kullanmak için Cloud Console'da faturalandırmayı etkinleştirmeniz gerekir. Bu codelab'i tamamlamak neredeyse hiç maliyetli değildir. Bu eğitimin ötesinde faturalandırılmayı önlemek için kaynakları kapatmak üzere oluşturduğunuz kaynakları veya projeyi silebilirsiniz. Yeni Google Cloud kullanıcıları 300 ABD doları değerinde ücretsiz deneme programından yararlanabilir.

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

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

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

3. Container görüntülerini gönderme

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ı depo biçimlerini destekler. Farklı türlerdeki yapay ürün depolarıyla etkileşimler spesifikasyonlarda tanımlanır ve yaygın olarak kullanılan standartlardır. Örneğin, Maven bağımlılıkları için yapılan istekler, Node bağımlılıkları için yapılan isteklerden farklıdır.

Belirli bir yapı API spesifikasyonlarını 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 depoyu oluşturmak üzere Cloud Shell'den 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 yeni oluşturduğunuz container-example adlı Docker deponuzu bulun. Bu 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. Ayrı kimlik bilgileri ayarlamak yerine Docker, gcloud kimlik bilgilerinizi sorunsuz bir şekilde kullanacak şekilde yapılandırılabilir.

Cloud Shell'de aşağıdaki komutu çalıştırarak Docker'ı, us-central1 bölgesindeki Artifact Registry'e gelen isteklerin kimliğini Google Cloud CLI ile doğrulayacak şekilde yapılandı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 isterse Enter tuşuna basın.

Örnek uygulamayı keşfetme

Ö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örde, basit bir web sayfası oluşturan örnek bir Java uygulaması bulunur. Bu klasörde, bu laboratuvar için geçerli olmayan çeşitli dosyaların yanı sıra src klasöründe kaynak kodu ve bir kapsayıcı görüntüsü oluşturmak için kullanacağımız bir Dockerfile dosyası da yer alır.

Container görüntüsünü oluşturma

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

Aşağıdaki komutu çalıştırarak kapsayıcı görüntüsünü oluşturun ve tam yapay nesne kayıt otoritesi yoluyla etiketleyin:

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'deki 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 ile etiketlenmiş resmi not edin. containerscanning.googleapis.com hizmeti aracılığıyla görüntülerin otomatik olarak taranmasını etkinleştirdiğimiz için güvenlik açığı taramasının çalıştığını veya tamamlandığını görebilirsiniz. İşlem tamamlandıktan sonra bu görüntü düzeltmesi için tespit edilen güvenlik açığı sayısını görebilirsiniz. Güvenlik açıklarını ve diğer yapay nesne analizlerini bir sonraki bölümde inceleyeceğiz.

4. Container görüntülerini inceleme

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

Üstteki kopyalama düğmesi, SHA karması da dahil olmak üzere söz konusu görüntü sürümünün tam nitelikli görüntü URI'sine kolayca erişmenizi sağladığı için özellikle kullanışlıdır. Bu URI daha sonra belirli bir resim sürümünü çekmek veya Kubernetes dağıtımında ya da Cloud Run hizmetinde resim referansı olarak kullanılabilir. Resim 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

En üstteki "Bağımlılıklar" sekmesine giderek resminizde algılanan tüm bağımlılıkları görebilirsiniz. Bu listede hem dil bağımlılıkları hem de işletim sistemi düzeyindeki bağımlılıklar yer alır. Ayrıca, bağımlılıkların her birine eklenen yazılım lisanslarını da görebilirsiniz.

Yakından baktığınızda SBOM bilgilerinin henüz doldurulmadığını görebilirsiniz. Yapıtınızın SOM'unu doldurmak için Cloud Shell'de aşağıdaki komutu çalıştırabilirsiniz. Bu komutta, en üstteki gezinme yolu çubuğundan kopyalayabileceğimiz tam nitelikli görüntü URI'sini kullanın.

gcloud artifacts sbom export --uri $IMAGE_URI

Sayfayı yenilediğinizde, Cloud Storage'da depolanan otomatik olarak oluşturulmuş SBOM'nin bağlantısını içerir. Görüntüleriniz için SBOM'ları kullanıyorsanız yapıtlarınız için otomatik olarak SBOM oluşturmak ve oluşturma işlemini CI/CD işlem hattınıza dahil etmek 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 tespit edilen tüm güvenlik açıklarını görebilirsiniz. En üstteki güvenlik açığı özetine ek olarak, en alttaki tabloda güvenlik açıklarının tam listesini görebilirsiniz. Her satır, CVE bültenine bağlanarak önem derecesini ve kaynaklandığı paketi gösterir. Düzeltmenin mevcut olduğu güvenlik açıkları için, güvenlik açığını düzeltmek üzere bağımlılıkların nasıl güncelleneceğiyle ilgili talimatlar da verilir.

5. Sanal ve Uzak Depolar

Önceki bölümde, resimlerimizi aktarmak ve çekmek için tek bir resim deposu kullandık. Bu yöntem küçük ölçekli kullanım alanları için ideal olsa da özellikle depoları üzerinde bağımsızlık isteyen farklı ekiplerin bulunduğu büyük kuruluşlar için zorluklar yaratır. Ekiplerin veya iş birimlerinin kendi izinleri ve yapılandırmalarıyla kendi resim depolarına sahip olması yaygın bir durumdur. Artifact Registry, bu depolardaki görüntülerin kullanımını basitleştirmek ve tüketicileri 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, popüler bir herkese açık görüntü kayıt defteridir ve birçok açık kaynak container görüntüsüne ev sahipliği yapar. Herkese açık depoyu doğrudan kullanmak kolay olsa da üretim ortamında bir dizi zorlukla karşılaşabilirsiniz. Bu zorlukları Artifact Registry'deki uzak depolarla aşabiliriz.

Uzak depolar, istekleri yukarı akış kayıt defterine yönlendirme ve bu sırada görüntüleri önbelleğe alma olanağı sunar. Bu sayede, resimlerin indirilme süreleri kısalır, harici hizmetin çalışma süresine olan bağımlılık ortadan kalkar ve kendi resimlerinize uyguladığınız güvenlik ve erişim politikalarını uygulayabilirsiniz.

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örmeniz gerekir:

Uzak deponuzun, uzak depoya istekleri proxy olarak iletip iletemediğini test etmek için Cloud Shell'de aşağıdaki komutu çalıştırarak nginx görüntüsünü çekin:

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

Çekme işlemi başarılı olduktan sonra Cloud Console'da depoya da bakabilirsiniz. Ayrıca, önbelleğe alınmış nginx görüntüsünün artık kendiniz oluşturduğunuz görüntüde gördüğümüz bağımlılık ve güvenlik açığı raporlamasını sağladığını da görebilirsiniz.

Sanal depo oluşturma

Şimdiye kadar kullandığımız süreçleri izleyerek her ekip veya işletme için bir dizi depo oluşturabilir ve her birinin sahipliğini ve IAM izinlerini net bir şekilde tanımlayabilirsiniz. Ayrıca, üçüncü taraf resimlerinin daha kolay ve güvenli bir şekilde kullanılabilmesi için uzak depolarla ilgili proxy'ler oluşturabiliriz. Bu kadar çok sayıda depoya sahip olmanın dezavantajı, bakış açınızı bu görüntülerin tüketicisine çevirdiğinizde belirginleşir. Geliştiriciler, dağıtımlarında hangi resim deposunu kullanmaları gerektiğini nasıl bilebilir?

Tüketimi basitleştirmek ve temel alınan 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ı açığa çıkarmadan sanal depodaki resimleri ç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 resimler hazır olduğunda bunları dağıtımda kullanmaya başlayabiliriz. Bir örnek kullanım alanını göstermek ve ek altyapı dağıtımını önlemek için kapsayıcımızı Cloud Run'a dağıtacağız. En basit biçimde dağıtım, Cloud Shell'de aşağıdaki komut çalıştırılarak gerçekleştirilebilir:

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şturulan 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ı "Hello World" mesajını görürsünüz.

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

Kapsayıcı resminiz canlı dağıtıma ulaştığına 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 bilgi sağladığını inceledik. Ancak kötü niyetli kişiler, tedarik zinciri boyunca resminize zararlı içerik ekleyebilir. Bu bölümde, derleme yapıtları için onaylama özelliğini kullanıma sunmak üzere SLSA çerçevesini nasıl kullanabileceğimizi ve yalnızca güvenilir yapıtların Cloud Run çalışma zamanımıza dağıtılmasını sağlamak için yapıtların şifreleme imzalarından nasıl yararlanabileceğimizi ele alacağız.

Cloud Build ile SLSA onayı

SLSA çerçevesi, tedarik zinciri yapıları için farklı kanıt düzeyleri sağlar. Spesifikasyon ve uygulama ilk bakışta göz korkutucu görünebilir ancak Cloud Build ile SLSA onayı oluşturmak, cloudbuild.yaml spesifikasyonu oluşturup requestedVerifyOption değerini VERIFIED olarak ayarlamak 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 gidip derlememizi açarak ve ardından Derleme Özeti bölümündeki Derleme Yapıtları'na bakarak elde ettiğimiz SLSA düzeyini görüntüleyebiliriz. Burada görünen resimde "Güvenlik Analizleri"ni görüntüleme düğmesi bulunur. Bu seçeneği tıkladığınızda, yerel derlememizi gönderdiğimizde Artifact Registry kullanıcı arayüzünde daha önce gördüğümüz SLSA onayının yanı sıra bildiğimiz güvenlik açığı raporlarını da görürsünüz.

Resmimiz için SLSA kaynağı, Cloud Shell'de aşağıdaki komut çalıştırılarak 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 Provenance'ı zorunlu kılma

Cloud Build işlem hattı kullanıldığında, üretime dağıttığımız tüm görüntülerin bu programlanabilir ve tekrarlanabilir derleme ortamı kullanılarak oluşturulmasını sağlamak harika olmaz mıydı?

İkili Program Yetkilendirmesi bu noktada devreye girer. Bu sayede, kapsayıcı görüntüsünü inceleyen ve güvenilir bir onay belgesinin varlığını doğrulayan bir bekçi yerleştirebilirsiniz. Onay bulunamazsa yapılandırmaya bağlı olarak denetleme günlüğü girişleri oluşturulur veya dağıtım tamamen engellenir.

Projemizin varsayılan İkili Program Yetkilendirmesi yapılandırmasını, Cloud Run tarafından verilen yerleşik onayı 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

Buraya kendi özel onaylayıcılarınızı da ekleyebilirsiniz ancak bu, bu codelab'in kapsamı dışındadır ve isteğe bağlı bir ek ders ödevi 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 İkili Program Yetkilendirmemizin doğru şekilde uygulandığı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

Beklendiği gibi, resmin neden dağıtılamadığını açıklayan ve aşağıdaki gibi 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 kez dağıtım başarılı olmalı ve aşağıdakine benzer bir başarılı dağıtım mesajı gösterilmelidir:

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 deposunu nasıl oluşturacağınızı ve paketleri bu depoya nasıl yükleyeceğinizi, farklı uygulamalarda nasıl kullanacağınızı öğreneceksiniz.

Maven paketi deposu oluşturma

Cloud Shell'den aşağıdaki komutu çalıştırarak Java yapıları için bir depo oluşturun:

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 gidin ve java-repo adlı yeni oluşturduğunuz Maven deposunu bulun. Bu depoyu tıkladığınızda şu anda boş olduğunu görebilirsiniz.

Artifact Repository'de kimlik doğrulamayı ayarlama

Artifact Registry kimlik bilgisi yardımcısının, depolarla bağlantı kurarken kimlik doğrulaması yapabilmesi için aşağıdaki komutu kullanarak Uygulama Varsayılan Kimlik Bilgileri'nin (ADC) bilinen konumunu kullanıcı hesabı kimlik bilgilerinizle güncelleyin:

gcloud auth login --update-adc

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

Java projenize eklenecek depo yapılandırmasını yazdırmak için 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 Cloud Shell Düzenleyici'de pom.xml dosyasını açın:

cloudshell edit pom.xml

ve döndürülen ayarları dosyadaki uygun bölümlere 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>

Depolar bölümünü güncelleme

 <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ına ilişkin bir örneği burada bulabilirsiniz. <PROJECT> kısmını 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 Artifact Registry'yi yapılandırdıktan sonra artık kuruluşunuzdaki diğer projelerde kullanılacak Java JAR'larını 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'deki Java paketini kontrol etme

Cloud Console - Artifact Registry - Repositories'e gidin. java-repo'ı tıklayın ve helloworld ikili yapısının orada olduğundan emin olun:

9. Tebrikler!

Tebrikler, codelab'i tamamladınız.

Kapsamda olanlar

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

Temizleme

Cloud Shell'de aşağıdaki komutu çalıştırarak projenin tamamını silin.

gcloud projects delete $PROJECT_ID