این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

رویدادهای Cloud Run برای Anthos Codelab

۱. مقدمه

Cloud Run به شما امکان می‌دهد کانتینرهای بدون وضعیت را در یک محیط کاملاً مدیریت‌شده اجرا کنید. این ابزار بر اساس Knative متن‌باز ساخته شده است و به شما امکان می‌دهد کانتینرهای خود را یا کاملاً مدیریت‌شده با Cloud Run یا در خوشه Google Kubernetes Engine خود با Cloud Run برای Anthos اجرا کنید.

Events for Cloud Run برای Anthos اتصال سرویس‌های Cloud Run را با رویدادهایی از منابع مختلف آسان می‌کند. این به شما امکان می‌دهد معماری‌های رویدادمحور بسازید که در آن‌ها میکروسرویس‌ها به صورت آزادانه جفت و توزیع شده‌اند. همچنین از دریافت، تحویل، امنیت، مجوزدهی و مدیریت خطا برای شما مراقبت می‌کند که چابکی توسعه‌دهنده و انعطاف‌پذیری برنامه را بهبود می‌بخشد.

در این آزمایشگاه کد، شما در مورد رویدادهای Cloud Run برای Anthos یاد خواهید گرفت. به طور خاص، به رویدادهای Cloud Pub/Sub، گزارش‌های حسابرسی، ذخیره‌سازی ابری، زمان‌بندی ابری و نحوه تولید/مصرف رویدادهای سفارشی گوش خواهید داد.

آنچه یاد خواهید گرفت

چشم‌انداز بلندمدت رویدادهای Cloud Run برای Anthos
وضعیت فعلی رویدادهای Cloud Run برای Anthos
یک سینک Cloud Run ایجاد کنید
یک تریگر رویداد برای Cloud Pub/Sub ایجاد کنید
ایجاد یک رویداد محرک برای گزارش‌های حسابرسی
ایجاد یک رویداد محرک برای فضای ذخیره‌سازی ابری
ایجاد یک محرک رویداد برای Cloud Scheduler
رویدادهای سفارشی را تولید و مصرف کنید

۲. چشم‌انداز بلندمدت

همانطور که ما معماری بدون سرور را اتخاذ می‌کنیم، رویدادها به بخش جدایی‌ناپذیری از نحوه ارتباط میکروسرویس‌های مستقل تبدیل می‌شوند. Events for Cloud Run for Anthos رویدادها را به یک عضو درجه یک از پیشنهاد Cloud Run for Anthos تبدیل می‌کند، به طوری که ساخت برنامه‌های بدون سرور مبتنی بر رویداد آسان است.

Events for Cloud Run برای Anthos، تحویل رویداد غیرهمزمان قابل اعتماد، ایمن و مقیاس‌پذیر را از منابع رویداد بسته‌بندی شده یا ایجاد شده توسط برنامه به مصرف‌کنندگان درون کلاستر و خارج از کلاستر امکان‌پذیر می‌کند.

منابع ابری گوگل	منابع رویدادی که متعلق به محصولات Google Cloud هستند
منابع گوگل	منابع رویداد که متعلق به محصولات گوگل هستند مانند Gmail، Hangouts، Android Management و موارد دیگر
منابع سفارشی	منابع رویدادی که متعلق به گوگل نیستند و توسط خود کاربران نهایی ایجاد می‌شوند. این منابع می‌توانند منابع توسعه‌یافته توسط کاربر Knative یا هر برنامه دیگری باشند که روی کلاستر اجرا می‌شود و می‌تواند یک رویداد ابری تولید کند.
منابع شخص ثالث	منابع رویدادی که نه متعلق به گوگل هستند و نه متعلق به کاربر نهایی. این شامل منابع رویداد محبوب مانند Github، SAP، Datadog، Pagerduty و غیره می‌شود که متعلق به ارائه دهندگان شخص ثالث، شرکا یا جوامع OSS هستند و توسط آنها نگهداری می‌شوند.

رویدادها برای قابلیت همکاری بین سرویس‌ها، به فرمت CloudEvents نسخه ۱.۰ نرمال‌سازی شده‌اند. CloudEvents یک استاندارد باز و بی‌طرف از نظر فروشنده است که داده‌های رویداد را در قالب‌های رایج توصیف می‌کند و امکان همکاری بین سرویس‌ها، پلتفرم‌ها و سیستم‌ها را فراهم می‌کند.

