이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Cloud Run for Anthos Codelab 이벤트

1. 소개

Cloud Run을 사용하면 완전 관리형 환경에서 스테이트리스(Stateless) 컨테이너를 실행할 수 있습니다. 오픈소스 Knative로 빌드되었으므로 컨테이너를 Cloud Run으로 완전 관리형으로 실행하거나 Cloud Run for Anthos를 통해 Google Kubernetes Engine 클러스터에서 실행할 수 있습니다.

Cloud Run for Anthos 이벤트를 사용하면 다양한 소스의 이벤트와 Cloud Run 서비스를 쉽게 연결할 수 있습니다. 마이크로서비스가 느슨하게 결합 및 분산된 이벤트 기반 아키텍처를 빌드할 수 있습니다. 또한 이벤트 수집, 전송, 보안, 승인, 오류 처리를 처리하여 개발자의 민첩성과 애플리케이션 복원력을 향상시킵니다.

이 Codelab에서는 Cloud Run for Anthos용 이벤트에 대해 알아봅니다. 구체적으로는 Cloud Pub/Sub, 감사 로그, Cloud Storage, Cloud Scheduler의 이벤트를 수신 대기하고 커스텀 이벤트의 생성/사용 방법을 알아봅니다.

학습할 내용

Cloud Run for Anthos 이벤트의 장기적 비전
Cloud Run for Anthos 이벤트의 현재 상태
Cloud Run 싱크 만들기
Cloud Pub/Sub에 대한 이벤트 트리거 만들기
감사 로그에 대한 이벤트 트리거 만들기
Cloud Storage용 이벤트 트리거 만들기
Cloud Scheduler에 대한 이벤트 트리거 만들기
맞춤 이벤트 생성 및 사용

2. 장기 비전

서버리스 아키텍처를 도입함에 따라 이벤트는 분리된 마이크로서비스 통신 방식의 필수 요소가 됩니다. Cloud Run for Anthos용 이벤트는 이벤트를 Cloud Run for Anthos 제품의 최우선 사용자로 만들어 이벤트 기반 서버리스 애플리케이션을 쉽게 빌드할 수 있게 해줍니다.

Cloud Run for Anthos용 이벤트는 패키지 또는 앱에서 만든 이벤트 소스에서 클러스터 내 및 클러스터 외 소비자에게 안정적이고 안전하며 확장 가능한 비동기 이벤트 전송을 지원합니다.

Google Cloud 소스	Google Cloud 소유 제품인 이벤트 소스
Google 소스	Gmail, 행아웃, Android 관리 등 Google 소유 제품인 이벤트 소스
맞춤 소스	Google 소유 제품이 아니며 최종 사용자가 직접 생성한 이벤트 소스입니다. 이러한 앱은 사용자가 개발한 Knative Sources나 클러스터에서 실행되는 기타 앱일 수 있으며 Cloud 이벤트를 생성할 수 있습니다.
서드 파티 소스	Google 소유도, 최종 사용자 소유도 아닌 이벤트 소스입니다. 여기에는 서드 파티 제공업체, 파트너 또는 OSS 커뮤니티에서 소유하고 유지 관리하는 GitHub, SAP, Datadog, Pagerduty 등 인기 있는 이벤트 소스가 포함됩니다.

이벤트는 교차 서비스 상호 운용성을 위해 CloudEvents v1.0 형식으로 정규화됩니다. CloudEvents는 일반적인 형식으로 이벤트 데이터를 설명하는 공급업체 중립적인 개방형 사양으로, 서비스, 플랫폼, 시스템 간의 상호 운용성을 지원합니다.

Cloud Run용 이벤트는 Knative Eventing을 준수하며 다른 Knative 기반 구현 간에 컨테이너를 자유롭게 이식할 수 있습니다. 이는 이벤트 제작자와 이벤트 소비자를 선언적으로 연결할 수 있도록 클라우드에 구애받지 않는 일관된 프레임워크를 제공합니다.

