درباره این codelab
1. نمای کلی
Artifact Registry یک مدیر بسته کاملاً مدیریت شده برای و یک ابزار یکپارچه برای مدیریت تصاویر ظرف OCI و بسته های زبان شما (مانند Maven و npm) است.
رجیستری مصنوع به طور کامل با طیف گسترده ای از سرویس های Google Cloud Google Cloud مانند مثال های زیر یکپارچه شده است:
- Cloud Build می تواند به طور مستقیم مصنوعات تصویر را در Artifact Registry آپلود کند.
- Cloud Deploy میتواند تصاویر آرتیفکت رجیستری را مستقیماً در محیطهای زمان اجرا مختلف مستقر کند.
- این تصاویر را در زمانهای اجرا کانتینر مانند Cloud Run و GKE فراهم میکند و قابلیتهای بهینهسازی عملکرد پیشرفته مانند جریان تصویر را فعال میکند.
- Artifact Registry می تواند به عنوان یک نقطه تشخیص برای Artifact Analysis برای نظارت مستمر برای آسیب پذیری های شناخته شده عمل کند.
- Cloud IAM کنترل ثابت و دقیقی را بر روی دسترسی و مجوزهای مصنوع ارائه می دهد.
این آزمایشگاه شما را از طریق بسیاری از این ویژگی ها در قالب یک آموزش عملی راهنمایی می کند.
آنچه خواهید آموخت
اهداف آموزشی این آزمایشگاه چیست؟
- مخازن مختلف برای کانتینرها و بسته های زبان ایجاد کنید
- ایجاد و استفاده از تصاویر کانتینر با رجیستری مصنوع
- از رجیستری Artifact برای تجزیه و تحلیل وضعیت امنیتی و محتوای مصنوعات خود استفاده کنید
- پیکربندی و استفاده از Artifact Registry برای وابستگی های Java Maven
2. راه اندازی و الزامات
تنظیم محیط خود به خود
- به Google Cloud Console وارد شوید و یک پروژه جدید ایجاد کنید یا از یک موجود استفاده مجدد کنید. اگر قبلاً یک حساب Gmail یا Google Workspace ندارید، باید یک حساب ایجاد کنید .
- نام پروژه نام نمایشی برای شرکت کنندگان این پروژه است. این یک رشته کاراکتری است که توسط API های Google استفاده نمی شود. همیشه می توانید آن را به روز کنید.
- شناسه پروژه در تمام پروژههای Google Cloud منحصربهفرد است و تغییرناپذیر است (پس از تنظیم نمیتوان آن را تغییر داد). Cloud Console به طور خودکار یک رشته منحصر به فرد تولید می کند. معمولاً برای شما مهم نیست که چیست. در اکثر کدها، باید شناسه پروژه خود را ارجاع دهید (معمولاً با نام
PROJECT_ID
شناخته می شود). اگر شناسه تولید شده را دوست ندارید، ممکن است یک شناسه تصادفی دیگر ایجاد کنید. از طرف دیگر، میتوانید خودتان را امتحان کنید، و ببینید آیا در دسترس است یا خیر. پس از این مرحله نمی توان آن را تغییر داد و در طول مدت پروژه باقی می ماند. - برای اطلاع شما، یک مقدار سوم وجود دارد، یک شماره پروژه ، که برخی از API ها از آن استفاده می کنند. در مورد هر سه این مقادیر در مستندات بیشتر بیاموزید.
- در مرحله بعد، برای استفاده از منابع Cloud/APIها باید صورتحساب را در کنسول Cloud فعال کنید . اجرا کردن از طریق این کد لبه هزینه زیادی نخواهد داشت. برای خاموش کردن منابع برای جلوگیری از تحمیل صورتحساب فراتر از این آموزش، میتوانید منابعی را که ایجاد کردهاید حذف کنید یا پروژه را حذف کنید. کاربران جدید Google Cloud واجد شرایط برنامه آزمایشی رایگان 300 دلاری هستند.
gcloud را راه اندازی کنید
در Cloud Shell، شناسه پروژه و شماره پروژه خود را تنظیم کنید. آنها را به عنوان متغیرهای PROJECT_ID
و PROJECT_NUMBER
ذخیره کنید.
export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
خدمات گوگل را فعال کنید
gcloud services enable \
cloudresourcemanager.googleapis.com \
run.googleapis.com \
artifactregistry.googleapis.com \
containerregistry.googleapis.com \
containerscanning.googleapis.com \
binaryauthorization.googleapis.com \
cloudbuild.googleapis.com
کد منبع را دریافت کنید
کد منبع این آزمایشگاه در سازمان GoogleCloudPlatform در GitHub قرار دارد. با دستور زیر آن را کلون کنید.
git clone https://github.com/GoogleCloudPlatform/java-docs-samples
3. فشار دادن تصاویر کانتینر
یک مخزن Docker در رجیستری Artifact ایجاد کنید
همانطور که قبلا ذکر شد Artifact Registry از فرمت های مخزن مختلف پشتیبانی می کند که به شما امکان می دهد تصاویر کانتینر و بسته های زبان را مدیریت کنید. تعاملات با انواع مختلف مخازن مصنوع در مشخصات تعریف شده است و استانداردهای به طور گسترده پذیرفته شده است. برای مثال درخواستهای وابستگیهای Maven با درخواستهای وابستگی Node متفاوت هستند.
برای پشتیبانی از مشخصات API مصنوع خاص، Artifact Registry باید مصنوعات شما را در انواع مخزن مربوطه مدیریت کند. هنگامی که یک مخزن جدید ایجاد می کنید، پرچم --repository-format
را برای نشان دادن نوع مخزن ارسال می کنید.
برای ایجاد اولین مخزن برای تصاویر Docker دستور زیر را از Cloud Shell اجرا کنید:
gcloud artifacts repositories create container-example --repository-format=docker \
--location=us-central1 --description="Example Docker repository"
اگر اعلان مجوز Cloud Shell ظاهر شد روی Authorize کلیک کنید
به Google Cloud Console - Artifact Registry - Repositories بروید و به مخزن Docker جدید ایجاد شده خود با نام container-example
توجه کنید، اگر روی آن کلیک کنید می بینید که در حال حاضر خالی است.
احراز هویت Docker را در رجیستری مصنوع پیکربندی کنید
هنگام اتصال به Artifact Registry به منظور دسترسی به اطلاعات اعتبار لازم است. بهجای تنظیم اعتبارنامههای جداگانه، Docker را میتوان طوری پیکربندی کرد که از اعتبارنامههای gcloud شما یکپارچه استفاده کند.
از Cloud Shell دستور زیر را برای پیکربندی Docker برای استفاده از Google Cloud CLI برای احراز هویت درخواستهای Artifact Registry در منطقه us-central1
اجرا کنید.
gcloud auth configure-docker us-central1-docker.pkg.dev
اگر دستور تأیید تغییر پیکربندی داکر Cloud Shell را درخواست کرد، اینتر را فشار دهید.
نمونه برنامه را کاوش کنید
یک نمونه برنامه در مخزن git که در مرحله قبلی کلون کردید ارائه شده است. به دایرکتوری جاوا تغییر دهید و کد برنامه را بررسی کنید.
cd java-docs-samples/run/helloworld/
ls
این پوشه حاوی یک مثال برنامه جاوا است که یک صفحه وب ساده را ارائه میکند: علاوه بر فایلهای مختلفی که مربوط به این آزمایشگاه خاص نیستند، حاوی کد منبع، زیر پوشه src
، و یک Dockerfile است که برای ساختن یک تصویر ظرف استفاده خواهیم کرد.
تصویر کانتینر را بسازید
قبل از اینکه بتوانید تصاویر کانتینر را در Artifact Registry ذخیره کنید، باید یکی را ایجاد کنید.
دستور زیر را برای ساخت تصویر کانتینر اجرا کنید و آن را با مسیر رجیستری کامل آرتیفکت تگ کنید:
docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1 .
تصویر کانتینر را به رجیستری مصنوع فشار دهید
دستور زیر را برای فشار دادن تصویر ظرف به مخزن ایجاد شده قبلی اجرا کنید:
docker push us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1
تصویر را در Artifact Registry مرور کنید
به Google Cloud Console - Artifact Registry - Repositories بروید .
مخزن container-example
را باز کنید و بررسی کنید که تصویر java-hello-world
در آنجا وجود دارد.
روی تصویر کلیک کنید و به تصویر برچسب گذاری شده با tag1
توجه کنید. از آنجایی که ما اسکن خودکار تصاویر را از طریق سرویس containerscanning.googleapis.com
فعال کردهایم، میتوانید ببینید که اسکن آسیبپذیری در حال اجرا است یا قبلاً تکمیل شده است. پس از تکمیل، میتوانید تعداد آسیبپذیریهایی که برای این ویرایش تصویر شناسایی شدهاند را مشاهده کنید. آسیبپذیریها و سایر بینشهای مصنوع را در بخش بعدی بررسی خواهیم کرد.
4. بازرسی تصاویر کانتینر
اکنون که اولین تصویر خود را به مخزن container-example
منتقل کردید، میتوانیم با جزئیات بیشتری به آن نگاه کنیم. در تب نسخه ها، روی نسخه ای که به تازگی ایجاد کرده ایم، کلیک کنید. برای نمایش تصویر با جزئیات بیشتر:
دکمه کپی بالایی به ویژه مفید است زیرا راهی آسان برای دسترسی به URI تصویر کاملاً واجد شرایط به آن نسخه تصویر از جمله SHA-hash را فراهم می کند. این URI سپس می تواند برای کشیدن یک نسخه تصویر خاص یا به عنوان مرجع تصویر در یک Kubernetes Deployment یا یک سرویس Cloud Run استفاده شود. برای تست URI تصویر می توانید دستور زیر را در Cloud Shell اجرا کنید:
docker pull $IMAGE_URI
درک وابستگی ها
با رفتن به برگه "وابستگی ها" در بالا، می توانید تمام وابستگی هایی را که در تصویر خود شناسایی شده اند مشاهده کنید. توجه داشته باشید که هم وابستگی ها را در وابستگی های زبان و هم در سطح سیستم عامل لیست می کند. همچنین میتوانید مجوزهای نرمافزاری را که به هر یک از وابستگیها پیوست شدهاند، مشاهده کنید.
اگر دقت کنید می بینید که اطلاعات SBOM هنوز پر نشده است. برای پر کردن SOM برای مصنوع خود، میتوانید دستور زیر را در Cloud Shell با استفاده از URI تصویر کاملاً واجد شرایط که میتوانیم از نوار breadcrumb در بالا کپی کنیم، اجرا کنید.
gcloud artifacts sbom export --uri $IMAGE_URI
هنگامی که صفحه را بازخوانی کردید، اکنون حاوی پیوندی به SBOM تولید شده به طور خودکار ذخیره شده در فضای ابری خواهد بود. اگر برای تصاویر خود به SBOM ها متکی هستید، ممکن است بخواهید به طور خودکار SBOM برای مصنوعات خود تولید کنید و تولید را به بخشی از خط لوله CI/CD خود تبدیل کنید.
بررسی آسیبپذیریهای تصویر
هنگامی که روی تب "آسیب پذیری" در بالای نما کلیک می کنید، می توانید تمام آسیب پذیری هایی را که در تصویر خود شناسایی شده اند مشاهده کنید. علاوه بر خلاصه ای از آسیب پذیری ها در بالا، می توانید لیست کامل آسیب پذیری ها را در جدول پایین مشاهده کنید. هر ردیف به بولتن CVE پیوند دارد و شدت آن و بسته ای را که از آن منشا گرفته است را نشان می دهد. برای آسیبپذیریهایی که رفع آن در دسترس است، دستورالعملهایی درباره نحوه بهروزرسانی وابستگیها برای رفع آسیبپذیری نیز ارائه میدهد.
5. مخازن مجازی و از راه دور
در بخش قبل از یک مخزن تصویر برای فشار دادن و کشیدن تصاویر خود استفاده کردیم. این برای موارد استفاده در مقیاس کوچک عالی عمل میکند، اما چالشهایی را بهویژه برای سازمانهای بزرگتر با تیمهای مختلف که نیاز به استقلال در مخازن خود دارند، فراهم میکند. معمولاً تیم ها یا واحدهای تجاری مخزن تصویر خود را با مجوزها و پیکربندی خود دارند. برای ساده کردن استفاده از تصاویر در این مخازن و محافظت از مصرف کننده در برابر ساختار سازمانی زیربنایی، Artifact Registry مخازن مجازی را فراهم می کند که می تواند منابع را از چندین مخزن زیربنایی جمع آوری کند. یک معماری بالقوه می تواند به شکل زیر باشد:
مخزن از راه دور برای داکر هاب
Docker Hub یک رجیستری تصویر عمومی محبوب است و بسیاری از تصاویر کانتینر منبع باز را میزبانی می کند. در حالی که استفاده از مخزن عمومی به طور مستقیم ساده است، اما با تعدادی چالش در محیط تولید همراه است که ما می توانیم با مخازن از راه دور در Artifact Registry بر آنها غلبه کنیم.
مخازن راه دور به شما این امکان را می دهد که درخواست ها را به رجیستری بالادستی پروکسی کنید و تصاویر را در طول مسیر ذخیره کنید. این نه تنها زمان دانلود تصاویر را کاهش می دهد، بلکه وابستگی به زمان آپدیت سرویس خارجی را نیز از بین می برد و به شما این امکان را می دهد که همان سیاست های امنیتی و دسترسی را اعمال کنید که برای تصاویر خود اعمال می کنید.
برای ایجاد یک مخزن از راه دور برای Docker Hub می توانید دستور زیر را در Cloud Shell اجرا کنید:
gcloud artifacts repositories create dockerhub \
--repository-format=docker \
--mode=remote-repository \
--remote-docker-repo=docker-hub \
--location=us-central1 \
--description="Example Remote Repo for Docker Hub"
اکنون باید یک مخزن اضافی را در لیست مخازن آرتیفکت رجیستری خود مشاهده کنید:
برای آزمایش اینکه آیا مخزن راه دور شما میتواند درخواستهای پراکسی به مخزن راه دور را انجام دهد، دستور زیر را در Cloud Shell اجرا کنید تا تصویر nginx را بکشید:
docker pull us-central1-docker.pkg.dev/$PROJECT_ID/dockerhub/nginx:stable-alpine
هنگامی که کشش موفقیت آمیز شد، می توانید به مخزن موجود در Cloud Console نیز نگاه کنید و تصویر کش nginx اکنون همان گزارش وابستگی و آسیب پذیری را ارائه می دهد که ما برای تصویری که خودتان ساخته اید دیده بودیم.
ایجاد یک مخزن مجازی
با پیروی از فرآیندهایی که تاکنون استفاده کردهایم، میتوانید تعدادی مخزن برای هر تیم یا کسبوکار ایجاد کنید و به وضوح مالکیت و مجوزهای IAM را برای هر کدام تعریف کنید. همچنین میتوانیم پراکسیهایی برای مخازن راه دور ایجاد کنیم که مصرف تصاویر شخص ثالث را آسانتر و ایمنتر میکند. اگر دیدگاه خود را به سمت مصرف کننده این تصاویر تغییر دهید، جنبه منفی این تعداد زیاد مخازن آشکار می شود. چگونه یک توسعه دهنده باید بداند که از کدام مخزن تصویر باید در استقرار خود استفاده کند؟
برای ساده کردن مصرف و پنهان کردن مخازن زیربنایی در پشت یک لایه انتزاعی، می توانید با دستور زیر در Cloud Shell یک مخزن مجازی در Artifact Registry ایجاد کنید:
gcloud projects add-iam-policy-binding $PROJECT_ID \
--member serviceAccount:service-$PROJECT_NUMBER@gcp-sa-artifactregistry.iam.gserviceaccount.com \
--role roles/artifactregistry.reader
cat <<EOF > /tmp/upstream.json
[{
"id" : "hello-repo",
"repository" : "projects/$PROJECT_ID/locations/us-central1/repositories/container-example",
"priority" : 100
},{
"id" : "dockerhub",
"repository" : "projects/$PROJECT_ID/locations/us-central1/repositories/dockerhub",
"priority" : 101
}]
EOF
gcloud artifacts repositories create all-images \
--repository-format=docker \
--mode=virtual-repository \
--location=us-central1 \
--upstream-policy-file=/tmp/upstream.json \
--description="Example Virtual Repo"
اکنون میتوانیم تصاویر را از مخزن مجازی بدون افشای ساختار زیرین بیرون بکشیم. برای تأیید اینکه همه چیز همانطور که انتظار می رود کار می کند، می توانید دستورات زیر را در Cloud Shell اجرا کنید:
docker pull us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1
docker pull us-central1-docker.pkg.dev/$PROJECT_ID/all-images/nginx:stable-alpine
6. در Cloud Run مستقر شوید
با وجود مخازن و تصاویر مربوطه، اکنون می توانیم به استفاده از آنها در یک استقرار روی بیاوریم. برای نشان دادن یک مثال استفاده و برای جلوگیری از استقرار زیرساخت های اضافی، کانتینر خود را در Cloud Run مستقر می کنیم. در ساده ترین شکل آن، استقرار را می توان با اجرای دستور زیر در Cloud Shell به دست آورد:
gcloud run deploy hello-world \
--image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
--region us-central1 \
--allow-unauthenticated
پس از اتمام استقرار، URL ایجاد شده به طور خودکار نشان داده می شود که تحت آن می توانید به سرویس خود دسترسی داشته باشید.
Deploying container to Cloud Run service [hello-world] in project [my-project] region [us-central1] OK Deploying... Done. OK Creating Revision... OK Routing traffic... OK Setting IAM Policy... Done. Service [hello-world] revision [hello-world-00001-wtc] has been deployed and is serving 100 percent of traffic. Service URL: https://hello-world-13746229022.us-central1.run.app
اگر آن URL را در یک برگه مرورگر جدید باز کنید، باید پیام موفقیت آمیز "Hello World" را ببینید.
7. تقویت امنیت زنجیره تامین
اکنون که تصویر Container شما به یک استقرار زنده راه یافته است، ممکن است زمان خوبی باشد تا ببینیم چگونه میتوانیم زنجیره تامین پایان تا پایان خود را تقویت کنیم. در بخش قبل به بررسی این موضوع پرداختیم که چگونه تجزیه و تحلیل کانتینر Artifact Registry بینش هایی را در مورد کتابخانه ها و مجوزهای استفاده شده در تصویر ارائه می دهد. با این حال هنوز هم ممکن است بازیگران مخرب محتوای مضر را در طول زنجیره تامین به تصویر شما وارد کنند. در این بخش بررسی خواهیم کرد که چگونه می توانیم از چارچوب SLSA برای معرفی تصدیق مصنوعات ساخت و حتی استفاده از امضای رمزنگاری شده خود مصنوعات استفاده کنیم تا اطمینان حاصل کنیم که فقط مصنوعات قابل اعتماد می توانند در زمان اجرای Cloud Run ما مستقر شوند.
گواهی SLSA با ساخت ابر
چارچوب SLSA سطوح مختلفی از شواهد را برای مصنوعات زنجیره تامین فراهم می کند. مشخصات و پیاده سازی ممکن است در نگاه اول دلهره آور به نظر برسد، اما با ایجاد گواهینامه SLSA در Cloud Build به سادگی افزودن ایجاد مشخصات cloudbuild.yaml
با requestedVerifyOption
تنظیم شده روی VERIFIED
.
برای برنامه ما می توانیم دستور زیر را در Cloud Shell اجرا کنیم تا یک فایل cloudbuild.yaml
در پوشه helloworld ایجاد کنیم.
cat <<EOF > cloudbuild.yaml
steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', '\$_IMAGE_URI', '.']
- name: 'gcr.io/cloud-builders/docker'
args: ['push', '\$_IMAGE_URI']
images:
- '\$_IMAGE_URI'
options:
requestedVerifyOption: VERIFIED
substitutions:
_IMAGE_URI: us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:latest
EOF
اکنون یک Cloud Build Job جدید ایجاد می کنیم که با اجرای دستور زیر در Cloud Shell نسخه جدیدی از Java Hello World Image ما را می سازد.
gcloud builds submit --substitutions=_IMAGE_URI=us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build
پس از تکمیل ساخت، میتوانیم به رابط کاربری Cloud Build در Google Cloud Console برویم و سطح SLSA را که با باز کردن ساختمان به دست آوردهایم و سپس نگاهی به Build Artifacts در زیر Build Summary مشاهده کنیم. تصویری که در آنجا مشاهده میشود دکمهای برای مشاهده «اطلاعات امنیتی» دارد. وقتی روی آن کلیک میکنید گواهی SLSA و همچنین گزارشهای آسیبپذیری آشنا را میبینید که قبلاً در رابط کاربری Artifact Registry وقتی که ساخت محلی خود را فشار دادیم مشاهده کردیم.
منشأ SLSA برای تصویر ما نیز با اجرای دستور زیر در Cloud Shell قابل بازیابی است:
gcloud artifacts docker images describe \
"us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build" \
--show-provenance
نیاز به منشأ ساخت ابر با مجوز باینری
با وجود خط لوله Cloud Build، آیا اطمینان از اینکه تمام تصاویری که برای تولید استفاده می کنیم با استفاده از آن محیط ساخت قابل برنامه ریزی و تکرارپذیر ساخته شده اند، عالی نیست؟
این جایی است که مجوز باینری وارد می شود. به شما این امکان را می دهد که یک دروازه بان را در مقابل زمان های اجرا کانتینر خود قرار دهید که تصویر کانتینر را بررسی می کند و وجود یک گواهی قابل اعتماد را تأیید می کند. اگر تأییدی یافت نشد، یا ورودی های گزارش حسابرسی را ایجاد می کند یا بسته به پیکربندی، استقرار را کاملاً مسدود می کند.
برای تغییر پیکربندی پیشفرض مجوز باینری پروژه ما برای نیاز به گواهی داخلی صادر شده توسط Cloud Run، دستور زیر را در Cloud Shell اجرا میکنیم:
cat << EOF > /tmp/policy.yaml
defaultAdmissionRule:
enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
evaluationMode: REQUIRE_ATTESTATION
requireAttestationsBy:
- projects/$PROJECT_ID/attestors/built-by-cloud-build
name: projects/$PROJECT_ID/policy
EOF
gcloud container binauthz policy import /tmp/policy.yaml
در اینجا بدیهی است که میتوانید گواهیدهندههای سفارشی خود را نیز اضافه کنید، اما این خارج از محدوده این نرمافزار است و به عنوان یک تمرین تکلیف درسی اضافی اختیاری باقی میماند.
برای اجرای مجوز باینری در سرویس Cloud Run، دستور زیر را در Cloud Shell اجرا می کنیم:
gcloud run services update hello-world \
--region us-central1 \
--binary-authorization=default
بیایید آزمایش کنیم که مجوز باینری به درستی اعمال می شود و ابتدا تصویری که به صورت محلی ساخته شده است را مجدداً اجرا می کنیم
gcloud run deploy hello-world \
--image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
--region us-central1
همانطور که انتظار می رود باید یک پیام خطایی دریافت کنید که توضیح می دهد چرا تصویر نمی تواند مستقر شود که چیزی شبیه به این است:
Image us-central1-docker.pkg.dev/my-project/all-images/java-hello-world@sha256:71eebbf04bf7d1d023e5de5e18f786ea3b8b6411bf64c8def3301c71baca0518 denied by attestor projects/my-project/attestors/built-by-cloud-build: No attestations found that were valid and signed by a key trusted by the attestor
بنابراین برای استقرار یک نسخه جدید در سرویس Cloud Run، باید تصویری ارائه کنیم که با Cloud Build ساخته شده است.
gcloud run deploy hello-world \
--image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:cloud-build \
--region us-central1
در این زمان استقرار باید موفقیت آمیز باشد و یک پیام استقرار موفقیت آمیز مشابه پیام زیر نشان دهد:
Deploying container to Cloud Run service [hello-world] in project [my-project] region [us-central1] OK Deploying... Done. OK Creating Revision... OK Routing traffic... Done. Service [hello-world] revision [hello-world-00005-mq4] has been deployed and is serving 100 percent of traffic. Service URL: https://hello-world-13746229022.us-central1.run.app
8. مدیریت بسته های زبان جاوا Maven
در این بخش نحوه راهاندازی یک مخزن جاوا Artifact Registry و آپلود بستهها در آن و استفاده از آنها در برنامههای مختلف را خواهید دید.
یک مخزن بسته Maven ایجاد کنید
از Cloud Shell دستور زیر را برای ایجاد یک مخزن برای مصنوعات جاوا اجرا کنید:
gcloud artifacts repositories create java-repo \
--repository-format=maven \
--location=us-central1 \
--description="Example Java Maven Repo"
اگر اعلان مجوز Cloud Shell ظاهر شد روی Authorize کلیک کنید
به Google Cloud Console - Artifact Registry - Repositories بروید و به مخزن جدید Maven خود با نام java-repo
توجه کنید، اگر روی آن کلیک کنید می بینید که در حال حاضر خالی است.
احراز هویت را در مخزن Artifact تنظیم کنید
از دستور زیر برای به روز رسانی مکان شناخته شده برای Application Default Credentials (ADC) با اعتبار حساب کاربری خود استفاده کنید تا کمک کننده اعتبار رجیستری Artifact بتواند با استفاده از آنها هنگام اتصال با مخازن احراز هویت کند:
gcloud auth login --update-adc
Maven را برای رجیستری مصنوع پیکربندی کنید
دستور زیر را برای چاپ پیکربندی مخزن برای افزودن به پروژه جاوا خود اجرا کنید:
gcloud artifacts print-settings mvn \
--repository=java-repo \
--location=us-central1 | tee config.xml
با اجرای دستور زیر در Cloud Shell از داخل پوشه helloworld، pom.xml را در Cloud Shell Editor باز کنید:
cloudshell edit pom.xml
و تنظیمات بازگشتی را به بخش های مربوطه در فایل اضافه کنید،
بخش توزیع مدیریت را به روز کنید
<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>
بخش افزونه های در حال ساخت را به روز کنید
<extensions>
<extension>
<groupId>com.google.cloud.artifactregistry</groupId>
<artifactId>artifactregistry-maven-wagon</artifactId>
<version>2.1.0</version>
</extension>
</extensions>
در اینجا نمونه ای از فایل کامل برای مرجع شما آورده شده است. مطمئن شوید که <PROJECT> را با شناسه پروژه خود جایگزین کرده اید.
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example.run</groupId>
<artifactId>helloworld</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<parent>
<groupId>com.google.cloud.samples</groupId>
<artifactId>shared-configuration</artifactId>
<version>1.2.0</version>
</parent>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring-boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<maven.compiler.target>17</maven.compiler.target>
<maven.compiler.source>17</maven.compiler.source>
<spring-boot.version>3.2.2</spring-boot.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<!-- [START Artifact Registry Config] -->
<distributionManagement>
<snapshotRepository>
<id>artifact-registry</id>
<url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
</snapshotRepository>
<repository>
<id>artifact-registry</id>
<url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
</repository>
</distributionManagement>
<repositories>
<repository>
<id>artifact-registry</id>
<url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
<build>
<extensions>
<extension>
<groupId>com.google.cloud.artifactregistry</groupId>
<artifactId>artifactregistry-maven-wagon</artifactId>
<version>2.2.0</version>
</extension>
</extensions>
<!-- [END Artifact Registry Config] -->
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>${spring-boot.version}</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>3.4.0</version>
<configuration>
<to>
<image>gcr.io/PROJECT_ID/helloworld</image>
</to>
</configuration>
</plugin>
</plugins>
</build>
</project>
بسته جاوا خود را در Artifact Registry آپلود کنید
با پیکربندی Artifact Registry در Maven، اکنون می توانید از Artifact Registry برای ذخیره جاوا Jars برای استفاده توسط پروژه های دیگر در سازمان خود استفاده کنید.
برای آپلود بسته جاوا در Artifact Registry دستور زیر را اجرا کنید:
mvn deploy
بسته جاوا را در Artifact Registry بررسی کنید
به Cloud Console - Artifact Registry - Repositories بروید روی java-repo
کلیک کنید و بررسی کنید که مصنوع دودویی helloworld
در آنجا باشد:
9. تبریک می گویم!
تبریک می گویم، شما نرم افزار کد را تمام کردید!
آنچه شما پوشش داده اید
- ایجاد مخازن برای کانتینرها و بسته های زبان
- تصاویر کانتینر مدیریت شده با رجیستری مصنوع
- رجیستری مصنوع یکپارچه با کد ابری
- Maven را برای استفاده از Artifact Registry برای وابستگی های جاوا پیکربندی کرد
پاکسازی
دستور زیر را در Cloud Shell اجرا کنید تا کل پروژه حذف شود
gcloud projects delete $PROJECT_ID