Bu codelab hakkında
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