3. 현재 상태

이 미리보기는 장기 기능의 초기 세트를 제공하는 첫 번째 버전입니다.

사용자가 이벤트 기반 서버리스 애플리케이션을 빌드할 수 있도록 하기 위해 처음에 중점을 두는 부분은 두 가지입니다.

Anthos 클러스터의 Cloud Run 서비스가 Google Cloud 서비스의 이벤트에 반응할 수 있도록 광범위한 Google Cloud 소스 생태계를 제공합니다.

처음에는 Google Cloud 소스의 이벤트가 Cloud 감사 로그 (CAL)를 통해 전송되므로 다양한 이벤트 소스를 사용할 수 있습니다. 이러한 소스의 이벤트 전송 지연 시간과 가용성은 Cloud 감사 로그의 지연 시간과 가용성과 관련이 있습니다. Google Cloud 소스의 이벤트가 게시될 때마다 해당하는 Cloud 감사 로그 항목이 생성됩니다.
Cloud 감사 로그와 함께 Cloud Storage, Cloud Pub/Sub, Cloud Scheduler의 이벤트를 사용하는 최고 수준의 지원이 제공됩니다. Google은 사용자 여정과 의견을 통해 더 많은 것을 배우면서 더 많은 최고의 소스를 통해 이 소스 생태계를 계속 확장해 나갈 것입니다.

네임스페이스 범위 클러스터 로컬 브로커 URL에 게시하여 최종 사용자 애플리케이션 및 서비스에서 맞춤 이벤트를 내보낼 수 있습니다.

기본 제공 메커니즘은 고객의 살펴보겠습니다 따라서 이 기능은 Cloud Pub/Sub와 동일한 전송 보장을 제공합니다.

이벤트 트리거를 사용하면 트리거 필터와 일치하는 이벤트가 트리거가 가리키는 대상 (또는 싱크)으로 전달되도록 이벤트를 구독할 수 있습니다.

모든 이벤트는 교차 서비스 상호 운용성을 위해 Cloud Events v1.0 형식으로 전송됩니다.

Google은 GA에 이르기까지 계속해서 더 많은 가치를 반복적으로 제공할 것입니다.

4. 설정 및 요구사항

자습형 환경 설정

Cloud 콘솔에 로그인하고 새 프로젝트를 만들거나 기존 프로젝트를 다시 사용합니다. 아직 Gmail이나 Google Workspace 계정이 없는 경우 계정을 만들어야 합니다.

프로젝트 이름은 이 프로젝트의 표시 이름입니다. 이름 지정 규칙을 따르기만 하면 원하는 것을 사용할 수 있고 언제든지 업데이트할 수 있습니다.
프로젝트 ID는 모든 Google Cloud 프로젝트에서 고유해야 하며 변경할 수 없습니다 (한 번 설정되면 변경할 수 없음). Cloud 콘솔이 고유한 문자열을 자동으로 생성합니다. 보통은 그게 뭔지 상관하지 않습니다. 대부분의 Codelab에서는 프로젝트 ID (일반적으로 PROJECT_ID로 식별됨)를 참조해야 하므로 마음에 들지 않는 경우 무작위로 다른 ID를 생성하거나 직접 시도해 보고 사용 가능한지 확인할 수 있습니다. 그런 다음 '고정'됩니다. 프로젝트 이름을 지정합니다

그런 후 Google Cloud 리소스를 사용할 수 있도록 Cloud Console에서 결제를 사용 설정해야 합니다.

이 Codelab 실행에는 많은 비용이 들지 않습니다. 이 가이드를 마친 후 비용이 결제되지 않도록 리소스 종료 방법을 알려주는 '삭제' 섹션의 안내를 따르세요. Google Cloud 신규 사용자에게는 미화$300 상당의 무료 체험판 프로그램에 참여할 수 있는 자격이 부여됩니다.

Cloud Shell 시작