Events for Cloud Run با Knative Eventing سازگار است و امکان حمل کانتینرها را به و از سایر پیاده‌سازی‌های مبتنی بر Knative فراهم می‌کند. این یک چارچوب سازگار و مستقل از فضای ابری برای اتصال اعلانی تولیدکنندگان رویداد به مصرف‌کنندگان رویداد فراهم می‌کند.

۳. وضعیت فعلی

این پیش‌نمایش اولین نسخه‌ای است که مجموعه‌ای اولیه از قابلیت‌های بلندمدت را ارائه می‌دهد.

برای اینکه کاربران بتوانند برنامه‌های بدون سرور مبتنی بر رویداد بسازند، تمرکز اولیه ما بر دو چیز است:

ارائه یک اکوسیستم گسترده از منابع ابری گوگل که سرویس‌های Cloud Run را در کلاستر Anthos قادر می‌سازد تا به رویدادهای سرویس‌های ابری گوگل واکنش نشان دهند.

در ابتدا، رویدادهای منابع ابری گوگل از طریق گزارش‌های حسابرسی ابری (CAL) ارائه می‌شوند که امکان دسترسی به طیف وسیعی از منابع رویداد را فراهم می‌کند. تأخیر و در دسترس بودن تحویل رویداد از این منابع به گزارش‌های حسابرسی ابری وابسته است. هر زمان که رویدادی از یک منبع ابری گوگل منتشر می‌شود، یک ورودی گزارش حسابرسی ابری مربوطه ایجاد می‌شود.
در کنار گزارش‌های حسابرسی ابری، پشتیبانی درجه یکی برای مصرف رویدادها از فضای ذخیره‌سازی ابری، انتشار/زیرساخت ابری و زمان‌بندی ابری وجود دارد. ما با کسب اطلاعات بیشتر از سفر کاربران و بازخوردها، این اکوسیستم منابع را با منابع درجه یک‌تر گسترش خواهیم داد.

با انتشار در یک آدرس اینترنتی کارگزار محلی خوشه‌ایِ محدود به فضای نام، به برنامه‌ها و سرویس‌های کاربر نهایی این امکان را بدهید که رویدادهای سفارشی را منتشر کنند.

مکانیزم تحویل اساسی از موضوعات و اشتراک‌های Cloud Pub/Sub که در پروژه‌های مشتریان قابل مشاهده هستند، استفاده می‌کند. از این رو، این ویژگی همان تضمین‌های تحویل Cloud Pub/Sub را ارائه می‌دهد.

تریگر رویداد (Event Trigger) راهی برای اشتراک در رویدادها فراهم می‌کند تا رویدادهایی که با فیلتر تریگر مطابقت دارند، به مقصد (یا سینک) که تریگر به آن اشاره می‌کند، ارسال شوند.

همه رویدادها برای قابلیت همکاری متقابل در سرویس، در قالب Cloud Events v1.0 ارائه می‌شوند.

ما به ارائه ارزش بیشتر به شیوه‌ای تکرارشونده تا GA و فراتر از آن ادامه خواهیم داد.

۴. تنظیمات و الزامات

تنظیم محیط خودتنظیم

وارد Cloud Console شوید و یک پروژه جدید ایجاد کنید یا از یک پروژه موجود دوباره استفاده کنید. اگر از قبل حساب Gmail یا Google Workspace ندارید، باید یکی ایجاد کنید .

نام پروژه ، نام نمایشی شما برای این پروژه است. تا زمانی که از قراردادهای نامگذاری آن پیروی کنید، می‌توانید از هر چیزی که می‌خواهید استفاده کنید و آن را در هر زمانی به‌روزرسانی کنید.
شناسه پروژه باید در تمام پروژه‌های گوگل کلود منحصر به فرد باشد و تغییرناپذیر است (پس از تنظیم، قابل تغییر نیست). کنسول کلود به طور خودکار یک رشته منحصر به فرد تولید می‌کند؛ معمولاً برای شما مهم نیست که چیست. در اکثر آزمایشگاه‌های کد، باید به شناسه پروژه ارجاع دهید (و معمولاً با نام PROJECT_ID شناخته می‌شود)، بنابراین اگر آن را دوست ندارید، یک شناسه تصادفی دیگر ایجاد کنید، یا می‌توانید شناسه خودتان را امتحان کنید و ببینید آیا در دسترس است یا خیر. سپس پس از ایجاد پروژه، آن "منجمد" می‌شود.

