1. Genel Bakış
Artifact Registry, OCI container görüntülerinizi ve dil paketlerinizi (Maven ve npm gibi) yönetmek için tam olarak yönetilen bir paket yöneticisidir ve birleşik bir araç sağlar.
Artifact Registry, Google Cloud'un diğer birçok Google Cloud hizmetiyle tamamen entegre edilmiştir. Örneğin:
- 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, bu özelliklerin birçoğu uygulamalı eğitim şeklinde 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 öğelerinizin 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. Dilediğiniz zaman güncelleyebilirsiniz.
- Proje kimliği, tüm Google Cloud projelerinde benzersizdir ve sabittir (ayarlandıktan sonra değiştirilemez). Cloud Console otomatik olarak benzersiz bir dize oluşturur. Genellikle bu dizenin ne olduğuyla ilgilenmezsiniz. Çoğu codelab'de proje kimliğinize (genellikle
PROJECT_IDolarak 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 çok fazla zamanınızı almaz. 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, kapsayıcı 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 deposunu 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ırabilirsiniz.
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 da yer alır.
Container görüntüsünü oluşturma
Container görüntülerini Artifact Registry'de 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
Kapsayıcı 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. Tarama tamamlandıktan sonra bu görüntü düzeltmesi için algılanan güvenlik açığı sayısını görebilirsiniz. Bir sonraki bölümde güvenlik açıkları ve diğer yapay nesne analizlerini 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. 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
Üstteki "Bağımlılıklar" sekmesine giderek resminizde algılanan tüm bağımlılıkları görebilirsiniz. Hem dil bağımlılıkları hem de işletim sistemi düzeyindeki bağımlılıkların listelendiğini unutmayın. 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ı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 artık Cloud Storage'da depolanan otomatik olarak oluşturulmuş SBOM'nin bağlantısını içerir. Görüntüleriniz için SBOM'lara güveniyorsanız yapıtlarınız için otomatik olarak SBOM oluşturmak ve oluşturma işlemini CI/CD ardışık düzeninize 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üzeltme içeren 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 kaynaklı 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şabilirsiniz.
Uzak depolar, istekleri yukarı akış kayıt defterine yönlendirmenize ve bu sırada görüntüleri önbelleğe almanıza olanak tanır. 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ı bu resimlere de 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 depodan 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çerikler 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 hatta yalnızca güvenilir yapıtların Cloud Run çalışma zamanımıza dağıtılabilmesini sağlamak için yapıtların şifreleme imzalarından nasıl yararlanabileceğimizi inceleyeceğiz.
Cloud Build ile SLSA onayı
SLSA çerçevesi, tedarik zinciri yapay ürünleri için farklı kanıt düzeyleri sağlar. İlk bakışta spesifikasyon ve uygulama 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 gidebilir, derlememizi açıp 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 düğmeyi 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.
Görüntümüzün 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 ardışık düzeni 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ı çalışma zamanlarınızın önüne bir bekçi yerleştirebilirsiniz. Bu bekçi, kapsayıcı görüntüsünü inceler ve güvenilir bir onay belgesinin varlığını doğrular. Onay bulunamazsa yapılandırmaya bağlı olarak denetleme günlüğü girişleri oluşturur veya dağıtımı tamamen engeller.
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 tasdik edenlerinizi de ekleyebilirsiniz ancak bu, bu codelab'in kapsamı dışındadır ve isteğe bağlı bir ödev alıştırması 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 bir hata mesajı alırsınız. Bu mesaj şu şekilde görünür:
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 paket 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ü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ına ilişkin ö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'da Artifact Registry yapılandırıldığında, kuruluşunuzdaki diğer projelerde kullanılmak üzere 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 simgesini tıklayın ve helloworld ikili yapısının mevcut olduğunu doğrulayın:
9. Tebrikler!
Tebrikler, codelab'i tamamladınız.
Kapsamda olanlar
- Kapsayıcılar ve Dil Paketleri İçin Depolar Oluşturma
- 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
Tüm projeyi silmek için Cloud Shell'de aşağıdaki komutu çalıştırın:
gcloud projects delete $PROJECT_ID