Google Cloud를 노트북에서 원격으로 실행할 수 있지만, 이 Codelab에서는 Cloud에서 실행되는 명령줄 환경인 Google Cloud Shell을 사용합니다.

GCP 콘솔에서 오른쪽 상단 툴바의 Cloud Shell 아이콘을 클릭합니다.

환경을 프로비저닝하고 연결하는 데 몇 분 정도 소요됩니다. 완료되면 다음과 같이 표시됩니다.

가상 머신에는 필요한 개발 도구가 모두 들어있습니다. 영구적인 5GB 홈 디렉토리를 제공하고 Google Cloud에서 실행되므로 네트워크 성능과 인증이 크게 개선됩니다. 이 실습의 모든 작업은 브라우저만으로 수행할 수 있습니다.

5. API 사용 설정, 영역 및 플랫폼 설정

프로젝트 ID 설정 및 알파 구성요소 설치

Cloud Shell 내에서 GOOGLE_CLOUD_PROJECT가 이미 프로젝트 ID로 설정되어 있어야 합니다. 그렇지 않은 경우 이 속성이 설정되어 있고 해당 프로젝트 ID로 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

영역 및 플랫폼 설정

Cloud Run 이벤트로 GKE 클러스터를 만들기 전에 클러스터 이름, 영역, 플랫폼을 설정합니다. 예를 들어 여기서는 이름과 영역을 events-cluster 및 europe-west1-b로 설정하고 플랫폼은 gke,입니다.

Cloud Shell에서 다음을 실행합니다.

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

6. Cloud Run 이벤트로 GKE 클러스터 만들기

CloudRun, HttpLoadBalancing, HorizontalPodAutoscaling 부가기능이 사용 설정된 상태로 Kubernetes 이상 1.15.9-gke.26를 실행하는 GKE 클러스터를 만듭니다.

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

7. Cloud Run 이벤트 설정 (제어 영역)

Cloud Run 이벤트에는 별도로 설정해야 하는 제어 영역과 데이터 영역이 있습니다. 제어 영역을 설정하려면 다음 안내를 따르세요.

Cloud Shell에서 다음을 실행합니다.

gcloud beta events init

이렇게 하면 이벤트가 초기화되고 필요한 여러 서비스 계정도 생성됩니다. '예'를 선택해야 합니다. 서비스 계정을 생성하라는 메시지가 표시되면

이 시점에서 제어 영역이 적절하게 초기화되어야 합니다. 각 포드의 4개의 포드가

Running 상태, cloud-run-events 네임스페이스에서 2 (controller-xxx-xxx 및 webhook-xxx-xxx), knative-eventing 네임스페이스에서 2 (eventing-controller-xxx-xxx 및 eventing-webhook-xxx-xxx) 다음 명령어를 실행하여 확인할 수 있습니다.

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

8. Cloud Run 이벤트 설정 (데이터 영역)

다음은 사용자 네임스페이스에 데이터 영역을 설정하는 것입니다. 그러면 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

9. 이벤트 검색

등록된 소스 정의, 소스에서 내보낼 수 있는 이벤트 유형, 이러한 소스를 사용하기 위해 트리거를 구성하는 방법을 살펴볼 수 있습니다.

다양한 이벤트 유형 목록을 보는 방법은 다음과 같습니다.

gcloud beta events types list

각 이벤트 유형에 대해 자세히 알아보려면 다음 단계를 따르세요.

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

10. Cloud Run 싱크 만들기

이벤트 싱크로 수신하는 CloudEvent의 콘텐츠를 기록하는 Cloud Run 서비스를 배포합니다.

이미 컴파일된 Knative의 event_display와 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을 열어 배포된 컨테이너로 이동할 수 있습니다.

11. Cloud Pub/Sub에 대한 이벤트 트리거 만들기

