Codelab "Eventos do Cloud Run for Anthos"

1. Introdução

6a5cf23c8e20491f.png

Com o Cloud Run, é possível executar contêineres sem estado em um ambiente totalmente gerenciado. Ele foi criado com base no Knative de código aberto, permitindo que você execute seus contêineres totalmente gerenciados com o Cloud Run ou no cluster do Google Kubernetes Engine com o Cloud Run for Anthos.

Com os Eventos do Cloud Run for Anthos, é fácil conectar serviços do Cloud Run a eventos de várias origens. Ele permite criar arquiteturas orientadas a eventos em que os microsserviços são distribuídos e têm acoplamento flexível. Ele também cuida da ingestão, entrega, segurança, autorização e tratamento de erros de eventos, o que melhora a agilidade do desenvolvedor e a resiliência do aplicativo.

Neste codelab, você vai aprender sobre o Events for Cloud Run for Anthos. Mais especificamente, você vai detectar eventos do Cloud Pub/Sub, dos registros de auditoria, do Cloud Storage e do Cloud Scheduler, além de aprender a produzir/consumir eventos personalizados.

O que você vai aprender

  • Visão de longo prazo dos eventos do Cloud Run for Anthos
  • Estado atual dos eventos do Cloud Run for Anthos
  • Criar um coletor do Cloud Run
  • Criar um gatilho de evento para o Cloud Pub/Sub
  • Criar um gatilho de evento para registros de auditoria
  • Criar um gatilho de evento para o Cloud Storage
  • Criar um gatilho de evento para o Cloud Scheduler
  • Produzir e consumir eventos personalizados

2. Visão de longo prazo

À medida que adotamos a arquitetura sem servidor, os eventos se tornam parte integrante da comunicação entre microsserviços desacoplados. O Events for Cloud Run for Anthos torna os eventos um elemento de primeira classe da oferta do Cloud Run for Anthos, facilitando a criação de aplicativos sem servidor orientados a eventos.

Com o Events for Cloud Run for Anthos, é possível fazer a entrega de eventos assíncronos confiável, segura e escalonável de origens de eventos empacotadas ou criadas por apps para consumidores no cluster e fora dele.

ce389bcafba6d669.png

Fontes do Google Cloud

Fontes de eventos que são produtos do Google Cloud

Fontes do Google

Fontes de eventos que são produtos do Google, como Gmail, Hangouts, Gerenciamento do Android e muito mais

Origens personalizadas

Fontes de eventos que não são produtos do Google e são criadas pelos próprios usuários finais. Podem ser fontes do Knative desenvolvidas pelo usuário ou qualquer outro app em execução no cluster que possa produzir um evento do Cloud.

Fontes de terceiros

Fontes de eventos que não são de propriedade do Google nem do usuário final. Isso inclui fontes de eventos conhecidas, como Github, SAP, Datadog, Pagerduty etc., que são de propriedade e mantidas por provedores terceirizados, parceiros ou comunidades de código aberto.

Os eventos são normalizados para o formato CloudEvents v1.0 para interoperabilidade entre serviços. O CloudEvents é uma especificação aberta independente de fornecedor que descreve dados de eventos em formatos comuns, permitindo a interoperabilidade entre serviços, plataformas e sistemas.

Os eventos para o Cloud Run estão em conformidade com o Knative Eventing e permitem a portabilidade de contêineres para e de outras implementações baseadas no Knative. Isso fornece uma estrutura consistente e independente da nuvem para conectar declarativamente produtores e consumidores de eventos.

3. Estado atual

Este pré-lançamento é a primeira versão que oferece um conjunto inicial de funcionalidades de longo prazo.

b1dd0d8a73185b95.png