در مرحله بعد، برای استفاده از منابع گوگل کلود، باید پرداخت را در Cloud Console فعال کنید .

اجرای این آزمایشگاه کد، اگر اصلاً هزینه‌ای نداشته باشد، نباید هزینه زیادی داشته باشد. حتماً دستورالعمل‌های بخش «پاکسازی» را که به شما نحوه خاموش کردن منابع را آموزش می‌دهد، دنبال کنید تا پس از این آموزش، متحمل هزینه نشوید. کاربران جدید Google Cloud واجد شرایط برنامه آزمایشی رایگان ۳۰۰ دلاری هستند.

شروع پوسته ابری

اگرچه می‌توان از راه دور و از طریق لپ‌تاپ، گوگل کلود را مدیریت کرد، اما در این آزمایشگاه کد، از گوگل کلود شل ، یک محیط خط فرمان که در فضای ابری اجرا می‌شود، استفاده خواهید کرد.

از کنسول GCP روی آیکون Cloud Shell در نوار ابزار بالا سمت راست کلیک کنید:

آماده‌سازی و اتصال به محیط فقط چند لحظه طول می‌کشد. وقتی تمام شد، باید چیزی شبیه به این را ببینید:

این ماشین مجازی مجهز به تمام ابزارهای توسعه مورد نیاز شماست. این ماشین یک دایرکتوری خانگی دائمی ۵ گیگابایتی ارائه می‌دهد و روی فضای ابری گوگل اجرا می‌شود که عملکرد شبکه و احراز هویت را تا حد زیادی بهبود می‌بخشد. تمام کارهای شما در این آزمایشگاه را می‌توان به سادگی با یک مرورگر انجام داد.

۵. فعال کردن APIها، تنظیم منطقه و پلتفرم

تنظیم شناسه پروژه و نصب اجزای آلفا

در داخل Cloud Shell، GOOGLE_CLOUD_PROJECT باید از قبل روی شناسه پروژه شما تنظیم شده باشد. اگر اینطور نیست، مطمئن شوید که تنظیم شده است و gcloud شما با آن شناسه پروژه پیکربندی شده است:

export GOOGLE_CLOUD_PROJECT=your-project-id
gcloud config set project ${GOOGLE_CLOUD_PROJECT}

مطمئن شوید که کامپوننت gcloud برای آلفا نصب شده است:

gcloud components install alpha

فعال کردن APIها

فعال کردن تمام سرویس‌های لازم:

gcloud services enable cloudapis.googleapis.com 
gcloud services enable container.googleapis.com 
gcloud services enable containerregistry.googleapis.com
gcloud services enable cloudbuild.googleapis.com

منطقه و پلتفرم را تنظیم کنید

قبل از ایجاد یک کلاستر GKE با Cloud Run Events، نام کلاستر، منطقه و پلتفرم را تنظیم کنید. به عنوان مثال، در اینجا ما نام و منطقه را events-cluster و europe-west1-b و پلتفرم را gke,

در پوسته ابری:

export CLUSTER_NAME=events-cluster
export CLUSTER_ZONE=europe-west1-b

gcloud config set run/cluster ${CLUSTER_NAME}
gcloud config set run/cluster_location ${CLUSTER_ZONE}
gcloud config set run/platform gke

می‌توانید بررسی کنید که پیکربندی تنظیم شده است:

gcloud config list

...
[run]
cluster = events-cluster
cluster_location = europe-west1-b
platform = gke

۶. ایجاد یک خوشه GKE با Cloud Run Events

یک کلاستر GKE ایجاد کنید که Kubernetes >= 1.15.9-gke.26 را اجرا کند و افزونه‌های زیر را فعال کنید: CloudRun ، HttpLoadBalancing ، HorizontalPodAutoscaling :

gcloud beta container clusters create ${CLUSTER_NAME} \
  --addons=HttpLoadBalancing,HorizontalPodAutoscaling,CloudRun \
  --machine-type=n1-standard-4 \
  --enable-autoscaling --min-nodes=3 --max-nodes=10 \
  --no-issue-client-certificate --num-nodes=3 --image-type=cos \
  --enable-stackdriver-kubernetes \
  --scopes=cloud-platform,logging-write,monitoring-write,pubsub \
  --zone ${CLUSTER_ZONE} \
  --release-channel=rapid