이벤트를 수신하는 한 가지 방법은 Cloud Pub/Sub를 사용하는 것입니다. 커스텀 애플리케이션은 Cloud Pub/Sub에 메시지를 게시할 수 있으며 이러한 메시지는 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 싱크는 수신 메시지의 본문을 로깅합니다. Cloud Run 인스턴스의 로그 섹션에서 확인할 수 있습니다.

'Hello there' Pub/Sub에서 전송한 대로 base64로 인코딩되므로 전송된 원본 메시지를 보려면 디코딩해야 합니다.

트리거 삭제

원하는 경우 테스트가 완료되면 트리거를 삭제할 수 있습니다.

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

12. 감사 로그에 대한 이벤트 트리거 만들기

감사 로그의 이벤트를 리슨하도록 트리거를 설정합니다. 구체적으로는 감사 로그에서 Pub/Sub 주제 생성 이벤트를 찾습니다.

감사 로그 사용 설정

서비스에서 이벤트를 수신하려면 감사 로그를 사용 설정해야 합니다. Cloud 콘솔의 왼쪽 상단 메뉴에서 IAM & Admin > Audit Logs를 선택합니다. 서비스 목록에서 Google Cloud Pub/Sub를 확인합니다.

오른쪽에서 관리, 읽기, 쓰기가 선택되어 있는지 확인합니다. 저장을 클릭합니다.

테스트 감사 로그

실제 트리거를 설정하는 데 필요한 매개변수를 식별하는 방법을 알아보려면 실제 작업을 실행하세요.

예를 들어 Pub/Sub 주제를 만듭니다.

gcloud pubsub topics create cre-gke-topic1

이제 이 업데이트로 인해 어떤 종류의 감사 로그가 생성되었는지 확인해 보겠습니다. Cloud 콘솔의 왼쪽 상단 메뉴에서 Logging > Logs Viewer를 선택합니다.

Query Builder, 아래에서 Cloud Pub/Sub Topic을 선택하고 Add를 클릭합니다.

쿼리를 실행하면 Pub/Sub 주제에 대한 로그가 표시되며 그중 하나는 google.pubsub.v1.Publisher.CreateTopic여야 합니다.

serviceName, methodName, resourceName를 확인합니다. 이 값은 트리거를 만들 때 사용됩니다.

트리거 만들기

이제 감사 로그에 대한 이벤트 트리거를 만들 준비가 되었습니다.

다음 명령어를 실행하여 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분 정도 기다립니다. 준비되면 생성 이벤트를 필터링하고 서비스로 전송합니다. 이제 이벤트를 실행할 준비가 되었습니다.

앞에서 한 것처럼 다른 Pub/Sub 주제를 만듭니다.

gcloud pubsub topics create cre-gke-topic2

Cloud 콘솔에서 Cloud Run 서비스의 로그를 확인하면 수신된 이벤트가 표시됩니다.

트리거 및 주제 삭제

원하는 경우 테스트가 완료되면 트리거를 삭제할 수 있습니다.

gcloud beta events triggers delete trigger-auditlog

다음 주제도 삭제합니다.

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

13. Cloud Storage용 이벤트 트리거 만들기

Cloud Storage에서 이벤트를 리슨하도록 트리거를 설정합니다.

버킷 만들기

먼저 배포된 Cloud Run 서비스와 동일한 리전에 Cloud Storage 버킷을 만듭니다. 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/

Cloud Storage 권한 설정

트리거를 만들기 전에 Cloud Storage의 기본 서비스 계정에 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

트리거 만들기

이제 Cloud Storage 이벤트에 대한 이벤트 트리거를 만들 준비가 되었습니다.

트리거를 구성하는 데 필요한 매개변수에 대한 자세한 내용을 확인할 수 있습니다.

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분 정도 기다립니다. 준비되면 생성 이벤트를 필터링하고 서비스로 전송합니다.

이제 이벤트를 실행할 준비가 되었습니다.

Cloud Storage 버킷에 무작위 파일을 업로드합니다.

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

Cloud 콘솔에서 Cloud Run 서비스의 로그를 확인하면 수신된 이벤트가 표시됩니다.

