Эта страница переведена с помощью Cloud Translation API.

События для Cloud Run для Anthos Codelab

1. Введение

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.
Создание и использование пользовательских событий

2. Долгосрочное видение

Когда мы внедряем бессерверную архитектуру, события становятся неотъемлемой частью взаимодействия разобщенных микросервисов. Events for Cloud Run for Anthos делает события первоклассным элементом предложения Cloud Run for Anthos, что упрощает создание бессерверных приложений, управляемых событиями.

Events for Cloud Run for Anthos обеспечивает надежную, безопасную и масштабируемую асинхронную доставку событий из упакованных или созданных приложением источников событий потребителям в кластере и за его пределами.

Источники Google Cloud	Источники событий, являющиеся продуктами Google Cloud.
Источники Google	Источниками событий являются продукты, принадлежащие Google, такие как Gmail, Hangouts, Android Management и другие.
Пользовательские источники	Источники событий, которые не являются продуктами Google и создаются самими конечными пользователями. Это могут быть разработанные пользователем Knative Sources или любое другое приложение, работающее в кластере, которое может создавать облачные события.
Сторонние источники	Источники событий, которые не принадлежат ни Google, ни конечному пользователю. Сюда входят популярные источники событий, такие как Github, SAP, Datadog, Pagerduty и т. д., которые принадлежат и обслуживаются сторонними поставщиками, партнерами или сообществами OSS.

События нормализуются в формате CloudEvents v1.0 для обеспечения совместимости между сервисами. CloudEvents — это независимая от поставщика открытая спецификация, описывающая данные о событиях в общих форматах, обеспечивающая совместимость между сервисами, платформами и системами.

Events for Cloud Run совместим с Knative Eventing и обеспечивает переносимость контейнеров в другие реализации на базе Knative и обратно. Это обеспечивает согласованную, не зависящую от облака структуру для декларативного связывания производителей событий с потребителями событий.

3. Текущее состояние

Эта предварительная версия является первой версией, которая предоставляет начальный набор долгосрочных функций.

Чтобы дать пользователям возможность создавать бессерверные приложения, управляемые событиями, наша первоначальная задача состоит в двух аспектах:

Предоставьте широкую экосистему источников Google Cloud, которая позволит службам Cloud Run в кластере Anthos реагировать на события из служб Google Cloud.

Вначале события из источников Google Cloud передаются через журналы облачного аудита (CAL), что обеспечивает широкий спектр источников событий. Задержка и доступность доставки событий из этих источников привязаны к журналам облачного аудита. Всякий раз, когда публикуется событие из источника Google Cloud, создается соответствующая запись в журнале аудита облака.
Наряду с журналами облачного аудита имеется первоклассная поддержка для использования событий из Cloud Storage, Cloud Pub/Sub и Cloud Scheduler. Мы продолжим расширять эту экосистему источников, добавляя больше первоклассных источников по мере того, как мы узнаем больше из опыта пользователей и отзывов.

Разрешите приложениям и службам конечных пользователей генерировать пользовательские события путем публикации на локальном URL-адресе брокера в области пространства имен кластера.

Базовый механизм доставки использует темы и подписки Cloud Pub/Sub, которые видны в проектах клиентов. Следовательно, эта функция обеспечивает те же гарантии доставки, что и Cloud Pub/Sub.

Триггер событий предоставляет способ подписки на события, чтобы события, соответствующие фильтру триггера, доставлялись в пункт назначения (или приемник), на который указывает триггер.

Все события доставляются в формате Cloud Events v1.0 для обеспечения совместимости между сервисами.

Мы продолжим итеративно приносить больше пользы, вплоть до общедоступной версии и за ее пределами.

4. Настройка и требования

Самостоятельная настройка среды

Войдите в Cloud Console и создайте новый проект или повторно используйте существующий. Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .

Имя проекта — это ваше отображаемое имя для этого проекта. Если вы соблюдаете соглашения об именах, вы можете использовать все, что захотите, и обновлять его в любое время.
Идентификатор проекта должен быть уникальным для всех проектов Google Cloud и неизменяемым (нельзя изменить после установки). Консоль Cloud автоматически генерирует уникальную строку; обычно тебя не волнует, что это такое. В большинстве лабораторий кода вам потребуется указать идентификатор проекта (обычно он обозначается как PROJECT_ID ), поэтому, если он вам не нравится, создайте другой случайный идентификатор или попробуйте свой собственный и посмотрите, доступен ли он. Затем он «замораживается» после создания проекта.

Далее вам необходимо включить биллинг в Cloud Console, чтобы использовать ресурсы Google Cloud.

Прохождение этой лаборатории кода не должно стоить много, если вообще стоит. Обязательно следуйте всем инструкциям в разделе «Очистка», в которых рассказывается, как отключить ресурсы, чтобы вам не приходилось нести расходы, выходящие за рамки этого руководства. Новые пользователи Google Cloud имеют право на участие в программе бесплатной пробной версии стоимостью 300 долларов США .

Запустить Cloud Shell

Хотя Google Cloud можно управлять удаленно с вашего ноутбука, в этой лаборатории вы будете использовать Google Cloud Shell , среду командной строки, работающую в облаке.