Para permitir que os usuários criem aplicativos sem servidor orientados a eventos, nosso foco inicial é duplo:

  1. Oferecer um amplo ecossistema de fontes do Google Cloud que permite que os serviços do Cloud Run no cluster do Anthos reajam a eventos dos serviços do Google Cloud.
  • Inicialmente, os eventos das origens do Google Cloud são entregues por meio dos registros de auditoria do Cloud (CAL, na sigla em inglês), permitindo uma ampla variedade de origens de eventos. A latência e a disponibilidade da entrega de eventos dessas fontes estão vinculadas às dos registros de auditoria do Cloud. Sempre que um evento de uma origem do Google Cloud é publicado, uma entrada de registro de auditoria do Cloud correspondente é criada.
  • Além dos registros de auditoria do Cloud, há suporte de primeira classe para consumir eventos do Cloud Storage, do Cloud Pub/Sub e do Cloud Scheduler. Vamos continuar expandindo esse ecossistema de fontes com mais fontes de primeira classe à medida que aprendemos mais com as jornadas e o feedback dos usuários.
  1. Permitir que aplicativos e serviços do usuário final emitam eventos personalizados publicando em um URL de broker local do cluster com escopo de namespace.

O mecanismo de entrega usa tópicos e assinaturas do Cloud Pub/Sub que ficam visíveis nos projetos dos clientes. Portanto, o recurso oferece as mesmas garantias de entrega do Cloud Pub/Sub.

O gatilho de evento oferece uma maneira de assinar eventos para que aqueles que correspondem ao filtro de gatilho sejam entregues ao destino (ou coletor) indicado pelo gatilho.

Todos os eventos são entregues no formato Cloud Events v1.0 para interoperabilidade entre serviços.

Vamos continuar oferecendo mais valor de maneira iterativa até a disponibilidade geral e depois dela.

4. Configuração e requisitos

Configuração de ambiente autoguiada

  1. Faça login no console do Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.

96a9c957bc475304.png

b9a10ebdf5b5a448.png

a1e3c01a38fa61c2.png

  • O Nome do projeto é o nome de exibição do projeto. Desde que você siga as convenções de nomenclatura, é possível usar o que quiser e atualizar a qualquer momento.
  • O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser alterado após a definição. O console do Cloud gera automaticamente uma string exclusiva. Em geral, não importa o que seja. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, normalmente identificado como PROJECT_ID. Se você não gostar dele, crie outro aleatório ou tente usar um próprio para ver se ele está disponível. Em seguida, ele fica "congelado" depois que o projeto é criado.
  1. Em seguida, será necessário ativar o faturamento no Console do Cloud para usar os recursos do Google Cloud.

A execução deste codelab não será muito cara, se for o caso. Siga todas as instruções na seção "Limpeza", que orienta você sobre como encerrar recursos para não incorrer em cobranças além deste tutorial. Novos usuários do Google Cloud estão qualificados para o programa de US$300 de avaliação sem custos.

Inicie o Cloud Shell

Embora o Google Cloud e o Spanner possam ser operados remotamente do seu laptop, neste codelab usaremos o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.

No Console do GCP, clique no ícone do Cloud Shell na barra de ferramentas localizada no canto superior direito:

bce75f34b2c53987.png

O provisionamento e a conexão com o ambiente levarão apenas alguns instantes para serem concluídos: Quando o processamento for concluído, você verá algo como:

f6ef2b5f13479f3a.png

Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Todo o trabalho neste laboratório pode ser feito apenas com um navegador.

5. Ativar APIs, definir zona e plataforma

Configurar o ID do projeto e instalar componentes alfa

No Cloud Shell, GOOGLE_CLOUD_PROJECT já deve estar definido como o ID do projeto. Caso contrário, verifique se ele está definido e se o gcloud está configurado com esse ID do projeto:

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

Verifique se o componente gcloud para alpha está instalado:

gcloud components install alpha

Ativar APIs

Ative todos os serviços necessários:

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

Definir zona e plataforma

Antes de criar um cluster do GKE com o Cloud Run Events, defina o nome do cluster, a zona e a plataforma. Por exemplo, aqui definimos o nome e a zona como events-cluster e europe-west1-b, e a plataforma como gke,.

No Cloud Shell, faça o seguinte:

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

Para verificar se a configuração está definida:

gcloud config list

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

6. Criar um cluster do GKE com o Cloud Run Events

Crie um cluster do GKE executando o Kubernetes >= 1.15.9-gke.26 com os seguintes complementos ativados: 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. Configurar eventos do Cloud Run (plano de controle)