트리거 삭제

원하는 경우 테스트가 완료되면 트리거를 삭제할 수 있습니다.

gcloud beta events triggers delete trigger-storage

14. Cloud Scheduler에 대한 이벤트 트리거 만들기

Cloud Scheduler에서 이벤트를 리슨하도록 트리거를 설정합니다.

App Engine 애플리케이션 만들기

현재 Cloud Scheduler를 사용하려면 App Engine 애플리케이션을 만들어야 합니다. App Engine 위치를 선택하고 앱을 만듭니다.

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

트리거 만들기

다음 명령어를 실행하여 Google Cloud 소스의 이벤트에 대한 트리거를 구성하는 데 필요한 매개변수에 대한 자세한 내용을 확인할 수 있습니다.

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

Cloud Scheduler 위치를 선택하여 스케줄러를 만듭니다.

export SCHEDULER_LOCATION=europe-west1

Google Cloud Scheduler에서 1분마다 실행되는 작업을 만들고 대상 서비스를 호출하는 트리거를 만듭니다.

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

트리거 생성이 전파되고 이벤트 필터링이 시작될 때까지 최대 10분 정도 기다립니다. 준비되면 생성 이벤트를 필터링하고 서비스로 전송합니다.

Cloud 콘솔에서 Cloud Run 서비스의 로그를 확인하면 수신된 이벤트가 표시됩니다.

트리거 삭제

원하는 경우 테스트가 완료되면 트리거를 삭제할 수 있습니다.

gcloud beta events triggers delete trigger-scheduler

15. 커스텀 이벤트 (브로커 엔드포인트)

Codelab의 이 부분에서는 브로커를 사용하여 맞춤 이벤트를 생성하고 사용합니다.

이벤트 생성을 위한 curl 포드 만들기

이벤트는 일반적으로 프로그래매틱 방식으로 생성됩니다. 하지만 이 단계에서는 curl를 사용하여 개별 이벤트를 수동으로 전송하고 이러한 이벤트가 올바른 소비자가 어떻게 수신하는지 확인합니다.

이벤트 제작자로 작동하는 포드를 만들려면 다음 명령어를 실행합니다.

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 포드가 올바르게 작동하는지 확인합니다. Status=Running가 포함된 curl라는 포드가 표시됩니다.

kubectl get pod curl -n ${NAMESPACE}

트리거 만들기

내보낼 특정 CloudEvents 유형 (이 경우 alpha-type)에 대한 필터로 트리거를 만듭니다. 개수에 상관없이 CloudEvents 속성과 확장 프로그램에 대한 일치검색 필터링이 지원됩니다. 필터가 여러 속성을 설정하는 경우 트리거에서 필터링하려면 이벤트에 모든 속성이 있어야 합니다. 반대로 필터를 지정하지 않으면 서비스에서 모든 이벤트가 수신됩니다.

트리거를 만듭니다.

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

트리거 테스트

모든 트리거를 나열하여 트리거가 성공적으로 생성되었는지 확인합니다.

gcloud beta events triggers list

브로커에 HTTP 요청을 전송하여 이벤트를 만듭니다. 다음을 실행하여 브로커 URL을 다시 확인합니다.

kubectl get brokers -n ${NAMESPACE}

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

SSH를 통해 앞에서 만든 curl 포드에 연결합니다.

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

16. 축하합니다.

축하합니다. Codelab을 완료했습니다.

학습한 내용

Cloud Run for Anthos 이벤트의 장기적 비전
Cloud Run for Anthos 이벤트의 현재 상태
Cloud Run 싱크 만들기
Cloud Pub/Sub에 대한 이벤트 트리거 만들기
감사 로그에 대한 이벤트 트리거 만들기
Cloud Storage용 이벤트 트리거 만들기
Cloud Scheduler에 대한 이벤트 트리거 만들기
맞춤 이벤트 생성 및 사용