۷. راه‌اندازی رویدادهای Cloud Run (صفحه کنترل)

رویدادهای Cloud Run دارای یک صفحه کنترل (Control Plane) و یک صفحه داده (Data Plane) هستند که باید جداگانه تنظیم شوند. برای تنظیم صفحه کنترل:

در پوسته ابری:

gcloud beta events init

این کار رویدادسازی را آغاز می‌کند و همچنین تعدادی حساب سرویس مورد نیاز را ایجاد می‌کند. هنگام درخواست ایجاد حساب سرویس، مطمئن شوید که «بله» را انتخاب می‌کنید.

در این مرحله، صفحه کنترل باید به درستی مقداردهی اولیه شده باشد. شما باید چهار پاد با ... ببینید.

وضعیت Running ، ۲ ( controller-xxx-xxx و webhook-xxx-xxx ) در فضای نام cloud-run-events و ۲ ( eventing-controller-xxx-xxx و eventing-webhook-xxx-xxx ) در فضای نام knative-eventing . می‌توانید با اجرای دستورات زیر بررسی کنید:

kubectl get pods -n cloud-run-events

NAME                         READY   STATUS    RESTARTS   AGE
controller-9cc679b67-2952n   1/1     Running   0          22s
webhook-8576c4cfcb-dhz82     1/1     Running   0          16m

kubectl get pods -n knative-eventing

NAME                                   READY   STATUS    RESTARTS   AGE
eventing-controller-77f46f6cf8-kj9ck   1/1     Running   0          17m
eventing-webhook-5bc787965f-hcmwg      1/1     Running   0          17m

۸. راه‌اندازی رویدادهای Cloud Run (صفحه داده)

مرحله بعدی، تنظیم صفحه داده در فضاهای نام کاربر است. این کار یک کارگزار (Broker) با مجوزهای مناسب برای خواندن/نوشتن از/به Pub/Sub ایجاد می‌کند.

درون Cloud Shell، یک متغیر محیطی NAMESPACE برای فضای نامی که می‌خواهید برای اشیاء خود استفاده کنید، تنظیم کنید. اگر می‌خواهید از فضای نام پیش‌فرض استفاده کنید، می‌توانید آن را به default تنظیم کنید، همانطور که در زیر نشان داده شده است:

export NAMESPACE=default

توجه داشته باشید که اگر فضای نام مشخص شده وجود ندارد (یعنی فضای نام پیش‌فرض نیست)، باید آن را ایجاد کنید:

kubectl create namespace ${NAMESPACE}

فضای نام را با رمز پیش‌فرض مقداردهی اولیه کنید:

gcloud beta events namespaces init ${NAMESPACE} --copy-default-secret

یک کارگزار پیش‌فرض در فضای نام ایجاد کنید:

gcloud beta events brokers create default --namespace ${NAMESPACE}

بررسی کنید که کارگزار ایجاد شده باشد. توجه داشته باشید که ممکن است چند ثانیه طول بکشد تا کارگزار آماده شود:

kubectl get broker -n ${NAMESPACE}

NAME      READY   REASON   URL
default   True             http://default-brokercell-ingress.cloud-run-events.svc.cluster.local/default/default

۹. کشف رویداد

شما می‌توانید کشف کنید که منابع ثبت‌شده چه هستند، چه نوع رویدادهایی می‌توانند منتشر کنند و چگونه تریگرها را برای مصرف آنها پیکربندی کنید.

برای مشاهده لیست انواع مختلف رویدادها:

gcloud beta events types list

برای کسب اطلاعات بیشتر در مورد هر نوع رویداد:

gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished

۱۰. یک سینک ابری ایجاد کنید

به عنوان یک سینک رویداد، یک سرویس Cloud Run را مستقر کنید که محتوای CloudEvent دریافتی را ثبت می‌کند.

می‌توانید از event_display مربوط به Knative که از قبل کامپایل شده و تصویر کانتینر آن به عنوان بخشی از انتشار Knative ساخته شده است، استفاده کنید. می‌توانید جزئیات تصویر کانتینر را در event-display.yaml مشاهده کنید:

...
containers:
  - image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27

استقرار در Cloud Run

برنامه کانتینر شده خود را روی Cloud Run مستقر کنید:

