۱. مرور کلی
Artifact Registry یک مدیر بسته کاملاً مدیریتشده است و ابزاری یکپارچه برای مدیریت تصاویر کانتینر OCI و بستههای زبانی (مانند Maven و npm) شما فراهم میکند.
رجیستری مصنوعات کاملاً با طیف گستردهای از سرویسهای دیگر گوگل کلود مانند مثالهای زیر یکپارچه شده است:
- Cloud Build میتواند مستقیماً مصنوعات تصویر را در Artifact Registry بارگذاری کند.
- Cloud Deploy میتواند تصاویر رجیستری مصنوعات را مستقیماً در محیطهای مختلف زمان اجرا مستقر کند.
- این ابزار، تصاویر را برای زمانهای اجرای کانتینر مانند Cloud Run و GKE فراهم میکند و قابلیتهای بهینهسازی عملکرد پیشرفته مانند پخش تصویر را فعال میکند.
- رجیستری مصنوعات میتواند به عنوان یک نقطه تشخیص برای تحلیل مصنوعات عمل کند تا به طور مداوم آسیبپذیریهای شناخته شده را رصد کند.
- مدیریت دسترسی و احراز هویت ابری (Cloud IAM) کنترل منسجم و دقیقی بر دسترسی به مصنوعات و مجوزها ارائه میدهد.
این آزمایشگاه شما را در قالب یک آموزش عملی با بسیاری از این ویژگیها آشنا خواهد کرد.
آنچه یاد خواهید گرفت
اهداف آموزشی این آزمایشگاه چیست؟
- ایجاد مخازن مختلف برای کانتینرها و بستههای زبان
- ایجاد و استفاده از تصاویر کانتینر با رجیستری Artifact
- از رجیستری مصنوعات برای تجزیه و تحلیل وضعیت امنیتی و محتوای مصنوعات خود استفاده کنید
- پیکربندی و استفاده از رجیستری Artifact برای وابستگیهای Java Maven
۲. تنظیمات و الزامات
تنظیم محیط خودتنظیم
- وارد کنسول گوگل کلود شوید و یک پروژه جدید ایجاد کنید یا از یک پروژه موجود دوباره استفاده کنید. اگر از قبل حساب جیمیل یا گوگل ورک اسپیس ندارید، باید یکی ایجاد کنید .
- نام پروژه، نام نمایشی برای شرکتکنندگان این پروژه است. این یک رشته کاراکتری است که توسط APIهای گوگل استفاده نمیشود. شما همیشه میتوانید آن را بهروزرسانی کنید.
- شناسه پروژه در تمام پروژههای گوگل کلود منحصر به فرد است و تغییرناپذیر است (پس از تنظیم، قابل تغییر نیست). کنسول کلود به طور خودکار یک رشته منحصر به فرد تولید میکند؛ معمولاً برای شما مهم نیست که چیست. در اکثر آزمایشگاههای کد، باید شناسه پروژه خود را (که معمولاً با عنوان
PROJECT_IDشناخته میشود) ارجاع دهید. اگر شناسه تولید شده را دوست ندارید، میتوانید یک شناسه تصادفی دیگر ایجاد کنید. به عنوان یک جایگزین، میتوانید شناسه خودتان را امتحان کنید و ببینید که آیا در دسترس است یا خیر. پس از این مرحله قابل تغییر نیست و در طول پروژه باقی میماند. - برای اطلاع شما، یک مقدار سوم، شماره پروژه ، وجود دارد که برخی از APIها از آن استفاده میکنند. برای کسب اطلاعات بیشتر در مورد هر سه این مقادیر، به مستندات مراجعه کنید.
- در مرحله بعد، برای استفاده از منابع/API های ابری، باید پرداخت صورتحساب را در کنسول ابری فعال کنید . اجرای این آزمایشگاه کد هزینه زیادی نخواهد داشت، اگر اصلاً هزینهای داشته باشد. برای خاموش کردن منابع به منظور جلوگیری از پرداخت صورتحساب پس از این آموزش، میتوانید منابعی را که ایجاد کردهاید یا پروژه را حذف کنید. کاربران جدید Google Cloud واجد شرایط برنامه آزمایشی رایگان ۳۰۰ دلاری هستند.
Set up 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
۳. ارسال تصاویر کانتینر
ایجاد مخزن داکر در رجیستری Artifact
همانطور که قبلاً ذکر شد، Artifact Registry از قالبهای مختلف مخزن پشتیبانی میکند که به شما امکان مدیریت تصاویر کانتینر و بستههای زبانی را میدهد. تعامل با انواع مختلف مخازن مصنوعات در مشخصات تعریف شده و استانداردهای گستردهای را پذیرفته است. به عنوان مثال، درخواستهای مربوط به وابستگیهای Maven با درخواستهای مربوط به وابستگیهای Node متفاوت است.
برای پشتیبانی از مشخصات API یک مصنوع خاص، Artifact Registry باید مصنوعات شما را در انواع مخزن مربوطه مدیریت کند. هنگام ایجاد یک مخزن جدید، پرچم --repository-format را برای نشان دادن نوع مخزن ارسال میکنید.
برای ایجاد اولین مخزن برای تصاویر داکر، دستور زیر را از Cloud Shell اجرا کنید:
gcloud artifacts repositories create container-example --repository-format=docker \
--location=us-central1 --description="Example Docker repository"
اگر پیام مجوز Cloud Shell ظاهر شد، روی تأیید کلیک کنید.
به Google Cloud Console - Artifact Registry - Repositories بروید و مخزن Docker تازه ایجاد شده خود با نام container-example را مشاهده کنید، اگر روی آن کلیک کنید، میبینید که در حال حاضر خالی است.
پیکربندی احراز هویت داکر در رجیستری مصنوعات
هنگام اتصال به 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 را درخواست کرد، اینتر را بزنید.
نمونه برنامه را بررسی کنید
یک برنامه نمونه در مخزن گیت که در مرحله قبل کلون کردید، ارائه شده است. به دایرکتوری جاوا بروید و کد برنامه را بررسی کنید.
cd java-docs-samples/run/helloworld/
ls
این پوشه شامل یک برنامه جاوای نمونه است که یک صفحه وب ساده را رندر میکند: علاوه بر فایلهای مختلفی که به این آزمایش خاص مربوط نیستند، شامل کد منبع، در پوشه src ، و یک فایل Dockerfile است که ما برای ساخت یک تصویر کانتینر از آن استفاده خواهیم کرد.
ساخت تصویر کانتینر
قبل از اینکه بتوانید تصاویر کانتینر را در رجیستری Artifact ذخیره کنید، باید یکی ایجاد کنید.
دستور زیر را برای ساخت تصویر کانتینر و برچسبگذاری آن با مسیر کامل رجیستری مصنوعات اجرا کنید:
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
تصویر موجود در رجیستری مصنوعات را بررسی کنید
به Google Cloud Console - Artifact Registry - Repositories بروید . مخزن container-example را باز کنید و تأیید کنید که تصویر java-hello-world در آنجا وجود دارد.
روی تصویر کلیک کنید و به تصویر با برچسب tag1 توجه کنید. از آنجا که ما اسکن خودکار تصاویر را از طریق سرویس containerscanning.googleapis.com فعال کردهایم، میتوانید ببینید که اسکن آسیبپذیری یا در حال اجرا است یا قبلاً تکمیل شده است. پس از اتمام آن، میتوانید تعداد آسیبپذیریهایی را که برای این ویرایش تصویر شناسایی شدهاند، مشاهده کنید. در بخش بعدی، آسیبپذیریها و سایر بینشهای مربوط به مصنوعات را بررسی خواهیم کرد.
۴. بررسی تصاویر کانتینر
حالا که اولین تصویر خود را به مخزن container-example ارسال کردید، میتوانیم آن را با جزئیات بیشتری بررسی کنیم. در تب versions، روی نسخهای که ایجاد کردهایم کلیک کنید. برای نمایش تصویر با جزئیات بیشتر:
دکمه کپی بالایی به ویژه مفید است زیرا راهی آسان برای دسترسی به URI تصویر کاملاً واجد شرایط به آن نسخه تصویر شامل SHA-hash فراهم میکند. سپس میتوان از این URI برای دریافت یک نسخه تصویر خاص یا به عنوان مرجع تصویر در Kubernetes Deployment یا Cloud Run Service استفاده کرد. برای آزمایش URI تصویر، میتوانید دستور زیر را در Cloud Shell اجرا کنید:
docker pull $IMAGE_URI
درک وابستگیها
با رفتن به برگه «وابستگیها» در بالا، میتوانید تمام وابستگیهایی را که در تصویر شما شناسایی شدهاند، مشاهده کنید. توجه داشته باشید که این فهرست، هم وابستگیهای مربوط به زبان و هم وابستگیهای مربوط به سیستم عامل را نشان میدهد. همچنین میتوانید مجوزهای نرمافزاری متصل به هر یک از وابستگیها را مشاهده کنید.
اگر با دقت نگاه کنید، میبینید که اطلاعات SBOM هنوز پر نشده است. برای پر کردن SOM برای مصنوع خود، میتوانید دستور زیر را در Cloud Shell با استفاده از URI تصویر کامل که میتوانیم از نوار breadcrumb در بالا کپی کنیم، اجرا کنید.
gcloud artifacts sbom export --uri $IMAGE_URI
پس از رفرش صفحه، اکنون لینکی به SBOM تولید شده خودکار که در Cloud Storage ذخیره شده است، نمایش داده میشود. اگر برای تصاویر خود به SBOMها متکی هستید، ممکن است بخواهید SBOMها را به طور خودکار برای مصنوعات خود تولید کنید و تولید را به بخشی از خط تولید CI/CD خود تبدیل کنید.
بررسی آسیبپذیریهای تصویر
وقتی روی تب «آسیبپذیریها» در بالای صفحه کلیک میکنید، میتوانید تمام آسیبپذیریهایی را که در تصویر شما شناسایی شدهاند، مشاهده کنید. علاوه بر خلاصه آسیبپذیریها در بالا، میتوانید لیست کامل آسیبپذیریها را در جدول پایین مشاهده کنید. هر ردیف به بولتن CVE لینک دارد که شدت آن و بستهای که از آن سرچشمه گرفته است را نشان میدهد. برای آسیبپذیریهایی که رفع آنها در دسترس است، دستورالعملهایی در مورد نحوه بهروزرسانی وابستگیها برای رفع آسیبپذیری نیز ارائه میدهد.
۵. مخازن مجازی و راه دور
در بخش قبلی، ما از یک مخزن تصویر واحد برای ارسال و دریافت تصاویر خود استفاده کردیم. این روش برای موارد استفاده در مقیاس کوچک عالی عمل میکند، اما به ویژه برای سازمانهای بزرگتر با تیمهای مختلف که نیاز به استقلال بر مخازن خود دارند، چالشهایی را ایجاد میکند. معمولاً تیمها یا واحدهای تجاری مخزن تصویر خود را با مجوزها و پیکربندیهای خاص خود دارند. برای سادهسازی استفاده از تصاویر در این مخازن و محافظت از مصرفکننده در برابر ساختار سازمانی زیربنایی، Artifact Registry مخازن مجازی را ارائه میدهد که میتوانند منابع را از چندین مخزن زیربنایی جمعآوری کنند. یک معماری بالقوه میتواند به این شکل باشد:
مخزن راه دور برای Docker Hub
داکر هاب یک رجیستری ایمیج عمومی محبوب است و میزبان بسیاری از ایمیجهای کانتینر متنباز است. اگرچه استفاده مستقیم از مخزن عمومی ساده است، اما در محیط عملیاتی با چالشهایی همراه است که میتوانیم با مخازن راه دور در رجیستری آرتیفکت بر آنها غلبه کنیم.
مخازن راه دور به شما این امکان را میدهند که درخواستها را به رجیستری بالادستی پروکسی کنید و در طول مسیر، تصاویر را ذخیره کنید. این کار نه تنها زمان دانلود تصاویر را کاهش میدهد، بلکه وابستگی به زمان روشن بودن سرویس خارجی را نیز از بین میبرد و به شما این امکان را میدهد که همان سیاستهای امنیتی و دسترسی را که برای تصاویر خود اعمال میکنید، اعمال کنید.
برای ایجاد یک مخزن از راه دور برای 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
پس از موفقیت در عملیات pull، میتوانید به مخزن موجود در 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
۶. استقرار در 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 را در یک برگه مرورگر جدید باز کنید، باید پیام "سلام دنیا" را با موفقیت مشاهده کنید.
۷. تقویت امنیت زنجیره تأمین
اکنون که تصویر کانتینر شما به صورت زنده پیادهسازی شده است، شاید زمان مناسبی باشد که بررسی کنیم چگونه میتوانیم زنجیره تأمین سرتاسری خود را تقویت کنیم. در بخش قبلی بررسی کردیم که چگونه تجزیه و تحلیل کانتینر Artifact Registry بینشهایی در مورد کتابخانهها و مجوزهایی که در تصویر استفاده میشوند، ارائه میدهد. با این حال، هنوز هم ممکن است عوامل مخرب محتوای مضر را در طول زنجیره تأمین به تصویر شما وارد کنند. در این بخش بررسی خواهیم کرد که چگونه میتوانیم از چارچوب SLSA برای معرفی گواهی برای مصنوعات ساخت استفاده کنیم و حتی از امضاهای رمزنگاری خود مصنوعات استفاده کنیم تا اطمینان حاصل شود که فقط مصنوعات قابل اعتماد میتوانند در زمان اجرای Cloud Run ما مستقر شوند.
گواهینامه SLSA با Cloud Build
چارچوب SLSA سطوح مختلفی از شواهد را برای مصنوعات زنجیره تأمین ارائه میدهد. مشخصات و پیادهسازی ممکن است در نگاه اول دلهرهآور به نظر برسد، اما با Cloud Build ایجاد گواهی SLSA به سادگی اضافه کردن مشخصات ایجاد 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 Shell، یک Cloud Build Job جدید ایجاد میکنیم که نسخه جدیدی از تصویر Hello World جاوای ما را میسازد.
gcloud builds submit --substitutions=_IMAGE_URI=us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build
پس از اتمام ساخت، میتوانیم به رابط کاربری Cloud Build در کنسول Google Cloud برویم و سطح SLSA که به آن دست یافتهایم را با باز کردن ساخت خود و سپس نگاه کردن به مصنوعات ساخت در زیر خلاصه ساخت، مشاهده کنیم. تصویری که در آنجا مشاهده میشود، دکمهای برای مشاهده "بینشهای امنیتی" دارد. وقتی روی آن کلیک میکنید، گواهی SLSA و همچنین گزارشهای آسیبپذیری آشنایی را که قبلاً در رابط کاربری Artifact Registry هنگام انتشار ساخت محلی خود دیده بودیم، مشاهده میکنید.
همچنین میتوان با اجرای دستور زیر در Cloud Shell، منشأ SLSA برای تصویر ما را بازیابی کرد:
gcloud artifacts docker images describe \
"us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build" \
--show-provenance
نیاز به ساخت ابری با مجوز دودویی (Binary Authorization)
با وجود خط تولید ابری، آیا عالی نمیشود اگر مطمئن شویم که تمام تصاویری که به محیط تولید ارسال میکنیم، با استفاده از آن محیط ساخت قابل برنامهریزی و تکرارپذیر ساخته شدهاند؟
اینجاست که احراز هویت دودویی (Binary Authorization) وارد عمل میشود. این امکان را به شما میدهد که یک دروازهبان (gatekeeper) را در جلوی زمانهای اجرای کانتینر خود قرار دهید که تصویر کانتینر را بررسی کرده و وجود یک گواهی معتبر (trusted attestation) را تأیید میکند. اگر هیچ گواهیای پیدا نشود، یا ورودیهای گزارش حسابرسی (audit log) ایجاد میکند یا بسته به پیکربندی، استقرار را به طور کامل مسدود میکند.
برای تغییر پیکربندی پیشفرض احراز هویت دودویی پروژهمان به گونهای که نیاز به گواهی داخلی صادر شده توسط 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
۸. مدیریت بستههای زبان جاوا Maven
در این بخش، نحوهی راهاندازی یک مخزن جاوای Artifact Registry و آپلود بستهها به آن و استفاده از آنها در برنامههای مختلف را خواهید دید.
ایجاد مخزن بسته Maven
از Cloud Shell دستور زیر را برای ایجاد مخزنی برای مصنوعات جاوا اجرا کنید:
gcloud artifacts repositories create java-repo \
--repository-format=maven \
--location=us-central1 \
--description="Example Java Maven Repo"
Click Authorize if the Cloud Shell authorization prompt appears
به Google Cloud Console - Artifact Registry - Repositories بروید و به مخزن Maven تازه ایجاد شده خود با نام java-repo توجه کنید، اگر روی آن کلیک کنید، میبینید که در حال حاضر خالی است.
تنظیم احراز هویت برای مخزن مصنوعات
از دستور زیر برای بهروزرسانی مکان شناختهشدهی Application Default Credentials (ADC) با اطلاعات حساب کاربری خود استفاده کنید تا ابزار کمکی اعتبارنامهی Artifact Registry بتواند هنگام اتصال به مخازن، با استفاده از آنها احراز هویت کند:
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 باز کنید:
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 آپلود کنید
با پیکربندی Artifact Registry در Maven، اکنون میتوانید از Artifact Registry برای ذخیره Java Jarها جهت استفاده توسط سایر پروژههای سازمان خود استفاده کنید.
دستور زیر را برای آپلود بسته جاوا در رجیستری Artifact اجرا کنید:
mvn deploy
بسته جاوا را در رجیستری Artifact بررسی کنید
به Cloud Console - Artifact Registry - Repositories بروید. روی java-repo کلیک کنید و بررسی کنید که فایل باینری helloworld در آنجا وجود داشته باشد:
۹. تبریک میگویم!
تبریک میگویم، شما codelab را تمام کردید!
آنچه شما پوشش دادهاید
- مخازن ایجاد شده برای کانتینرها و بستههای زبان
- تصاویر کانتینر مدیریتشده با رجیستری مصنوعات
- رجیستری یکپارچه مصنوعات با کد ابری
- Maven برای استفاده از Artifact Registry برای وابستگیهای جاوا پیکربندی شد
پاکسازی
دستور زیر را در Cloud Shell اجرا کنید تا کل پروژه حذف شود.
gcloud projects delete $PROJECT_ID