Os eventos do Cloud Run têm um plano de controle e um plano de dados que precisam ser configurados separadamente. Para configurar o plano de controle:

No Cloud Shell, faça o seguinte:

gcloud beta events init

Isso vai inicializar o envio de eventos e criar várias contas de serviço necessárias. Selecione "Sim" quando for solicitado a criar uma conta de serviço.

A esta altura, o plano de controle precisa estar inicializado corretamente. Você vai ver quatro pods com um

status Running, 2 (controller-xxx-xxx e webhook-xxx-xxx) no namespace cloud-run-events e 2 (eventing-controller-xxx-xxx e eventing-webhook-xxx-xxx) no namespace knative-eventing. Para verificar, execute os seguintes comandos:

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. Configurar eventos do Cloud Run (plano de dados)

Em seguida, configure o plano de dados nos namespaces do usuário. Isso cria um broker com as permissões adequadas para leitura/gravação do/no Pub/Sub.

No Cloud Shell, defina uma variável de ambiente NAMESPACE para o namespace que você quer usar nos seus objetos. Defina como default se quiser usar o namespace padrão, conforme mostrado abaixo:

export NAMESPACE=default

Se o namespace especificado não existir (ou seja, não for o padrão), crie-o:

kubectl create namespace ${NAMESPACE}

Para inicializar o namespace com o secret padrão:

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

Crie um agente padrão no namespace:

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

Verifique se o broker foi criado. Talvez leve alguns segundos até que o agente esteja pronto:

kubectl get broker -n ${NAMESPACE}

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

9. Descoberta de eventos

Você pode descobrir quais são as origens registradas, os tipos de eventos que elas podem emitir e como configurar acionadores para consumi-los.

Para ver a lista de diferentes tipos de eventos:

gcloud beta events types list

Para mais informações sobre cada tipo de evento:

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

10. Criar um coletor do Cloud Run

Como um gravador de eventos, implante um serviço do Cloud Run que registre o conteúdo do CloudEvent recebido.

Você pode usar o event_display do Knative, que já está compilado e tem a imagem do contêiner criada como parte do lançamento do Knative. Confira os detalhes da imagem do contêiner em event-display.yaml:

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

Implantar no Cloud Run

Implante um aplicativo conteinerizado no 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

Em caso de sucesso, a linha de comando exibe o URL de serviço. Agora você pode acessar o contêiner implantado abrindo o URL de serviço em qualquer janela do navegador.

11. Criar um gatilho de evento para o Cloud Pub/Sub

Uma forma de receber eventos é pelo Cloud Pub/Sub. Os aplicativos personalizados podem publicar mensagens no Cloud Pub/Sub, e essas mensagens podem ser entregues aos coletores do Google Cloud Run via Eventarc para Cloud Run.

Criar um tópico

Primeiro, crie um tópico do Cloud Pub/Sub. Você pode substituir TOPIC_ID por um nome de tópico exclusivo de sua preferência:

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

Criar um gatilho

Antes de criar o gatilho, confira mais detalhes sobre os parâmetros necessários para criar um gatilho para eventos do Cloud Pub/Sub:

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

Crie um gatilho para filtrar eventos publicados no tópico do Cloud Pub/Sub para o serviço do Cloud Run implantado:

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

Testar o gatilho

Para verificar se o gatilho foi criado, liste todos os gatilhos:

gcloud beta events triggers list

Talvez seja necessário aguardar até 10 minutos para que a criação do gatilho seja propagada e para que ele comece a filtrar eventos.

Para simular o envio de mensagens por um aplicativo personalizado, você pode usar gcloud para acionar um evento:

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

O coletor do Cloud Run que criamos registra o corpo da mensagem recebida. Você pode conferir isso na seção "Registros" da sua instância do Cloud Run:

9526909a06c6d4f4.png

A mensagem "Hello there" será codificada em base64 porque foi enviada pelo Pub/Sub. Você precisará decodificá-la se quiser ver a mensagem original.

Excluir o gatilho

Se quiser, exclua o gatilho depois de concluir o teste.

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

12. Criar um gatilho de evento para registros de auditoria

Você vai configurar um gatilho para detectar eventos dos registros de auditoria. Mais especificamente, você vai procurar eventos de criação de tópicos do Pub/Sub nos registros de auditoria.