export SERVICE_NAME=event-display
gcloud run deploy ${SERVICE_NAME} \
  --namespace=${NAMESPACE} \
  --image gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27

در صورت موفقیت، خط فرمان URL سرویس را نمایش می‌دهد. اکنون می‌توانید با باز کردن URL سرویس در هر پنجره مرورگری، کانتینر مستقر شده خود را مشاهده کنید.

۱۱. یک تریگر رویداد برای Cloud Pub/Sub ایجاد کنید

یکی از راه‌های دریافت رویدادها از طریق Cloud Pub/Sub است. برنامه‌های سفارشی می‌توانند پیام‌هایی را در Cloud Pub/Sub منتشر کنند و این پیام‌ها می‌توانند از طریق Events for Cloud Run به سینک‌های Google Cloud Run ارسال شوند.

ایجاد تاپیک

ابتدا، یک موضوع Cloud Pub/Sub ایجاد کنید. می‌توانید TOPIC_ID با یک نام موضوع منحصر به فرد که ترجیح می‌دهید جایگزین کنید:

export TOPIC_ID=cr-gke-topic
gcloud pubsub topics create ${TOPIC_ID}

یک تریگر ایجاد کنید

قبل از ایجاد تریگر، جزئیات بیشتری در مورد پارامترهایی که برای ساخت تریگر برای رویدادها از Cloud Pub/Sub نیاز دارید، کسب کنید:

gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished

یک تریگر برای فیلتر کردن رویدادهای منتشر شده در موضوع Cloud Pub/Sub به سرویس Cloud Run مستقر شده ما ایجاد کنید:

gcloud beta events triggers create trigger-pubsub \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type google.cloud.pubsub.topic.v1.messagePublished \
  --parameters topic=${TOPIC_ID}

تریگر را آزمایش کنید

می‌توانید با فهرست کردن تمام تریگرها، ایجاد شدن تریگر را بررسی کنید:

gcloud beta events triggers list

ممکن است لازم باشد تا 10 دقیقه صبر کنید تا ایجاد تریگر منتشر شود و شروع به فیلتر کردن رویدادها کند.

برای شبیه‌سازی ارسال پیام توسط یک برنامه‌ی سفارشی، می‌توانید gcloud برای ایجاد یک رویداد استفاده کنید:

gcloud pubsub topics publish ${TOPIC_ID} --message="Hello there"

سینک Cloud Run که ما ایجاد کردیم، بدنه پیام ورودی را ثبت می‌کند. می‌توانید این را در بخش Logs نمونه Cloud Run خود مشاهده کنید:

۹۵۲۶۹۰۹a۰۶c۶d۴f۴.png

توجه داشته باشید که عبارت "Hello there" به صورت base64 کدگذاری شده است، زیرا توسط Pub/Sub ارسال شده است و اگر می‌خواهید پیام اصلی ارسال شده را ببینید، باید آن را رمزگشایی کنید.

تریگر را حذف کنید

به صورت اختیاری، می‌توانید پس از انجام آزمایش، تریگر را حذف کنید.

gcloud beta events triggers delete trigger-pubsub --namespace ${NAMESPACE}

۱۲. یک تریگر رویداد برای گزارش‌های حسابرسی ایجاد کنید

شما یک تریگر برای گوش دادن به رویدادها از گزارش‌های حسابرسی تنظیم خواهید کرد. به طور خاص، شما به دنبال رویدادهای ایجاد موضوع Pub/Sub در گزارش‌های حسابرسی خواهید بود.

فعال کردن گزارش‌های حسابرسی

برای دریافت رویدادها از یک سرویس، باید گزارش‌های حسابرسی را فعال کنید. از کنسول ابری، از منوی سمت چپ بالا IAM & Admin > Audit Logs انتخاب کنید. در لیست سرویس‌ها، Google Cloud Pub/Sub را علامت بزنید:

در سمت راست، مطمئن شوید که گزینه‌های Admin، Read و Write انتخاب شده‌اند. روی ذخیره کلیک کنید:

گزارش‌های حسابرسی تست

برای یادگیری نحوه شناسایی پارامترها، باید یک تریگر واقعی تنظیم کنید و یک عملیات واقعی انجام دهید.

برای مثال، یک موضوع Pub/Sub ایجاد کنید:

gcloud pubsub topics create cre-gke-topic1