В консоли GCP щелкните значок Cloud Shell на верхней правой панели инструментов:

Подготовка и подключение к среде займет всего несколько минут. Когда все будет готово, вы должны увидеть что-то вроде этого:

Эта виртуальная машина оснащена всеми необходимыми инструментами разработки. Он предлагает постоянный домашний каталог объемом 5 ГБ и работает в Google Cloud, что значительно повышает производительность сети и аутентификацию. Всю работу в этой лабораторной работе можно выполнять с помощью простого браузера.

5. Включите 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,

В 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. Создайте кластер GKE с событиями Cloud Run.

Создайте кластер 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

7. Настройка событий запуска облака (плоскость управления)

У событий Cloud Run есть плоскость управления и плоскость данных, которые необходимо настраивать отдельно. Чтобы настроить плоскость управления:

В Cloud Shell:

gcloud beta events init

Это инициализирует обработку событий, а также создаст необходимое количество учетных записей служб. Обязательно выберите «Да», когда будет предложено создать учетную запись службы.

На этом этапе плоскость управления должна быть правильно инициализирована. Вы должны увидеть четыре капсулы с

Статус Running : 2 ( controller-xxx-xxx и webhook-xxx-xxx ) в пространстве имен cloud-run-events и 2 ( 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

8. Настройка событий запуска облака (плоскость данных)

Далее необходимо настроить плоскость данных в пространствах имен пользователей. При этом создается брокер с соответствующими разрешениями на чтение/запись из/в 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

В качестве приемника событий разверните службу 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-адрес службы в любом окне браузера.

11. Создайте триггер события для Cloud Pub/Sub.

Один из способов получения событий — через Cloud Pub/Sub. Пользовательские приложения могут публиковать сообщения в Cloud Pub/Sub, и эти сообщения можно доставлять в приемники Google Cloud Run через Events for 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» будет закодировано в формате Base64, как оно было отправлено Pub/Sub, и вам придется его декодировать, если вы хотите увидеть отправленное исходное сообщение.

Удалить триггер

При желании вы можете удалить триггер после завершения тестирования.

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

12. Создайте триггер событий для журналов аудита.

Вы настроите триггер для прослушивания событий из журналов аудита. В частности, вы будете искать события создания тем Pub/Sub в журналах аудита.

Включить журналы аудита

Чтобы получать события от службы, вам необходимо включить журналы аудита. В Cloud Console выберите IAM & Admin > Audit Logs в верхнем левом меню. В списке сервисов отметьте Google Cloud Pub/Sub:

С правой стороны убедитесь, что выбраны «Администратор», «Чтение» и «Запись». Нажмите «Сохранить»:

Журналы тестового аудита

Чтобы узнать, как определить параметры, необходимые для настройки фактического триггера, выполните реальную операцию.

Например, создайте тему 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 . Мы будем использовать их при создании триггера.

Создать триггер

Теперь вы готовы создать триггер событий для журналов аудита.

Вы можете получить более подробную информацию о параметрах, которые вам понадобятся для создания триггера для событий из источников 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 Run в Cloud Console, вы должны увидеть полученное событие:

Удалить триггер и темы

При желании вы можете удалить триггер после завершения тестирования:

gcloud beta events triggers delete trigger-auditlog

Также удалите темы:

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

13. Создайте триггер события для облачного хранилища.

Вы настроите триггер для прослушивания событий из Cloud Storage.

Создать сегмент

Сначала создайте сегмент Cloud Storage в том же регионе, где находится развернутый сервис 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/

Настройка разрешений облачного хранилища

Прежде чем создавать триггер, вам необходимо предоставить учетной записи службы по умолчанию для 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 Run в Cloud Console, вы должны увидеть полученное событие:

Удалить триггер

При желании вы можете удалить триггер после завершения тестирования:

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}

Создать триггер

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

Выберите местоположение облачного планировщика, чтобы создать планировщик:

export SCHEDULER_LOCATION=europe-west1

Создайте триггер, который будет создавать задание, которое будет выполняться каждую минуту в 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

15. Пользовательские события (конечная точка брокера)

В этой части лабораторной работы вы будете создавать и использовать пользовательские события с помощью Broker.

Создайте модуль 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 Pod работает правильно. Вы должны увидеть модуль под названием curl со Status=Running :

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 . Выйдите из сеанса SSH с помощью Ctrl + D

Убедитесь, что опубликованное событие было отправлено, просмотрев журналы Cloud Run Service:

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

Удалить триггер

При желании вы можете удалить триггер после завершения тестирования:

gcloud beta events triggers delete trigger-custom

16. Поздравляем!

Поздравляем с завершением работы над кодом.

Что мы рассмотрели

Долгосрочное видение событий Cloud Run для Anthos
Текущее состояние событий для Cloud Run для Anthos
Создайте приемник Cloud Run
Создайте триггер события для Cloud Pub/Sub.
Создайте триггер событий для журналов аудита.
Создайте триггер события для облачного хранилища.
Создайте триггер событий для Cloud Scheduler.
Создание и использование пользовательских событий