Ativar os registro de auditoria

Para receber eventos de um serviço, é necessário ativar os registros de auditoria. No Console do Cloud, selecione IAM & Admin > Audit Logs no menu superior esquerdo. Na lista de serviços, marque o Google Cloud Pub/Sub:

97bd4b57c6a05fcc.png

À direita, verifique se as opções "Administrador", "Leitura" e "Gravação" estão selecionadas. Clique em "Salvar":

bec31b4f35fbcea.png

Testar registros de auditoria

Para aprender a identificar os parâmetros necessários para configurar um gatilho real e realizar uma operação real.

Por exemplo, crie um tópico do Pub/Sub:

gcloud pubsub topics create cre-gke-topic1

Agora, vamos ver que tipo de registro de auditoria essa atualização gerou. No Console do Cloud, selecione Logging > Logs Viewer no menu superior esquerdo.

Em Query Builder,, escolha Cloud Pub/Sub Topic e clique em Add:

f5c634057e935bc6.png

Depois de executar a consulta, você vai ver os registros dos tópicos do Pub/Sub. Um deles será google.pubsub.v1.Publisher.CreateTopic:

b083cce219773d24.png

Observe serviceName, methodName e resourceName. Vamos usar esses valores para criar o gatilho.

Criar um gatilho

Agora você já pode criar um gatilho de evento para registros de auditoria.

Para mais detalhes sobre os parâmetros necessários para criar um gatilho para eventos de fontes do Google Cloud, execute o seguinte comando:

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

Crie o gatilho com os filtros certos:

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

Testar o gatilho

Liste todos os gatilhos para confirmar que o gatilho foi criado com sucesso:

gcloud beta events triggers list

Aguarde até 10 minutos para que a criação do gatilho seja propagada e para que ele comece a filtrar eventos. Quando estiver pronto, ele vai filtrar os eventos de criação e enviá-los para o serviço. Agora você já pode disparar um evento.

Crie outro tópico do Pub/Sub, como fez antes:

gcloud pubsub topics create cre-gke-topic2

Se você verificar os registros do serviço do Cloud Run no Console do Cloud, verá o evento recebido:

aff3b2e7ad05c75d.png

Excluir o gatilho e os temas

Se quiser, exclua o gatilho depois de concluir o teste:

gcloud beta events triggers delete trigger-auditlog

Exclua também os tópicos:

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

13. Criar um gatilho de evento para o Cloud Storage

Você vai configurar um gatilho para detectar eventos do Cloud Storage.

Crie um bucket

Primeiro, crie um bucket do Cloud Storage na mesma região do serviço do Cloud Run implantado. Você pode substituir BUCKET_NAME por um nome exclusivo de sua preferência:

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

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

Configurar permissões do Cloud Storage

Antes de criar um gatilho, conceda à conta de serviço padrão do Cloud Storage permissão para publicar no Pub/Sub.

Primeiro, encontre a conta de serviço que o Cloud Storage usa para publicar no Pub/Sub. Siga as etapas descritas em Como acessar a conta de serviço do Cloud Storage ou use o seguinte comando:

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

A conta de serviço vai aparecer em email_address.

Suponha que a conta de serviço encontrada acima seja service-XYZ@gs-project-accounts.iam.gserviceaccount.com e defina isso como uma variável de ambiente:

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

Em seguida, conceda direitos a essa conta de serviço para publicar no Pub/Sub:

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

Criar um gatilho

Agora você já pode criar um gatilho de evento para eventos do Cloud Storage.

Confira mais detalhes sobre os parâmetros necessários para criar o gatilho:

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

Crie o gatilho com os filtros certos:

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

Testar o gatilho

Liste todos os gatilhos para confirmar que o gatilho foi criado com sucesso:

gcloud beta events triggers list

Aguarde até 10 minutos para que a criação do gatilho seja propagada e para que ele comece a filtrar eventos. Quando estiver pronto, ele vai filtrar os eventos de criação e enviá-los para o serviço.

Agora você já pode disparar um evento.

Faça upload de um arquivo aleatório para o bucket do Cloud Storage:

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