حالا، بیایید ببینیم این به‌روزرسانی چه نوع گزارش حسابرسی ایجاد کرده است. از کنسول ابری، از منوی سمت چپ بالا، گزینه Logging > Logs Viewer را انتخاب کنید.

در قسمت Query Builder, گزینه Cloud Pub/Sub Topic را انتخاب کنید و روی Add کلیک کنید:

پس از اجرای کوئری، گزارش‌هایی برای موضوعات Pub/Sub مشاهده خواهید کرد و یکی از آنها باید google.pubsub.v1.Publisher.CreateTopic باشد:

به serviceName ، methodName و resourceName توجه کنید. ما از این موارد در ایجاد trigger استفاده خواهیم کرد.

یک تریگر ایجاد کنید

اکنون آماده‌اید تا یک محرک رویداد برای گزارش‌های حسابرسی (Audit Logs) ایجاد کنید.

با اجرای دستور زیر می‌توانید جزئیات بیشتری در مورد پارامترهای مورد نیاز برای ساخت یک تریگر برای رویدادها از منابع Google Cloud دریافت کنید:

gcloud beta events types describe google.cloud.audit.log.v1.written

با فیلترهای مناسب، محرک را ایجاد کنید:

gcloud beta events triggers create trigger-auditlog \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=google.cloud.audit.log.v1.written \
  --parameters serviceName=pubsub.googleapis.com \
  --parameters methodName=google.pubsub.v1.Publisher.CreateTopic

تریگر را آزمایش کنید

برای تأیید اینکه تریگر با موفقیت ایجاد شده است، تمام تریگرها را فهرست کنید:

gcloud beta events triggers list

تا 10 دقیقه صبر کنید تا ایجاد تریگر منتشر شود و شروع به فیلتر کردن رویدادها کند. پس از آماده شدن، رویدادهای ایجاد شده را فیلتر کرده و آنها را به سرویس ارسال می‌کند. اکنون آماده اجرای یک رویداد هستید.

همانطور که قبلاً انجام دادید، یک موضوع انتشار/زیرموضوع دیگر ایجاد کنید:

gcloud pubsub topics create cre-gke-topic2

اگر گزارش‌های سرویس Cloud Run را در Cloud Console بررسی کنید، باید رویداد دریافتی را مشاهده کنید:

تریگر و موضوعات را حذف کنید

به صورت اختیاری، می‌توانید پس از انجام آزمایش، تریگر را حذف کنید:

gcloud beta events triggers delete trigger-auditlog

همچنین تاپیک ها را حذف کنید:

gcloud pubsub topics delete cre-gke-topic1 cre-gke-topic2

۱۳. ایجاد یک رویداد (Event trigger) برای فضای ذخیره‌سازی ابری

شما یک تریگر (trigger) برای دریافت رویدادها از فضای ذخیره‌سازی ابری (Cloud Storage) تنظیم خواهید کرد.

یک سطل ایجاد کنید

ابتدا، یک مخزن ذخیره‌سازی ابری (Cloud Storage bucket) در همان منطقه‌ای که سرویس Cloud Run مستقر شده است، ایجاد کنید. می‌توانید BUCKET_NAME با یک نام منحصر به فرد که ترجیح می‌دهید جایگزین کنید:

export BUCKET_NAME=[new bucket name]
export REGION=europe-west1

gsutil mb -p $(gcloud config get-value project) \
  -l $REGION \
  gs://$BUCKET_NAME/

مجوزهای ذخیره‌سازی ابری را تنظیم کنید

قبل از ایجاد یک تریگر، باید به حساب سرویس پیش‌فرض برای ذخیره‌سازی ابری، اجازه انتشار در Pub/Sub را بدهید.

ابتدا، باید حساب سرویسی را که Cloud Storage برای انتشار در Pub/Sub استفاده می‌کند، پیدا کنید. می‌توانید از مراحل ذکر شده در «دریافت حساب سرویس Cloud Storage» برای دریافت حساب سرویس استفاده کنید یا از دستور زیر استفاده کنید:

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://storage.googleapis.com/storage/v1/projects/$(gcloud config get-value project)/serviceAccount"

حساب کاربری سرویس باید در زیر email_address فهرست شده باشد.

فرض کنید حساب سرویسی که از بالا پیدا کردید service-XYZ@gs-project-accounts.iam.gserviceaccount.com بود، این را روی یک متغیر محیطی تنظیم کنید:

export GCS_SERVICE_ACCOUNT=service-XYZ@gs-project-accounts.iam.gserviceaccount.com

سپس، به آن حساب سرویس، حق انتشار در Pub/Sub را اعطا کنید:

gcloud projects add-iam-policy-binding ${GOOGLE_CLOUD_PROJECT} \
  --member=serviceAccount:${GCS_SERVICE_ACCOUNT} \
  --role roles/pubsub.publisher

یک تریگر ایجاد کنید

اکنون آماده‌اید تا یک محرک رویداد برای رویدادهای ذخیره‌سازی ابری ایجاد کنید.

می‌توانید جزئیات بیشتری در مورد پارامترهای مورد نیاز برای ساخت تریگر دریافت کنید:

gcloud beta events types describe google.cloud.storage.object.v1.finalized

با فیلترهای مناسب، محرک را ایجاد کنید:

gcloud beta events triggers create trigger-storage \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=google.cloud.storage.object.v1.finalized \
  --parameters bucket=${BUCKET_NAME}

تریگر را آزمایش کنید

برای تأیید اینکه تریگر با موفقیت ایجاد شده است، تمام تریگرها را فهرست کنید:

gcloud beta events triggers list

تا 10 دقیقه صبر کنید تا ایجاد تریگر منتشر شود و شروع به فیلتر کردن رویدادها کند. پس از آماده شدن، رویدادهای ایجاد شده را فیلتر کرده و آنها را به سرویس ارسال می‌کند.

اکنون آماده‌ی راه‌اندازی یک رویداد هستید.

یک فایل تصادفی را در فضای ذخیره‌سازی ابری آپلود کنید:

echo "Hello World" > random.txt
gsutil cp random.txt gs://${BUCKET_NAME}/random.txt

اگر گزارش‌های سرویس Cloud Run را در Cloud Console بررسی کنید، باید رویداد دریافتی را مشاهده کنید:

تریگر را حذف کنید

به صورت اختیاری، می‌توانید پس از انجام آزمایش، تریگر را حذف کنید:

gcloud beta events triggers delete trigger-storage

۱۴. یک محرک رویداد برای Cloud Scheduler ایجاد کنید

شما یک تریگر (trigger) برای گوش دادن به رویدادها از Cloud Scheduler تنظیم خواهید کرد.

یک برنامه App Engine ایجاد کنید

در حال حاضر، Cloud Scheduler نیاز دارد که کاربران یک برنامه App Engine ایجاد کنند. یک مکان برای App Engine انتخاب کنید و برنامه را ایجاد کنید:

export APP_ENGINE_LOCATION=europe-west
gcloud app create --region=${APP_ENGINE_LOCATION}

یک تریگر ایجاد کنید

gcloud beta events types describe google.cloud.scheduler.job.v1.executed

برای ایجاد زمانبند، یک مکان برای زمانبند ابری انتخاب کنید:

export SCHEDULER_LOCATION=europe-west1

یک Trigger ایجاد کنید که یک job ایجاد کند که هر دقیقه در Google Cloud Scheduler اجرا شود و سرویس هدف را فراخوانی کند:

gcloud beta events triggers create trigger-scheduler \
  --namespace ${NAMESPACE} \
  --target-service=${SERVICE_NAME} \
  --type=google.cloud.scheduler.job.v1.executed \
  --parameters location=${SCHEDULER_LOCATION} \
  --parameters schedule="* * * * *" \
  --parameters data="trigger-scheduler-data"

تریگر را آزمایش کنید

برای تأیید اینکه تریگر با موفقیت ایجاد شده است، تمام تریگرها را فهرست کنید:

gcloud beta events triggers list

اگر لاگ‌های سرویس Cloud Run را در Cloud Console بررسی کنید، باید رویداد دریافتی را مشاهده کنید.

تریگر را حذف کنید

به صورت اختیاری، می‌توانید پس از انجام آزمایش، تریگر را حذف کنید:

gcloud beta events triggers delete trigger-scheduler

۱۵. رویدادهای سفارشی (نقطه پایانی کارگزار)

در این بخش از آزمایشگاه کد، شما با استفاده از Broker رویدادهای سفارشی تولید و استفاده خواهید کرد.

ایجاد Curl Pod برای تولید رویدادها