Se você verificar os registros do serviço do Cloud Run no Console do Cloud, verá o evento recebido:

aff3b2e7ad05c75d.png

Excluir o gatilho

Se quiser, exclua o gatilho depois de concluir o teste:

gcloud beta events triggers delete trigger-storage

14. Criar um gatilho de evento para o Cloud Scheduler

Você vai configurar um gatilho para detectar eventos do Cloud Scheduler.

Criar um aplicativo do App Engine

No momento, o Cloud Scheduler exige que os usuários criem um aplicativo do App Engine. Escolha um local do App Engine e crie o app:

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

Criar um gatilho

Para mais detalhes sobre os parâmetros necessários para criar um gatilho para eventos de fontes do Google Cloud, execute o seguinte comando:

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

Escolha um local do Cloud Scheduler para criar o programador:

export SCHEDULER_LOCATION=europe-west1

Crie um gatilho que vai criar um job para ser executado a cada minuto no Cloud Scheduler do Google Cloud e chamar o serviço de destino:

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"

Testar o gatilho

Liste todos os gatilhos para confirmar que o gatilho foi criado com sucesso:

gcloud beta events triggers list

Aguarde até 10 minutos para que a criação do gatilho seja propagada e para que ele comece a filtrar eventos. Quando estiver pronto, ele vai filtrar os eventos de criação e enviá-los para o serviço.

Se você verificar os registros do serviço do Cloud Run no Console do Cloud, o evento recebido vai aparecer.

Excluir o gatilho

Se quiser, exclua o gatilho depois de concluir o teste:

gcloud beta events triggers delete trigger-scheduler

15. Eventos personalizados (endpoint do broker)

Nesta parte do codelab, você vai produzir e consumir eventos personalizados usando o Broker.

Criar um pod Curl para gerar eventos

Os eventos geralmente são criados de forma programática. No entanto, nesta etapa, você vai usar curl para enviar manualmente eventos individuais e ver como eles são recebidos pelo consumidor correto.

Para criar um pod que atua como produtor de eventos, execute o seguinte comando:

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

Verifique se o pod curl está funcionando corretamente. Você vai ver um pod chamado curl com Status=Running:

kubectl get pod curl -n ${NAMESPACE}

Criar um gatilho

Você vai criar um gatilho com um filtro no tipo de CloudEvents específico (neste caso, alpha-type) que será emitido. A filtragem de correspondência exata para qualquer número de atributos do CloudEvents e extensões é compatível. Se o filtro definir vários atributos, um evento precisará ter todos eles para que o gatilho possa filtrá-lo. Por outro lado, se você não especificar um filtro, todos os eventos serão recebidos no seu serviço.

Crie o gatilho:

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

Testar o gatilho

Liste todos os gatilhos para confirmar que o gatilho foi criado com sucesso:

gcloud beta events triggers list

Crie um evento enviando uma solicitação HTTP para o Broker. Para lembrar o URL do broker, execute o seguinte:

kubectl get brokers -n ${NAMESPACE}

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

Use SSH para acessar o pod curl criado anteriormente:

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

Você fez SSH no pod e agora pode fazer uma solicitação HTTP. Uma solicitação semelhante à seguinte vai aparecer:

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:/ ]$

Crie um evento:

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"}'

Se o evento tiver sido recebido, você vai receber uma resposta HTTP 202 Accepted. Saia da sessão SSH com Ctrl + D

Verifique se o evento publicado foi enviado observando os registros do serviço do Cloud Run:

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

Excluir o gatilho

Se quiser, exclua o gatilho depois de concluir o teste:

gcloud beta events triggers delete trigger-custom

16. Parabéns!

Parabéns por concluir o codelab.

O que aprendemos

  • Visão de longo prazo dos eventos do Cloud Run for Anthos
  • Estado atual dos eventos do Cloud Run for Anthos
  • Criar um coletor do Cloud Run
  • Criar um gatilho de evento para o Cloud Pub/Sub
  • Criar um gatilho de evento para registros de auditoria
  • Criar um gatilho de evento para o Cloud Storage
  • Criar um gatilho de evento para o Cloud Scheduler
  • Produzir e consumir eventos personalizados