رویدادها معمولاً به صورت برنامه‌نویسی‌شده ایجاد می‌شوند. با این حال، در این مرحله، شما curl برای ارسال دستی رویدادهای منفرد و مشاهده نحوه دریافت این رویدادها توسط مصرف‌کننده صحیح استفاده خواهید کرد.

برای ایجاد یک Pod که به عنوان تولیدکننده رویداد عمل می‌کند، دستور زیر را اجرا کنید:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: curl
  name: curl
  namespace: $NAMESPACE
spec:
  containers:
  - image: radial/busyboxplus:curl
    imagePullPolicy: IfNotPresent
    name: curl
    resources: {}
    stdin: true
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    tty: true
EOF

تأیید کنید که curl Pod به درستی کار می‌کند. باید یک pod به نام curl با Status=Running ببینید:

kubectl get pod curl -n ${NAMESPACE}

یک تریگر ایجاد کنید

شما یک Trigger با یک فیلتر روی نوع CloudEvents خاص (در این مورد alpha-type ) که منتشر می‌کنید، ایجاد خواهید کرد. توجه داشته باشید که فیلتر کردن تطابق دقیق روی هر تعداد از ویژگی‌های CloudEvents و همچنین افزونه‌ها پشتیبانی می‌شود. اگر فیلتر شما چندین ویژگی را تنظیم کند، یک رویداد باید تمام ویژگی‌های Trigger را برای فیلتر کردن آن داشته باشد. برعکس، اگر فیلتری مشخص نکنید، تمام رویدادها در سرویس شما دریافت می‌شوند.

تریگر را ایجاد کنید:

gcloud beta events triggers create trigger-custom \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=alpha-type \
  --custom-type

تریگر را آزمایش کنید

برای تأیید اینکه تریگر با موفقیت ایجاد شده است، تمام تریگرها را فهرست کنید:

gcloud beta events triggers list

با ارسال یک درخواست HTTP به Broker، یک رویداد ایجاد کنید. با اجرای دستور زیر، آدرس اینترنتی Broker را به خودتان یادآوری کنید:

kubectl get brokers -n ${NAMESPACE}

NAME      READY   REASON   URL
default   True             http://default-broker.<NAMESPACE>.svc.cluster.local

با استفاده از SSH به curl Pod که قبلاً ایجاد کردید، دسترسی پیدا کنید:

kubectl --namespace ${NAMESPACE} attach curl -it

شما به پاد SSH متصل شده‌اید و اکنون می‌توانید درخواست HTTP ارسال کنید. پیامی مشابه تصویر زیر ظاهر می‌شود:

Defaulting container name to curl.
Use 'kubectl describe pod/curl -n default' to see all of the containers in this pod.
If you don't see a command prompt, try pressing enter.
[ root@curl:/ ]$

ایجاد یک رویداد:

curl -v "<BROKER-URL>" \
-X POST \
-H "Ce-Id: my-id" \
-H "Ce-Specversion: 1.0" \
-H "Ce-Type: alpha-type" \
-H "Ce-Source: my-source" \
-H "Content-Type: application/json" \
-d '{"msg":"send-cloudevents-to-broker"}'

اگر رویداد دریافت شده باشد، پاسخ HTTP 202 Accepted دریافت خواهید کرد. با Ctrl + D از جلسه SSH خارج شوید.

با بررسی گزارش‌های سرویس Cloud Run، تأیید کنید که رویداد منتشر شده ارسال شده است:

kubectl logs --selector serving.knative.dev/service=$SERVICE_NAME \
 -c user-container -n $NAMESPACE --tail=100

تریگر را حذف کنید

به صورت اختیاری، می‌توانید پس از انجام آزمایش، تریگر را حذف کنید:

gcloud beta events triggers delete trigger-custom

۱۶. تبریک می‌گویم!

تبریک می‌گویم که آزمایشگاه کد را تمام کردی.

آنچه ما پوشش داده‌ایم

چشم‌انداز بلندمدت رویدادهای Cloud Run برای Anthos
وضعیت فعلی رویدادهای Cloud Run برای Anthos
یک سینک Cloud Run ایجاد کنید
یک تریگر رویداد برای Cloud Pub/Sub ایجاد کنید
ایجاد یک رویداد محرک برای گزارش‌های حسابرسی
ایجاد یک رویداد محرک برای فضای ذخیره‌سازی ابری
ایجاد یک محرک رویداد برای Cloud Scheduler
رویدادهای سفارشی را تولید و مصرف کنید